Knowledge base
What is copyleft (and why it matters)?
Copyleft is the idea that turned open source into a movement. It is also the single licensing concept most likely to surprise a business that did not know it was there.
6 min read · Updated June 26, 2026
The core idea
Copyleft uses copyright against itself. A normal copyright restricts what others can do with your work. A copyleft license instead grants broad freedoms to use, study, modify, and share the work, on one condition: anyone who redistributes it must pass those same freedoms downstream. The GNU Project coined the term to describe this reversal, keeping the code and its freedoms legally inseparable.
That reciprocity is the whole point. With a permissive license you can take the code closed. With copyleft you cannot: improvements to the shared code have to flow back out under the same terms.
A short history
Copyleft grew out of the Free Software Foundation and the GNU Project in the 1980s, and its best-known expression is the GNU General Public License (GPL). The version line is easy to remember: GPLv1 in 1989, GPLv2 in June 1991 (the version that carried Linux to the world), and GPLv3 in June 2007.
How it actually works
Copyleft is built on copyright, not in opposition to it. The license grants you rights on the condition that you license your derivative works under the same terms when you distribute them. If you distribute a derivative without complying, you fall outside the license, and distributing copyrighted code without a license is infringement. The condition has teeth precisely because copyright law backs it.
Strong, weak, and network copyleft
Copyleft comes in strengths, and the strength decides how far the obligation reaches:
- Strong copyleft (GPL-2.0, GPL-3.0): a distributed work that incorporates the code must, as a whole, be released under the same license.
- Weak / file-level copyleft (LGPL-3.0, MPL-2.0, EPL-2.0): only the covered files or library carry the obligation; you can combine them with proprietary code. MPL is explicitly file-level, and LGPL is designed so a proprietary program can link the library as long as users can relink against a modified version.
- Network copyleft (AGPL-3.0): extends strong copyleft to software offered to users over a network. See what "no AGPL" really means.
Why a business should care
The risk has a name: license contamination. Pull strong-copyleft code into a proprietary product and distribute it, and you can be obligated to release your own source. Most of the time the reality is milder, because you are not distributing the code, or because it is weak copyleft with a narrow obligation. But mild-most-of-the-time is not a compliance posture. You have to know the copyleft is there.
It hides in the transitive graph
The SBOM of this site surfaced LGPL-3.0 binaries (inside the sharp image library) and MPL-2.0 code (lightningcss) that no one had declared. Weak copyleft, modest obligation here, but invisible until a scan revealed it.
Surfacing copyleft across hundreds of dependencies, on every release, is exactly what an SBOM plus software composition analysis are for.
Has anyone actually been forced to release source?
Yes, copyleft has been upheld in court and enforced through many settlements. But the realistic outcome is narrower than the fear. Companies were made to come into compliance and release the source of the copyleft-covered components, almost always through a settlement. No documented case has forced a company to open-source its entire proprietary product.
- The BusyBox suits (US, 2007 onward). The first US GPL lawsuit (Monsoon Multimedia, 2007) and a wave after it (Verizon, Samsung, Westinghouse) ended in settlements: publish the BusyBox source, appoint a compliance officer, and notify users. Westinghouse, which stopped defending, drew a default judgment with an injunction and damages. Sources: SFLC (Monsoon), SFC (Westinghouse)
- FSF v. Cisco (US, 2008). Over GCC and glibc in Linksys routers. Settled in 2009: Cisco appointed a Free Software Director and released the corresponding source of the FSF programs, not its own firmware. Source: FSF settlement
- gpl-violations.org in Germany (2004 to 2006). Harald Welte won the first rulings upholding the GPL, against Sitecom, Fortinet (which had hidden Linux inside encryption), and D-Link. The courts confirmed the GPL is valid and binding under German law and ordered compliance. Sources: Sitecom, D-Link judgment
- Artifex v. Hancom (US, 2017). Over Ghostscript embedded without a commercial license. A US court held the GPL is enforceable as a contract, not only as a copyright license. The case then settled. Source: FSF (court ruling)
What the cases did not do
In none of them was a company forced to open-source its whole product. The lever was always the same: comply going forward and release the source of the copyleft components. The "use one GPL package and your entire codebase goes public" story is not supported by any documented outcome. One case is often misreported: Hellwig v. VMware was dismissed on an evidentiary technicality and decided nothing about the GPL itself, though VMware later removed the disputed code anyway.
What counts as a modification (and what if you just use it)?
A common assumption is that copyleft only bites if you change the code. That is not how it works. Two things matter more than modification.
- Running it is free. The GPL explicitly does not restrict running the program. Using an unmodified GPL tool, internally, triggers nothing.
- Distribution is the trigger. The obligation attaches when you convey (distribute) the software or a work based on it. Keep it internal and plain GPL asks for nothing. The AGPL is the exception: it extends the trigger to serving a modified version over a network.
So if you use open-source software in a proprietary product without modifying it, whether copyleft reaches your code depends on three questions, not on whether you edited anything:
- Do you distribute it? Internal-only use of plain GPL imposes no source obligation.
- Is it combined into your program, or kept separate? The FSF’s position is that linking GPL code into your program, statically or dynamically, makes the whole thing a derivative work that must be GPL when distributed. Bundling a genuinely separate program that communicates at arm’s length (a separate process, pipes, the command line) is "mere aggregation" and does not affect your code. Worth knowing: this linking theory has never been settled by a US court and respected lawyers disagree, so most companies treat it as a risk to avoid rather than a decided rule.
- Which license is it? Often the deciding factor. LGPL and MPL are weak copyleft built precisely for the used-but-not-modified, linked case: you can link an LGPL library or include MPL files in a proprietary product without your code becoming copyleft, as long as you meet the narrow conditions (LGPL: let users relink a modified library; MPL: share changes to the MPL files only).
The short version
"We did not modify it" is the wrong question. Ask instead: do we distribute it, is it linked into our code or run as a separate program, and is it strong copyleft (GPL, AGPL) or weak (LGPL, MPL). Those three decide it.
This is a working explanation, not legal advice. The boundaries, especially what counts as a derivative work, are genuinely contested, and a real decision deserves a lawyer.
Frequently asked questions
What does copyleft mean?
Copyleft is a licensing approach that uses copyright to guarantee that software stays free: you may use and modify the code, but if you redistribute it you must license your version under the same terms, passing the same freedoms to the next person.
Is copyleft the opposite of copyright?
No. Copyleft is built on copyright. It uses the copyright owner’s rights to attach a reciprocity condition, rather than to restrict copying. Without copyright law, copyleft would have nothing to enforce.
What is the difference between strong and weak copyleft?
Strong copyleft (GPL) requires the entire distributed work that includes the code to use the same license. Weak copyleft (LGPL, MPL) limits the obligation to the covered files or library, so you can combine it with proprietary code.
Is the MIT license copyleft?
No. MIT is a permissive license. It lets you use the code in closed-source products with no obligation to share your changes, which is the opposite of copyleft reciprocity.
Has a company ever been forced to release source because of the GPL?
Companies have been compelled, by settlement or court ruling, to comply and release the source of the GPL-covered components, as in the BusyBox suits and FSF v. Cisco. No documented case has forced a company to open-source its entire proprietary product.
Does copyleft apply if I use open-source code but do not modify it?
It can. Copyleft turns on whether you distribute the software and whether the code is linked into your program, not on whether you modified it. Running unmodified GPL code internally triggers nothing, but linking it into a distributed product can. Weak-copyleft licenses like LGPL and MPL are designed to allow linking without affecting your code.
Does linking to a GPL library make my program GPL?
The Free Software Foundation says yes, that linking statically or dynamically creates one derivative work that must be GPL when distributed. No US court has settled the question and it is legally contested, but most companies avoid linking GPL libraries into proprietary code to stay safe. The LGPL exists specifically to permit linking.
Keep reading
Sources
Part of the software supply-chain field notes on this site. Written by Antoni K Pestka.