An important thing to emerge from the GNU project has been the GNU Public License (GPL). This license explicitly states that the software being released is free and that no one can ever take away these freedoms. It is acceptable to take the software and resell it, even for a profit; however, in this resale, the seller must release the full source code, including any changes. Because the resold package remains under the GPL, the package can be distributed for free and resold yet again by anyone else for a profit. Of primary importance is the liability clause: The programmers are not liable for any damages caused by their software.
It should be noted that the GPL is not the only license used by open source software developers (although it is arguably the most popular). Other licenses, such as BSD and Apache, have similar liability clauses but differ in terms of their redistribution. For instance, the BSD license allows people to make changes to the code and ship those changes without having to disclose the added code. (The GPL would require that the added code be shipped.) For more information about other open source licenses, check out www.opensource.org.
If the GPL seems like a bad idea from the standpoint of commercialism, consider the surge of successful open source software projects—they are indicative of a system that does indeed work. This success has evolved for two reasons. First, as mentioned earlier, errors in the code itself are far more likely to be caught and quickly fixed under the watchful eyes of peers. Second, under the GPL system, programmers can release code without the fear of being sued. Without that protection, people may not feel as comfortable to release their code for public consumption.
Most projects don’t start out as full-featured, polished pieces of work. They may begin life as a quick hack to solve a specific problem bothering the programmer at the time. As a quick-and-dirty hack, the code may not have a sales value. But when this code is shared and consequently improved upon by others who have similar problems and needs, it becomes a useful tool. Other program users begin to enhance it with features they need, and these additions travel back to the original program. The project thus evolves as the result of a group effort and eventually reaches full refinement. This polished program may contain contributions from possibly hundreds, if not thousands, of programmers who have added little pieces here and there. In fact, the original author’s code is likely to be little in evidence.
There’s another reason for the success of generally licensed software. Any project manager who has worked on commercial software knows that the real cost of development software isn’t in the development phase. It’s in the cost of selling, marketing, supporting, documenting, packaging, and shipping that software. A programmer carrying out a weekend hack to fix a problem with a tiny, kludged program may lack the interest, time, and money to turn that hack into a profitable product.
When Linus Torvalds released Linux in 1991, he released it under the GPL. As a result of its open charter, Linux has had a notable number of contributors and analyzers. This participation has made Linux strong and rich in features. Torvalds himself estimates that since the v.2.2.0 kernel, his contributions represent only 5 percent of the total code base. Since anyone can take the Linux kernel (and other supporting programs), repackage them, and resell them, some people have made money with Linux. As long as these individuals release the kernel’s full source code along with their individual packages, and as long as the packages are protected under the GPL, everything is legal. Of course, this means that packages released under the GPL can be resold by other people under other names for a profit.
In the end, what makes a package from one person more valuable than a package from another person are the value-added features, support channels, and documentation. Even IBM can agree to this; it’s how they made most of their money from 1930 to 1970, and now in the late 1990s and early 2000s with IBM Global Services. The money isn’t necessarily in the product alone; it can also be in the services that go with it.
