oreilly.comSafari Books Online.Conferences.


What Is Free Software
Pages: 1, 2, 3

The GNU General Public License

He did this not only by writing code--though he wrote a lot, some of it quite good and widely used--but also by devising a copyright license whose terms guaranteed that his code would be perpetually free. The result, the GNU General Public License (GPL), is a clever piece of legal judo. It says that the code may be copied and modified without restriction, but that both copies and derivative works (that is, modified versions) must be distributed under the same license as the original, with no additional restrictions.

The GPL thus uses copyright law to achieve an effect opposite that of traditional copyright: instead of limiting the software's distribution, it prevents anyone, even the author or copyright holder, from limiting it. For Stallman, this was better than simply putting his code into the public domain. If it were in the public domain, any particular copy of it could be incorporated into a proprietary program.

While such incorporation wouldn't diminish the original code's continued availability, it would mean that Stallman's efforts could benefit the enemy--proprietary software. The GPL is a form of protectionism for free software: it prevents nonfree programs from taking advantage of any GPL'd code, while allowing all GPL'd programs to cooperate among themselves by sharing unrestrictedly.

The Rise of Open Collaboration

In some ways, Stallman's plan succeeded wildly. By means of the GPL and other writings, such as The GNU Manifesto, he put free software on the map as a political concept--even programmers who disagreed with the FSF's position still had to acknowledge and consider it. And Stallman eventually got the wholly free operating system he wanted, though many pieces were contributed by people not affiliated with the Free Software Foundation.

But in other ways, his original goal was overshadowed by the sheer technical success of collaborative programming under open copyright, an activity that was never the exclusive province of the FSF. Many others were doing it, and while less ideologically motivated than Stallman and the FSF, they were just as good at shipping code.

For example, the Berkeley Software Distribution (BSD), a gradual reimplementation of AT&T's Unix operating system, did not make overt political statements about the need for programmers to band together and share with one another. But the BSD group certainly knew how to do it in practice: they coordinated a massive distributed development effort, in which the Unix command-line utilities and code libraries, and eventually the operating system kernel itself, were rewritten from scratch mostly by volunteers. The BSD project released its code under a license very similar to the GPL, but without the clause insisting that all derivative works must be under the same license. Thus BSD code could be incorporated into proprietary systems, although of course that didn't detract from the freedom of the original code.

This separation of ideology from practice turned out to be one of the most important developments in free software in the late 1980s and early 1990s. It turned out that many programmers were happy to contribute their time to free software projects even when they didn't have a strong philosophical commitment to source code freedom. Programmers by nature hate duplicated effort, and if there's one thing free software is good at, it's avoidance of duplicated effort. When two programmers need to solve the same problem and there's no marketing or business reason for them to keep their work private, their instinct is to join forces, even if they've never met. What the free software movement did was create a standard framework for this sort of spontaneous collaboration. Programmers learned how to use computer networks to organize loosely knit groups of volunteers into functioning meritocracies, how to make projects inviting to both software developers and users, how to make decisions collectively, and how to handle conflicts between people who only know each other online.

Open copyright was crucial to the development of this system. Although free software licenses differ in some minor details, they all do basically the same thing: they prevent power monopolies in software projects, by giving any disaffected party the right to copy the code and take it in a new direction. In free software, this is known as forking: one copy continues along the original path, while another takes a different "fork" in the road. Most projects manage to avoid forks, but this is precisely because the implicit threat of a fork moderates everyone's behavior. Every participant knows that the only force holding things together is people's shared belief that they are better off working together than separately. Even a highly opinionated programmer will suddenly be motivated to compromise when the alternative is to go it alone.

The Free Software Foundation played a large role in developing this culture. It developed coding and documentation standards, and provided infrastructure support, such as mailing lists and file-sharing servers, for certain important projects. It also released some very useful programming tools as free software, which helped give the nascent community technical standards to organize around. But the FSF was by no means the only agent. Many people collaborated independently of the FSF, and there was a tremendous amount of cross-pollination between FSF and non-FSF projects.

While not all programmers agreed that all software should be free all the time, it became a cultural norm to put ideology aside and work together when there was code to be written. This norm arose because no individual participant's ideology could affect the freedom of the code anyway. Code written under a free license stays free, no matter what its various authors may think of software freedom in general. You may not always see eye to eye with your neighbor on economic policy, but if you both agree that the street outside needs plowing, then sharing the cost of a snowplow makes sense.

The difference between the two kinds of licenses--ones such as the GPL, which prohibit proprietary derivative works, and ones such as the BSD license, which allow them--thus turned out to not matter very much, at least as far as making software was concerned. Programmers who were willing to volunteer their time to work on free code at all generally didn't seem to care whether that code's license allowed proprietary derivative works. Some cared, of course, but for most, the decisive factor was the software's functionality. As long as the license allowed the basic freedoms necessary for unrestricted development and forking, it didn't matter if that license also permitted proprietary derivative versions.

Pages: 1, 2, 3

Next Pagearrow

Sponsored by: