What Is Copyleft

Legacy context

This site is an independent educational reference dedicated to clarifying open licensing terminology. The term “copyleft” describes a method for using copyright law to ensure that a work—and its derivatives—remain freely available for sharing and modification. Rather than restricting use, copyleft licenses grant broad permissions, provided that any distributed versions carry the same freedoms forward.

Because the preserved historical records for this archive are currently empty, we cannot verify specific past definitions or organizational origins. We therefore present this explanation as a general, neutral introduction to the concept, based on common usage in open-source and creative communities. Visitors seeking authoritative legal interpretations should consult current license texts or qualified legal counsel. This archive does not offer legal advice or represent any active institution.

What Is Copyleft? A Practical Explainer for Developers and Businesses

If you have ever read a software license and seen the phrase "you must distribute your source code under the same license," you have encountered copyleft. Copyleft is a legal mechanism that uses copyright law to achieve the opposite of its usual purpose: instead of restricting copying, it guarantees that everyone who receives a copy of the work can use, modify, and redistribute it—provided they keep those same freedoms for the next recipient.

This guide explains how copyleft works, where it fits in the open-source spectrum, how to choose between copyleft and permissive licenses, and the mistakes that trip up developers and companies.

The Core Idea: Copyright Turned Upside Down

Copyright grants the author exclusive rights to copy, modify, and distribute a work. A permissive license (like MIT or BSD) says: "You may do almost anything, but you must keep the attribution notice." A copyleft license says: "You may do almost anything, but if you distribute the work or a derivative, you must provide the complete corresponding source code under the same license."

The term was coined by Richard Stallman in the 1980s. The canonical example is the GNU General Public License (GPL). The mechanism is simple: the license is a conditional grant of rights. You receive the right to use and modify the software only if you agree to pass on the same rights to others. If you violate the condition (for example, by distributing a modified version without source), your rights terminate automatically.

Strong vs. Weak Copyleft: The Spectrum

Not all copyleft is equal. The distinction matters for practical decisions.

• Strong copyleft (e.g., GPL-3.0, AGPL-3.0): If you link, combine, or modify the code into a larger program, the entire combined work must be licensed under the same copyleft terms. The AGPL adds a special clause: if you make the software available over a network (e.g., a web service), you must offer the source code to those users, even if you do not distribute copies.
• Weak copyleft (e.g., LGPL-2.1, MPL-2.0): The copyleft applies only to the specific files that came from the original project. You can link an LGPL library into a proprietary application without releasing your own source code, as long as you allow the user to replace the library with a modified version (typically by providing relinkable object files). The MPL applies copyleft at the file level, so you can mix MPL files with proprietary files in the same project.
• Permissive (e.g., MIT, Apache-2.0): No copyleft. You can incorporate the code into proprietary software and never share your changes.

How Copyleft Works in Practice: A Concrete Example

Imagine you download a GPL-licensed library, modify it to fix a bug, and then distribute your application as a compiled binary to a customer. Under GPL, you must:

1. Provide the complete corresponding source code for the modified library.
2. License that source code under the same GPL version.
3. Include the license text and copyright notices.
4. Make the source available in a "preferred form for modification" (e.g., not obfuscated).

If you only use the library internally and never distribute it, the copyleft obligation does not trigger. If you run it as a web service, the GPL does not require source disclosure (but the AGPL does).

Choose copyleft when:

• You want to guarantee that improvements to your code remain available to the community.
• You are building a public infrastructure or a standard that should not be forked into proprietary silos.
• You want to prevent a competitor from taking your code, adding proprietary features, and closing the result.
• You are writing a library that you want to be used in open-source projects but not in proprietary ones (use GPL for that; use LGPL if you want broader adoption).

Choose permissive when:

• You want maximum adoption, including by commercial companies that will not open their source.
• You are working on a small utility where the "viral" effect is not important.
• You are employed by a company that requires permissive licenses for legal simplicity.
• You want to avoid the administrative burden of tracking copyleft boundaries in a large codebase.

Common Mistakes and Failure Modes

1. Assuming "distribution" means "public release." In many jurisdictions, providing software to a single client under a contract is distribution. Internal use is not. If you give a modified GPL program to a contractor, you likely trigger the obligation.
2. Mixing copyleft and permissive code without tracking provenance. A single GPL file in a proprietary project can force the entire combined work to be GPL. Always run license scanners (e.g., FOSSA, ScanCode) before release.
3. Using the wrong version of the GPL. GPL-2.0 and GPL-3.0 are not compatible in all directions. GPL-2.0-only code cannot be combined with GPL-3.0 code unless the GPL-2.0 code has an "or later" clause. The LGPL-2.1 and LGPL-3.0 have similar incompatibilities.