MIT vs GPL vs Apache

The first time I put code of my own on the internet I got as far as the file called LICENSE and stopped. Everything up to that point had been an engineering problem. This was a legal one, and my instinct — copy whatever the popular projects use — was exactly the instinct that gets people into trouble later.

So I read the three that matter, properly, once. They are shorter than you expect and they encode three genuinely different views of what should happen to work you give away. This article is about that choice from the author's side — what you are deciding when you pick one for your own code, and why the kernel picked the one it did.

The question all three are answering

Without a licence, code you publish is not free to use. Copyright applies by default, and default means nobody else may legally copy, modify or distribute your work. A public repository with no licence file is a museum exhibit: look, do not touch. People misunderstand this constantly, and it is the single most consequential thing to know before anything else.

A licence is therefore a grant: you, the holder of the rights, permitting others to do specific things. The three common ones differ almost entirely in one dimension — what you require in return.

MIT — take it, just do not blame me

The MIT licence is about a hundred and seventy words, and roughly half of them are the warranty disclaimer. In substance it says: do whatever you like with this — use it, change it, sell it, put it inside a closed commercial product — as long as you keep the copyright notice, and understand that there is no warranty of any kind.

That is it. No obligation to share your changes, no obligation to publish anything, no conditions on what you combine it with. It is the most permissive thing you can do short of surrendering your rights entirely.

Choose it when you want maximum adoption and genuinely do not mind what happens next. A library you want inside as many products as possible, a utility you wrote for yourself and are publishing as a courtesy, anything where the goal is usefulness rather than reciprocity. The trade you are accepting is real: somebody can take your work, improve it substantially, sell the improved version, and owe you nothing but a line in a credits file.

GPL — take it, but then it stays open

The GPL grants the same freedoms and attaches one condition, usually called copyleft. If you distribute software built on GPL code, you must distribute it under the same terms, with source available. The freedom travels with the code and cannot be stripped off it.

The word people reach for here is "viral", usually with a sour face. I think that framing obscures the mechanism, so let me state it plainly instead: the GPL is a trade. You get the accumulated work of everyone before you, on condition that everyone after you gets yours. Nobody is compelled to accept the trade — you can simply not use the code — but you cannot take one side of it and not the other.

One boundary is worth knowing because it is misunderstood constantly: the obligation attaches to distribution, not to use. Running GPL software inside your company, modified however you like, triggers nothing at all. You only owe source to people you give the software to. This is why a company can run a heavily customised Linux internally and publish none of it, entirely legitimately.

Apache 2.0 — permissive, with the patent question answered

Apache 2.0 sits in the same permissive family as MIT: use it, change it, close it, sell it. It is longer for one substantive reason — it deals explicitly with patents.

Contributors grant you a licence to any patents covering their contribution, and if you sue somebody over patents in that software, your own grant terminates. MIT is silent on all of this, which in practice means a contributor could contribute code and later assert a patent over the technique it implements. Rare, but not theoretical, and enough that corporate lawyers have a strong preference.

Choose Apache when the work might end up near commercial products and you would rather the patent question be settled in the document than in a courtroom. It is MIT with the corners filed off, and the additional length buys exactly that.

Why the kernel is GPL, and what followed

This is the part that changed how I think about the choice.

The kernel's licence was set early and deliberately, and the consequence is visible three and a half decades later. Companies that build products on it — router manufacturers, phone makers, appliance vendors, anyone shipping embedded hardware — have to release their kernel modifications. Not their whole product, but that part. Which means improvements made for a television end up available to a server, and improvements made for a supercomputer end up available to a laptop from 2016.

That is the mechanism behind something I rely on commercially. The reason a machine a vendor abandoned still has working drivers is that the code driving its hardware could not be quietly enclosed by any of the companies that used it. Had the kernel been MIT-licensed, every large manufacturer would have had both the ability and the commercial incentive to maintain a private fork, and decades of improvements would sit in dozens of separate vaults.

I want to be careful not to turn that into a moral ranking, because the permissive licences produced results of their own that I use daily — much of the internet's plumbing is permissively licensed and is everywhere precisely because it is frictionless to adopt. The two philosophies produced different things. Copyleft built a commons that could not be enclosed. Permissive licensing built infrastructure that spread without resistance. Both worked, at different jobs.

So the question to ask about your own code is not which licence is best. It is: if somebody takes this, improves it, and closes the result, have I lost something I cared about? Answer honestly. If yes, copyleft. If no, permissive, and pick Apache over MIT if patents are anywhere near your domain. That is the entire decision, and it took me an evening of reading to be able to make it deliberately instead of by imitation.