It would not be an exaggeration to say that the magic of open source software (OSS) is based as much on legal innovation as it is on collaboration. Indeed, the essential innovation that launched free and open source software was not Richard Stallmans GNU Project, but his announcement of a revolutionary new licensing philosophy, and the actual license agreements needed to put that philosophy into effect. Only later did global collaboration among developers explode, riding the wave of Stallman’s licenses, Linus Torvald’s pioneering work in creating the distributed development process, and rapidly increasing telecommunications bandwidth.
In this installment, we’ll explore how Stallman’s philosophy spread and forked, and where it has taken us to today.
The legal theories, agreements, and documentation that relate to FOSS are far too complex to explore more than superficially in an article of this type. But for current purposes, it is less important to acquire a deep knowledge of FOSS legal terms than it is to gain insight into why the legalities of FOSS are so important.
Threshold facts and principles: The interaction of OSS and the law will seem like a hopeless jumble unless a few important facts are first understood:
- No one entity usually owns a FOSS product: For reasons that are partly historical and partly ideological, in most projects every individual developer that contributes a line of code will retain ownership of that line. As a result, any piece of FOSS is likely to have many authors –sometimes, as with the Linux kernel, even thousands. Since successful FOSS undergoes constant improvements and corrections, the authors and their contributions are constantly changing as well. When you license a piece of FOSS, you therefore license not from one licensor, but from many — sometimes very many.
- It takes a village to build a distro: FOSS comes in many pieces, large and small: text editors, libraries, programming languages, interfaces, and much more. Because the store of available FOSS becomes ever larger and there is no reason to constantly reinvent the wheel, a FOSS application or operating system is likely to include many modules and components borrowed from other projects as well as software developed by the project whose name is primarily associated with the FOSS in question. (The same, incidentally, is true of many proprietary packages, a practice which is discussed below.)
- Rock, paper, scissors: Because of the heterogeneous nature of such “village” software, it will be likely that selections made by a FOSS project on purely technical merit will result in a final package that includes modules that were developed under different license agreements. As a result, care must be taken to ensure that all of the licenses that relate to the constituent parts of the final package are compatible, which can result in something of a dilemma at the end of a development project unless good legal hygiene is practiced along the way. The problem is more severe for proprietary software vendors, who must not only ensure that they can deliver all necessary legal rights to their customers, but avoid inclusion of copyleft-licensed code that might require them to license their entire product on similar license terms.[i]
- It’s not just about money: The copyleft licenses discussed below include provisions that are intended to protect the strongly held personal beliefs of the developers that prefer such licenses. As a result, these licenses include rules that are philosophical as well as economic in origin and effect.
- New wine in new bottles: While some parts of free software licenses are quite similar to their proprietary analogues and are included for similar purposes (e.g., warranty disclaimer language), other parts seek to accomplish new and novel results, often using language that was previously unfamiliar to lawyers. Such licenses presented new interpretive questions to judges, not all of which have, as yet, been answered. Where they have been addressed, it has been in the isolated courts of various jurisdictions. As a result, “settled law” may not be achieved on some FOSS, and particularly copyleft, licenses for some time.
- It takes more than a license: Because any piece of OSS software is likely to have many authors, each retaining ownership of her code, it is important for contribution agreements or “certificates of origin” (or similarly titled) documents to be in place between each developer and the project in which they participate, to be sure that a licensee of the software that the project makes available actually has the rights it needs to use the software. The process of collecting such rights is complicated by the fact that many contributors to a product may be subject to agreements with their employers that may be inconsistent with the rights needed by the project.
- It’s often all about copyrights: While some licenses (such as the GPL 2.0 and GPL 3.0) include terms that are relevant, or that seek to influence behavior relating, to patents, the contribution agreements and distribution licenses that relate to OSS often deal primarily with copyright and trademark rights. In contrast, a proprietary software license between two commercial entities will always give the licensee the express rights it needs with respect to any patents the owner owns or controls. This dichotomy is in part due to the fact that those that contribute code to FOSS projects may not be aware of, or control, all patent claims that may be infringed by the use of the code they contribute (and their employers may not, either). Nor are they in a financial position, or willing, to pay compensation if a licensee is later sued for infringement. For these reasons, FOSS software downloaded from a code repository should be regarded as being provided “as is.” However, as a practical matter, the user of a popular FOSS product may have little to fear due to the market taboo that has evolved against asserting patents against such programs. When a user obtains a license to a commercial distribution of a FOSS program, like Linux, they are likely to have greater protection than using a non-commercial distribution, since the software vendor will usually provide the same kind of warranty and indemnification protections to its customers as would a proprietary software vendor.
As can be seen, launching and maintaining a successful OSS project and distributing and using the results take place on a rather complicated legal landscape. Some of the thousands of FOSS projects that have been launched (particularly in the early days) paid comparatively little attention to the legal niceties that can make later use of their work product less problematic. However, best practices and supporting legal documentation for OSS development are now broadly available, including at each of the umbrella organizations discussed below, and instances of sloppy code maintenance are therefore becoming less frequent.
Permissive and copyleft licenses: The first licenses identifiable as “open source” licenses were very simple indeed, and focused on what a licensee could do, rather than what she couldn’t. The common ancestor of all open source licenses is generally agreed to be the original version of the BSD License, the terms of which said little more than, “do as you please, but let people know where this code came from — and don’t sue us.”[ii] The BSD License, and the multiple, similar variations that followed, therefore came to be called “permissive” licenses.
The availability of increasingly valuable code under permissive licenses had two predictable consequences: people used the code, and some of them used that code to make money. This annoyed some developers, and particularly a programmer at the Massachusetts Institute of Technology Artificial Intelligence Center named Richard Stallman, who vowed to do something about it. What Stallman did was to codify his beliefs in what he called the Free Software Definition, and then craft a license that would impose conditions on the reuse of such software that would map to the that definition and the software community values it represented. The result was a new type of license — the GNU[iii] General Public License, or GPL. The GPL was intended to impose obligations on the user that would guarantee that any modifications created by the licensee would be available on terms that would comply with the Free Software Definition, principally by requiring that the licensee distribute source code as well as binary code, and by prohibiting the licensee from adding any restrictive conditions that would subvert developer freedoms.
Stallman gave the name “copyleft” to the provisions that accomplished the more innovative of these goals. Because a license including copyleft terms restricted licensees to release their modified works only under license conditions that were in harmony with the terms of the original license, this category of agreements is sometimes referred to as “restricted” licenses.[iv]
The evolution of the GPL: The first version of the GPL was based on precursor licenses used with GNU Project component programs, and allowed multiple OSS programs to be combined more easily. It was first used in 1989, and amended in 1991, at which time a somewhat more permissive license was added for use with software libraries. That license was initially called the “Library General Public License”, or LGPL (which began life as version 2, not 1, in order to match the new version of the GPL, with which it harmonized), and later renamed the “Limited General Public License”.
The major evolutionary change from the first to the second version of the GPL was the addition of a broader, more free-form legal obligation that Stallman called the “Liberty or Death” clause, a kind of catchall hammer clause intended to thwart any action that might result in a program downstream from the original, GPL licensor ever being able to restrict the required freedoms of its own licensees.
The third (and current) version of the GPL was not released until March of 2007, following a long and laborious process of discussions, public comments, and multiple discussion drafts. The reasons for the protracted process were several, reflecting the increasing commercial value of free software released under the GPL (most notably, Linus Torvalds had switched the Linux kernel to GPL 2.0 from its earlier, permissive license). It was also intended to thwart certain types of emerging commercial behavior deemed by Stallman and others to be anti-community which the terms of the GPL 2.0 did not prohibit. The multi-year process that led to the eventual approval of the third version of the GPL involved achieving consensus on a large number of contentious changes and goals, an ordeal not made easier by having so many cooks, both lawyers and non-lawyers alike — over 130 in all, broken up into four committees — operating within the textual confines of the same, very small kitchen.[v]
The result was a license that was applauded by many, but not deemed by all to be appropriate for all situations. As a result, the GPL 3.0 has not replaced the prior version in all projects, and many new projects continue to adopt the GPL 2.0 license. Many pre-existing projects remain with the GPL 2.0 as well, in some cases due to logistical difficulties (e.g., the inability to track down no longer active programmers owning the copyright to their included contributions).
The GPL family of licenses is unique in a variety of ways, not least among which is its iconic status as both a legal document as well as a social contract among those that adopt it. The result is that any legal challenge to the GPL would be deemed to be an attack upon the entire global community of free software developers. Because so many commercial interests and their customers rely so heavily upon free software that is subject to the GPL, the license enjoys something of a legally privileged status. Perhaps largely for this reason, the GPL licenses have attracted far fewer legal challenges than might normally be expected to be brought when such an innovative and broadly utilized license is introduced to the marketplace.
Evolution of permissive licenses: Over time, some FOSS contributors and users became concerned that the very brief original permissive licenses (e.g., the BSD and MIT licenses) might be read to convey only copyright permissions, and not undertakings regarding patent claims that would be infringed by use of contributed code. As a result, in 2004 the Apache Foundation replaced its then-current BSD-like license with a longer, more detailed agreement that addressed several points of perceived improvement, one of which is an explicit license to practice inventions covered by patent claims owned by the contributor. The Apache Foundation also adopted complementary individual and corporate contributor license agreements. These agreements are signed by code contributors to a project using the Apache 2.0 license to confirm to the project that downstream developers and users will have the copyright and patent rights enumerated in the Apache 2.0 license agreement. As of this writing, the Apache 2.0 license agreement is the third most used FOSS license.[vi]
Other licenses: There are over sixty FOSS licenses currently recognized by the Open Source Initiative. When open source software first appeared on the scene, new project founders sometimes tinkered with the license of a predecessor, leading to the development of an evolutionary license tree that grew out of the original BSD terms of use. Sun Microsystem, Microsoft and other companies came up with their own FOSS licenses, as did various non-profit foundations, including the Apache, Eclipse and Mozilla Foundations. Even governments, such as the European Commission, created unique variants. The same process followed in relation to the GPL, both within Richard Stallman’s Free Software Foundation and elsewhere, with proprietary vendors being particularly disposed to crafting their own variations on the FOSS theme. Typically, the vendor or project that produced a new license would submit it to OSI for approval and entry on OSI’s master list of approved licenses.
Over time, many of the branches on this evolutionary licensing tree withered, resulting in a number of early licenses becoming little used (i.e., they are rarely selected by new projects, and projects that originally made use of them may have migrated to a different license). Today, it is commonly acknowledged that there are more OSI-approved licenses, with too few differences, than are necessary. As a result, the vast majority of projects today license their code under just a handful of licenses.[vii]
But code remains in use from these earlier licenses. Unfortunately, some software developers pay insufficient (or no) attention to the terms of the software that they pull down from a software repository and add into their own programs. The result can be a software product that includes software subject to many, and even dozens, of different, and frequently incompatible, licenses. Happily, useful taxonomies have been created in response to the plethora of licenses in order to make it easier for projects to decide which licensed code can appropriately be incorporated into their code bases and which should not.[viii]
Open source practice: While the goals of FOSS are straightforward, the legalities are not. Merging code together from multiple sources into both OSS as well as proprietary products creates many traps for the unwary, both on the business (e.g., code contamination) as well as the legal (misunderstanding what a given license term is intended to address) fronts.
The GPL (versions 2 and 3) in particular seek to achieve a variety of significant, and sometimes subtle, legal and commercial goals, and the elements of the social contract underlying these terms is as important as the strict legal terms. Concluding that a particular type of behavior is “legal” while ignoring the way in which the behavior may be regarded in the FOSS world can result in undesired community, if not necessarily legal, consequences.
Finally, as noted, the body of case law that is available for courts to consult in crafting their own decisions relating to these new licenses is, as yet, scant. For all these reasons, anyone doing business in the FOSS area, and their legal counsel, should take the time to understand the emerging lore, as well as the law, before they become too-deeply involved.
Next time: The FOSS Ecosystem Today
End Notes
[i] As can be imagined, the availability of an ever expanding cornucopia of FOSS components has resulted not only in headaches for vendors, but in nightmares for anyone involved in a technology merger or acquisition. Any transaction involving (especially) a software vendor now includes a meticulous, line by line, “codebase” analysis of all software that the acquirer will purchase, to determine what license terms apply to each line. Where issues are (almost inevitably) discovered, remediation then follows, which may include removal or replacement of code that is available only under terms deemed not to be acceptable by the acquirer. Well-run software vendors today utilize readily available software tools to analyze, and, as necessary, exclude software that is subject to licensing terms deemed to be incompatible with their commercial goals; the same tools are essential in the context of an acquisition. Sellers who have not used such tools prior to the transaction are invariably astounded at the high percentage of their products made up of third party FOSS pulled down from code repositories by their employees over the years.
[ii] The BSD License drafted and first used in 1989 in connection with the distribution of a UNIX-like operating system created by the Computer Systems Research Group (CSRG) at the University of California, Berkeley. Its original text can be found at: https://opensource.org/licenses/BSD-3-Clause The currently more commonly used version of the BSD License eliminates the text found in the third numbered clause.
[iii] The “GNU” in the GPL title refers to a computer operating system and related software developed by the GNU Project, a free software initiative founded and managed by Richard Stallman. The name is a recursive acronym of “GNUS’s Not Unix!” GNU resembles, but does derive from the code of, UNIX, an operating system originally developed by Bell labs which GNU resembles
[iv] Richard Stallman is as well-known for the rough edges of his personality as he is for the brilliance of his thought leadership. Famously, he will not provide an interview to a journalist that does not agree in advance to use several of Stallman’s preferred free software terms. For example, the journalist must use the phrase “GNU/Linux” to refer to the operating system more commonly referred to simply as “Linux,” in order to acknowledge that the GNU Project came first, and that non-embedded “Linux” implementations will invariably include software developed by the GNU Project as well. Also, he is fond of appearing at events as St. IGNUcius. See: https://www.google.com/search?q=richard+stallman+saint+ignucius&rlz=1C1CHBD_enUS855&source=lnms&tbm=isch&sa=X&ved=0ahUKEwif_LuCnZLjAhVSdt8KHbwDDvIQ_AUIEigD&biw=1280&bih=577
[v] As of this writing, the Linux kernel remains under the GPL v2, in part because Linus Torvalds does not agree with some of the new terms added to GPL v3.
[vi] The controversy over whether the BSD, MIT and similarly brief and non-specific OSS licenses should be interpreted by the courts to include an implied patent license , notwithstanding their omission of an explicit patent license, continues to this day, with many experts at odds over what the correct conclusion should be.
[vii] In 2018, the most popular FOSS licenses in use were the MIT (26%), Apache 2.0 (22%), GPL 3.0 (16%), LGPL (6%), BSD 3 clause (3%) and Microsoft Public (3) licenses. All other licenses combined represented less than 9%. See Top 10 Open Source Licenses in 2018: Trends and Predictions, at https://resources.whitesourcesoftware.com/blog-whitesource/top-open-source-licenses-trends-and-predictions.
[viii] OSI’s category page can be found here: http://opensource.org/licenses/category