The major open-source licenses fall on a spectrum from permissive (MIT, BSD, Apache 2.0), which let you do almost anything as long as you preserve attribution, through weak copyleft (LGPL, MPL), which require only the specific open component to stay open, to strong copyleft (GPL, AGPL), which require entire derivative works — and, for the AGPL, even network-hosted services — to be shared under the same terms. Choosing or auditing dependencies means knowing where each license sits on that spectrum, because the difference determines whether you can keep your own code proprietary and what you must disclose when you distribute or host software.
This article is a general comparison of common license terms. It is not legal advice — consult a qualified attorney for decisions about your specific situation.
The Comparison Table
The table below summarizes the seven most common open-source licenses across the dimensions that matter most in practice.
| License | Type | Copyleft strength | Explicit patent grant | Source disclosure required? | Can be used in proprietary software? |
|---|---|---|---|---|---|
| MIT | Permissive | None | No | No | Yes |
| BSD (2/3-clause) | Permissive | None | No | No | Yes |
| Apache 2.0 | Permissive | None | Yes | No | Yes |
| MPL 2.0 | Weak copyleft | File-level | Yes | Only modified MPL files | Yes |
| LGPL | Weak copyleft | Library-level | Yes (v3) | Library and its modifications | Yes (with relinking) |
| GPL | Strong copyleft | Whole work | Yes (v3) | Yes, on distribution | No, if distributed as derivative |
| AGPL | Strong copyleft | Whole work + network | Yes | Yes, including network use | No, if modified and served |
A few takeaways stand out. All three permissive licenses allow proprietary use with no source disclosure; Apache 2.0 is distinguished mainly by its explicit patent grant and its NOTICE-file and change-documentation conditions. The weak-copyleft licenses confine their obligations to the open component itself. The strong-copyleft licenses reach the whole derivative work, and the AGPL uniquely extends that reach to hosted services.
Copyleft vs Permissive: The Core Divide
The single most important axis in any license comparison is whether the license is copyleft or permissive.
Permissive licenses (MIT, BSD, Apache 2.0) impose minimal conditions — essentially attribution — and let you relicense derivatives under any terms, including closed-source. They maximize adoption and are the safest choice for embedding in commercial products.
Copyleft licenses require that the freedoms be preserved downstream. Weak copyleft (LGPL, MPL) limits that requirement to the specific licensed component: modify the library or the MPL file and keep it open, but keep your surrounding code however you like. Strong copyleft (GPL, AGPL) extends the requirement to the entire derivative work when distributed, and the AGPL further extends it to software users reach over a network — closing the "SaaS loophole." Our dedicated concepts library breaks down this spectrum in depth, and the academy turns it into practical policy guidance.
What This Means for Your Project and Compliance
The comparison is only useful if it changes what you do. Three practical rules follow from it.
First, match the license to your distribution model. If you ship closed-source software or build proprietary SaaS, permissive licenses are frictionless, weak copyleft is usually fine with care, and strong copyleft — especially the AGPL — demands scrutiny before adoption. If you never distribute and never expose modified code over a network, even GPL obligations may not trigger, but that is a fragile assumption to build a product on.
Second, watch compatibility. Licenses do not always mix. Apache 2.0 is compatible with GPLv3 but not GPLv2; the retired BSD 4-clause is GPL-incompatible; MPL 2.0 has a secondary-license mechanism specifically to enable GPL combination. Combining incompatible licenses in a distributed work is a genuine legal defect. Our comparison pages detail these relationships.
Third, the obligations survive into transitive dependencies. A permissive-only policy means nothing if a strong-copyleft package rides in three levels deep. The entire comparison collapses to one operational need: an accurate, continuously updated inventory of every license you actually ship.
How Safeguard Tracks License Compliance Across the Spectrum
Comparing licenses on paper is easy; knowing which of them are in your build is the hard part. Real applications carry hundreds or thousands of transitive dependencies spanning every category in the table above.
Safeguard's Software Composition Analysis resolves the license of every open-source component across your full dependency graph and classifies each on the permissive-to-copyleft spectrum, so you can see at a glance where you stand and where a copyleft component may have slipped in. Findings appear in development and CI, where remediation is cheapest.
SBOM Studio records each component's license in a CycloneDX or SPDX software bill of materials, giving legal and engineering teams a single auditable inventory. Policy gates let you encode your organization's rules — permit permissive, review weak copyleft, block strong copyleft in proprietary products — and evaluate every build automatically, turning the abstract comparison into an enforced guardrail. Create a free account to see your own license mix mapped onto this spectrum, or read the documentation to configure a policy.
Frequently Asked Questions
Which open-source license is the most permissive? The MIT and BSD 2-clause licenses are the most permissive in common use: they impose only an attribution condition and are silent on patents. The Apache License 2.0 is also permissive but adds an explicit patent grant plus NOTICE-file and change-documentation conditions, which makes it slightly more involved while offering stronger patent protection. All three allow proprietary, closed-source use.
What is the difference between weak and strong copyleft? Weak copyleft (LGPL, MPL 2.0) confines the reciprocity obligation to the specific open component — the library or the individual file — so your surrounding code can stay proprietary. Strong copyleft (GPL, AGPL) extends the obligation to the entire derivative work when distributed, and the AGPL further extends it to software accessed over a network. Weak copyleft is far easier to combine with proprietary code.
Can I mix code under different open-source licenses? Sometimes, but not always. Compatibility matters: Apache 2.0 combines with GPLv3 but not GPLv2, MPL 2.0 has a mechanism to enable GPL combination, and the deprecated BSD 4-clause is GPL-incompatible. Permissive code generally combines freely, while combining strong-copyleft code with proprietary code in a distributed product is usually not permitted. Verify compatibility before shipping a combined work.
Do permissive licenses have any obligations at all? Yes. Even the most permissive licenses require you to preserve the copyright notice and license text when you redistribute the software. Apache 2.0 additionally requires preserving any NOTICE file and stating significant changes. These attribution duties are easy to satisfy but also easy to forget across hundreds of dependencies, which is why automated inventory matters even for permissive-only projects.