Knowledge base

Permissive vs copyleft licenses

Every open-source license falls on a spectrum from permissive to copyleft. Knowing which is which, and what each obligates you to do, is the core of open-source license compliance.

7 min read · Updated June 26, 2026

Two families, one spectrum

Open-source licenses split into two broad families. Permissive licenses let you do almost anything as long as you preserve the copyright notice. Copyleft licenses add a reciprocity condition: if you distribute the software, or a work derived from it, you have to pass the same freedoms downstream, which usually means sharing your source.

The practical question for a business is always the same: can I use this component in my proprietary product without being forced to release my own code? For permissive licenses the answer is almost always yes. For copyleft it depends on the license and on how you use the component, which is exactly why an SBOM and license scanning matter.

Permissive licenses

Permissive licenses ask for little: keep the license text and attribution, and you can use, modify, and ship the code in closed-source products. The common ones:

MIT: short and very permissive. Keep the copyright notice; do almost anything else.
BSD-2-Clause / BSD-3-Clause: similar to MIT; the 3-clause variant adds a no-endorsement clause.
Apache-2.0: permissive, but with an explicit patent grant and a patent-retaliation clause. That patent protection is why many companies prefer Apache-2.0 over MIT or BSD for anything patent-sensitive.

Copyleft licenses

Copyleft licenses use copyright to guarantee that the freedoms travel with the code. They come in strengths. See what copyleft is and why it matters for the full picture; in short:

Weak / file-level copyleft (LGPL-3.0, MPL-2.0, EPL-2.0): you can combine the component with proprietary code. Only changes to the copyleft-covered files (and, for LGPL, the ability to relink the library) must be shared.
Strong copyleft (GPL-2.0, GPL-3.0): a work that includes GPL code and is distributed must itself be released under the GPL.
Network copyleft (AGPL-3.0): extends strong copyleft to software offered over a network, closing the "software as a service" gap. See what "no AGPL" really means.

The obligations at a glance

License	Family	Use in proprietary product?	Must share your changes?
MIT, BSD, Apache-2.0	Permissive	Yes	No (just keep the notice)
LGPL-3.0	Weak copyleft	Yes, via linking	Changes to the library only
MPL-2.0	Weak copyleft	Yes	Modified MPL files only
GPL-3.0	Strong copyleft	Risky when distributed	Yes, the combined work
AGPL-3.0	Network copyleft	Often banned	Yes, even over a network

SPDX identifiers

Use the canonical SPDX ids in any SBOM. Prefer the -only or -or-later forms (GPL-3.0-or-later, LGPL-3.0-only); the bare GPL-3.0 and LGPL-3.0 identifiers are deprecated.

How teams actually decide

Most engineering organizations run a simple policy: permissive licenses are fine to use freely; weak copyleft is allowed with care; strong copyleft is restricted to code that is never distributed; and AGPL is frequently banned outright. The hard part is not writing that policy, it is enforcing it across hundreds of transitive dependencies on every build. That is the job of license scanning and software composition analysis, driven by your SBOM.

Frequently asked questions

What is the difference between permissive and copyleft licenses?

Permissive licenses (MIT, BSD, Apache-2.0) let you use and modify code in closed-source products as long as you keep the attribution. Copyleft licenses (GPL, LGPL, MPL, AGPL) require you to share your changes, and sometimes your whole combined work, under the same license when you distribute it.

Is the MIT license better than the GPL?

Neither is better; they serve different goals. MIT maximizes adoption and lets anyone use the code anywhere. The GPL maximizes user freedom by requiring that derivatives stay open. The right choice depends on whether you want maximum reuse or guaranteed reciprocity.

Why do companies prefer Apache-2.0 over MIT?

Apache-2.0 includes an explicit patent grant and patent-retaliation clause, giving users protection that the shorter MIT and BSD licenses do not spell out. For patent-sensitive organizations that protection is worth the extra length.

Can I use GPL code in a proprietary product?

If you distribute the product, including GPL code generally requires releasing the combined work under the GPL, which most proprietary vendors will not do. Weak-copyleft licenses like LGPL and MPL are more accommodating, and permissive licenses have no such requirement.

Keep reading

What is copyleft (and why it matters)? Copyleft is the idea that turned open source into a movement. It is also the single licensing concept most likely to surprise a business that did not know it was there. What does "no AGPL" really mean? If you have seen a "no AGPL" rule in a company policy and wondered why one license gets singled out, this explains exactly what it does, and what it does not. What is an SBOM? A Software Bill of Materials is a complete, machine-readable inventory of everything your software is built from. Here is what that means, what goes in one, and why it has become a requirement rather than a nice-to-have.

Sources

Part of the software supply-chain field notes on this site. Written by Antoni K Pestka.