If everyone took Richard Stallman’s advice or followed Linus Torvalds’s example and used the GNU GPL, there would be fewer licensing problems. We will learn in this chapter that one complaint against the GNU GPL (and the BSD) licenses — possibility of forking — may actually be a virtue instead of a fault. Beyond the GNU GPL we will look at what happens when developers start choosing different software with different licenses and mixing them together.
Forking is a natural process in Open Source software development. Because each user receives source code and is free to make alterations, it is only natural that the theoretical number of versions of a product could approach the number of developers who receive it. Accordingly, there is one camp that believes that every bug fix and every improvement is a potential fork, and remains unworried by the process. Developers who are unsatisfied with the way Linux works can devise patches to change its behavior, and freely circulate those patches. Until accepted by Linus Torvalds and his inner circle for inclusion into the kernel, this may be the only way these versions circulate, unless someone chooses to compile a kernel with those patches, and distribute that instead.
On the other hand, there are those who worry that Linux may be heading toward the same forking that sapped the strength of UNIX, and that eventually we will have as many flavors of Linux as we have of UNIX. This fragmentation turned UNIX from a promising universal operating system to a series of niche markets. The UNIX flavors originated in the tweaking of the code by hardware manufacturers to obtain the fastest and most efficient performance of UNIX on their own hardware; to fight off commoditization, the various vendors also added what they hoped were distinctive features and insisted that their enhanced versions were superior to the products of competitors. Software interoperability was not an issue. The point of the exercise was to lock in customers to a particular hardware vendor; software was just one means to that end.
Today some worry that the various Linux distributions will head down this same trail and eventually cause customers to pick a particular distribution not only because it is the "leading brand," but also because all the application vendors are trying to maximize sales by optimizing their code to run on this leading brand, putting the other distributions even further behind in the race for market share. To counter this possibility, the new Free Standards Group (recently formed from the Linux Standard Base initiative and the Linux Internationalization Initiative) seeks to define a common Linux base that all distributions will undertake to implement in the same manner, thus preserving software compatibility while allowing some distinctive features among distributions.
To better judge whether Linux is approaching the dreaded fork in its road, we need to know a little more about why projects fork in the first place. The reason most commonly given is politics among developers.
An Open Source project is a voluntary association based on mutual respect for coding prowess, and a developer is free to leave at any time. It goes to say that only a sensitive but disciplined leader can hold a group together for any length of time. The leader can fail the group in only one way: lack of responsiveness to those led. This lack of responsiveness can take two forms. One is the failure to respond personally to the followers in a satisfactory fashion; "personality differences" is a common reason given for the forking of a project. A more important response failure — and probably the cause of the majority of forks — is that the leader does not take a project technically where the followers want it to go, that is, does not satisfy the technical reasons they are working on the software in the first place. Because technical motivation is the large motor for joining a project, technical motivation is a sufficient reason for forking it.
It is perfectly possible for developers to voluntarily join or resign from a project. To be a real member, of course, you need to be a contributor of useful code. But if the leadership will not listen to your ideas and adopt your code, you are free to march off and begin your own version of the project. Whether you attract anyone to join you is a matter of how good and useful the results of your fork are. GNU EMACS, for instance, remains a command-line tool; those who wanted an Intel graphics version eventually left EMACS and formed the project resulting in XEmacs.
To state that forking occurs because the license permits it is to repeat the reason given above: because you can. The BSD-type licenses permit a developer to accept the source code, modify it, and distribute a compiled version, keeping the changes proprietary. As a result, BSD comes in several versions. Linux so far has not forked.
As an exercise, we can undertake a Unified Field Theory of Forking (see Figure 7-1). While it is not perfect, it provides a useful means of examining some of the licenses and forking phenomena around us.
Examining licenses and forking phenomena
Arrange the various licenses on a two-dimensional grid that measures Free Software versus proprietary software on the horizontal scale, and tendency to fork (or experience of forking) on the vertical scale. On the lower right-hand side, we see that proprietary software such as Microsoft Office is not likely to fork since the source code is unavailable. Shareware may be more freely distributable, but shareware developers keep their hands on the source code. One example of "Not for Commercial Use" software is Aladdin's Ghostscript. The Aladdin Free Public License makes the source code available and distributable with modifications, but commercial distribution is prohibited. Effectively the improvements come from a single source, the copyright holder. There is hardly a forking tendency here.
If we look at the top of the vertical scale, we see BSD with the highest forking tendency (and experience). It sits on the borderline between Free and Proprietary because its source code is freely available, but may be modified and redistributed without the source code. The various BSD versions (BSD OS, FreeBSD, OpenBSD, and NetBSD) attest to its many descendants, or at least to the ones retaining the BSD name. There is a financial incentive to fork here; BSD OS does not have any free versions, but only commercial sales.
The other leader of the forking pack is the original Java license. It sits on the borderline between Free and Proprietary because Sun Microsystems gave developers two choices: license the Sun source code for a large fee, or implement the Java specification at no charge. Hewlett-Packard, among others, declined to pay the source code fees and instead did its own implementation. While doing all the coding necessary, HP decided to make a few convenient changes. The result of several companies taking the do-it-yourself implementation option was incompatibilities among Java implementations, a real obstacle to the "write once, run many" objective of the project. Microsoft took the path of paying for the code and making its own changes to it.
There is an obvious benefit, then, to having a license that requires that modifications to Open Source code remain under an Open Source license. The availability of modified code to all developers takes away much of the technical motivation for forking. Some firms, however, fear that loss of control of the code will result from allowing variant versions. Sun used the Sun Community Source License (SCSL) for its new Java 2. The license requires all bug fixes and externally distributed modifications to its code to be fed back to Sun. The strictness of the compatibility testing shows that revenue is not the sole aim of this difficult license; it intends to prevent the compatibility problems brought on by forking under the earlier license. The SCSL accordingly ends up low on the forking scale, and on the proprietary side of the chart.
At the top of the Free licenses with forking tendencies we find the Perl Artistic License. Larry Wall, the inventor of the Perl scripting language, never intended to write it or to set up a strenuous definition of property rights; he originally used the GNU GPL. He noticed that businesspeople tended to be shy of the GPL, and so he started including an explanation of it in his package. Just as the Perl scripting language offers multiple ways to achieve an end, Wall thought that offering an alternative license to the GPL might suit some users’ taste better. Consequently, users can use either the Artistic License or the GPL, and the Artistic License itself offers a number of alternatives to choose from in following it. Among its considerable freedoms, the license allows forking, provided the forking is plainly marked.
Developers who put out an alternative version of Perl must rename the changed packages so that a recipient’s standard version of Perl will still work, or instead include a full standard version of Perl with the alternative version, to ensure that the user has ready access to it. These liberties, combined with the inability of the Artistic License to bind downstream parties to the original agreement, provide a large opportunity for forking. Because Perl itself recognizes alternative ways of doing things, and because variant versions are plainly marked as such, forking has not been a problem for Perl. There was a temporary redundancy of Windows versions, but a directed effort under the One Perl campaign managed to unify the code.
The playfulness of the hacker world played its part in the writing of the Artistic License. Larry Wall has pointed out that his following the Perl principle of TMTOWTDI — "There’s more than one way to do it" — is in itself a subversion of the licensing process. He is right, of course.
We have seen that the BSD-style license encourages forking because it allows developers to take the source code, freely modify it, and then distribute binary-only versions of the result. The source tree then looks like the one shown in Figure 7-2.
A BSD-type source tree
There are two unifying centripetal forces working against the unlimited centrifugal forces of dispersion. The first is that because the BSD distributions themselves are Open Source code, the BSD licenses allow each version to borrow improved code from the other versions. The second force returning improvements to the Open Source distributions is that once proprietary innovations have served their market purpose and are subsequently imitated by competitors, the innovators tire of single-handedly maintaining the differences, and seek to return the modifications to the source tree. The BSD distributions do receive freely contributed code from users.
The GNU GPL, on the other hand, mandates openness of source code at all times, with the results shown in Figure 7-3.
A GPL-type source tree
Every Open Source project labors to a greater or lesser degree under the possibility of forking. The most conservatively managed have licenses that allow only the originator to incorporate changes permanently in the source tree, and restrict others to distributing changes only as patches to the code. Projects using licenses like the GPL, on the other hand, live under constant threat of having someone take over the project by producing a better version of the code, and doing it faster than the original project owners.
Nevertheless, forking seldom happens on GPL-licensed projects because the original project can incorporate the code of variants if it chooses. The original project may not be so advanced as the variants at any given time, but it may nevertheless be good enough to be useful, and there may be those who prefer a slower pace of upgrade. Two projects may end up in symbiosis, one advancing the code rapidly, while the other integrates and tests it more slowly, and issues more stable releases.
Part V, "Open Source Software AS Your Business," contains a longer discussion of business models and the software licenses that further their goals. The emphasis there is on the use of single licenses. It is important, however, to say a few general words here about how licenses can work together or come into conflict. There is a very limited compatibility among licenses.
The GNU GPL, for instance, is designed to pull into its orbit every piece of software with which it is compiled. It is true, of course, that the copyright holder can issue software under a number of different licenses, but improvements that users submit under the GPL cannot be incorporated directly into versions of the software that are under another license. In such cases the developer must write new code to achieve the desired functions. Netscape, for instance, did not use the GNU GPL for this reason. On the other hand, code and modifications submitted under a BSD-type or X license can be incorporated into a GPL-licensed product — Linux has enough examples in it.
Subtler and more difficult problems occur when the license does not carry the same terms under all conditions. Some licenses, for instance, say the product may be freely distributed, except as part of a commercial product. This is a particular problem with development tools, since their output is often counted as a derivative work.
The diagram shown in Figure 7-4 illustrates some guidelines regarding licensing dependencies.
In the Figure 7-4 diagram the foundation on which all software rests — the operating system — is shown. The success of Linux demonstrates that this base layer is strongest when it is founded on the GNU GPL, which forces all software to adopt its standard license and thus keeps the system free and open to all developers and likewise free of all closed material. There is not a wide choice of operating systems as there is of applications; an operating system can be seen as a public good or even community property. Certainly Linux users regard Linux as freely available and inalienable community property.
In Figure 7-4 the GNU GPL has swept the decks of other licenses at the operating system level, but multiple licenses exist at the next level. While the operating system is free, at this next level there may be either free or commercial software. The licenses for these should be consistent so that the same material may not suddenly come under different distribution restrictions because it has become part of a commercial package. Software that changes state causes problems in licensing dependencies.
The Qt Public License Problem
Because Section 5 in the Open Source Definition (OSD) says that Open Source licenses may not discriminate against persons or groups, we should not expect an OSI-approved license to discriminate against businesspeople. Further, since Section 6 of the OSD says that Open Source licenses may not discriminate against fields of endeavor, we do not expect an OSI-approved license to discriminate against independent software vendors (ISVs).
But this is just what the Qt Public License (QPL) does. Developers can live with its retentive attitude toward code that allows only patches to be distributed, rather than modified files. The real problem with the license is that it allows free distribution of its derivative software (graphical interfaces), except when these are distributed commercially. At that point the distributor must purchase a special commercial development license from the maker, Troll Tech AS. This problem might have remained a minor nuisance except that the very popular Linux desktop, KDE, was built on the Qt Toolkit. Because KDE is freely distributable, many developers thought that their derivative work built on KDE was free also. But, when these derivative works are commercial software applications depending on KDE for their graphical interface, the commercial license raises its head and the developer discovers that beneath KDE there is a troll awaiting his toll. The fact that the Open Source Initiative has placed the QPL on its approved list does not make licensing any simpler.
A license does not need to forbid commercial distribution in so many words. The QPL, for example, simply requires that distribution of the Troll Tech Qt Toolkit (needed with the derivative applications, such as the graphic interfaces to applications running on the KDE desktop) take place under the QPL, which requires that the source code be made freely available and modifiable. Commercial vendors in a niche market are unlikely to accept this requirement. Although the QPL makes no mention of it, these vendors will find that they can distribute their binary-only code with the Qt Toolkit only under the Qt Professional Edition (commercial) license. To avoid these problems a firewall should be built between free and proprietary products at this level.
It follows that extensions and libraries for toolkits need to follow the same licenses as the toolkits that use them. This simplifies licensing questions and prevents surprises. Nevertheless, developers must develop the habit of reading the licenses of the toolkits, libraries, and extensions they work with and making sure these match the intended use and distribution of the resulting software. Licensing dependencies are just as important as software dependencies.
As we move away from the operating system, there is a larger selection of products and a smaller number of users for each product. Consequently vendors tend to prefer proprietary licenses and binary distributions to protect their development investment. We can expect the majority of tools to fall into this category. The developer then has the choice of developing proprietary applications with the help of tools that allow either free or commercial applications to be built with them, or to build these applications using tools that limit their derivatives to commercial applications. For simplicity, the tools themselves, like toolkits, should have clear licenses that allow either free and commercial distribution of their derivatives, or confine themselves to commercial distribution.
At this level the GNU LGPL will not always work for proprietary code, but the BSD-type licenses, or an Apache license, will. The Stronghold server is an example of adaptation of Apache code into a proprietary product. The Aladdin Free Public License fits into the category of free-only license, while the Perl Artistic License permits both free and proprietary distributions.
Product segmentation is the art of building a single product into a product line that serves different market segments. Producers can vary size, price, distribution, and many other product characteristics to capture a larger share of the total market. Hard goods from automobiles to breakfast foods have followed these patterns for many years. Intellectual property, that is, software, can likewise be segmented and sized, priced, and distributed in many different ways. The trick is to find the right licensing for the right purpose. Generally, simpler models mean more ease of administration and less confusion, but the right multiple licenses may nevertheless be the best solution to a complex problem.
As Open Source software moves up towards the largest machines, and down into the smallest, licensing will follow it. The next section of this book, Part IV, will deal with these two extremes of the market.
Next chapter: The Drive Toward the Mainframe
Table of Contents
Copyright © 2000 by IDG Books Worldwide, Inc. Published under IDG Books Worldwide, Inc. Open Content License.