In the early 1980s, Richard Stallman began a movement within the software industry. He
preached (and still does) that software should be free. Note that by free, he doesn’t mean
in terms of price, but rather free in the same sense as freedom. This meant shipping not
just a product, but the entire source code as well.
Stallman’s policy was, somewhat ironically, a return to classic computing, when software
was freely shared among hobbyists on small computers and given as part of the
hardware by mainframe and minicomputer vendors. (It was not until the late 1960s that
IBM considered selling application software. Through the 1950s and most of the 1960s,
they considered software merely a tool for enabling the sale of hardware.)
This return to openness was a wild departure from the early 1980s convention of selling
prepackaged software, but Stallman’s concept of open-source software was in line
with the initial distributions of UNIX from Bell Labs. Early UNIX systems did contain
full source code. Yet by the late 1970s, source code was typically removed from UNIX
distributions and could be acquired only by paying large sums of money to AT&T (now
SBC). The Berkeley Software Distribution (BSD) maintained a free version, but its commercial counterpart, BSDi, had to deal with many lawsuits from AT&T until it could be
proved that nothing in the BSD kernel was from AT&T.
The idea of giving away source code is a simple one: A user of the software should
never be forced to deal with a developer who might or might not support that user’s
intentions for the software. The user should never have to wait for bug fixes to be
published. More importantly, code developed under the scrutiny of other programmers
is typically of higher quality than code written behind locked doors. The greatest benefit of open source software, however, comes from the users themselves: Should they need
a new feature, they can add it to the original program and then contribute it back to the
source so that everyone else can benefit from it.
This line of thinking sprung a desire to release a complete UNIX-like system to the
public, free of license restrictions. Of course, before you can build any operating system,
you need to build tools. And this is how the GNU project was born.
What Is the GNU Public License?
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
THE ADVANTAGES OF OPEN SOURCE SOFTWARE
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.