--- title: "All About Copyleft Licenses" description: "An exploration of copyleft licenses, their history, differences from permissive licenses, and their role in the open source community." canonical_url: "https://fossa.com/blog/all-about-copyleft-licenses/" markdown_url: "https://fossa.com/blog/all-about-copyleft-licenses.md" content_type: "blog" language: "en" date_published: "2021-05-10" date_modified: "2025-11-07" author: "Kristen Miller" organization: "FOSSA" --- # All About Copyleft Licenses > An exploration of copyleft licenses, their history, differences from permissive licenses, and their role in the open source community. There are hundreds of different [open source software licenses](https://fossa.com/developers-guide-open-source-software-licenses) in use today, with provisions ranging from [the comical (i.e. the Beerware License](https://fossa.com/blog/top-6-most-out-there-open-source-licenses.md)) to the classic (i.e. [GPL v2](https://fossa.com/blog/open-source-software-licenses-101-gpl-v2.md)). 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](https://fossa.com/blog/all-about-permissive-licenses.md), 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. ![Open Source Business](https://fossa.com/Group-831-17.png) ## 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](https://blog.altlegal.com/alt-legal-ip-docketing-blog/to-the-left-to-the-left-an-introduction-to-copyleft-and-open-source-software) 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](https://genius.com/Bill-gates-an-open-letter-to-hobbyists-annotated) 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](https://www.gnu.org/). According to Stallman, a truly free software program would [allow the following](https://www.gnu.org/gnu/gnu-history.html):
  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?”](https://www.gnu.org/licenses/copyleft.en.html)) The original GNU General Public License (GNU GPL), which [Stallman wrote in 1989](https://groups.google.com/g/gnu.announce/c/m0Jjj_64PeQ/m/8xL1xkVKJb8J?pli=1) 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](https://fossa.com/blog/open-source-software-licenses-101-gpl-v3.md), was released in 2007. Other copyleft licenses, like the [Mozilla Public License 2.0](https://fossa.com/blog/open-source-software-licenses-101-mozilla-public-license-2-0.md) and the [Eclipse Public License](https://fossa.com/blog/open-source-software-licenses-101-eclipse-public-license.md), have also gained traction in the OSS community. Currently, the most-used copyleft license in open source software is the [GNU GPL v2](https://fossa.com/blog/open-source-software-licenses-101-gpl-v2.md), 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](https://fossa.com/blog/which-open-source-license-is-the-best-for-commercialization.md) 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](https://fossa.com/developers-guide-open-source-software-licenses), 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](https://fossa.com/blog/open-source-software-licenses-101-gpl-v2.md) and [GPL v3](https://fossa.com/blog/open-source-software-licenses-101-gpl-v3.md), as well as the [Affero GPL License (AGPL)](https://fossa.com/blog/open-source-software-licenses-101-agpl-license.md). 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](https://fossa.com/blog/open-source-software-licenses-101-mozilla-public-license-2-0.md) and the [CDDL (Common Development and Distribution License)](https://fossa.com/blog/open-source-licenses-101-cddl-common-development-distribution-license.md) 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](https://fossa.com/blog/open-source-software-licenses-101-lgpl-license.md), 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](https://blog.altlegal.com/alt-legal-ip-docketing-blog/to-the-left-to-the-left-an-introduction-to-copyleft-and-open-source-software), 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](https://fossa.com/blog/open-source-licenses-101-mit-license.md) and the [Apache License 2.0](https://fossa.com/blog/open-source-licenses-101-apache-license-2-0.md). (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](https://fossa.com/blog/open-source-software-licenses-101-gpl-v2.md) 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. ## Frequently Asked Questions About Copyleft Licenses ### What is a copyleft license? A copyleft license is an open source software license that requires any derivative work or modifications of the licensed software to be released under the same license. This ensures that the code remains open source and that improvements are shared back with the community. ### What's the difference between copyleft and permissive licenses? Copyleft licenses require you to release modifications under the same license and make source code available when distributing binaries. Permissive licenses like MIT or Apache 2.0 only require you to include the license text and copyright notice, allowing you to keep modifications proprietary. ### What's the difference between strong and weak copyleft licenses? Strong copyleft licenses like GPL require the entire program, including linked libraries and components, to be released under the same license. Weak copyleft licenses like MPL 2.0 or LGPL only require modifications to the licensed files themselves to be released under the same license, allowing other code to remain proprietary. ### Can I use copyleft-licensed code in commercial software? Yes, you can use copyleft-licensed code in commercial software and charge money for it. However, you must make the source code available to anyone who receives the software, and any modifications must be released under the same copyleft license. ### Do I need to share my modifications to copyleft-licensed code? If you distribute your modifications or software that includes copyleft-licensed code, you must share your modifications under the same license. However, if you only use the code internally and don't distribute it, you're not required to share your modifications. ### What are examples of strong copyleft licenses? Examples of strong copyleft licenses include the GNU General Public License (GPL) v2 and v3, and the Affero General Public License (AGPL) v3. These licenses require the entire program to be released under the same license. ### What are examples of weak copyleft licenses? Examples of weak copyleft licenses include the Mozilla Public License (MPL) 2.0, the Common Development and Distribution License (CDDL), and the GNU Lesser General Public License (LGPL). These licenses only require modifications to the licensed files to be released under the same license.