LFCA 108 🐧 Open Source Licensing — Overview
Open source licenses fall into a spectrum from permissive to strong copyleft, and understanding where each license sits on that spectrum is essential for anyone working with open source software. The choice of license determines what you can and cannot do with code, whether you must share your modifications, and what obligations you carry when distributing software.
Key point: Permissive licenses (MIT, BSD, Apache 2.0) allow proprietary reuse with minimal requirements, usually just attribution. Copyleft licenses (GPL) require derivative works to use the same license and share source code. Weak copyleft (LGPL, MPL) applies copyleft only to the licensed component, not the entire application that uses it.
Why open source licensing exists
The legal foundation problem. Software is protected by copyright by default. Without a license, no one has the right to use, modify, or distribute your code, even if you publish it publicly. An open source license grants those rights explicitly, with conditions that define what “open” means for that project.
The collaboration problem. Open source thrives on contribution, but contributions require clear terms. A license defines the rules under which others can use, modify, and redistribute the code. Without a license, potential contributors and adopters have no legal basis to participate.
The business model problem. Different licenses support different business models. Permissive licenses maximize adoption and allow companies to build proprietary products on top. Copyleft licenses ensure that improvements flow back to the community, and dual-licensing models use copyleft as leverage to sell commercial exceptions.
The compliance problem. Organizations must track the licenses of the open source components they use. A permissive license is safe for commercial products; a strong copyleft license may require open-sourcing proprietary code. Misunderstanding a license creates legal risk.
a. The license spectrum
Open source licenses exist on a spectrum from highly permissive to strongly protective. The Open Source Initiative (OSI) approves licenses that meet the Open Source Definition, which requires free redistribution, source code availability, and no discrimination against persons, groups, or fields of endeavor.
Permissive licenses impose minimal restrictions. They allow anyone to use, modify, and distribute the code, including in proprietary software, as long as they preserve copyright notices.
Weak copyleft licenses occupy the middle. They require that modifications to the licensed component itself remain open source, but allow the component to be combined with proprietary code in a larger work.
Strong copyleft licenses sit on the other end. They require that derivative works and combined works use the same license and that source code be provided. The license “propagates” to software that incorporates or links with the licensed code.
b. Permissive licenses: MIT, BSD, and Apache 2.0
Permissive licenses are the most widely used because they impose almost no conditions on reuse.
The MIT License is the simplest and most common, requiring only that the copyright notice and license text be preserved. Projects using MIT include React, Angular, Node.js, and jQuery.
The BSD licenses are similar. The 2-Clause version is nearly identical to MIT. The 3-Clause version adds a restriction against using the names of copyright holders to endorse derived products without permission.
The Apache License 2.0 is also permissive but adds explicit patent protection. It includes a patent grant from contributors and a patent retaliation clause that terminates the grant if the licensee sues contributors for patent infringement. This makes Apache 2.0 attractive for corporate-backed projects where patent clarity matters. It is compatible with GPL v3 but not GPL v2. Kubernetes, TensorFlow, Android, and Apache Kafka use Apache 2.0.
The key implication for organizations is that permissive licenses are safe for commercial use. You can incorporate MIT, BSD, or Apache 2.0 code into proprietary software without releasing your own source. The only requirement is attribution — preserving copyright notices, typically in documentation or an “About” dialog.
c. Copyleft licenses: GPL and AGPL
The GNU General Public License is the most well-known copyleft license. It requires that derivative works be distributed under the same GPL terms and that source code be provided when binaries are distributed. This “viral” quality ensures that the software remains free as it evolves.
GPL v2 is used by the Linux kernel, Git, and WordPress. GPL v3 adds explicit patent grants similar to Apache 2.0, anti-tivoization provisions that prevent hardware restrictions on modified software, and compatibility with Apache 2.0.
The AGPL (Affero GPL) extends copyleft to network use. Where GPL requires source disclosure only when binaries are distributed, AGPL triggers the requirement when the software is made available over a network, closing the “SaaS loophole.”
For organizations, GPL presents significant risk for proprietary software. If you modify GPL code or create a derivative work, you must open-source it when you distribute. Linking proprietary code with GPL libraries can also trigger copyleft requirements, though legal interpretation varies.
d. Weak copyleft licenses: LGPL, MPL, and EPL
Weak copyleft licenses balance openness with commercial usability.
The LGPL (Lesser GPL) is designed for libraries. It requires that modifications to the LGPL-licensed library itself be open-sourced, but allows the library to be linked into proprietary applications without requiring the entire application to be open-sourced.
The Mozilla Public License (MPL) applies copyleft at the file level. Modifications to MPL-licensed files must be shared, but the license does not propagate to other files in the larger work. The Eclipse Public License (EPL) is similar in scope.
These licenses are appropriate when you want improvements to a specific component to remain open, but you also want to allow commercial software to use that component without becoming fully open source.
e. Choosing a license
The choice of license comes down to how much control you want over downstream use.
If maximum adoption is the priority, choose MIT or Apache 2.0. If you want to ensure that improvements to your library stay open, choose LGPL or MPL. If you want every derivative to remain free software, choose GPL. If you also want to close the SaaS loophole, choose AGPL.
The decision also affects who will adopt your project. Permissive licenses remove friction and encourage enterprise use. Strong copyleft licenses signal a commitment to software freedom but are blocked by many corporate policies. Ambiguous or missing licensing is itself a compliance risk.
Complete Example Session
# ============================================
# PART 1: CHECK THE LICENSE OF A PROJECT
# ============================================
# Look for LICENSE, LICENSE.md, or LICENSE.txt
ls LICENSE*
cat LICENSE# ============================================
# PART 2: IDENTIFY LICENSE TYPE
# ============================================
# MIT: "Permission is hereby granted, free of charge..."
# Apache 2.0: "Licensed under the Apache License, Version 2.0"
# GPL: "GNU GENERAL PUBLIC LICENSE"# ============================================
# PART 3: MIT LICENSE HEADER
# ============================================
# Permission is hereby granted, free of charge, to any person
# obtaining a copy of this software...
# The above copyright notice shall be included in all copies.# ============================================
# PART 4: APACHE 2.0 PATENT GRANT
# ============================================
# "Grant of Patent License" section in the LICENSE file
# Contributors grant patent rights; retaliation clause# ============================================
# PART 5: GPL SOURCE DISCLOSURE
# ============================================
# If you distribute binaries, you must provide source.
# Modifications must be licensed under GPL.# ============================================
# PART 6: AGPL NETWORK TRIGGER
# ============================================
# If users interact with the software over a network,
# you must offer them the source code.# ============================================
# PART 7: LGPL LIBRARY LINKING
# ============================================
# You can link LGPL libraries into proprietary apps,
# but modifications to the library must be shared.# ============================================
# PART 8: LICENSE COMPLIANCE CHECK
# ============================================
# Use a tool to scan dependencies
npx license-checker --summary# ============================================
# PART 9: ATTRIBUTION FILE
# ============================================
# Include open source notices in your product
cat THIRD_PARTY_NOTICES.md# ============================================
# PART 10: DUAL LICENSING
# ============================================
# Some projects offer GPL + commercial license.
# Commercial license removes copyleft obligations.These ten parts cover checking a license file, identifying license types, reading MIT and Apache terms, understanding GPL and AGPL obligations, LGPL linking rules, license scanning, attribution files, and dual licensing.
Quick Reference
| License | Type | Key Requirement | Commercial Use |
|---|---|---|---|
| MIT | Permissive | Attribution | Unrestricted |
| BSD 2/3-Clause | Permissive | Attribution (+ no endorsement for 3-clause) | Unrestricted |
| Apache 2.0 | Permissive + patents | Attribution, patent grant | Unrestricted |
| LGPL | Weak copyleft | Share library modifications | Allowed with conditions |
| MPL 2.0 | Weak copyleft | Share file modifications | Allowed with conditions |
| GPL v2/v3 | Strong copyleft | Share derivative works | Restricted |
| AGPL | Network copyleft | Share network-served derivatives | Heavily restricted |
Best Practices
✅ Do This:
# Include license file in every project
# Track open source dependencies
# Preserve copyright notices
# Consult legal for GPL in proprietary products❌ Don’t Do This:
# Use code without a license
# Remove copyright notices
# Assume "open source" means "no rules"
# Ignore AGPL for SaaS productsCommon Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| No license = no rights | Copyright by default | Add a license |
| GPL in proprietary product | Unaware of copyleft | Audit dependencies |
| Missing attribution | Notices removed | Include notices file |
| AGPL ignored in SaaS | Network trigger overlooked | Review AGPL obligations |
| License conflict | Incompatible licenses combined | Check compatibility |
Visual
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 │
└──────────────────────────────────────────────────────────────┘What Each License Requires
┌──────────────────────────────────────────────────────────────┐
│ MIT/BSD → Preserve copyright notice │
│ Apache 2.0 → Preserve notice + patent grant │
│ LGPL → Share library changes │
│ MPL → Share file changes │
│ GPL → Share derivative works under GPL │
│ AGPL → Share network-served derivatives │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Permissive | MIT, BSD, Apache 2.0 |
| Weak copyleft | LGPL, MPL, EPL |
| Strong copyleft | GPL v2, GPL v3 |
| Network copyleft | AGPL |
| MIT requirement | Attribution |
| Apache 2.0 addition | Patent grant |
| GPL requirement | Share derivative works |
| AGPL trigger | Network use |
| LGPL scope | Library modifications |
| OSI | Approves licenses meeting Open Source Definition |
Key takeaways:
- Permissive licenses maximize adoption. MIT, BSD, and Apache 2.0 allow proprietary reuse with only attribution requirements, making them safe for commercial products.
- Apache 2.0 adds patent protection. It includes an explicit patent grant and retaliation clause, providing legal clarity that MIT and BSD lack.
- Strong copyleft requires sharing. GPL requires that derivative works and combined works use the same license and provide source code when distributed.
- Weak copyleft applies to the component, not the application. LGPL and MPL require modifications to the licensed code to be shared, but allow proprietary applications to use the component.
- AGPL closes the SaaS loophole. It triggers source disclosure when software is provided over a network, not just when binaries are distributed.
- License compliance is a legal obligation. Organizations must track the licenses of all open source components and ensure their use complies with the terms.
Remember: Open source licensing is not about whether software is free of cost — it is about what you are legally permitted to do with the code. Every license grants rights (use, modify, distribute) and imposes conditions (attribution, source disclosure, same-license requirements). The spectrum from permissive to copyleft reflects different philosophies about how open source should work: permissive licenses prioritize adoption and freedom for users, while copyleft licenses prioritize the freedom of the software itself. Choosing the right license means understanding what you want to happen downstream — whether your code should be freely incorporated into proprietary products or whether it should remain open in all derivatives. For IT professionals, the practical skill is recognizing which licenses are safe for which uses and knowing when to consult legal counsel before incorporating open source code into a product.
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!