Open source licensing: What every technologist should know

Learn about different types of open source licenses and get answers to common licensing questions.
1057 readers like this.
A diagram of a branching process

Opensource.com

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

  • BSD (Berkeley Software Distribution)
  • MIT
  • Apache 2
  • Affero GPL (AGPL)
  • GPL
  • Lesser GPL (LGPL)
  • Mozilla Public License (MPL)
  • Eclipse Public License (EPL)
  • Common Development and Distribution License (CDDL)

Top open source questions

When I advise clients on open source licensing, the four most common questions they ask are:

  1. What is “distribution?”
  2. How do open source licenses affect patent rights in software?
  3. What is the “notice” requirement and how do I comply?
  4. 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:

  1. 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.

  1. 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.
  1. 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.
  1. 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>

Tags
Heather Meeker
Heather Meeker is a partner in O’Melveny & Myers’ Silicon Valley office. She advises  clients on technology transactions and intellectual property matters.  She is an internationally-known specialist in open source software licensing.  She received the prestigious IP Vanguard Award for private practice from the Intellectual Property Section of the California state bar for 2016.

4 Comments

I'm fully in support of open source software and believe everyone benefits when code is publicly available.

Just to play devils advocate here: Sure, nothing forces you to release your proprietary code under the GPL if you have a derivative work and you are not in compliance with the license. You could certainly just stop distributing the software you have spent years developing, cost you millions of dollars to develop, and your business depends on it. So while you are not "forced" to license your formerly proprietary software under the GPL, companies are often left with very few options to remedy the situation (and continue distributing their proprietary software). Depending on who the copyright holder is on the dependent GPL software, you may be able to get an exception from the copyright holder (possibly in exchange for money). If you're unable to get an exception, your only options are to either stop distributing your license-infringing software or release your software under the GPL.

Well another option is to re-architect the integration as a "plugin". This means you take your codebase which is "all rights reserved" or differently licensed, separate it out from the GPL licensed code you wanted to work with, and try to only join the two together very loosely with a defined API. It might be that your code is the "main software" and the GPL bit is the "plugin", or the other way round.

Depending on the situation, that might be more hassle than it's worth, and obviously it's easier done if you think about doing it this way in the first place.

In reply to by airfishey

I have to agree with airfishey.

The critical part for derivative works is in regards to this statement: "The remedy for copyright infringement is either damages (money) or injunction (stop using the GPL code). "

Which begs the question - what is the status of the derivative work AFTER any damages have been paid? Does it remain subject to GPL terms or is it now free of them? Or is that subject to agreement (and quanta)?

I think this depends on how exactly the copyright infringement is settled. I am not a lawyer, and this is not legal advice.

The copyright holder may sue you for damages, and still require you to come into compliance with the GPL. Depending on which version of the GPL you are using, the copyright holder may have to explicitly give you permission to resume distributing your software (presumably after they have verified you are now in compliance with the license). I believe other versions of the GPL (version 3 I think) allow you to have your rights restored immediately if you come into compliance with the license (only for first time offenses).

Another way damages might be paid would be for the copyright holder holder to grant you an exception in exchange for something. This might mean that the copyright holder allows you to use their software in your closed-source/proprietary program in exchange for money (e.g. royalties or some other fee), advertising, developing another piece of software for them, doing chores around the house, etc. The copyright holder can chose to license their software however they please, so it's really up to them how/if they grant you an exception. If the copyright holder is your best friend, they may just grant you the exception to use their software however you want without having to pay any real "damages".

An example of using the GPL with an exception from the copyright holders would be the GNU Classpath: https://www.gnu.org/software/classpath/license.html

GCC Runtime Library Exception: https://www.gnu.org/licenses/gcc-exception-3.1.en.html

In reply to by tmz

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.