License guide · Copyleft
Copyleft licenses, in plain English
Copyleft is the “give-back” side of open source: you get broad rights to use and change the code, but if you distribute it — or something built from it — you have to pass those same freedoms on and share your source. That single idea, applied more or less strictly, is what separates LGPL from GPL from AGPL — and it’s what decides whether you can ship proprietary or commercial software on top of it.
Updated 27 Jul 2026 · by the depproof team
General information, not legal advice. The controlling text is always the specific license and how it applies to your facts; confirm any “can we ship this?” decision with counsel. License names below are used nominatively to refer to the licenses they identify.
Copyleft vs permissive: the core split
Open-source licenses fall into two broad families, and the difference is entirely about what you owe back.
- Permissive (MIT, Apache-2.0, BSD). Do almost anything — including taking the code closed and shipping it inside proprietary software — as long as you keep the copyright notice and license text. There is no obligation to share your changes.
- Copyleft (LGPL, MPL, GPL, AGPL). Reciprocal. You get the same broad rights, but on the condition that when you distribute the work, your derivative is licensed under the same terms and the corresponding source is made available. The freedoms are designed to travel downstream with the code and everything built from it.
Neither is “more commercial” than the other — you can sell copyleft software. The practical question is narrower: can you keep the combined work closed while distributing it? Permissive says yes. Copyleft says it depends on how strong the copyleft is.
The copyleft spectrum: weak → strong → network
Copyleft isn’t one setting; it’s a dial. The further right you go, the wider the reciprocal obligation reaches around your own code.
- Permissive (MIT, Apache-2.0, BSD) — no reciprocity. The baseline for comparison, not copyleft at all.
- Weak copyleft (LGPL-3.0, MPL-2.0) — the obligation stays at the boundary of the licensed component. Share your changes to that component, but you can link it into a larger proprietary program without the whole program becoming subject to the license. MPL applies this per-file; LGPL applies it to the library.
- Strong copyleft (GPL-2.0 / GPL-3.0) — the obligation reaches the whole combined or derivative work. Distribute a program that incorporates GPL code and the entire distributed work generally must be offered under the GPL, with source.
- Network copyleft (AGPL-3.0) — strong copyleft plus a network trigger. Letting users interact with the software over a network counts like distribution, so even a never-“shipped” SaaS deployment can owe source disclosure.
The trigger that matters: distribution
Almost every copyleft obligation is dormant until a specific event fires. For the GPL family, that event is distribution — conveying the software (or a derivative of it) to a third party. Modify GPL code, run it, and improve it entirely inside your organization, and you generally owe nothing: no obligation to publish your changes kicks in until you hand the software to someone else.
AGPL-3.0 is the deliberate exception. Its network clause was written to close the “SaaS loophole,” treating making the software available to users over a network like distribution. So the trigger you have to watch shifts from “are we shipping a binary?” to “are outside users reaching this over the network?” — a much easier line to cross without noticing.
Can you ship proprietary or commercial software on copyleft code?
This is the decision legal is usually being asked to make. It comes down to three things: how strong the copyleft is, whether you distribute (or expose over a network), and how the code is combined (linked vs. a genuinely separate work). At a high level:
| Can you… | Weak copyleft LGPL, MPL-2.0 | Strong copyleft GPL-2.0/3.0 | Network copyleft AGPL-3.0 |
|---|---|---|---|
| Use it internally / privately, unmodified | Yes | Yes | Yes, but network use may trigger obligations |
| Modify it and keep the changes private (no distribution) | Yes | Yes | No if users reach it over a network — share source |
| Distribute a derivative work | Yes — publish changes to the component under the same license | Yes — the whole work must be under the GPL, with source | Yes — same as GPL, with source |
| Combine with proprietary code and distribute the closed result | Usually yes — keep the component replaceable / linked, not merged | No — the combined work is generally GPL | No — same as GPL |
| Offer it to users over a network (SaaS) without sharing source | Generally yes — no network trigger | Generally yes — GPL has no network trigger | No — network use requires offering source to those users |
| Sell it / use it commercially | Yes | Yes | Yes |
The recurring theme: “commercial” is never the blocker. What copyleft constrains is keeping the combined work closed while you distribute or expose it. Weak copyleft leaves room to do that around a replaceable component; strong and network copyleft largely do not. The riskiest real cases are borderline linking questions — see the individual GPL, LGPL, and AGPL guides for the specifics.
Where copyleft trips up dependency & license policy
The copyleft component that hurts you is rarely one you chose. It arrives transitively — a permissively licensed package you added on purpose pulls in a GPL or AGPL dependency several levels down that nobody reviewed. If your product is distributed or offered as SaaS, that buried component can create exactly the obligations the table above warns about, and it typically surfaces at the worst moment: a release gate, a customer audit, or acquisition due diligence.
The practical control is to know the license of every dependency in your tree — not just the direct ones — so copyleft is flagged and reviewed before it ships, not after.
- Check your Maven dependency licenses — surface GPL, LGPL, AGPL, and everything else across the full transitive tree.
- Check your npm dependency licenses — the same, for JavaScript and Node projects.
- See license posture across every repo — for legal and compliance teams that need org-wide visibility, not one project at a time.
Frequently asked questions
What is a copyleft license?
A copyleft license is an open-source license that is “reciprocal”: it grants you broad rights to use, modify, and redistribute the code, but on the condition that when you distribute the software (or a derivative work built from it), you license those changes under the same terms and make the corresponding source available. The goal is to keep the code and everything derived from it open. This is the opposite of a permissive license like MIT, Apache-2.0, or BSD, which lets you take the code closed with essentially only an attribution requirement.
What is the difference between weak, strong, and network copyleft?
They differ in how far the reciprocal obligation reaches. Weak copyleft (LGPL, MPL-2.0) generally keeps the obligation at the boundary of the licensed component itself — you must share changes to that component, but you can link it into a larger proprietary program without the whole program becoming subject to the license. Strong copyleft (GPL-2.0, GPL-3.0) reaches the whole combined/derivative work: distribute it and the entire work must be offered under the GPL with source. Network copyleft (AGPL-3.0) is strong copyleft plus an extra trigger: offering the software to users over a network counts like distribution, so a SaaS deployment can create source-disclosure obligations even though nothing is “shipped.”
Does copyleft apply if I only use the software internally?
For classic copyleft (LGPL, MPL, GPL), generally no. The reciprocal obligations of the GPL family are triggered by distribution — conveying the software to a third party. Using and modifying GPL software purely inside your organization, without distributing it, typically does not require you to publish your changes. The major exception is AGPL-3.0, whose network clause treats interaction with users over a network like distribution, so an internal-only tool that outside users reach over the network can still trigger obligations.
Can I ship proprietary or commercial software that depends on copyleft code?
It depends on the license’s strength, whether you distribute, and how the code is combined. Weak copyleft (LGPL, MPL-2.0) is usually compatible with shipping a proprietary application as long as you keep the licensed component replaceable and publish your changes to it. Strong copyleft (GPL) is the hard case: if you distribute a work that is a derivative of GPL code, the whole distributed work generally must be offered under the GPL — which is incompatible with keeping it proprietary. AGPL extends that reasoning to network use. “Commercial” is not the problem — you can sell GPL software — the constraint is keeping the combined work closed while distributing it.
Does linking to a GPL library make my whole program GPL?
This is the linking question at the heart of copyleft, and it turns on whether your program plus the library form a single derivative work. The Free Software Foundation’s position is that linking a GPL library into your program creates a combined work, so distributing it means the whole work must be GPL. That is exactly why the LGPL exists — it was written to let a library be linked into proprietary software without imposing the license on the whole program, provided users can relink against a modified version. If a component is licensed under plain GPL rather than LGPL and you link it into distributed software, treat the combined work as subject to the GPL unless counsel advises otherwise.
Why does copyleft matter for my dependency and license policy?
Because the risk usually arrives transitively. A permissively licensed package you added on purpose can pull in a GPL or AGPL dependency several levels down that nobody chose or reviewed. If your product is distributed or offered as SaaS, that buried copyleft component can create obligations you didn’t plan for — and it tends to surface at the worst moment, during a release gate, an audit, or due diligence. The practical control is to inventory the license of every transitive dependency, not just your direct ones, and flag copyleft explicitly so legal can make the “can we ship this?” call before it ships.
Read next
- License compatibility matrix — which of these you can actually combine, arranged by what you are shipping.
- GPL-3.0 explained — strong copyleft and what “the whole work” really covers.
- LGPL-3.0 explained — weak copyleft and the linking exception it was built for.
- AGPL-3.0 explained — the network clause in detail.
- Apache-2.0 vs GPL-3.0 — permissive against copyleft, side by side, and the one-way compatibility rule between them.
- Is AGPL safe for commercial and SaaS use? — the network trigger applied to a real product decision.
General information, not legal advice; confirm specific decisions with counsel. License names such as GPL, LGPL, MPL, and AGPL are used nominatively to refer to the licenses they identify.