Introduction
Open-source software (OSS) licenses define how code can be used, modified, redistributed, or integrated into other software systems. While many licenses allow developers to freely incorporate open-source components into proprietary applications, others impose strong copyleft obligations that may legally require organizations to disclose their own source code if they integrate the licensed components.
This article compares the major OSS license families GPL, AGPL, LGPL, SSPL, MPL, Apache, MIT, BSD with a focus on how they impact commercial, closed-source development.
1. Understanding Copyleft vs. Permissive Licensing
Permissive Licenses
Permissive licenses (MIT, BSD, Apache) allow almost unrestricted use:
- Code can be copied, modified, and included in proprietary software.
- You are not required to open-source your own code.
- Only minimal obligations apply (e.g., copyright notice).
Zero risk for proprietary software.
Copyleft Licenses
“Copyleft” licenses impose obligations:
- If you modify the covered code and distribute it, you must make your modifications open-source.
- Stronger copyleft licenses force your entire application to become open-source if you link them.
Copyleft has two categories:
1. Weak Copyleft
- Applies only to the modified files or components under that license.
- Your proprietary code can remain closed.
Examples: LGPL (dynamic link), MPL, EPL, CDDL
2. Strong Copyleft
- Extends to any program that links, combines, or interacts with the licensed code.
- Your entire application may need to be open-sourced.
Examples: GPL, AGPL, SSPL (very strong)
2. Analysis of Strong Copyleft Licenses
2.1 GPL (GNU General Public License – v2 & v3)
Key Principle
If you link GPL code (even dynamically) into your application, the entire application becomes a derivative work, and you must release the entire source code under GPL.
Implications for proprietary software
- GPL code cannot be used in commercial closed-source applications.
- Any distribution of GPL-linked software requires open-source disclosure.
- GPLv3 adds anti-tivoization and patent clauses, making it even more restrictive.
Strength
Strong copyleft.
2.2 AGPL (Affero General Public License)
Why it is stronger than GPL
AGPL closes the “SaaS loophole”.
Even if you NEVER distribute the software, but only run it as a hosted service, you must still provide full source code to users who interact with it.
Impact
If AGPL code runs in:
- A backend API
- A microservice
- An internal platform exposed to users
→ You must open-source your modifications and often the entire stack.
Strength
Very strong copyleft, extends through the network.
2.3 SSPL (Server Side Public License)
MongoDB’s replacement for AGPL
SSPL requires:
- If you use the software as a service,
- You must open-source not only your modifications
- BUT also “the entire service stack”, including:
- Deployment scripts
- Orchestration tooling
- Monitoring code
- Any management software
This makes SSPL incompatible with almost all proprietary cloud services.
Strength
Extreme copyleft, broader than AGPL, not OSI approved.
3. Weak Copyleft Licenses
3.1 LGPL (Lesser GPL)
Dynamic linking allowed
If you dynamically link to an LGPL library:
- Your code can remain closed-source.
- Only modifications to the LGPL component must be disclosed.
Static linking danger
If statically linked, LGPL behaves similarly to GPL:
→ Your code may be considered a derivative work → forces disclosure.
Strength
Weak-to-medium copyleft, depending on linking.
3.2 MPL (Mozilla Public License)
File-level copyleft
If you modify MPL-licensed files:
- Only those files (not your entire project) must remain open-source.
Safe for proprietary projects
As long as MPL files stay separate.
3.3 CDDL & EPL
Similar to MPL:
- Copyleft applies per file/module.
- Proprietary code remains proprietary.
Strength
Weak copyleft.
4. Permissive Licenses (Safe for Commercial Use)
4.1 MIT License
- Minimal obligations.
- Allows reuse in proprietary software.
4.2 Apache 2.0
- Patent protection included.
- Safe for enterprise usage.
4.3 BSD Licenses
- Similar permissive terms to MIT.
Strength
Zero copyleft.
5. High-Level Comparison Table
| License | Copyleft Strength | Requires Open-Sourcing Entire App? | SaaS Obligation? | Safe for Proprietary Use? |
|---|---|---|---|---|
| GPL-2.0 / GPL-3.0 | Strong | Yes | No | ❌ No |
| AGPL-3.0 | Very Strong | Yes | Yes | ❌ No |
| SSPL | Extreme | Yes | Yes – full service stack | ❌ No |
| LGPL | Weak/Medium | Only if static link | No | ⚠️ Usually |
| MPL-2.0 | Weak | No | No | ✔ Yes |
| EPL / CDDL | Weak | No | No | ✔ Yes |
| MIT / BSD | None | No | No | ✔✔ Yes |
| Apache 2.0 | None | No | No | ✔✔ Yes |
6. Summary of Key Differences
GPL / AGGPL / SSPL (strong copyleft)
- Forces open-sourcing of your code if linked or combined.
- AGPL forces disclosure for network services.
- SSPL forces disclosure of entire cloud infrastructure stack.
LGPL / MPL / CDDL / EPL (weak copyleft)
- Only modifications to the licensed files must be shared.
- Your proprietary code can remain closed.
MIT / BSD / Apache (permissive)
- No obligation to open-source your own code.
- Minimal restrictions.
Mahyar Notes