What Is Copyleft

Legacy context

This independent educational reference site preserves and explains foundational concepts in digital culture and licensing. The following entry offers a neutral, historical overview of the term "copyleft," based on widely documented public discussions.

Copyleft is a licensing method that uses copyright law to guarantee every user the freedom to use, modify, and distribute a work—provided that any derivative versions remain under the same terms. Unlike traditional copyright, which restricts copying, copyleft flips the default: it grants permissions while preventing others from imposing new restrictions on future adaptations. The concept emerged in the 1980s within software development, most notably through the GNU Project, as a deliberate counterweight to proprietary licensing. Its core principle is often summarized as "all rights reversed," though it operates entirely within existing legal frameworks. This page serves as a starting point for further research and does not represent any organization or current legal advice.

What Is Copyleft? A Practical Explainer for Developers and Businesses

Copyleft is a legal mechanism that uses copyright law to achieve the opposite of its traditional purpose. Instead of reserving all rights, a copyleft license grants broad permissions to use, modify, and distribute software—but with a critical condition: any derivative work you distribute must be licensed under the same copyleft terms. In short, copyleft ensures that improvements to a piece of software remain available to everyone under the same freedoms.

This guide explains how copyleft works, how it differs from permissive licenses, when to choose it, common mistakes, and a compact reference table for daily decisions.

1. The Core Mechanism: Copyright as a Lever

Copyleft is not a separate legal system. It relies on standard copyright law. The author of a work automatically holds exclusive rights (reproduction, modification, distribution). A copyleft license is a grant of those rights, but it is conditional.

The most famous example is the GNU General Public License (GPL). Under GPL version 3, you may run, study, share, and modify the software. However, if you distribute a modified version, you must:

• Provide the complete corresponding source code.
• License the derivative work under the same GPL version (or a compatible later version).
• Preserve copyright notices and disclaimers.
• Not add further restrictions on recipients.

The condition applies to "derivative works." In software, that usually means linking, modifying, or embedding the copyleft code into a larger program. The boundary of what counts as a derivative work is a legal question, not a technical one. Courts have not uniformly defined it across all jurisdictions. In practice, the Free Software Foundation (FSF) argues that dynamic linking creates a derivative work; some developers disagree. You should treat that ambiguity as a risk factor, not a certainty.

2. Copyleft vs. Permissive Licenses: The Decision Criteria

Permissive licenses (MIT, Apache 2.0, BSD) allow you to use, modify, and redistribute code under any license you choose, including proprietary. You may keep your changes closed-source. Copyleft licenses force your changes to remain open under the same terms.

Use this decision matrix:

• Choose copyleft (GPL, AGPL) if: your goal is to build a commons, prevent proprietary forks, or ensure that user-facing network services share their modifications. AGPL extends copyleft to software accessed over a network, closing the "SaaS loophole" where a modified GPL program is run on a server without distribution.
• Choose permissive (MIT, Apache) if: you want maximum adoption, including by commercial vendors who will not share their changes. Permissive licenses are common in libraries and SDKs because they reduce legal friction.
• Choose weak copyleft (LGPL, MPL) if: you want to allow proprietary code to link to your library, but require modifications to the library itself to be shared. LGPL is for libraries; MPL (Mozilla Public License) is file-based, so only modified files must be shared.

3. Common Mistakes and Misunderstandings

Mistake 1: "Copyleft means no one can charge money." False. You can sell copyleft software. The GPL explicitly allows charging for distribution. What you cannot do is restrict the buyer from redistributing it for free. The price is a business decision, not a license violation.

Mistake 2: "If I use GPL code, my entire project must be GPL." Not automatically. The obligation triggers only when you distribute a derivative work. If you use GPL code as a separate process (e.g., a command-line tool invoked by your proprietary script), that may not create a derivative work. But if you link it into your binary, it almost certainly does. The safest assumption: if the copyleft code is combined into a single executable or library, the combined work is derivative.

Mistake 3: "I can avoid copyleft by not distributing." True for GPL, but not for AGPL. If you run a modified AGPL program on a server and let users interact with it, you must offer the source code to those users. This is a common trap for web startups.

Mistake 4: "I can change the license of the copyleft code." No. You cannot relicense someone else's code. You can only choose the license for your own original contributions. If you mix GPL and proprietary code, the combined work must be distributed under GPL-compatible terms. You cannot strip the copyleft.

Mistake 5: "Copyleft is viral and infects everything." The "viral" label is misleading. The condition applies to derivative works, not to independent programs that merely communicate with the copyleft code via standard interfaces (e.g., HTTP APIs). The boundary is legal and fact-specific. Do not rely on analogies; consult a lawyer for high-stakes decisions.

4. Practical Compliance Steps

If you decide to use copyleft code in a project you will distribute, follow these steps:

1. Identify the license version. GPL-2.0 and GPL-3.0 are not fully compatible. GPL-2.0-only code cannot be combined with GPL-3.0-only code. Check the SPDX identifier in the source header.
2. Keep source and binary together. When you distribute a binary, provide the corresponding source on a durable medium (e.g., a link to a tarball) or a written offer valid for three years.
3. Include the license text. Do not omit the full license text or the copyright notices. A common failure is copying code without the header.
4. Track provenance. Maintain a file (e.g., THIRD_PARTY_NOTICES) listing every copyleft component, its version, and its license. This is not optional; it is a compliance requirement.
5. Use compatible licenses for your own code. If you write new code that links to GPL libraries, your code must be GPL-compatible. You can choose GPL-3.0 or Apache-2.0 (which is compatible with GPL-3.0 but not GPL-2.0). MIT is compatible with both.

5. Compact Actionable Reference

Scenario	Recommended License	Key Obligation
You want all derivatives to stay open	GPL-3.0	Distribute source with binary
You run a web service and want modifications shared	AGPL-3.0	Offer source to network users
You write a library and allow proprietary linking	LGPL-3.0	Share changes to the library itself
You want maximum adoption, no copyleft	MIT or Apache-2.0	None (attribution only)
You modify a file in an MPL project	MPL-2.0	Share only the modified file's source