Copyleft is a licensing method in software that uses copyright law to grant broad freedoms to use, study, modify and share a program, on the condition that redistributed versions carry the same freedoms. Instead of reserving rights to the author, a copyleft license turns those rights into an obligation that travels with the code, so that derivative works cannot be made proprietary.
In software licensing, copyleft is the defining feature of licenses such as the GPL, the LGPL, the AGPL and the Mozilla Public License. It sits in contrast to permissive licenses such as the MIT license and the Apache License, which allow code to be absorbed into closed products. Understanding where a copyleft obligation starts and stops is one of the most practical skills in open source compliance.
How copyleft uses copyright to keep code free
Copyleft works because copyright is the default: without a license, nobody may copy or adapt a program. A copyleft license grants these permissions, but only under conditions. If a recipient distributes the program or a modified version, the license requires them to pass on the same license and to provide the complete corresponding source code.
The mechanism has three parts. First, a grant of freedoms covers running, studying, changing and redistributing the code. Second, a reciprocity condition obliges anyone who distributes a covered work to license it under the same terms. Third, a source availability requirement ensures that recipients can actually exercise those freedoms, because freedom to modify means little without the source.
The obligation is triggered by a specific act, usually distribution or conveyance of the work to another party. Private modification and internal use generally trigger nothing. This detail explains why a company can run modified GPL software on its own servers without publishing the changes, and why the AGPL was created to close that gap.
The following table separates the elements that a copyleft license combines and shows what each one achieves in practice.
| Element | What it requires | Practical effect |
|---|---|---|
| Freedom grant | Permission to run, study, modify and share | Recipients may build on the code |
| Same-license rule | Derivatives keep the original license | Freedoms cannot be stripped downstream |
| Source obligation | Complete corresponding source on distribution | Changes remain visible and reusable |
| No added restrictions | No extra terms that limit the granted rights | Prevents closed layers on top |
| Termination clause | Rights end on violation, often with a cure period | Gives the license enforcement power |
Strong, weak and network copyleft
Copyleft licenses differ mainly in the scope of the reciprocity condition, meaning how much surrounding code must adopt the same license. The usual classification distinguishes strong copyleft, weak copyleft and network copyleft, although the boundaries depend on the exact license text.
Strong copyleft extends to the whole combined work. If a program links a GPL library into a single executable, the combination as a whole must be distributed under the GPL. Weak copyleft limits the obligation to the licensed component itself: changes to an LGPL library or to an MPL file must be shared, but the application that uses them may stay under another license.
| Variant | Typical licenses | Scope of obligation | Trigger |
|---|---|---|---|
| Strong copyleft | GPL-2.0, GPL-3.0 | Entire combined or derived work | Distribution |
| Weak copyleft (library) | LGPL-2.1, LGPL-3.0 | The library and changes to it | Distribution |
| Weak copyleft (file) | MPL-2.0, EPL-2.0 | Modified licensed files only | Distribution |
| Network copyleft | AGPL-3.0 | Whole work, including network use | Distribution or remote interaction |
Network copyleft addresses software as a service. Under the AGPL, users who interact with a modified program over a network must be offered its source, even though no copy is distributed. This makes the AGPL the most demanding common copyleft license for hosted applications and the one that legal teams review most carefully.
Copyleft compared with permissive licensing and public domain
Copyleft is one of two broad strategies within open source and free software licensing. Both strategies grant the freedoms of the Open Source Definition and the Free Software Definition, but they differ in what they demand from redistributors. Permissive licenses require little more than keeping the copyright notice, while copyleft licenses require reciprocity.
The comparison below shows how copyleft relates to permissive licensing, to public domain dedication and to proprietary licensing on the key questions a project or adopter faces.
| Question | Copyleft | Permissive | Public domain dedication | Proprietary |
|---|---|---|---|---|
| May the code be modified | Yes | Yes | Yes | Usually no |
| Must derivatives stay open | Yes, same license | No | No | Not applicable |
| Can it enter closed products | Only within the license scope | Yes, with attribution | Yes | Yes |
| Main condition | Reciprocity and source | Notice and license text | None | Contract terms |
| Typical examples | GPL, AGPL, MPL | MIT, BSD, Apache-2.0 | CC0, Unlicense | Commercial EULA |
A frequent misconception equates copyleft with free software and permissive licensing with open source. Both license families satisfy both definitions. The difference is a policy choice about whether freedoms should be protected downstream or merely offered once.
License compatibility and combining code
Because a copyleft license forbids additional restrictions, code under two different copyleft licenses often cannot be combined into one distributed work. License compatibility is the question of whether the terms of two licenses can be satisfied at the same time for a combined work.
Permissive code can usually flow into a copyleft project, because the permissive terms impose nothing the copyleft license forbids. The reverse direction is blocked. Some pairs are explicitly reconciled: Apache-2.0 is compatible with GPL-3.0 but not with GPL-2.0, because of its patent termination clause. MPL-2.0 includes a secondary license provision that allows combination with the GPL family unless the author opts out.
| Combination | Outcome | Reason |
|---|---|---|
| MIT code into a GPL-3.0 program | Allowed | Permissive terms add no restriction |
| Apache-2.0 code into a GPL-3.0 program | Allowed | GPL-3.0 accepts its patent terms |
| Apache-2.0 code into a GPL-2.0-only program | Not allowed | Patent clause counts as extra restriction |
| GPL-2.0-only and GPL-3.0 code together | Not allowed | Each version forbids the other terms |
| LGPL library used by a proprietary application | Allowed with conditions | Relinking and notice duties apply |
The phrase or any later version matters here. A project licensed as GPL-2.0-or-later can be combined with GPL-3.0 code, whereas a GPL-2.0-only project cannot. Checking the exact license identifier, ideally in SPDX form, prevents many compatibility errors.
Practical compliance and common mistakes
Compliance with copyleft rests on a few repeatable duties: identify every licensed component, determine whether the product is distributed, and if it is, provide license texts, notices and complete corresponding source. A software bill of materials and automated license scanning make these duties manageable in large codebases.
Most violations arise from misunderstanding the trigger or the scope rather than from deliberate misuse. The table lists frequent mistakes and how practitioners avoid them.
| Mistake | Consequence | Prevention |
|---|---|---|
| Shipping firmware without source | Breach of GPL distribution terms | Publish matching source with each release |
| Ignoring AGPL in a hosted service | Duty to offer source to network users | Review AGPL components before deployment |
| Statically linking LGPL code | Relinking duty becomes harder to meet | Prefer dynamic linking or supply object files |
| Removing license notices | Loss of rights and attribution breach | Keep notices in source and documentation |
| Assuming internal use triggers nothing everywhere | Surprise when software is later sold | Track components from the first commit |
Enforcement usually aims at restoring compliance rather than collecting damages. GPL-3.0 added a cure period: a first violation that is fixed within 30 days of notice restores the license automatically. Even so, the legal risk is real, and courts in several jurisdictions have treated copyleft terms as enforceable license conditions.
Stripped to the essentials
Copyleft is a share-alike rule for software. The author says: you may use my code, change it and give it to others, but if you pass on your version, you must give the next person the same freedoms and the source code too.
Think of a community recipe book where anyone may copy a recipe and improve it, but anyone who hands out an improved recipe must also allow others to copy and improve it. Nobody can lock a recipe away. That is the whole idea: freedom that cannot be taken away later.
Where it is applied
A manufacturer of home network routers builds its firmware on the Linux kernel, which is licensed under GPL-2.0, and adds its own drivers and patches to the kernel. Because the routers are sold to customers, the firmware is distributed, and the copyleft condition applies.
The compliance team therefore publishes the complete kernel source for every firmware version, including the modified drivers, build scripts and configuration, and includes a written offer for the source in the product documentation. The proprietary web interface runs as a separate program that talks to the kernel through standard interfaces, so it stays closed.
The outcome is a product that keeps its own user interface private while meeting the GPL obligations in full. Independent developers can later use the published source to build alternative firmware, which is exactly the downstream freedom that copyleft is designed to protect.