MIT, GPL, Apache: what they mean for you

There is an article on this site about choosing a licence for code you wrote. This is the other side of the same question, and it is the one that actually affects more people: what do these three words mean for you when you are simply using software, running a business, and have no intention of writing a line of anything.

The short answer, which I will spend the rest of the article qualifying: for ordinary use, all three give you the same thing, and the differences only appear at three specific moments. Knowing which three saves you from both the people who tell you licences do not matter and the people who tell you one of them is dangerous.

What all three guarantee you

Run the software for any purpose, including commercially, without paying, without asking, without counting users. Install it on as many machines as you like. Never negotiate a renewal, never get audited for licence compliance, never discover that the price has changed.

That set is identical across MIT, GPL and Apache, and for the overwhelming majority of people it is the entire practical content of the licence. A dental practice running an open document editor and an open file server has the same rights under all three and will never encounter a difference between them.

It is worth pausing on how unusual that is compared to the alternative. Commercial licences count things — users, cores, devices, concurrent sessions — and someone has the right to check. Every small business I have worked with has a drawer of licence anxiety somewhere. All three of these licences simply remove that category of problem, and that is the headline, not the footnotes below.

Moment one: you hand the software to somebody else

Here the difference appears, and it is the only one that affects a meaningful number of businesses.

Under MIT and Apache, you may put the software inside a product, change it, close it and sell it. Under the GPL, if you distribute a product built on GPL code, you must make the source of that work available under the same terms — and the obligation covers the combined work, not only the lines you took.

Note carefully what triggers it: distribution. Not use. A company that runs modified GPL software internally, on its own servers, for its own staff, owes nothing to anyone and may keep every change private. This is the single most common misunderstanding in this area and it causes companies to avoid software they could use freely.

So: are you shipping a product to customers with this code inside it? If no — and for most businesses the answer is no — the distinction does not reach you. If yes, it is a real question and worth an hour with somebody qualified.

Moment two: something goes wrong

All three disclaim warranty entirely, and they do it in capital letters. No guarantee it works, no liability for damage, no promise of fitness for anything.

People react to this as though it were a scandal. It is not a meaningful difference from commercial software, where the liability is usually capped at what you paid — but it does mean that if you need somebody contractually on the hook, the licence will never give you that. You buy it separately, from a support provider, and the code being free is what makes that market possible.

Apache differs in one practical detail here: it explicitly grants you patent rights from contributors. MIT says nothing about patents at all. In a regulated or patent-heavy industry that gap is worth knowing about; in a joinery workshop it is not.

Moment three: the project changes its mind

This is the one I care about most as somebody choosing software for other people, and it is barely ever discussed.

A project can change its licence for future versions. It has happened repeatedly to well-known software: years of open development, a large user base, and then new terms that are no longer open. What protects you is that the version released under the old licence stays under the old licence, permanently. Nobody can retroactively take that away.

In practice this means the community can continue the last open version independently, and several times it has — with the continuation becoming the version most people use. That possibility is the actual guarantee an open licence gives you. Not that the project will always behave well, but that if it stops, you are not stranded.

What I actually check before putting something on a client's machine

Three things, in about five minutes, and none of them is which of the three licences it uses.

Is it an actual open licence, or one of the newer terms that restrict commercial use while using the word open in the marketing? That distinction matters far more than MIT against GPL, and it is the one that has changed most in the last few years.

Who governs it — a foundation with multiple members, or a single company with investors? The second can change terms; the first structurally struggles to.

And where the data lives, in what format, readable by what. Because in the end that is the thing a licence is really protecting: your ability to leave. A perfect licence over software that traps your files in a format nothing else reads has given you freedom you cannot exercise.