MIT, Apache, and GPL Licenses: Practical Differences for Developers

When it's time to open a repository, most developers pick a license by elimination: "MIT seems simple, I'll go with MIT." Works most of the time. But anyone who's worked at a company receiving a contract to integrate an open source project knows the legal team stops everything when they see GPL in the README — and they're right to stop.

This post isn't an introduction to open source. If you're still getting oriented in that ecosystem, the post What is open source covers the context. Here the subject is what each license actually allows, what it prohibits, and where each one creates practical problems.

The fundamental split: permissive versus copyleft

Before getting into each license, the concept that structures everything:

Permissive licenses (MIT, Apache 2.0, BSD) let you do essentially whatever you want with the code — including keeping your derived product's source closed. The only requirement is to retain the copyright notice and, depending on the license, a few other attributions.

Copyleft licenses (GPL, AGPL, LGPL) impose one condition: if you distribute software that uses code under this license, your product's code also needs to be made available under the same terms. The name "copyleft" is a play on copyright — instead of protecting the author's exclusive right, it protects everyone's ongoing right to access the code.

This distinction determines whether a license is "commercially viable" or not for a closed project. It's not a matter of ethics — it's legal viability.

MIT: the least-friction license

The MIT license is under 200 words. You can read the full text in two minutes and understand everything.

What it allows: use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software. No commercial use restrictions. No obligation to open derived code.

What it requires: include the original MIT license text and copyright notice in any distribution of the software, whether source code or binary.

What it doesn't cover: patents. The MIT license never mentions patents. If a contributor holds a patent covering something implemented in the code, they can technically sue users for patent infringement even if the code is MIT. In practice this rarely happens with small projects, but in critical infrastructure or corporate environments with significant money involved, that gap matters.

Commercial use: ✓
Proprietary distribution: ✓
Private modification: ✓
Requirement to open derived code: ✗
Explicit patent protection: ✗

MIT is the right license for libraries you want everyone to use without friction. React, Vue, Rails, Express — all MIT for exactly this reason.

Apache 2.0: permissive with patent protection

Apache 2.0 works essentially like MIT with one important addition: explicit patent grant.

Any contributor who submits code to the project automatically grants a license to their patents for all users of the software, covering the rights necessary to use, make, sell, and distribute the software. Additionally, if a user files a patent lawsuit against the project, they automatically lose that patent grant.

This protects both users and contributors. A conglomerate with hundreds of patents that contributes to an Apache project cannot later use those same patents to sue the project's users.

The practical difference from MIT is relevant in two scenarios: (1) your project may be subject to patent litigation — infrastructure software, protocols, data compression; (2) you work at a company that requires legal review of dependencies, and Apache 2.0 passes that process more easily than MIT by explicitly covering the topic.

Commercial use: ✓
Proprietary distribution: ✓
Private modification: ✓
Requirement to open derived code: ✗
Explicit patent protection: ✓
Patent grant revokable if you sue: ✓

A compatibility detail that matters in large projects: Apache 2.0 and GPL v2 are incompatible. You cannot merge Apache 2.0 code into a GPL v2 project. Apache 2.0 is compatible with GPL v3.

Kubernetes, Terraform, Elasticsearch (before switching to SSPL), Android — all Apache 2.0.

GPL: strong copyleft

GPL (GNU General Public License) is where things get more complex.

GPL v2 and v3 require that any software you distribute that includes or is derived from GPL code also be distributed under GPL — with source code available to anyone who receives the binary. This property is called "strong copyleft" and is often described as "viral" or "infectious," terms that carry negative connotations but describe the behavior accurately.

What this means in practice: if you use a GPL library in your closed product and distribute that product, you need to make the complete source code available. For internal software without external distribution, there's no problem — copyleft activates only upon distribution.

Commercial use: ✓ (as long as code is open when distributing)
Proprietary distribution: ✗
Private modification without distributing: ✓
Requirement to open derived code upon distribution: ✓ (all derivatives)
Patent protection: ✓ (v3)

GPL v3 added protections against DRM and "tivoization" — the practice of distributing hardware that uses GPL software but physically prevents firmware modifications. Consumer devices with patched Linux firmware sometimes run into this conflict. The Linux project uses GPL v2, deliberately, to avoid some of the more restrictive clauses in v3.

For libraries you want to remain open source but that can be used in proprietary projects, there's LGPL (Lesser GPL). It allows proprietary code to use the library dynamically without needing to open its code — as long as the library itself remains LGPL. Qt (community mode), ffmpeg — LGPL resolves the "I want my code to be open source but don't want to force that on users" use case.

AGPL: copyleft for the SaaS era

There's a gap the GPL doesn't cover: you can take GPL code, run it on a server as a service, and never "distribute" the software in the technical sense. Your users interact with it over the network but don't receive a binary. GPL doesn't require you to open code in that scenario.

AGPL (Affero GPL) closes that gap. If you run AGPL software as a service accessible over a network, you need to make the source code available to users. This is why many open source projects that compete with SaaS models choose AGPL — MongoDB (before switching to SSPL), Grafana, Nextcloud.

Companies building products on top of open source generally handle AGPL dependencies with care. If your legal team is already auditing licenses in your dependencies, AGPL will show up with a yellow flag.

The compatibility trap

Licenses aren't just terms documents — they need to be compatible when you combine code from multiple sources.

The basic rules:

• MIT code can go into Apache 2.0, GPL, AGPL projects — no problem.
• Apache 2.0 code can go into GPL v3 and AGPL projects, but not GPL v2.
• GPL v2 code can go into GPL v2 projects, but not Apache 2.0 or proprietary.
• GPL v3 code can go into GPL v3 and AGPL projects.
• AGPL is the most restrictive — it propagates AGPL to everything.

This matters when you have transitive dependencies. Your project's package.json might have 300 dependencies. If one of them is AGPL, you have a legal problem if you're running a SaaS without opening your code. Most people have never looked at this.

# Check licenses for all npm dependencies
npx license-checker --summary

# Or for Python
pip-licenses --order=license

Tools like license-checker (npm) and pip-licenses (Python) automate the audit. In commercial projects, running this in CI is worth it.

Which license to choose for your project

If you're opening source code, here's the direct decision tree:

You want maximum adoption and don't care about commercial use? → MIT. No question.

You want the same freedom as MIT but with patent protection (large company contributing, litigation risk)? → Apache 2.0.

You want everyone who distributes your code to keep it open? → GPL v3.

You want to prevent SaaS from running your code without giving back? → AGPL.

You want your library to be usable in proprietary products, but the library code itself to remain open source? → LGPL.

For quickly generating ready-to-use license files, choosealicense.com from GitHub has clean MIT, Apache, and GPL templates with the current year automatically filled in.

Frequently asked questions

Can I use MIT-licensed code in a commercial product without opening the source?

Yes. Permissive licenses like MIT and Apache 2.0 allow commercial use and proprietary distribution. MIT's only requirement is including the copyright notice and license text in distributed products. You can sell the product, keep the source closed, sublicense — no problem. What you cannot do is remove credit to the original author.

What's the difference between GPL v2 and GPL v3?

GPL v3 (2007) added three protections absent in v2: (1) anti-tivoization clause — prevents hardware manufacturers from blocking modifications to GPL software running on their devices; (2) explicit compatibility with Apache 2.0 — which v2 blocked; (3) more robust patent protection. The Linux kernel deliberately uses GPL v2 (without the "or later" option) precisely to avoid v3's additional restrictions, which generated significant community debate. For new projects, GPL v3 is the default choice.

Does MIT-licensed code "become" GPL when combined with GPL code?

The MIT code itself stays MIT. What happens is the combined project needs to be distributed under GPL, because GPL terms apply to the distribution of the combined work. You're not forcing the MIT code author to change their license — you're accepting that your specific combination needs to follow the more restrictive rules. This is why copyleft is described as "infectious": it propagates to the project that incorporates it, not to external projects.

Can I use AGPL code in an internal service without releasing the code?

Yes, with one important caveat: "internal" needs to be genuinely internal. If the service is used only by company employees with no external availability, you're probably not "distributing over the network" in the AGPL sense. If external users (customers, partners) interact with the service over a network, AGPL activates. The line is: is the group with access to the service the same legal entity that controls the software? Yes → no obligation. No → code needs to be available.

MIT, Apache, GPL — the right choice depends on what you want to protect

There's no universally better license. MIT maximizes adoption. Apache 2.0 protects contributors from patent litigation. GPL ensures code stays free. AGPL closes the SaaS gap.

The common mistake isn't choosing the wrong license for yourself — it's not checking the licenses of your dependencies. Your license choice for the project needs to be compatible with everything in the dependency graph. In small projects this is rarely a problem. In commercial products with dozens of dependencies, the audit is worth doing.

The second trap is assuming "open source" means "can use however you want." MIT: yes. GPL: no — at least not without opening your code. Reading the LICENSE file in a repository before using it in production takes two minutes. The cost of not reading it can be an uncomfortable conversation with legal counsel six months later.