Adding a LICENSE file is usually the last thirty seconds of starting a project: copy whatever the previous repo used and move on. That is a strange amount of thought to give the one file that determines who may use your work, whether a company can build a product on it without giving anything back, and whether you have accidentally handed away a patent. The differences between the common licenses are small in word count and large in consequence. Here is what actually separates them.
Permissive vs copyleft: the only distinction that really matters
Every mainstream open source license sits on one side of a single line.
Permissive licenses — MIT, BSD, Apache 2.0 — let anyone use, modify, and redistribute your code, including inside closed-source commercial products, as long as they preserve your copyright and license notice. Someone can take your library, build a proprietary product on it, sell it, and never publish a line of their changes. That is not abuse; it is the intended behavior.
Copyleft licenses — the GPL family — permit the same freedoms but attach a condition: if you distribute a derivative work, that work must also be released under the same license. The freedoms travel with the code. This is why GPL is sometimes called "viral," though "reciprocal" is the fairer word — it demands the same openness it grants.
Everything else is detail. Decide first whether you want maximum adoption (permissive) or a guarantee that derivatives stay open (copyleft), and the shortlist takes care of itself.
MIT vs Apache 2.0: the patent clause is the difference
Both are permissive, and for most day-to-day use they behave identically: keep the notice, do what you like. The MIT license is famously about a paragraph long and grants broad rights with almost no obligations beyond attribution.
Apache 2.0 is longer because it addresses something MIT is simply silent on: patents. It includes an explicit patent grant — contributors license the patents that their contribution would necessarily infringe — plus a patent retaliation clause: if you initiate patent litigation over the covered code, your license terminates. MIT grants copyright permissions and says nothing about patents at all, leaving that risk unaddressed rather than resolved.
For a small utility library the distinction rarely bites. For anything a company might build a business on, or anything touching patentable techniques, Apache 2.0's explicit grant is why it is the default at most large organizations and foundations. It converts an ambiguity into a written term.
One compatibility trap worth knowing, straight from the Apache Software Foundation's own FAQ: Apache 2.0 is "compatible with version 3 of the GPL" but "not compatible with GPL version 2, because it has some requirements that are not in that older version. These include certain patent termination and indemnification provisions." So Apache-licensed code cannot be combined into a GPLv2 project. MIT-licensed code, having no such provisions, drops into either.
The GPL, and the server-shaped hole in it
The GPL's reciprocity is triggered by distribution. If you ship a modified GPL program — as a binary, a package, a device — you must offer the corresponding source under the GPL. That worked well when software was something you handed to people.
Then software moved to servers, and a gap opened. Running a program on your own machine to serve users over a network is not distribution, so the GPL's obligations are never triggered. The FSF describes the problem plainly: if a developer "modifies the program, he might very likely run it on his own server and never release copies. Then you would never get a copy of the source code of his version, so you would never have the chance to include his changes in your version."
The AGPL closes exactly this gap. Per the FSF, it is "a modified version of the ordinary GNU GPL version 3" with "one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there."
That single clause is why the AGPL is the most consequential license in the SaaS era — and why many companies ban AGPL dependencies outright, since incorporating AGPL code into a hosted service can obligate them to publish source. If your project is mainly useful as a network service and you want contributions back from those who host it, AGPL is the tool built for that job. Expect it to reduce corporate adoption; that is the trade.
Choosing, in practice
Illustrative decision path
Want the widest possible adoption, don't care about closed-source use?
→ MIT (shortest, simplest, no patent terms)
→ Apache 2.0 (same freedoms + explicit patent grant — safer for anything commercial)
Want derivatives to stay open?
→ GPLv3 (reciprocity on distribution)
→ AGPLv3 (reciprocity extended to network/SaaS use)A few practical notes. Adding a license later is painful: without one, your code is under exclusive copyright by default and technically nobody may use it — but once contributors exist, relicensing needs their agreement, so choose early. Your license must also be compatible with your dependencies; you cannot wrap GPL code in an MIT library and call it permissive. And none of this is legal advice — for anything with real commercial stakes, the fifteen minutes of a lawyer's time is cheap next to the alternative.
Key Takeaways
- The real fork is permissive vs copyleft: maximum adoption, or a guarantee derivatives stay open.
- MIT vs Apache 2.0 comes down to patents — Apache adds an explicit patent grant and a retaliation clause; MIT is silent on patents.
- Apache 2.0 is GPLv3-compatible but not GPLv2-compatible, due to its patent termination and indemnification provisions.
- The GPL is triggered by distribution, which leaves hosted services untouched; the AGPL adds the network clause that closes that gap.
- Pick your license at project start — retrofitting one after contributors arrive requires their consent.