Copyleft means using copyright law in reverse: instead of restricting what others can do with your work, a copyleft license grants broad freedom to use, modify, and share the software on the condition that derivative works carry the same freedoms forward. The term is a deliberate pun on "copyright" — where copyright reserves rights to the author, copyleft uses that same legal authority to guarantee the software stays free for everyone downstream. If you have ever wondered why using a GPL library can obligate you to release your own source code, copyleft is the mechanism behind it.
Understanding copyleft is not academic. It directly shapes which open source components you can safely build a proprietary product on, which is why it belongs in any engineering conversation about dependencies.
The core idea: freedom that propagates
A copyleft license gives you the four freedoms associated with free software: to run the program, to study and modify it, to redistribute copies, and to distribute your modified versions. In exchange, it attaches one reciprocal condition — when you distribute a modified version or a work built on the licensed code, you must release it under the same copyleft license and make the corresponding source available.
That reciprocity is the entire point. It prevents someone from taking freely licensed code, improving it, and locking the improvements away as proprietary software. The freedoms do not just apply to the original; they propagate to every derivative. This is what people mean when they call copyleft "viral" — though "reciprocal" is the fairer word, since the obligation is a condition you accept in exchange for the grant, not an infection.
Copyleft versus permissive licensing
The clearest way to grasp copyleft is to contrast it with the other main family of open source licenses.
Permissive licenses — MIT, BSD, Apache 2.0 — grant the same freedoms to use and modify but attach almost no reciprocal condition. You can take MIT-licensed code, build a closed-source commercial product on it, and never share your changes. You typically must preserve the copyright notice and license text, but that is close to the extent of it.
Copyleft licenses attach the reciprocal string. Take copyleft code, build on it, distribute the result, and you owe the community your source under the same terms. Neither model is better in the abstract; they encode different goals. Permissive licensing prioritizes maximum adoption and business flexibility. Copyleft prioritizes keeping the software and its descendants free. Which one matters to you depends on whether you are consuming the code or publishing it.
Strong versus weak copyleft
Copyleft is not one setting; it comes in degrees, and the degree determines how far the reciprocal obligation reaches.
Strong copyleft, exemplified by the GPL, extends the obligation to the entire combined work. If you link GPL code into your application and distribute it, the whole application generally falls under the GPL, which means releasing all of its source. This is the strictest form and the one that catches teams off guard.
Weak copyleft, exemplified by the LGPL and the Mozilla Public License, limits the obligation to the licensed component itself. You must share modifications to the copyleft library, but you can link it into a larger proprietary application without that application inheriting the license. The MPL draws the line at the file level: changed files stay open, new files you add can be proprietary. Weak copyleft is a middle path that keeps the library free without pulling your whole product along.
There is also a network-scope variant. The AGPL extends strong copyleft to cover software offered over a network, closing the gap where a hosted service was never technically "distributed." If you run modified AGPL software as a web service, you owe its source to your users. That distinction matters enough that AGPL dependencies deserve their own scrutiny, which we cover in more depth in our GNU AGPL v3 guide.
Why copyleft matters for your dependencies
The practical risk is inheriting an obligation you did not intend. A developer adds a GPL-licensed library to a proprietary product, the project ships, and the company has now, arguably, triggered an obligation to release its source. For a business built on keeping that source closed, discovering this during acquisition due diligence is a genuinely bad day.
The complication is that copyleft licenses arrive transitively. You vet your direct dependencies, but one of them pulls in a copyleft package three levels down that you never chose. Manual review of your top-level dependency list will not find it. This is exactly the visibility problem software composition analysis solves — resolving the full dependency graph and reporting every component's license, so a strong-copyleft package buried deep in the tree gets flagged before it ships. A tool such as Safeguard's SCA surfaces those transitive license obligations as part of the same scan that finds vulnerable dependencies.
Working with copyleft, not against it
Copyleft is not a hazard to avoid; it is a set of terms to respect. Plenty of successful products use copyleft software correctly. The workflow that keeps you safe is straightforward: define a license policy that classifies permissive, weak-copyleft, and strong-copyleft licenses; enforce it in CI so a strong-copyleft dependency triggers a review rather than sliding through; and when you do use copyleft code, comply — share the source you owe, preserve notices, and use weak-copyleft or permissive alternatives where a strong-copyleft obligation would conflict with your distribution model. The goal is conscious decisions, not accidental obligations.
FAQ
What does copyleft mean in simple terms?
Copyleft uses copyright law to guarantee software stays free: it grants everyone the right to use, modify, and share the code, on the condition that any derivative work you distribute carries the same freedoms and makes its source available. It is copyright turned toward openness rather than restriction.
What is the difference between copyleft and permissive licenses?
Copyleft licenses require derivative works you distribute to be released under the same license with source available — a reciprocal obligation. Permissive licenses like MIT and Apache 2.0 let you build closed-source products on the code without sharing changes, requiring little more than preserving the copyright notice.
What is the difference between strong and weak copyleft?
Strong copyleft, like the GPL, extends the source-sharing obligation to your entire combined work when distributed. Weak copyleft, like the LGPL or MPL, limits the obligation to the licensed component itself, so you can link it into a proprietary application without that application inheriting the license.
How do I find copyleft licenses in my dependencies?
Use license scanning within software composition analysis, which resolves your full transitive dependency graph and reports each component's license. This catches copyleft packages several levels deep that reviewing only your direct dependencies would miss, letting you enforce a license policy before shipping.