LFCA 109 🐧 Common Licenses — MIT, GPL, Apache
This chapter examines three of the most widely used open source licenses in detail: the MIT License, the GNU General Public License (GPL), and the Apache License 2.0. These three licenses represent the major philosophical and practical positions in open source licensing—permissive, strong copyleft, and permissive-with-patent-grant—and understanding their exact terms is essential for anyone who uses, modifies, or distributes open source software.
Key point: MIT is the simplest permissive license, requiring only attribution. Apache 2.0 is permissive but adds an explicit patent grant and retaliation clause. GPL is strong copyleft, requiring that derivative works be distributed under the same license with source code available.
Why these three licenses matter
The ubiquity problem. MIT, Apache 2.0, and GPL collectively cover the vast majority of open source software in use today. The Linux kernel uses GPL v2. Kubernetes uses Apache 2.0. React, Node.js, and jQuery use MIT. Understanding these three licenses covers most of the software you will encounter.
The philosophical split. These licenses represent two fundamentally different views of open source. MIT and Apache 2.0 prioritize adoption and freedom for users—you can do almost anything with the code. GPL prioritizes freedom for the software itself—derivatives must remain open. The choice between them is a choice about what “open source” should mean.
The compliance risk. Misunderstanding these licenses creates legal risk. Using GPL code in a proprietary product without complying with its terms is copyright infringement. Using MIT code without preserving attribution is a license violation. The differences matter in practice.
The patent problem. Apache 2.0 was created partly in response to patent concerns that MIT and BSD do not address. It includes an explicit patent grant from contributors and a retaliation clause that terminates the grant if the licensee sues over patents. This makes it safer for corporate use.
a. The MIT License
The MIT License is the simplest and most widely used permissive license. It grants permission to use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software, subject to one condition: the copyright notice and permission notice must be included in all copies or substantial portions of the software .
The full license text is short enough to include here:
Copyright <YEAR> <COPYRIGHT HOLDER>
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.The implications are straightforward. You can use MIT-licensed code in any project, including proprietary commercial software. You can modify it, redistribute it, and sell it. The only requirement is that you preserve the copyright notice and the license text. There is no requirement to share your modifications or to release your source code .
MIT does not include a patent grant. This means that while the license grants copyright permissions, it says nothing about patents. A contributor who holds a patent on the software could theoretically assert it against users. In practice, this is rare, but it is a difference from Apache 2.0.
b. The Apache License 2.0
The Apache License 2.0 is also permissive, but it adds explicit provisions for patents and notices. Like MIT, it allows use, reproduction, modification, and distribution of the work and derivative works, subject to conditions .
The key difference is the patent grant. Section 3 of the license states:
“Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work” .
This means contributors cannot later sue users for patent infringement based on their contributions. The grant is irrevocable except in one case: if the licensee initiates patent litigation against any entity alleging that the work infringes a patent, all patent licenses granted to that licensee terminate .
Apache 2.0 also requires that you preserve any NOTICE file that the original work includes. The NOTICE file typically contains attribution information and must be included in any distribution. You must also include a copy of the license itself .
The practical implication is that Apache 2.0 is safer for corporate use than MIT or BSD because of the patent grant. Companies that are concerned about patent litigation prefer Apache 2.0 for this reason. Like MIT, it allows proprietary derivative works—you can incorporate Apache 2.0 code into a closed-source product without releasing your source.
c. The GNU General Public License (GPL)
The GPL is the most well-known copyleft license. It grants the same permissions as MIT and Apache 2.0—use, copy, modify, distribute—but imposes a critical condition: derivative works must be distributed under the same GPL terms, and source code must be made available .
The source code requirement is detailed. Section 3 of GPL v2 specifies that when you distribute a program in object code or executable form, you must do one of the following :
- Accompany it with the complete corresponding machine-readable source code, distributed under the same license.
- Accompany it with a written offer, valid for at least three years, to provide the source code to any third party for no more than the cost of distribution.
- Accompany it with the information you received about how to obtain the source code (allowed only for noncommercial distribution).
The “complete corresponding source code” means all the source code for all modules, plus any associated interface definition files, plus the scripts used to control compilation and installation .
The viral nature of GPL is its defining characteristic. If you link GPL code with your proprietary code to create a single program, the entire program is subject to GPL. This means you cannot use GPL libraries in proprietary software without releasing the entire application under GPL .
GPL v3 adds several provisions. It includes an explicit patent grant similar to Apache 2.0, anti-tivoization rules that prevent hardware from restricting modified software, and compatibility with Apache 2.0 .
The practical implication for organizations is significant. GPL is not suitable for proprietary products unless the entire product will be open-sourced under GPL. For internal tools that are never distributed, GPL obligations do not trigger because the source code requirement applies to distribution.
d. Comparing the three licenses
| Aspect | MIT | Apache 2.0 | GPL |
|---|---|---|---|
| Type | Permissive | Permissive + patents | Strong copyleft |
| Attribution required | Yes | Yes | Yes |
| Patent grant | No | Yes | Yes (v3) |
| Source disclosure | No | No | Yes |
| Derivative works | Any license | Any license | GPL only |
| Proprietary use | Allowed | Allowed | Not allowed if distributed |
| NOTICE file | No | Yes | No |
| Compatibility | Broad | GPL v3 | Limited |
The choice between them depends on your goals. MIT maximizes adoption with minimal requirements. Apache 2.0 adds patent clarity for corporate users. GPL ensures that derivatives remain open source.
Complete Example Session
# ============================================
# PART 1: IDENTIFY THE LICENSE
# ============================================
# Check the LICENSE file in a project.
ls LICENSE*
head -20 LICENSE# ============================================
# PART 2: MIT LICENSE DETECTION
# ============================================
# Look for "Permission is hereby granted, free of charge"
grep "Permission is hereby granted" LICENSE# ============================================
# PART 3: APACHE 2.0 DETECTION
# ============================================
# Look for "Apache License, Version 2.0"
grep "Apache License" LICENSE# ============================================
# PART 4: GPL DETECTION
# ============================================
# Look for "GNU GENERAL PUBLIC LICENSE"
grep "GNU GENERAL PUBLIC LICENSE" LICENSE# ============================================
# PART 5: CHECK PATENT GRANT (APACHE)
# ============================================
# Look for "Grant of Patent License"
grep -A5 "Grant of Patent" LICENSE# ============================================
# PART 6: CHECK SOURCE DISCLOSURE (GPL)
# ============================================
# Look for "complete corresponding machine-readable source code"
grep "complete corresponding" LICENSE# ============================================
# PART 7: ATTRIBUTION FILE
# ============================================
# MIT and Apache require preserving notices.
cat THIRD_PARTY_NOTICES.md# ============================================
# PART 8: CHECK NOTICE FILE (APACHE)
# ============================================
# Apache 2.0 requires NOTICE preservation.
ls NOTICE
cat NOTICE# ============================================
# PART 9: LICENSE SCANNING
# ============================================
# Use a tool to scan dependencies.
npx license-checker --summary# ============================================
# PART 10: COMPLIANCE CHECK
# ============================================
# Verify GPL is not in proprietary product.
npx license-checker --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC"These ten parts cover identifying licenses, detecting MIT, Apache, and GPL, checking patent grants and source disclosure requirements, maintaining attribution and NOTICE files, and scanning dependencies for compliance.
Quick Reference
MIT License
| Aspect | Detail |
|---|---|
| Type | Permissive |
| Requires | Copyright notice preservation |
| Allows | Proprietary use, modification, distribution |
| Patent grant | No |
| Source disclosure | No |
Apache 2.0
| Aspect | Detail |
|---|---|
| Type | Permissive + patents |
| Requires | Notice preservation, NOTICE file, license copy |
| Allows | Proprietary use, modification, distribution |
| Patent grant | Yes, with retaliation clause |
| Source disclosure | No |
GPL
| Aspect | Detail |
|---|---|
| Type | Strong copyleft |
| Requires | Same license for derivatives, source disclosure |
| Allows | Use, modification, distribution under GPL |
| Patent grant | Yes (v3) |
| Source disclosure | Yes, when distributing binaries |
Best Practices
✅ Do This:
# Preserve copyright notices
# Include license text in distributions
# Preserve NOTICE files for Apache 2.0
# Audit GPL usage in proprietary products
# Use license scanning tools❌ Don’t Do This:
# Remove copyright notices
# Use GPL in proprietary product without compliance
# Ignore NOTICE file requirements
# Assume "open source" means "no rules"Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Missing attribution | Notices removed | Include notices file |
| GPL in proprietary product | Unaware of copyleft | Audit dependencies |
| Apache NOTICE ignored | Not read license | Preserve NOTICE file |
| No patent grant | Used MIT for patent-sensitive project | Use Apache 2.0 |
| GPL distribution without source | Not complying | Provide source or offer |
Visual
License Comparison
┌──────────────────────────────────────────────────────────────┐
│ MIT APACHE 2.0 GPL │
│ ──── ────────── ─── │
│ Attribution Attribution Attribution │
│ No patent Patent grant Patent grant │
│ No source No source Source required │
│ Any license Any license GPL only │
│ Proprietary OK Proprietary OK Proprietary NO │
└──────────────────────────────────────────────────────────────┘GPL Source Distribution Requirement
┌──────────────────────────────────────────────────────────────┐
│ Distribute binary → Must provide source │
│ │
│ Option 1: Include source with binary │
│ Option 2: Written offer valid 3 years │
│ Option 3: Pass along the offer received │
│ │
│ Source must be "complete corresponding source code" │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| MIT | Simplest permissive license; attribution only |
| MIT requirement | Preserve copyright notice |
| Apache 2.0 | Permissive with patent grant |
| Apache 2.0 requirement | Notice preservation, NOTICE file, license copy |
| Apache 2.0 patent clause | Irrevocable unless litigation initiated |
| GPL | Strong copyleft license |
| GPL requirement | Same license for derivatives, source disclosure |
| GPL source options | Include source, written offer, or pass offer |
| GPL v3 additions | Patent grant, anti-tivoization, Apache 2.0 compatibility |
Key takeaways:
- MIT is the simplest permissive license. It requires only that the copyright notice and license text be preserved. You can use MIT code in proprietary products, modify it, and distribute it without sharing your source code .
- Apache 2.0 adds an explicit patent grant. Contributors grant a perpetual, irrevocable patent license, and the grant terminates only if the licensee initiates patent litigation. This makes Apache 2.0 safer for corporate use .
- Apache 2.0 requires NOTICE file preservation. If the original work includes a NOTICE file, you must include it in your distribution along with a copy of the license .
- GPL requires source disclosure for distributed binaries. When you distribute a GPL program in object code or executable form, you must provide the complete corresponding source code, either included with the distribution or through a written offer .
- GPL is viral. Linking GPL code with proprietary code creates a combined work that must be licensed under GPL. This means GPL libraries cannot be used in proprietary software that is distributed .
- GPL v3 adds patent and anti-tivoization provisions. It grants patents explicitly and prevents hardware restrictions on modified software. It is also compatible with Apache 2.0 .
- The choice depends on your goals. MIT maximizes adoption. Apache 2.0 adds patent clarity for corporate users. GPL ensures that derivatives remain open source.
Remember: MIT, Apache 2.0, and GPL are the three licenses you will encounter most often. MIT is the simplest: use it however you want, just keep the notice. Apache 2.0 is MIT plus a patent grant and a NOTICE file requirement—safer for companies worried about patents. GPL is the one that changes your obligations: if you distribute software that includes GPL code, you must provide the source under GPL. For internal use, GPL obligations do not trigger. For distribution, they do. The practical skill is recognizing which license you are dealing with and understanding what it requires. When in doubt, read the LICENSE file in the project you are using, and consult legal counsel before incorporating GPL code into a proprietary 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!