The Licences, Told Apart

Section 01A map before the argument starts

Every piece of free and open-source software carries a licence. That licence is a legal document, but its practical meaning fits in a sentence: it says what you may do with the code and what, if anything, you owe in return. Most of the arguments you will encounter about open-source licences — online, at work, in a project README — turn out to be arguments about two cells in one table. Before reaching those two cells, it helps to know what the table looks like.

The columns that matter most are three: Can you use this for anything? Can you change it? And if you ship it to someone else, what do you have to pass along? The last question is where the argument lives. For a user who simply downloads software and runs it, the licence rarely touches them at all — it is addressed to anyone who redistributes the software or builds something on top of it. Understanding that audience distinction immediately clarifies why so many debates feel abstract: they are abstract, for ordinary users. For a developer, a business, or anyone who ships products, the distinctions are very concrete.

Five licences cover the great majority of free and open-source software in the wild. They are not the only ones — the Open Source Initiative ↗ maintains a list of approved licences that runs to well over a hundred — but knowing these five equips you to read almost any project's terms without confusion.

Section 02The five, described plainly

The MIT Licence is the shortest of the five and, by some measures, the most widely used in modern software. It grants permission to use, copy, modify, merge, publish, distribute, sublicense, and sell copies, subject to one condition: the copyright notice and the licence text must travel with the software. That is the entire requirement. A company may take MIT-licensed code, build a proprietary product around it, and ship that product without releasing a line of their own code. The MIT Licence asks for attribution; it asks for nothing else. Its brevity is a feature in the eyes of its fans and a flaw in the eyes of its critics, who argue that it gives away community work with no guarantee that the community benefits in return.

The Apache Licence, Version 2.0 grants a similarly broad set of permissions. Like the MIT Licence, it allows proprietary use; unlike it, it also contains an explicit patent grant, meaning contributors formally licence any relevant patents they hold to downstream users. It also includes a clause that terminates the patent grant if a licensee initiates patent litigation against contributors. The Apache Software Foundation, which developed it, designed it partly to address the gaps that simpler licences leave when patent risk is real. For projects used in commercial environments where patent exposure is a genuine concern, Apache 2.0 is the common choice over MIT precisely because it says more.

The GNU General Public Licence, version 2 (GPLv2) is the Free Software Foundation's original strong copyleft licence, still in force for a great deal of significant software — including the Linux kernel. Copyleft is the mechanism that distinguishes this family of licences from the permissive ones above: if you distribute software based on GPLv2 code, you must make the corresponding source code available under the same licence. The freedom to use, study, modify and distribute is preserved for everyone in the chain. This is what "free" actually means in the Free Software Foundation's framework: not a low price but a set of persistent, irrevocable permissions that cannot be stripped away as software passes through hands.

The GNU General Public Licence, version 3 (GPLv3) is the FSF's revision, published in 2007, which added protections that GPLv2 did not anticipate. Two additions matter most. First, an explicit patent licence and patent non-aggression provision — similar in intent to what Apache 2.0 provides, but built into the copyleft framework. Second, anti-tivoisation provisions: the licence requires that if you distribute hardware that contains GPLv3 software, users must be able to install modified versions of that software on the device. This is aimed directly at situations where a manufacturer uses open source internally but locks the device so owners cannot exercise their rights in practice. Linus Torvalds and the Linux kernel maintainers have declined to move the kernel from GPLv2 to GPLv3, and their reasons — principally the anti-tivoisation clause and its interaction with hardware businesses — represent one of the most substantive technical-legal debates the community has had.

The GNU General Public Licence, version 3 (GPLv3) is the FSF's revision, published in 2007, which added protections that GPLv2 did not anticipate.

The GNU Lesser General Public Licence (LGPL) sits between copyleft and permissive. It was designed for libraries — reusable code components that many programs link to. Under the LGPL, a program that merely links to an LGPL library (rather than incorporating and modifying its code directly) does not itself need to be released under a copyleft licence. The library itself, if modified and redistributed, must remain under the LGPL. This was a pragmatic compromise: the FSF wanted free libraries to be used as widely as possible, and a full GPL requirement would have deterred proprietary programs from linking to them. The LGPL is why you can legally build a closed-source application that uses a free software library without violating that library's licence.

Section 03The two cells where most arguments live

Return now to the table and its columns. On the question of use and modification, every open-source licence discussed here agrees: you may do both freely. The real argument is in the last column — the one about redistribution — and within that, it breaks into two sub-questions.

The first sub-question is copyleft or not? MIT and Apache 2.0 say: distribute on whatever terms you like, just carry the copyright notice. GPL says: distribute, but the freedom must survive — your recipients must get source and the same rights you got. LGPL says: it depends on how tightly your code is coupled to the library. Whether copyleft is a gift or a burden depends entirely on your position in the chain. For a solo developer publishing a tool they never intend to commercialise, copyleft costs nothing. For a business building a proprietary platform, it is a structural constraint that shapes what components they can incorporate.

The second sub-question is which GPL? Version 2 or version 3 is not a cosmetic choice. If your product runs on embedded hardware, GPLv3's installation requirements may mean you cannot use GPLv3 code at all without giving device owners the ability to replace your firmware. If your project receives contributions from many parties and patent risk is real, GPLv3's patent provisions offer stronger protection than GPLv2. These are not edge cases — they are the exact situations that prompted the FSF to write GPLv3 in the first place, and the exact situations that prompted some projects to decline the upgrade.

Everything else in most licence debates — the length of the text, the name of the foundation, the historical context — is background. The signal is: permissive, or copyleft? And if copyleft, which version, and does your use case trigger the extra provisions?

A final practical note, and one worth keeping close: licence compatibility matters when you combine code under different licences into a single project. MIT code can generally be incorporated into a GPL project; GPL code cannot generally be incorporated into a proprietary project; Apache 2.0 and GPLv3 are compatible, but Apache 2.0 and GPLv2 are generally not, because GPLv2 predates the patent language and the two licences impose requirements that cannot simultaneously be satisfied. Checking compatibility before combining is not a legal formality — it is how you avoid distributing software that violates its own licence. None of this is legal advice; when real money or liability is involved, a lawyer familiar with intellectual property is the right resource.

Five licences, two questions, one table. The rest is detail.