There are hundreds of different open source software licenses in use today, with provisions ranging from the comical (i.e. the Beerware License) to the classic (i.e. GPL v2).

Broadly, though, OSS licenses can be broken down into two categories: permissive and copyleft.

Copyleft licenses — the subject of this blog — generally require that any derivative work of the copyleft-licensed software be released under the same license as the original software. In other words, the modified code has to be exactly as “open” as the original. One of the practical ramifications of this requirement is that OSS users may be forced to publish their own changes or additions in source code form if they release a binary that includes a copyleft-licensed component.

Copyleft licenses stand in contrast to permissive licenses, which tend to have few restrictions on use of the licensed code. They also don’t have any such code-sharing requirement, so the “open source-ness” does not necessarily persist to the derivative work. That is a feature or a bug, depending on how you look at it. For developers of proprietary software, software under copyleft licenses must be used with care. For developers of free and open source software, copyleft is a way to ensure the software remains freely available.  

In this blog, we’ll take a close look at copyleft licenses, including their history, how they compare to permissive licenses, and the difference between strong and weak copyleft licenses.

The History of Copyleft Licenses

The word “copyleft” was coined in direct opposition to the familiar term “copyright.” In 1976, developer Dr. Li-Chen Wang added this humorous text to the distribution notice of his Palo Alto Tiny BASIC programming language: "COPYLEFT ALL WRONGS RESERVED." The line was a dig at Microsoft co-founder Bill Gates, who had complained about software hobbyists pirating the company’s Altair BASIC program, which sold for $150 a pop at the time.

That line didn’t have any legal power, but it was catchy (and pretty funny, if we do say so). And it positioned “free” (as in free to use, copy, modify, etc.) software (Tiny BASIC) against proprietary/copyrighted software (Microsoft’s Altair BASIC).

Things got more serious in the 1980s when famed free software advocate Richard Stallman made the word the centerpiece of the GNU Project. According to Stallman, a truly free software program would allow the following:

1. The freedom to run the program as you wish

2. The freedom to copy the program and give it away to your friends and co-workers

3. The freedom to change the program as you wish, by having full access to source code

4. The freedom to distribute an improved version and thus help build the community

Stallman built the GNU operating system with the above freedoms — and the concept of copyleft — in mind. The “What is Copyleft?” page of GNU.org explains copyleft with regard to software in these terms:

“To copyleft a program, we first state that it is copyrighted; then we add distribution terms, which are a legal instrument that gives everyone the rights to use, modify, and redistribute the program's code, or any program derived from it, but only if the distribution terms are unchanged. Thus, the code and the freedoms become legally inseparable.
“Proprietary software developers use copyright to take away the users’ freedom; we use copyright to guarantee their freedom. That’s why we reverse the name, changing “copyright” into “copyleft.” (GNU.org, “What is Copyleft?”)

The original GNU General Public License (GNU GPL), which Stallman wrote in 1989 to accompany the GNU operating system and related programs, put the concept of copyleft into explicit form. Since then, the GNU GPL has been updated several times. The latest version, GNU GPL v3, was released in 2007. Other copyleft licenses, like the Mozilla Public License 2.0 and the Eclipse Public License, have also gained traction in the OSS community. Currently, the most-used copyleft license in open source software is the GNU GPL v2, which has been in wide use for 20 years.

Copyleft vs. Permissive Licenses

The primary differences between copyleft and permissive licenses are compliance requirements and how “open” any code modifications must be. Typically, permissive licenses only require users to include a copy of the license text and the original copyright notice in any redistribution of the licensed code. Otherwise, they can do whatever they want with it. For example, a developer can take the code, modify it to create a new program, then keep the code of that program to themselves, making it proprietary and closed-source. They could then sell that program commercially.

Copyleft licenses, on the other hand, have more stringent conditions. Like permissive licenses, they generally require users to include the original copyright notice and the license text, but they also obligate users to make the source code of any modifications or derivative works to all recipients of the binary, under the same license as the original.

Copyleft License Use Cases

The best type of license for any given piece of software depends on a number of factors. Before selecting a license for your own OSS project, consider what you want to achieve with your software and how you want others to interact with your code.

For instance, a copyleft license may be the right fit for your project if you:

  • Want to share improvements with the OSS community
  • Believe in a collaborative approach to building software
  • Want to commercialize your project
  • Don’t want your code made proprietary by someone else
  • Are creating a project within a community that tends to use a specific copyleft license

On the other hand, a permissive license might be the best choice if you:

  • Don’t want to spend much time (or worry) on license compliance
  • Want to make it as easy and appealing as possible for others to use your code
  • Are creating a project within a community that tends to use a specific permissive license

Luckily, there are plenty of resources out there to help you pick the right license for your project (this guide, for instance). Plus, you can always ask other members of the OSS community.

Types of Copyleft Licenses

Copyleft licenses come in two flavors: strong and weak. This distinction turns on how much new or adjacent code is subject to the copyleft license.

Under a strong copyleft license like GPL, if you redistribute a program that includes GPL code written by others, you must make your entire program available under GPL. That includes any linked libraries or other components of the program. Examples of licenses that fall into this category include GPL v2 and GPL v3, as well as the Affero GPL License (AGPL).

Weak copyleft licenses also obligate users to release their changes. However, this requirement applies to a narrower set of code. The Mozilla Public License 2.0 and the CDDL (Common Development and Distribution License) are examples of weak copyleft licenses that illustrate this principle. If a user keeps the licensed code in separate files, they can then combine it with additional and/or modified code to create an aggregate work. The newly added files may be released under a different license or kept proprietary (closed-source). This is sometimes referred to as file-based copyleft. Another example is the LGPL, which mainly applies to libraries. Any changes to the library must be released under the same license, but a work that simply uses the library is exempt.

The LGPL also has different requirements depending on how the library is integrated with the remainder of the program. For example, you may have heard that the LGPL requires the library to be dynamically linked. While it is possible to comply with the LGPL for a statically linked program, there are more requirements — so dynamic linking of LGPL code is a best practice.

It’s worth noting that copyleft licenses don’t exist solely within open source software. The Creative Commons (CC) license, for instance, is a copyleft license often applied to artistic works like photographs, music, etc.

Copyleft Licenses in the OSS Community

Currently, permissive licenses are the most-used license type in open source software, with the most popular being the MIT License and the Apache License 2.0. (Different sources report different numbers, but it’s generally estimated that around 65-75% of OSS projects have permissive licenses.)

But copyleft licenses also play an integral role in the OSS ecosystem. For example, the GPL family will likely continue to be among the most commonly used OSS licenses — as the license of choice for the Linux kernel, it holds a special place in the software development ecosystem.

In addition, copyleft licenses help both companies and developers further the purpose of “free” software, which shares improvements and gives back to the open source software community. As long as OSS contributors continue to value this mindset, copyleft licenses will be here to stay.