Understanding Open Source and Free Software Licensing

Forking

By maintaining its own Apache development as an open development project, IBM avoided creating a fork. Forking occurs whenever a software project splits. While the two versions may remain entirely or partially compatible for some period of time, inevitably the unique (and now distinct) histories of each one's development will push them apart.

Forks can happen for many different reasons and may have entirely healthy consequences. A very simple piece of code may be developed by a group of programmers to do, for example, packet-switching. One half of the group may decide to follow a development tree leading toward making the simple packet-switching program into a complex database, and the other half may want to make the same program into a video-on-demand server for use in cable television systems. Such forks can occur without rancor and without any real concern for duplicative or unnecessary programming; the two future developments are so starkly different that mutual compatibility is of no concern.

Forks in more mature projects, however, are much more capable of producing undesirable results. For example, in 1993, the GNU Emacs project forked. Jamie Zawinski led a group of other developers on a line separate from that of Emacs' creator Richard Stallman and the GNU project. In part, this fork was driven by real differences as to the best course of future development for Emacs, but it also may have been the result of personality conflicts and concerns with the progress of Emacs development. Some felt that Stallman was relying too much on his own efforts and those of other programmers from the GNU project, thereby slowing development of Emacs. The fork was successful in the sense that two Emacs development projects resulted; as of this writing, both projects are continuing with no indication that this fork will ever close.

Forks in mature projects are properly feared. In addition to creating hard feelings, such forks undermine the foundation of the open development process. They split the user base as well as the programmers that contribute to the project. Given the importance of users to open development, this is a result to be avoided. While two open development projects may remain sufficiently similar for some period of time that modifications and bug patches can be ported from one project to another, at some point, the developments will have diverged sufficiently such that porting a solution from a competing project is no easier than developing that same solution from scratch. This duplication of effort and division of the development community for what, after all, are likely to be two very similar programs, argues strongly against such a fork, except under exceptional circumstances.

Given the serious consequences of forking, it is not unreasonable to look to licenses to prevent or at least to decrease the probability of such forks. While no open source or free software license is fork-proof, they do provide varying levels of protection against such forks.^[11] Some licenses, such as the Apache and Perl Licenses, rely largely on the reputation of the project developers to avoid forks, but they also include some terms that shore up that defense against forks. Other licenses, such as the GPL, at least hinder forking by requiring that developers distribute or modify the licensed code only under "open development" terms. However, by permitting non-open development of code developed under them, code licensed under the MIT or the BSD License may be more prone to forking than code licensed under other licenses.

The network security program Kerberos was released under a variation of the X license that operates substantially like the MIT and BSD licenses. As described in Chapter 2, Microsoft adopted Kerberos and implemented it in its Windows 2000 (and subsequent) operating systems in a version that contained proprietary extensions for communicating with Microsoft servers. This was a fork in that because of these extensions, Microsoft's version of Kerberos is on a separate development plane than the MIT-distributed version of Kerberos and will likely continue to develop more proprietary extensions as Microsoft expands it. This was the result of the use of the X license, which has no terms that would prevent this development.

As described in Chapter 2, the Apache License does not prevent the incorporation of its code into code licensed under another license, including a proprietary license. The Apache license does, however, include provisions protecting the Apache name. Specifically, the Apache license, Version 1.1 (as well as Version 2.0), prevents the use of the name Apache in connection with the work being distributed without permission, through Sections 4 and 5.

4. The names "Apache" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [e-mail].

5. Products derived from this software may not be called "Apache" nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation.

Through this relatively simple device, maintaining a monopoly over the name—if not the licensed code—and maintaining a dynamic high quality distribution, the Apache Software Foundation has remained as the center of Apache development and avoided any forks of consequence.

A similar strategy works in the Artistic License that applies to Perl. As described in Chapter 4, the Artistic License defines both a Copyright Holder and a Standard Version of the program. Contributors to a program so licensed must either permit their modifications to be incorporated into the Standard Version, abstain from public distributions of their version of the work, or clearly document the changes in their version. While forking is possible under this license, the likelihood that any such fork would create a major competitor to the Standard Version is substantially reduced. Indeed, these provisions of the license—along with the steadfast commitment to Perl of its creator, Larry Wall, and his reputation in open source and free software development—have prevented any significant forks from developing in Perl to date.

The GNU GPL limits the likelihood of forks by prohibiting non-open development models for projects that incorporate GPL-licensed code. Every development project under the GPL can accordingly draw freely from every other project. After a fork of a GPL project, each leg of the project remains free to draw on the work of the other—to the extent such work may be available^[12]—a process that may hasten the closing of such a fork and permit the reunification of the forked project. This is obviously not foolproof, as seen in the example of GNU Emacs.

Accordingly, while the choice of license certainly can have some effect on preventing forks, the nature of the open development model is conducive to forking. Permitting open access to source code and encouraging development by outsiders both allows for and creates incentives for the development of forks. Addressing forks is less a question of adopting the proper license, as any open source or free software license permits forking in some way, and is more a question of project development.

---

^[11] Proprietary licenses are unforkable. There is no development by anyone other than the licensor and accordingly no possible foundation for a fork. Licenses such as the Sun Community Source License, while not open source licenses, head off forking by designating an official version by compliance testing and by prohibiting the commercial distribution of other versions.

^[12] While the GPL requires that code derived from GPL-licensed code also be distributed under the GPL, a developer can avoid "sharing" the code she has developed by simply not distributing it.