Copyleft is a condition attached to an open source licence: you can use, study, modify and share the code freely, but if you distribute a copy or a modified version to someone else, you must also give them the corresponding source under the same or a compatible licence. The trigger is distribution, not use.
That single distinction answers most of the confusion around it. Running a copyleft library inside a private build server is not the same act as shipping a product that contains it, and the difference decides whether your project has to open up. This guide walks through where the obligation comes from, which licences are strong and which are weak, and what a developer actually has to do before a release goes out.
Nothing here is legal advice. Licence obligations turn on the exact text and version you accepted plus the specific facts of your build and distribution, so treat this as a map of the territory and get a qualified lawyer to sign off on anything that matters commercially. Last updated in 2026.
Table of Contents
- What Is Copyleft? A Plain-English Definition
- How Does Copyleft Affect Your Project?
- How Copyleft Licensing Works
- Strong Copyleft vs. Weak Copyleft
- What Triggers Copyleft Obligations?
- Can You Use Copyleft Code in a Commercial Project?
- How to Assess a Copyleft Project Before Release
- How to Choose the Right License for Your Project
- Frequently Asked Questions
- Does copyleft mean my entire project must be open source?
- Can I modify GPL or LGPL code for a proprietary application?
- Does using copyleft software in a private company trigger an obligation?
- Does copyleft apply to software delivered only through a website or API?
- What is the difference between GPL, LGPL, MPL, and AGPL?
- Key Takeaways for Your Project
What Is Copyleft? A Plain-English Definition
Copyleft is a licence condition that keeps modified versions of a program available under the same terms as the original. Copyright by default reserves every right; copyleft grants you broad rights to use, copy, modify and share the work, then adds a share-alike clause that obliges you to pass those freedoms on when you distribute your version.
The word is a deliberate play on copyright, and the two are not opposites in the way people assume. Copyright is the legal right that exists automatically the moment an author fixes their work in a tangible form. Copyleft is a set of conditions the author attaches to the permission to use that work, and those conditions are enforced through copyright law itself.
You will hear copyleft called reciprocal licensing, which is the accurate description, and viral licensing, which is the misleading one. Nothing is viral about it. A share-alike condition travels with the code and with derivatives of the code, not with your entire company, your other products or your internal processes.
Two terms worth having straight right away. A derivative work is a work based on the original, modified or not, in the sense the copyright statutes use. An aggregate is several separate works simply shipped in the same package, which the GPL treats as something other than a single combined work.
How Does Copyleft Affect Your Project?
Copyleft affects a project at the moment you convey the software to someone else, and the practical effect depends on how far the share-alike obligation reaches. In the weakest case you add a notice. In the strongest case your entire combined application has to be published under the same licence.
Here is how the common situations line up.
| What you do | Does a copyleft obligation kick in? | What you owe |
|---|---|---|
| Use a copyleft library internally, never shipping it | No, for the GPL and LGPL | Nothing beyond keeping the notices intact |
| Modify copyleft code and use it only inside your own company | No, for the GPL and LGPL | Nothing, but your forks stay privately licensed |
| Ship a product that bundles copyleft code | Yes | Corresponding source, licence text and notices for the covered work |
| Run copyleft software as a hosted service | Yes under the AGPL only | Network users must be offered the source of your modified version |
| Publish a modified copy of a library on your own | Yes, scoped by the licence | File-level release for the MPL, whole-work release for the GPL |
| Contribute a patch upstream | No, your patch stays yours | You are already publishing under the project’s licence |
Beyond source access, copyleft usually requires you to keep the copyright notice and the licence text intact, to mark any changes you made, and to pass along the same licence terms with what you distribute. Apache 2.0 is the counter-example most developers should know: it is permissive, but it carries an explicit patent grant, so a patent worry that a bare MIT licence leaves open is closed there.
Compatibility is where projects get stuck. If a dependency is copyleft and your own code is under a licence that cannot be combined with it, the fix is usually to swap the dependency before you ship, not to argue about the boundary afterwards. Developers describe this in forum threads as the moment a technically ideal library turns into a release blocker.
How Copyleft Licensing Works
Think of the obligation as a lifecycle with four stages. A maintainer publishes code under a copyleft licence. You obtain it, usually through a package manager, and you receive it with the licence attached. You then do something with it, and only the third and fourth stages matter legally.
Stage one: you receive it. The licence is part of the download. GitHub, npm, PyPI and package repositories all carry the licence text, and using the code in good faith means you took it with those terms attached. No notice does not mean no licence; it means all rights reserved, which is a separate and much more restrictive default.
Stage two: you decide what to do with it. Keeping it on your own machines, building with it, running it, testing it, reading it, and even modifying it privately all stay inside your company. This is the part almost every developer gets right once they hear it stated plainly.
Stage three: you distribute. The moment you hand a copy to someone outside your organisation, whether as a binary, a container image, an appliance, a downloaded installer or a copy of a modified library, obligations attach. A copy you give to a contractor, a customer or another company’s team all count as distribution.
Stage four: the obligation flows downstream. Anyone who receives your distributed version inherits the same requirement, and the chain continues as long as copies keep moving. That is the part that makes downstream reciprocity work in practice.
The GPL expresses this in Section 5, which asks you to license the entire work, as a whole, under the GPL when you convey it. Section 2 is the counterweight: the safe harbours that let a larger program remain separately licensed when it is merely an aggregate, sitting beside the copyleft code rather than fused into it.
Strong Copyleft vs. Weak Copyleft
Strong copyleft reaches the whole combined work. Weak copyleft, sometimes called file-level copyleft, reaches only the files that carry the licence or only the library you link. The practical difference is how much of your own codebase you have to publish.
| Licence | Type | Trigger | Scope of the obligation | Typical fit |
|---|---|---|---|---|
| GPL-3.0 | Strong | Distribution of binaries or source | Entire combined work, as a whole | Kernel, compiler, tools where you want improvements to flow back |
| AGPL-3.0 | Strong, network | Distribution or offering the program over a network | Entire combined work, plus hosted use | Hosted services where you want cloud deployments to count |
| LGPL-3.0 | Weak, library | Distribution of the library | The library itself; you must allow relinking | Shared libraries that proprietary applications link against |
| MPL-2.0 | Weak, file-level | Distribution of covered files | Only the files that were modified | Projects that want patches back but not a full release |
| EPL-2.0 | Weak, file-level | Distribution of covered files | Modified files, plus new files that compete with them | Enterprise frameworks and plugins |
The LGPL boundary turns on a technical fact rather than a legal doctrine. If you link the library dynamically, meaning it is loaded at runtime through a shared object, you can generally keep your application under your own terms. If you link it statically, meaning the library’s code is copied into your binary at build time, the obligation reaches your application too, unless you provide the object files or shared-library build inputs needed to relink a modified version.
That rule is genuinely contested, and courts have not settled it across jurisdictions. Treat it as a working heuristic rather than a guarantee, and keep the relinking ability if you want a defensible position.
One more distinction worth keeping: copyleft conditions attach to copyright, not to patents. If a patent grant matters to your business model, read the specific patent clause. Apache 2.0 grants one explicitly; the GPL family does not, and that gap is a real consideration in corporate review.
What Triggers Copyleft Obligations?
Copyleft obligations are triggered by conveying copies, not by using code, with one important extension for network software. The actions that most often fire the trigger are shipping a compiled binary, publishing a container image, distributing a modified library under your own name, and offering a modified program to users over a network.
Container images deserve their own line. Pushing a base image that contains AGPL or GPL components to a registry, then letting customers run it, has been treated by several projects’ own analyses as distribution. Whether your customers’ copies of your application are new conveyances of the covered work is a fact-specific question, and it is exactly the kind of thing that stalls a release until someone reads the licence text carefully.
Conveying a copy does not require a sale. A company shipping free software to its customers is still distributing it, and a maintainer donating a tool to a non-profit is still distributing it. Payment only matters for the separate question of commercial use, which copyleft permits in every case.
Because obligations turn on the specific text you accepted, never assume all copyleft licences behave the same. GPL version 2 and version 3 differ in patent and anti-tivoisation terms, LGPL has its own relinking mechanics, and MPL operates at a completely different granularity. Check the version identifier, and treat the SPDX short form on your dependency’s manifest as the starting point rather than the answer.
Can You Use Copyleft Code in a Commercial Project?
Yes. Every mainstream open source licence, copyleft included, permits commercial use. Selling a product built on GPL code is lawful; what you owe in return is the corresponding source for the covered work, offered to every recipient of the binary on the same terms.
In practice there are four workable outcomes, and most teams land on one of them:
Publish the combined work under a compatible licence. This is the standard path with a strong copyleft dependency. You keep selling it, and your code goes out under terms your users can use and modify.
Isolate the copyleft component. Keeping the library behind a process boundary, an API call or a separate service can keep your application an aggregate rather than a combined work. Whether a given architecture is genuinely separate is fact-specific, and this is one of the most-litigated areas of open source law.
Preserve the notices and ship the source offer. For LGPL, providing the relinkable build inputs or object files for the library can satisfy the condition while your own application stays closed.
Retain proprietary rights where the licence permits it, or buy a commercial licence. Some projects offer dual licensing, letting you choose the open source half or a paid alternative. Several maintainers have also asked in public for a licence stronger than the AGPL to protect their own improvements, which tells you how live this area remains.
If your dependency graph is large, you are shipping on-prem to enterprise customers, or the rearchitecture cost would hurt, that is the point to bring in a lawyer. Not because the question is exotic, but because a well-defined opinion is worth more than an afternoon of forum archaeology.
How to Assess a Copyleft Project Before Release
Assess a project before release by treating licensing as an inventory problem, not a reading exercise. The list below is roughly Monday-morning work for a team shipping a product with third-party dependencies.
1. List direct dependencies. Start with the manifest files in your repositories: package.json, requirements.txt, Cargo.toml, go.mod, pom.xml. Every entry has a licence field, and that field is the entry point to the actual text.
2. Walk the transitive tree. Your direct dependencies drag in their own dependencies, and the copyleft licence is often two or three levels down. Dependency scanning and SBOM generation exist for exactly this step, and running one in CI turns a quarterly scramble into a build-time warning.
3. Read the exact version, not the family name. GPL-2.0-only and GPL-3.0-or-later are different obligations. Copy the SPDX identifier for each copyleft component into a file you control.
4. Map your modifications. Mark every file you have changed that is covered by a copyleft licence. Under the MPL that list defines your entire obligation; under the LGPL it defines your relinking duties; under the GPL it starts the question of whether the whole work is covered.
5. Mark your distribution boundary. Write down every channel through which the software leaves your organisation, including container registries, mobile app stores, hardware shipments and customer-managed deployments. Internal-only use and distribution have different answers.
6. Check the notice and source-offer mechanics. Confirm the licence text ships with the product, the copyright notice survives, changes are marked where required, and the corresponding source offer points somewhere durable. A written request route can satisfy some licences, so a link is convenient rather than mandatory in every case.
7. Verify compatibility before release, not after. If a planned dependency cannot be combined with your licence, replace it now. Swapping a library in a container build is a day; rearchitecting a shipped product is a quarter.
8. Record the result. Keep the inventory, the notices and the correspondence in the repository. When a customer or acquirer asks about your licence hygiene three years later, you will want evidence rather than memory.
How to Choose the Right License for Your Project
Choose a licence by deciding which outcome you want, not by copying whatever a similar project used. The four real models are permissive, weak copyleft, strong copyleft and network copyleft, and each optimises for something different.
| Licence | Model | Commercial use | Patent grant | Best fit |
|---|---|---|---|---|
| MIT or BSD-3-Clause | Permissive | Yes, with notice | No | Maximising adoption, including inside closed products |
| Apache-2.0 | Permissive plus patent | Yes, with notice and NOTICE file | Yes, explicit | Corporate and patent-sensitive contexts |
| MPL-2.0 | Weak, file-level | Yes, on modified files | Yes | Getting patches back without a full release |
| LGPL-3.0 | Weak, library | Yes, with relinking rights | Yes, limited | Libraries meant to be linked by proprietary apps |
| GPL-3.0 | Strong | Yes, source required on distribution | No explicit grant | Tools where downstream improvements matter most |
| AGPL-3.0 | Strong, network | Yes, source required on network use too | No explicit grant | Hosted services that want cloud use to count as distribution |
If adoption is your priority, permissive wins and the trade-off is simple: you gain reach and give up the guarantee that improvements come back. If reciprocity is your priority, strong copyleft wins and the trade-off is that some companies will not touch your project because their legal review will not clear it, which practitioners describe as a real gate rather than a preference.
A weak copyleft licence is the compromise many maintainers actually choose, and it is worth considering seriously. You get modifications returned for the files people touched, without forcing your whole codebase into the open.
Two extra decisions sit alongside the licence choice. Dual licensing lets you sell a commercial licence to companies that want to stay closed, funded by the ones who take the open option. And if you are relicensing an existing project, you need contributor consent, because you cannot unilaterally relicense code you no longer hold the rights to. A CLA or a copyright assignment collected up front prevents that argument later.
Whichever route you take, adding a licence file and a commit history check to CI will not cost you much. Several open projects moved to stronger copyleft and debated exactly this adoption-versus-funding trade-off publicly while doing it.
Frequently Asked Questions
Does copyleft mean my entire project must be open source?
Not automatically. With weak copyleft such as LGPL or MPL 2.0, only the library or the modified files are affected, and your own application can stay closed if you meet the relinking or file-scope conditions. With the GPL or AGPL, distributing a combined work means the whole work goes out under the same terms. If you only use the code inside your own company and never distribute it, no obligation is triggered at all.
Can I modify GPL or LGPL code for a proprietary application?
Yes, and the GPL is explicit that private modification is unrestricted. The obligation appears when you distribute. Ship a proprietary app containing modified GPL code and the whole combined work must be released under the GPL with corresponding source. Under the LGPL, the same app can usually stay proprietary if you link the library dynamically, or if you ship the object files needed to relink a modified version.
Does using copyleft software in a private company trigger an obligation?
For the GPL, LGPL, MPL and most other licences, no. They are triggered by conveying copies outside your organisation, and internal use, testing, modification and even building a product that never ships are all fine. The exception is the AGPL, which extends the trigger to offering the program as a service over a network. Some licences also ask for source offers when you distribute internally across legal entities.
Does copyleft apply to software delivered only through a website or API?
Only if the licence is the AGPL, or another licence with a network clause. The GPL and LGPL are distribution licences, so running a copyleft server behind a browser usually changes nothing for you. The AGPL adds a network use trigger: if you modify the program and let users interact with it remotely, you must offer them the source of your modified version. That is the clause most SaaS teams discover late.
What is the difference between GPL, LGPL, MPL, and AGPL?
They differ mainly in scope and trigger. The GPL is strong copyleft covering the whole combined work on distribution. The AGPL is the same, plus a trigger when you offer the software over a network. The LGPL is weak copyleft aimed at libraries, letting proprietary applications link as long as relinking stays possible. The MPL 2.0 is file-level copyleft, so only the files you modified are affected when you distribute.
Key Takeaways for Your Project
Start by inventorying the code. Generate an SBOM, mark every copyleft component with its exact version, and write down whether you modify, combine or distribute it, because that answer decides which section of this guide applies to you.
The rule that carries the most weight is short: using copyleft code is fine, shipping a combined work is where the obligation starts. Copyleft asks you to keep the commons open when you pass software along, and it never asks you to stop charging for it.
