This chapter covers the legal underpinnings of open source software as embodied in the licenses created to protect and extend the aims of the software’s creators. From the foundation provided by the GPL that Richard Stallman created for his GNU project, which governs the use and distribution of Linux today, to its predecessors developed by MIT and UC Berkeley, open source licenses have since evolved into more than 50 “flavors” administrated by universities, individuals, and increasingly, corporations including IBM, Apple, and Sun.
How much time an IT department must spend worrying about licenses depends on how open source will be used. For most CIOs and CTOs, who are interested in using open source software only to meet their day-to-day needs, there is little to be concerned about. This group will benefit from this chapter’s explanations of licenses as they related to the SCO case, which is discussed in more detail in Chapter 9, as well as discussions of other software debates and policy issues.
For companies that are developing software that includes open source as components, it is critical to understand the aims and restrictions of these licenses. Even upper management should study the principles involved. One license might require sharing any new code created with the open source community, and another might mean handing over that code to a software giant’s private developers. The current generation of licenses might also prove to be a model for the terms under which new or formerly proprietary software projects are released as an open source effort.
The casual use of the terms open source and free software
among programmers and in the press has led to a popular, albeit hazy, impression that open source software exists in the public domain, or that the software’s creators have otherwise volunteered not to exercise their copyrights (or to file for patents). This misconception is born from another misconception: that open source advocates are anti-capitalist, anti-intellectual property zealots out to destroy the commercial software business. (Actually, only a few of them are.)
The open source movement and community are governed by a broad spectrum of widely used licenses with distinct, strict provisions for the use, modification, and distribution of source code and the “derivative works” compiled from that source code. The OSI lists 54 approved licenses on its web site.
In this chapter, even the phrase open source is up for dispute, redefinition, and then hairsplitting by the advocates of competing licenses. Richard Stallman, who in 1984 created for his GNU project the first and still most popular open source license, the GPL, actually hates the term open source and demands the use of free software instead. This is not a marketing dispute; an avowed “pragmatic idealist,” Stallman expressly designed the GPL so that any software that uses it as a license is open to modification, and so that any larger software project that incorporates code issued under the GPL is automatically bound by the GPL. Developers should think carefully before including GPL-protected code in the next version of their software, especially if there is any chance that one day it might become a product. However, if code is protected under a different license—such as BSD and the BSD license—developers can use that open source code as a foundation for proprietary products. (This is exactly what Apple did when it utilized parts of BSD in Mac OS X. It created layers, and kept open source in one layer and put the proprietary parts of the operating system in another. In addition, Sun used BSD Unix as the foundation for its Solaris operating system.)
Understanding the overlap and incompatibilities among different licenses is critical for any developer seeking to harness an open source project or mix-and-match open source code. (The GPL, for example, has a list of conditions that determine whether software bound by a different license is “compatible.”) Conversely, the fine print on these licenses often offers a cut-and-paste foundation for a custom license governing the release of formerly proprietary software as an open source project.
The legal scope of the rights, privileges, and protections granted by these licenses has become an extremely contentious subject over the past few years. The first real test was in the lawsuit filed by the former Linux distributor, SCO, against IBM in 2003. SCO claims to have purchased the original rights to the Unix operating system, and that IBM programmers illegally incorporated pieces of copyrighted Unix code into Linux. In effect, SCO claims to own Linux, and is involved in litigation on a number of fronts to reinforce this claim. (We cover the details and future implications of these continuing suits in Chapter 9.)
The rest of this chapter will explore and compare the terms of the most popular open source licenses to date. We will start with the “classic” licenses invented by individuals and universities—the GPL, BSD, and MIT licenses—before moving on to the second and third waves of project-specific licenses (e.g., Perl’s Artistic license) and corporate license (such as those of Apple, IBM, and Sun) to emerge in the last decade.