Understanding GPL, MIT, and Apache Licenses

The Big Three

Walk into any open source project, and chances are you’ll encounter one of three licenses: MIT, Apache 2.0, or GPL. Together, they cover the vast majority of open source software.

But what do they actually mean? What’s the difference between them? And which one should you care about as a developer?

This guide breaks down these three licenses in plain English, comparing them side-by-side, and explaining the practical implications for your daily work.

Why These Three Matter

The Statistics

Based on GitHub’s 2024 data:

• MIT License: ~45% of open source projects
• Apache 2.0: ~15% of open source projects
• GPL family: ~20% of open source projects (GPLv2, GPLv3, LGPL, AGPL)
• Other licenses: ~20%

Combined, MIT, Apache, and GPL cover roughly 80% of the open source ecosystem. Understanding these three means understanding most of the open source you’ll encounter.

The Philosophy Divide

These licenses represent fundamentally different philosophies:

MIT: Maximum Freedom “Do whatever you want, just don’t sue me.”

Apache: Business-Friendly Freedom “Do whatever you want, here are the patent rights, don’t sue me.”

GPL: Guaranteed Freedom “You’re free to use this, but keep it free for others too.”

MIT License: The Simple Choice

What It Says (Plain English)

The MIT License is remarkably short. Here’s the essence:

You can:
- Use this code for anything
- Modify it however you want
- Distribute it freely
- Use it in proprietary software
- Sell products using it

You must:
- Include this license text
- Include the copyright notice

You cannot:
- Sue the author if something breaks

That’s it. Really.

The Actual Text (Annotated)

MIT License

Copyright (c) [year] [fullname]

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...

↑ This part grants you unlimited rights

...including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software...

↑ Explicit list of what you can do

...and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

↑ Here come the only requirements

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.

↑ Must keep the license and copyright notice

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND...

↑ Author has no liability if something goes wrong

Practical Implications

As a User of MIT-Licensed Code:

You can:

// Take MIT-licensed library
import awesomeLib from 'awesome-mit-library';

// Use it in your proprietary app
const result = awesomeLib.doSomething();

// Modify it
function myModifiedVersion() {
  // Custom implementation
}

// Don't share your modifications
// This is totally fine under MIT

You must:

myapp/
├── src/
│   └── app.js
├── node_modules/
│   └── awesome-mit-library/
│       └── LICENSE    ← Keep this
└── LICENSES.txt       ← Or aggregate here

As a Creator Using MIT:

Benefits:

• Maximum adoption
• Companies love it
• Simple compliance
• No complications

Drawbacks:

• Others can close-source your code
• No requirement to contribute back
• Amazon could build a service on your work and never share improvements

Who Uses MIT?

Major projects:

• React (Facebook/Meta)
• Node.js
• Ruby on Rails
• jQuery
• .NET Core

Why they chose MIT:

• Want maximum ecosystem growth
• Corporate backing means sustainability isn’t license-dependent
• Value adoption over copyleft protection

Common Misconceptions

Myth: “MIT means public domain” Reality: No, you still must include the license and copyright notice.

Myth: “I can remove the MIT License” Reality: No, you must keep it with the code.

Myth: “MIT requires sharing modifications” Reality: No, you can keep modifications private.

Apache License 2.0: The Corporate Favorite

What It Says (Plain English)

Apache 2.0 is like MIT with extra provisions:

You can:
- Everything MIT allows
- Get explicit patent rights
- Use contributor's patents

You must:
- Include the license
- Include copyright notice
- State significant changes
- Include NOTICE file if present

You cannot:
- Use trademarks without permission
- Sue over patents (you lose your license if you do)

The Key Difference: Patents

This is the big one. Apache 2.0 includes explicit patent grants that MIT lacks.

The Patent Grant:

3. Grant of Patent 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...

Translation: If a contributor has a patent that covers their contribution, they automatically give you rights to use that patent.

The Patent Retaliation Clause:

If You institute patent litigation against any entity [...] alleging
that the Work [...] constitutes direct or contributory patent
infringement, then any patent licenses granted to You under this
License for that Work shall terminate...

Translation: If you sue someone claiming the software violates your patent, you lose your license to use the software.

The Structure

Apache 2.0 is organized into sections:

Section 1-2: Definitions Legal terms defined precisely

Section 3: Grant of Copyright License What you can do with the code

Section 4: Grant of Patent License What you can do with patents

Section 5: Redistribution Requirements What you must do when distributing

Section 6-9: Miscellaneous Liability, warranties, etc.

Practical Implications

The NOTICE File:

If the project includes a NOTICE file:

myproject/NOTICE

This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).

[Other attributions...]

You must include this NOTICE file’s contents in your distributions.

Documenting Changes:

/**
 * Copyright 2025 Original Author
 *
 * Licensed under the Apache License, Version 2.0...
 *
 * MODIFICATIONS:
 * - 2025-11-25: Modified timeout handling (Your Name)
 * - Added retry logic
 */

You must document significant modifications.

As a User of Apache-Licensed Code:

// Use Apache-licensed library
import { Client } from 'apache-licensed-sdk';

// You get:
// ✅ Rights to use the code
// ✅ Rights to use contributor patents
// ✅ Protection if someone sues you

// But you must:
// ✅ Include Apache 2.0 license text
// ✅ Include NOTICE file (if present)
// ✅ State your changes (if you modify)
// ✅ Not use project trademarks

As a Creator Using Apache:

Benefits:

• Explicit patent protection
• Corporate-friendly (most companies approve it easily)
• Patent retaliation discourages patent trolls
• Still permissive

Drawbacks:

• More complex than MIT
• More compliance requirements
• Slightly lower adoption than MIT
• Incompatible with GPLv2 (but compatible with GPLv3)

Who Uses Apache?

Major projects:

• Kubernetes
• TensorFlow
• Android
• Hadoop
• Apache projects (Kafka, Spark, etc.)

Why they chose Apache:

• Patent protection is critical
• Corporate contributors need patent clarity
• Professional/enterprise focus
• Want strong copyleft alternative that’s still permissive

Apache vs MIT: When Does It Matter?

Choose Apache 2.0 when:

• Patents are a concern in your domain
• You have corporate contributors
• You want explicit patent grants
• You’re building infrastructure/platforms

Choose MIT when:

• Simplicity matters more than patent protection
• Your domain isn’t patent-heavy
• You want absolute maximum adoption
• You prefer brevity

For most projects: The difference doesn’t matter much. Both are permissive and corporate-friendly.

GPL (GNU General Public License): The Copyleft Champion

What It Says (Plain English)

GPL is fundamentally different. It’s about preserving freedom:

You can:
- Use the code for anything
- Modify it however you want
- Distribute it

You must:
- Provide source code to recipients
- License your modifications under GPL
- Include the GPL license text
- Document your changes
- Grant patent rights
- Provide installation information (GPLv3)

You cannot:
- Distribute without providing source
- Use in proprietary software (generally)
- Add additional restrictions

The Core Principle: Copyleft

“Copyleft” is a play on “copyright.” Instead of restricting what you can do, it ensures freedom is preserved:

You give me freedom → I give users freedom → They give others freedom
                     ↑                        ↓
                     └────────────────────────┘

This creates a “viral” effect: GPL code makes dependent code GPL.

GPLv2 vs GPLv3

Two major versions are widely used:

GPLv2 (1991)

• Older, more common
• Used by Linux kernel
• Simpler
• No explicit patent grant
• No anti-tivoization clause

GPLv3 (2007)

• Modern improvements
• Explicit patent grant
• Anti-tivoization (can’t lock down hardware)
• Better internationalization
• More complex

Many projects use “GPLv2 or later” to allow upgrades.

The Viral Effect Explained

Scenario 1: Linking to GPL Code

// my-app.js (your code, any license)
import gplLibrary from 'gpl-library'; // GPL licensed

// Result: Your code must be GPL too
// (generally, for most linking scenarios)

Scenario 2: Modifying GPL Code

// gpl-project/main.js (GPL licensed)
function originalFunction() {
  // Original GPL code
}

// Your modification
function enhancedFunction() {
  originalFunction();
  // Your improvements
}

// Result: Your enhancements must be GPL

Scenario 3: Separate Programs

# Your proprietary app
./my-app

# GPL tool used as separate process
./my-app | gpl-tool | other-tool

# Result: Your app can stay proprietary
# (they're separate programs communicating)

What Counts as “Distribution”?

Critical concept: GPL obligations trigger on distribution.

Distribution:

• Giving binaries to customers
• Selling software
• Putting it on download servers
• Shipping it with hardware

Not distribution (generally):

• Internal company use
• SaaS/web services (GPLv2/v3)
  • But see AGPL for the exception
• Personal use

This creates the “ASP loophole”: Companies can modify GPL software for SaaS without releasing source.

Practical Implications

As a User of GPL Code:

You can:

# Use it personally
./gpl-program

# Modify it
vim gpl-program/src/main.c
make

# Run modified version internally
./gpl-program

# Study how it works
less src/main.c

You must (if distributing):

# Provide source code
tar -czf myapp-source.tar.gz src/

# Include GPL license
cp LICENSE dist/

# Offer source to all recipients
# (can charge reasonable fee for media/shipping)

As a Creator Using GPL:

Benefits:

• Prevents proprietary forks
• Ensures improvements come back
• Builds a commons
• Aligns with free software philosophy

Drawbacks:

• Many companies ban GPL code
• Lower adoption than permissive licenses
• Complexity in determining what’s a “derivative work”
• Can’t mix with some other licenses

Who Uses GPL?

Major projects:

GPLv2:

• Linux kernel
• Git
• MySQL (with FOSS exception)

GPLv3:

• GNU tools (bash, gcc, gdb)
• GIMP
• WordPress (actually GPLv2 or later)

Why they chose GPL:

• Philosophical commitment to software freedom
• Want to prevent proprietary forks
• Build a collaborative commons
• Ensure reciprocity

Common GPL Misconceptions

Myth: “GPL means you can’t sell the software” Reality: You can absolutely sell GPL software. You must provide source to buyers.

Myth: “GPL infects all code on the same computer” Reality: Only code that forms a single work with GPL code.

Myth: “If I use a GPL tool, my code becomes GPL” Reality: Using a tool (compiler, editor, etc.) doesn’t affect your code’s license.

Myth: “GPL means no commercial use” Reality: Commercial use is explicitly allowed. Red Hat built a billion-dollar business on GPL software.

Side-by-Side Comparison

The Matrix

Feature	MIT	Apache 2.0	GPL v3
Permission Type	Permissive	Permissive	Copyleft
Length	Very short	Medium	Long
Patent Grant	❌ No	✅ Yes	✅ Yes
Patent Retaliation	❌ No	✅ Yes	✅ Yes
Use in Proprietary Software	✅ Yes	✅ Yes	❌ No*
Must Share Modifications	❌ No	❌ No	✅ Yes
Must Include License	✅ Yes	✅ Yes	✅ Yes
Must Document Changes	❌ No	✅ Yes	✅ Yes
Trademark Protection	❌ No	✅ Yes	✅ Yes
Company-Friendly	✅✅ Very	✅✅ Very	⚠️ Mixed
Complexity	Low	Medium	High
Legal Certainty	Medium	High	High

*Depends on how you define “proprietary” and “derivative work”

Use Cases Compared

Building a JavaScript Library

MIT:

// ✅ Perfect choice
// - Maximum adoption
// - Easy for companies to use
// - Simple compliance

Apache 2.0:

// ✅ Good choice
// - If patents matter
// - Slightly more protection
// - Still very accessible

GPL:

// ⚠️ Consider carefully
// - Will limit adoption
// - Many companies can't use it
// - Better for applications than libraries

Building a Web Application

MIT/Apache:

// ✅ Works fine
// - Companies can fork privately
// - No guarantee of contributions back

GPL:

// ✅ If you want copyleft
// - But watch out for ASP loophole
// - Consider AGPL instead

Building Infrastructure Tools

MIT:

✅ If adoption is priority (like Docker initially)

Apache 2.0:

✅ If patents matter (like Kubernetes)

GPL:

✅ If community matters most (like Git)

License Compatibility

Can you mix these licenses?

Compatibility Matrix

Using \ In	MIT Project	Apache Project	GPL Project
MIT Code	✅ Yes	✅ Yes	✅ Yes
Apache Code	⚠️ Yes*	✅ Yes	✅ Yes (GPL v3)**
GPL Code	❌ No	❌ No	✅ Yes

*Keep Apache license **GPLv2 and Apache 2.0 are incompatible

Practical Examples

Scenario 1: MIT + Apache

// Your project: MIT
import apacheLib from 'apache-library'; // Apache 2.0

// ✅ This works
// Result: Keep both licenses
// Some consider result to be under Apache 2.0

Scenario 2: MIT + GPL

// Your project: MIT
import gplLib from 'gpl-library'; // GPL

// ❌ Problem: GPL "wins"
// Result: Entire project must be GPL

Scenario 3: Apache + GPLv3

# Your project: Apache 2.0
from gplv3_library import something  # GPLv3

# ✅ GPLv3 explicitly allows this
# Result: Entire project must be GPLv3

Scenario 4: Apache + GPLv2

# Your project: Apache 2.0
from gplv2_library import something  # GPLv2 only

# ❌ Incompatible
# Result: Can't do this legally

Making Your Choice

Decision Tree

Start Here
    |
    ├─ Do you want to prevent proprietary forks?
    |  ├─ Yes → GPL (or AGPL for web services)
    |  └─ No → Continue
    |
    ├─ Are patents a major concern?
    |  ├─ Yes → Apache 2.0
    |  └─ No → Continue
    |
    └─ Want maximum simplicity and adoption?
       └─ Yes → MIT

By Project Type

Library for Other Developers:

• MIT or Apache 2.0
• Avoid GPL (limits adoption)

End-User Application:

• Any license works
• GPL if you want copyleft

Infrastructure/Platform:

• Apache 2.0 (patents matter)
• Or MIT for simplicity

Web Service/SaaS:

• MIT/Apache if you don’t care about forks
• AGPL if you want copyleft (not covered in detail here)

Tool for Developers:

• MIT for maximum adoption
• GPL if it’s part of GNU ecosystem

By Philosophy

“I just want people to use this” → MIT

“I want people to use this, but patents matter” → Apache 2.0

“I want to ensure freedom is preserved” → GPL

“I want to build a commons where everyone contributes” → GPL

Practical Compliance

As a Developer Using These Licenses

Every Project Should Have:

project/
├── LICENSE              # Full license text
├── NOTICE              # If using Apache 2.0
├── LICENSES/           # Third-party licenses
│   ├── mit-lib.txt
│   ├── apache-lib.txt
│   └── ...
└── README.md           # License badge/info

In Your README:

## License

This project is licensed under the MIT License - see the [LICENSE](LICENSE)
file for details.

### Third-Party Licenses

This project uses:
- [library-name](link) - MIT License
- [other-lib](link) - Apache 2.0 License

See [LICENSES/](LICENSES/) for full third-party license texts.

Tools for License Management

JavaScript/Node.js:

# Check licenses
npx license-checker

# Generate attribution
npx license-checker --out LICENSES.txt

# Check for specific licenses
npx license-checker --onlyAllow "MIT;Apache-2.0;BSD-2-Clause"

Python:

# Install tool
pip install pip-licenses

# Check licenses
pip-licenses

# Export to file
pip-licenses --format=markdown --output-file=LICENSES.md

Go:

# Install tool
go install github.com/google/go-licenses@latest

# Check licenses
go-licenses report ./...

# Save to file
go-licenses save ./... --save_path=third_party

When Things Go Wrong

Accidental License Violations

Discovery:

# Oh no, we used a GPL library in our MIT project
npx license-checker | grep GPL

Options:

1. Remove the dependency

   npm uninstall gpl-library
   # Find an alternative

2. Change your license to GPL

   # If you own all copyright
   mv LICENSE LICENSE.old
   # Add GPL LICENSE
   git commit -m "Change to GPL to comply with dependencies"

3. Get an exception

   Contact the GPL library authors
   Request a license exception for your use case
   (Don't count on this)

Enforcing Your License

Someone violated your MIT license by removing your copyright notice:

Hi [user],

I noticed you're using my-project, which is great! However, the MIT
License requires keeping the copyright notice and license text.

Could you please add the LICENSE file to your distribution?

Example:
myapp/
├── src/
└── LICENSE  ← MIT License text with my copyright

Thanks!

Someone violated your GPL license:

Hi [company],

I noticed you're distributing software based on my-gpl-project.
That's allowed under GPL, but requires providing source code to users.

Per GPL section 6, you must:
- Provide source code to all recipients
- Include the GPL license
- Document your modifications

Please let me know how you plan to comply, or if you'd like to
discuss a commercial license arrangement.

Conclusion

The three major licenses serve different needs:

MIT: Simple, permissive, maximum freedom for users

• Choose when: Adoption is priority #1

Apache 2.0: Business-friendly with patent protection

• Choose when: Patents matter, corporate-friendly permissive needed

GPL: Copyleft protection ensuring freedom continues

• Choose when: Preventing proprietary forks matters more than maximum adoption

Most developers will use MIT or Apache 2.0 for libraries, and GPL for applications where they want copyleft.

All three are good licenses. The “best” choice depends on your goals, values, and circumstances.

Now you understand the big three. Choose wisely, apply correctly, and contribute to the open source ecosystem with confidence.

The future of software is open. Pick your license and build something amazing.