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.
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.
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:
Copyleft licenses add requirements to the permissive license. In addition to the requirements listed above, copyleft licenses also require that:
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
When I advise clients on open source licensing, the four most common questions they ask are:
The short answers to these questions appear below:
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.
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>