LFCA 110 🐧 Copyleft vs Permissive Licenses
Open source licenses fall into two broad philosophical camps: permissive and copyleft. The distinction is not about whether the software is free to use — both allow that — but about what happens to derivative works. Permissive licenses grant broad freedoms with minimal conditions, allowing the code to be incorporated into proprietary products. Copyleft licenses grant the same freedoms but require that derivative works carry the same license, ensuring that the software remains open as it evolves and spreads.
This chapter covers the philosophical foundations of each approach, the specific obligations each imposes, the concept of license propagation, the compatibility issues that arise when licenses are combined, and the practical decision of which approach to use for a given project.
Key point: Permissive licenses (MIT, BSD, Apache 2.0) allow proprietary derivatives with minimal attribution requirements. Copyleft licenses (GPL, AGPL, LGPL, MPL) require that derivative works remain under the same license and that source code be shared. The difference determines whether your code can be incorporated into closed-source products.
Why the distinction exists
The freedom-for-users versus freedom-for-software problem. Permissive licenses prioritize the freedom of users to do what they want with the code, including incorporating it into proprietary products. Copyleft licenses prioritize the freedom of the software itself, ensuring that it cannot be locked away in a proprietary derivative. Both are “free software” under the Free Software Foundation’s definition, but they disagree about what protects freedom in the long run.
The tragedy-of-the-commons problem. If everyone can take from a commons and enclose what they take, the commons shrinks. A developer who releases code under a permissive license may find that a company incorporates it into a proprietary product, improves it, and never contributes the improvements back. Copyleft prevents this by requiring that improvements be shared, keeping the commons from being enclosed.
The adoption-versus-protection problem. Permissive licenses maximize adoption because they remove friction. Companies can use the code without legal review of obligations, and they can combine it with proprietary code without fear of copyleft propagation. Copyleft licenses maximize protection of the commons but reduce adoption by companies that are unwilling to open-source their derivatives. The choice is a trade-off, not a right answer.
The commercial-use problem. A company building a proprietary product cannot use GPL code without either open-sourcing the product or obtaining a commercial license from the copyright holder. This makes GPL a poor choice for libraries intended to be used by proprietary software. Permissive licenses have no such restriction.
The compatibility problem. Different licenses have different obligations, and combining code under incompatible licenses creates legal risk. GPL v2 is incompatible with Apache 2.0, so a project cannot combine GPL v2 code with Apache 2.0 code and distribute the result. GPL v3 is compatible with Apache 2.0. Understanding compatibility is essential when assembling a project from multiple sources.
a. Permissive licenses
Permissive licenses impose minimal conditions on reuse. They grant permission to use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software, subject to attribution and the disclaimer of warranty.
MIT is the simplest. It requires that the copyright notice and permission notice be included in all copies or substantial portions of the software. There is no requirement to share modifications, no copyleft propagation, and no patent grant.
BSD is similar. The 2-Clause version is nearly identical to MIT. The 3-Clause version adds a restriction against using the names of contributors to endorse derived products without permission.
Apache 2.0 adds an explicit patent grant and a NOTICE file requirement. The patent grant is irrevocable unless the licensee initiates patent litigation. The NOTICE file must be preserved in distributions.
The key characteristic of permissive licenses is that they do not propagate. A derivative work can be licensed under any terms, including proprietary terms. The original code remains under its original license, but the derivative as a whole can be proprietary.
| License | Attribution | Patent Grant | Source Disclosure | Proprietary Derivatives |
|---|---|---|---|---|
| MIT | Yes | No | No | Allowed |
| BSD 2-Clause | Yes | No | No | Allowed |
| BSD 3-Clause | Yes + no endorsement | No | No | Allowed |
| Apache 2.0 | Yes + NOTICE | Yes | No | Allowed |
b. Copyleft licenses
Copyleft licenses grant the same permissions as permissive licenses but add a condition: derivative works must be distributed under the same license, and source code must be made available. This condition is what makes copyleft “viral” — it propagates to anything that incorporates the licensed code.
GPL (GNU General Public License) is the canonical strong copyleft license. Any work that is based on GPL code must be licensed under GPL, and the complete corresponding source code must be provided when the work is distributed.
AGPL (Affero GPL) extends copyleft to network use. Where GPL triggers source disclosure on distribution, AGPL triggers it when the software is made available over a network. This closes the “SaaS loophole” where a company could modify GPL software, run it as a service, and never distribute it.
LGPL (Lesser GPL) is weak copyleft designed for libraries. Modifications to the LGPL-licensed library must be shared, but the library can be linked into proprietary applications without requiring the entire application to be open-sourced.
MPL (Mozilla Public License) is file-level copyleft. Modifications to MPL-licensed files must be shared, but the license does not propagate to other files in the larger work.
| License | Scope | Source Disclosure | Proprietary Derivatives |
|---|---|---|---|
| GPL v2/v3 | Whole derivative work | Yes, on distribution | Not allowed |
| AGPL | Whole derivative work | Yes, on network use | Not allowed |
| LGPL | Library modifications | Yes, library only | Allowed with conditions |
| MPL 2.0 | File modifications | Yes, modified files | Allowed with conditions |
c. License propagation
License propagation is the mechanism by which copyleft licenses extend their terms to derivative works. The scope of propagation determines how much of a combined work is affected.
Strong copyleft (GPL, AGPL) propagates to the entire derivative work. If you link GPL code with proprietary code, the combined work is subject to GPL. The legal interpretation of “derivative work” and “linking” varies, but the practical guidance is that any work that includes GPL code and is distributed must be GPL.
Weak copyleft (LGPL, MPL) propagates only to the licensed component. Modifications to LGPL libraries must be shared, but the application that links to them can remain proprietary. Modifications to MPL files must be shared, but other files in the same project are unaffected.
Permissive licenses do not propagate. The derivative work can be licensed under any terms.
The propagation question is what determines whether a license is suitable for a given use. A permissive library can be used anywhere. A weak copyleft library can be used in proprietary software as long as modifications to the library are shared. A strong copyleft library cannot be used in proprietary software that is distributed.
d. License compatibility
License compatibility is whether two licenses can be combined in a single work. Incompatible licenses cannot be combined without violating one or both.
GPL v2 is incompatible with Apache 2.0. The Apache 2.0 patent retaliation clause adds conditions that GPL v2 does not permit, so a work combining GPL v2 and Apache 2.0 code cannot be distributed. GPL v3 was written to be compatible with Apache 2.0, so GPL v3 and Apache 2.0 code can be combined.
MIT and BSD are compatible with almost everything. Their minimal conditions do not conflict with other licenses. Apache 2.0 is compatible with GPL v3 but not GPL v2. GPL v2 and GPL v3 code cannot be combined in a single work because the licenses are different.
The practical implication is that projects assembling code from multiple sources must verify compatibility. A project that uses GPL v2 code cannot include Apache 2.0 code. A project that uses GPL v3 code can include Apache 2.0 code. A project that uses MIT code can include almost anything.
e. Choosing between them
The choice between permissive and copyleft depends on what you want to happen downstream.
Choose permissive when you want maximum adoption, when the code is a library intended for broad use, when you do not want to impose obligations on users, or when you want companies to be able to build proprietary products on top of your code without legal review.
Choose copyleft when you want to ensure that improvements flow back to the community, when you want to prevent proprietary enclosure of your code, when you are building a project that should remain open in all derivatives, or when you want to use copyleft as leverage for a dual-licensing business model.
Choose weak copyleft when you want improvements to a specific component to remain open but you also want the component to be usable in proprietary applications. LGPL and MPL serve this purpose.
Choose AGPL when you want copyleft to apply to network use as well as distribution. This is appropriate for server software that is offered as a service.
Complete Example Session
# ============================================
# PART 1: IDENTIFY THE LICENSE
# ============================================
ls LICENSE*
head -5 LICENSE# ============================================
# PART 2: PERMISSIVE LICENSE DETECTION
# ============================================
grep -l "Permission is hereby granted" LICENSE*
# MIT detected# ============================================
# PART 3: COPYLEFT LICENSE DETECTION
# ============================================
grep -l "GNU GENERAL PUBLIC LICENSE" LICENSE*
# GPL detected# ============================================
# PART 4: CHECK PROPAGATION SCOPE
# ============================================
# Strong copyleft: whole work affected
# Weak copyleft: component only
grep -i "lesser\|library" LICENSE# ============================================
# PART 5: CHECK COMPATIBILITY
# ============================================
# GPL v2 incompatible with Apache 2.0
# GPL v3 compatible with Apache 2.0
grep -i "version 2\|version 3" LICENSE# ============================================
# PART 6: AUDIT DEPENDENCIES
# ============================================
npx license-checker --summary# ============================================
# PART 7: CHECK FOR COPYLEFT IN PROPRIETARY PRODUCT
# ============================================
npx license-checker --failOn "GPL;AGPL"# ============================================
# PART 8: GENERATE ATTRIBUTION FILE
# ============================================
npx license-checker --json > licenses.json
# Include in THIRD_PARTY_NOTICES.md# ============================================
# PART 9: DUAL LICENSING CHECK
# ============================================
# Some projects offer GPL + commercial
grep -i "commercial\|dual" README.md# ============================================
# PART 10: COMPLIANCE SUMMARY
# ============================================
# Permissive: safe for proprietary
# Copyleft: requires compliance
# Incompatible combinations: avoidThese ten parts cover license identification, permissive vs copyleft detection, propagation scope, compatibility checking, dependency auditing, copyleft prohibition in proprietary products, attribution file generation, dual licensing, and compliance summary.
Quick Reference
Comparison
| Aspect | Permissive | Copyleft |
|---|---|---|
| Examples | MIT, BSD, Apache 2.0 | GPL, AGPL, LGPL, MPL |
| Attribution | Required | Required |
| Source disclosure | No | Yes |
| Derivative license | Any | Same license |
| Proprietary use | Allowed | Restricted |
| Propagation | None | Strong or weak |
Propagation Scope
| License | Propagates To |
|---|---|
| MIT, BSD, Apache 2.0 | Nothing |
| MPL | Modified files only |
| LGPL | Library modifications |
| GPL, AGPL | Entire derivative work |
Compatibility
| Combination | Compatible |
|---|---|
| MIT + anything | Yes |
| Apache 2.0 + GPL v3 | Yes |
| Apache 2.0 + GPL v2 | No |
| GPL v2 + GPL v3 | No |
| BSD + GPL | Yes |
Choosing a License
| Goal | License |
|---|---|
| Maximum adoption | MIT |
| Adoption + patent clarity | Apache 2.0 |
| Library usable in proprietary | LGPL |
| File-level copyleft | MPL |
| Ensure derivatives stay open | GPL |
| Close SaaS loophole | AGPL |
Best Practices
✅ Do This:
# Audit dependencies for license types
npx license-checker --summary
# Preserve attribution and NOTICE files
# Check compatibility before combining
# Consult legal for copyleft in proprietary
# Document license obligations❌ Don’t Do This:
# Use GPL in proprietary distributed product
# Combine incompatible licenses
# Remove copyright notices
# Assume "open source" means "no rules"Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| GPL in proprietary product | Unaware of copyleft | Audit dependencies |
| Incompatible license combination | Not checked | Verify compatibility |
| Missing attribution | Notices removed | Include notices file |
| AGPL ignored in SaaS | Network trigger overlooked | Review AGPL obligations |
| LGPL treated as permissive | Misunderstanding weak copyleft | Share library modifications |
Visual
The License Spectrum
┌──────────────────────────────────────────────────────────────┐
│ PERMISSIVE WEAK COPYLEFT STRONG COPYLEFT │
│ ─────────── ───────────── ─────────────── │
│ MIT LGPL GPL v2/v3 │
│ BSD MPL AGPL │
│ Apache 2.0 EPL │
│ │
│ Fewer obligations ◀──────────────────▶ More obligations │
│ More adoption More sharing │
│ Proprietary OK Proprietary NO │
└──────────────────────────────────────────────────────────────┘Propagation
┌──────────────────────────────────────────────────────────────┐
│ PERMISSIVE: │
│ Your code + MIT code → Your code can stay proprietary │
│ │
│ WEAK COPYLEFT: │
│ Your code + LGPL library → Library changes shared, │
│ your code stays proprietary │
│ │
│ STRONG COPYLEFT: │
│ Your code + GPL code → Entire work must be GPL │
└──────────────────────────────────────────────────────────────┘Compatibility
┌──────────────────────────────────────────────────────────────┐
│ MIT ──────── compatible with everything │
│ Apache 2.0 ── compatible with GPL v3, not GPL v2 │
│ GPL v2 ────── incompatible with Apache 2.0, GPL v3 │
│ GPL v3 ────── compatible with Apache 2.0, not GPL v2 │
│ BSD ──────── compatible with GPL │
└──────────────────────────────────────────────────────────────┘Choosing a License
┌──────────────────────────────────────────────────────────────┐
│ Do you want proprietary derivatives allowed? │
│ │ │
│ ├── Yes ──▶ Want patent clarity? │
│ │ ├── Yes ──▶ Apache 2.0 │
│ │ └── No ──▶ MIT or BSD │
│ │ │
│ └── No ──▶ Do you want derivatives to stay open? │
│ ├── Yes ──▶ GPL │
│ │ │
│ └── Network use? ──▶ AGPL │
│ │
│ Library usable in proprietary? ──▶ LGPL or MPL │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Permissive | Minimal conditions; proprietary derivatives allowed |
| Copyleft | Derivatives must use same license; source shared |
| Strong copyleft | GPL, AGPL; propagates to entire work |
| Weak copyleft | LGPL, MPL; propagates to component only |
| MIT | Simplest permissive; attribution only |
| Apache 2.0 | Permissive + patent grant |
| GPL | Strong copyleft; source disclosure on distribution |
| AGPL | Network copyleft; source disclosure on network use |
| LGPL | Weak copyleft for libraries |
| Propagation | Scope of copyleft obligation |
| Compatibility | Whether licenses can be combined |
Key takeaways:
- Permissive licenses allow proprietary derivatives. MIT, BSD, and Apache 2.0 grant broad freedoms with only attribution requirements. They do not propagate to derivative works .
- Copyleft licenses require derivatives to remain open. GPL, AGPL, LGPL, and MPL require that derivative works carry the same license and that source code be shared. The scope of this requirement varies by license .
- Strong copyleft propagates to the entire work. GPL and AGPL affect everything that incorporates the licensed code. A proprietary application that links GPL code must be released under GPL .
- Weak copyleft propagates only to the component. LGPL and MPL affect the licensed library or file but allow the larger application to remain proprietary. Modifications to the licensed component must be shared .
- License compatibility matters. GPL v2 is incompatible with Apache 2.0. GPL v3 is compatible with Apache 2.0. MIT and BSD are compatible with almost everything. Combining incompatible licenses creates legal risk .
- The choice depends on goals. Permissive licenses maximize adoption and allow proprietary derivatives. Copyleft licenses ensure that improvements flow back to the community and prevent proprietary enclosure.
- Auditing is essential. Organizations must track the licenses of all open source components and ensure that their use complies with the terms. License scanning tools automate this process .
Remember: The distinction between permissive and copyleft is about what happens downstream. Permissive licenses say “do what you want, just give credit.” Copyleft licenses say “do what you want, but derivatives must remain open.” Neither is better in the abstract; they serve different goals. Permissive licenses are appropriate when you want your code to be widely adopted, including by companies building proprietary products. Copyleft licenses are appropriate when you want to ensure that your code and its improvements remain open source forever. Weak copyleft licenses are appropriate when you want a library to be usable in proprietary applications but also want improvements to the library to be shared. Understanding these distinctions, and the compatibility issues that arise when licenses are combined, is essential for anyone working with open source software.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!