If you’re a software developer today, you know how to use open source software, but do you know how and why open source licensing started? A little background will help you understand how and why the licenses work the way they do.
Origins of open source licensing
Technologists today, having grown up in the age of Microsoft Windows and proprietary software, may believe that open source licensing is a recent trend that began in the 1990s. Although open source licensing’s popularity has skyrocketed in the past two decades, in truth, open source was the original model for software licensing, with proprietary licensing coming later.
In fact, the two models for software licensing (open source and proprietary) trace their origins from a common source: the Unix operating system. Unix was developed by AT&T Bell Laboratories in the late 1960s and early 1970s and was the first general-purpose operating system. At that time, AT&T’s market position was so dominant that the US Justice Department issued a consent decree barring AT&T from engaging in commercial activities outside the field of its telephone service, which was AT&T’s primary business. Because of the consent decree, AT&T could not exploit Unix as a commercial product, so Bell Labs gave Unix away in source code form under terms that allowed its modification and redistribution. This led to Unix’s widespread use and popularity among computer scientists in the 1970s and 1980s.
After the US Justice Department lifted the consent decree in 1983, AT&T pivoted to commercialize Unix as a proprietary product and adopted more restrictive licensing terms that allowed Unix to be redistributed only in object code format. Meanwhile, the 1980s saw the advent of microcomputers (PCs), which led to the standardization of software. This standardization, in turn, encouraged companies to distribute their software in binary-only form because there was less need for users to investigate or troubleshoot source code. And so proprietary licensing became the dominant model for licensing software.
Interest in open source licensing reemerged in the 1990s with the development of the Linux operating system. Since the privatization of UNIX, the demand had swelled for an operating system that would be a free alternative to UNIX. To be useful, that operating system needed both an operating system kernel and the tools necessary to install, run and develop programs for it. Linus Torvalds, a teenager in Finland, developed the first Linux kernel as a school project. Meanwhile, the GNU Project has been formed to develop those tools, and when those two parts were combined, a free alternative to UNIX was available. The combined operating system—most commonly called Linux—was released under the GNU General Public License (GPL), a licensing model that was created by Richard Stallman of the GNU Project. The GPL granted recipients unfettered rights to redistribute software with the condition that the source code could not be kept secret. As Linux grew in popularity, with thousands of contributors and billions of users, the industry learned to follow and adopt GPL’s terms. By the late 1990s, GPL and the open source licensing paradigm more broadly gained traction and industry-wide acceptance. In the 2010s, it has nearly eclipsed proprietary license in importance to the technology industry.
Types of open source license
Today, the GPL license that Stallman pioneered is in its third version (GNU GPLv3) and is only one of several dozen types of open source licenses. The Open Source Initiative, an organization founded in 1998 to promote open source software and normalize the use of the term, has approved more than 80 open source licenses. These 80 licenses generally fall into one of two categories: permissive licenses and copyleft licenses.
A permissive license is simple and is the most basic type of open source license: It allows you to do whatever you want with the software as long as you abide by the notice requirements. Permissive licenses provide the software as-is, with no warranties. So permissive licenses can be summarized as follows:
- Do whatever you want with the code
- Use at your own risk
- Acknowledge the author/contributor
Copyleft licenses add requirements to the permissive license. In addition to the requirements listed above, copyleft licenses also require that:
- If you distribute binaries, you must make the source code for those binaries available
- The source code must be available under the same copyleft terms under which you got the code
- You cannot place additional restrictions on the licensee's exercise of the license
The table below categorizes popular open source licenses under the permissive and copyleft frameworks. The copyleft licenses are also listed in ascending order of strength, from strongest at the top to the weakest at the bottom. “Strength” refers to the degree to which surrounding software may need to be subject to the same copyleft requirements. For example, GPL is strong because it requires that any program that contains GPL code must contain only GPL code. LGPL is weaker because it allows dynamic linking to other proprietary code without subjecting that linked code to the same GPL requirements. The weakest copyleft licenses, EPL and MPL, allow any kind of integration with other code, as long as EPL or MPL code is in its own file.
|
Permissive Licenses |
Copyleft Licenses |
|
|
Top open source questions
When I advise clients on open source licensing, the four most common questions they ask are:
- What is “distribution?”
- How do open source licenses affect patent rights in software?
- What is the “notice” requirement and how do I comply?
- What is a “derivative work” and, related, does incorporating GPL code into my proprietary code cause the proprietary code to be licensed under GPL?
The short answers to these questions appear below:
- What is “distribution?” In simple terms, distribution refers to transferring a copy of a copyrighted work (such as software) from one legal person to another. The concept of distribution matters because the requirements of open source licenses are triggered only when software is distributed. Thus, a person who does not distribute software cannot violate an open source license’s terms. And because “legal person” includes a corporation, there is no distribution—and therefore no risk of violating a license’s terms—if software is merely transferred between employees of the same company.
Today, distribution can be a thornier question for businesses that deploy software through the Internet, cloud, or a SaaS model. Does allowing users to interact with a software application over the Internet qualify as distribution? For most open source licenses, the answer is no. Indeed, GPLv3 uses the term “convey” rather than “distribute,” precisely to clarify that SaaS use does not trigger any license requirements. But the Affero GPL (AGPL) license is one exception that takes a different approach. AGPL’s requirements (which are the same as GPL) are triggered once software is modified and made available for use and interaction over a network.
- How do open source licenses affect patent rights in software? Some open source licenses (e.g., Apache 2, GPLv3) include express patent license provisions, which grant recipients a license to any patents covering the software product. Other open source licenses (e.g., BSD, MIT, GPLv2) are mum on patent licenses. Nonetheless, for these licenses, courts may use the doctrine of “implied license” to find that recipients are still licensed and protected from any patent infringement allegation arising from using the licensed software product. By doing this, courts prevent licensors from taking “two bites at the apple” and suing for patent infringement for using the very software they have licensed. In sum, unless expressly stated otherwise, open source licenses limit the author’s ability to sue license-abiding recipients for alleged patent infringement.
- What is the “notice” requirement and how do I comply? The notice requirement means that a distributor of open source software must inform recipients that certain open source software, which is available under the noticed license, is included in the software being delivered to the recipient. Open source licenses each have their own specific notice requirements. Commonly, these requirements include providing entire copies of applicable licenses and acknowledging authors and contributors. A best practice is to deliver the source code covered by the license up front because full copies of licenses are typically included as text files in the source code package. Another best practice is to follow the GPL’s notice requirements because they are considered among the most stringent. Thus, complying with GPL’s notice requirements will usually ensure compliance with other applicable open source licenses’ notice requirements.
- Derivative works and the myth of viral GPL: A common concern of clients is that by incorporating code licensed under GPL (or similar copyleft license) into their proprietary code, the proprietary code will be “infected” or “contaminated” and become licensed under GPL (i.e., the proprietary code is effectively converted into GPL code) or forced into the public domain. This concern causes some to view GPL as viral and discourages them from using GPL code because they are worried that any derivative works that incorporate GPL code will also be licensed under GPL.
These concerns are largely unfounded. It is true that under GPL, all code in a single program must be either be subject to GPL or not subject to GPL. So if a developer were to combine GPL code with proprietary code and redistribute that combination, it would violate the GPL. But the likely worst-case consequence of this violation is that the author of the GPL code could exercise their right to bring a claim for copyright infringement. The remedy for copyright infringement is either damages (money) or injunction (stop using the GPL code). Critically, copyright law supports no remedy that would force the offending developer to license their proprietary code under GPL or to put that code into the public domain. Combining GPL code with proprietary code does not therefore “infect” the proprietary code or convert it into GPL code.
To learn more, attend Heather Meeker’s talk, Open source software licensing: What every technologist needs to know, at Strange Loop, which will be held September 28-30 in St. Louis, Missouri.em>
4 Comments