GPL vs MIT vs Apache: a licence history
Why the GPL, MIT and Apache 2.0 exist, what each one asks of you, and what the SSPL and BUSL relicensing wave means if you self-host the software.
GPL vs MIT vs Apache: what each licence asks of you
GPL, MIT and Apache 2.0 answer the same question in different ways: what do you owe other people when you pass the software on? MIT asks for a copyright notice and nothing more. Apache 2.0 asks for that notice plus a patent bargain between everyone who touches the code. The GPL asks you to publish the source of what you built on top, under the same licence you received.
That looks like a question for lawyers until the day a project you run changes its licence and splits in two. Then it is an operations question. You have two package repositories to choose between, and client libraries that stop talking to each other. This guide is about the licences and their mechanics, not about the movement that produced them, so every section ends where it touches you: the person who has to run the upgrade.
Why the GPL exists: a printer nobody was allowed to fix
Around 1980 the MIT Artificial Intelligence Lab received a Xerox 9700 laser printer. The lab had patched the software for an earlier printer so it would tell you when your job jammed. For the new one there was no source code, and the request for it was refused because of a nondisclosure agreement. Richard Stallman, then a programmer at the lab, treated that refusal as the general case rather than a bad day, and announced the GNU project on 27 September 1983.
Copyleft is built out of copyright law, not against it. By default you have no right to copy someone else's code at all. The GPL grants that right on a condition: if you give the program to someone else, you must give them the source, under the same terms, so they can do what the lab could not. The condition is enforceable because without the licence you had no permission in the first place.
Stallman wrote a licence for GNU Emacs first, then generalised it into GPL version 1 on 25 February 1989. GPL version 2 followed in June 1991, and it is still the licence on most of the system software you run. The Lesser GPL arrived for libraries, so a copyleft library could be linked by a program under any licence without pulling that program into the GPL.
One detail decides how the GPL affects a self-hoster. The obligation triggers on distribution, not on use. You can modify a GPL program, run it on your own server, serve the public with it, and owe nobody anything, because you never handed out a copy. That gap is the reason the AGPL exists.
The permissive tradition: BSD, then MIT
Berkeley took a different route. The Computer Systems Research Group released its Unix work under a licence that asked for the copyright notice to be kept and disclaimed all warranty. The original version had four clauses, and the fourth, the advertising clause, required an acknowledgement of the University in all advertising material mentioning features of the software. That does not scale. Stallman counted 75 separate acknowledgements in a 1997 version of NetBSD. UC Berkeley withdrew the clause on 22 July 1999, in a letter from William Hoskins of its Office of Technology Licensing.
What is left is the 3-clause BSD licence, which adds a ban on using contributors' names to endorse your product, and the 2-clause version, which drops even that. The MIT licence text came out of MIT in the 1980s, where it covered the X Window System, and in practice it does the same job as 2-clause BSD.
The motives were different. A university funded with public money wanted its work used everywhere, including by companies. The GNU project wanted a commons that could not be closed. Both positions are honest, and both have a failure mode. Permissive code can be taken private, and you get nothing back. Copyleft code is refused by companies whose lawyers will not accept the condition.
There is a second lesson from Berkeley, and it is the one this post keeps returning to. AT&T's Unix System Laboratories sued Berkeley Software Design in 1992 over the BSD code, and the case settled in early 1994. For two years nobody could be sure BSD was safe to build on, and adoption stalled while Linux grew. Legal uncertainty stops adoption faster than a missing feature does.
Why Apache 2.0 added a patent grant
The Apache Group's first licence was a BSD 4-clause derivative with the same advertising problem. Version 1.1, in 2000, removed that clause. Version 2.0, published in January 2004, was a rewrite rather than a patch.
The important addition is patents. MIT and BSD say nothing about them at all. A contributor can give you clear copyright permission for their code and still hold a patent that reads on what the code does, then sue the people using it. Apache 2.0 closes that hole: every contributor grants a patent licence covering their contribution, and anyone who sues claiming the work infringes their patents loses their own patent licence to it. The threat is mutual, so in practice nobody fires.
The rest of 2.0 is administrative, and that is why companies like it. There is a defined NOTICE file, so attribution has one home instead of being scattered through the tree. The licence can be applied by reference instead of pasted into every source file. Contributions are covered by explicit terms. Trademarks are excluded. A legal review of an Apache 2.0 dependency finds every question it wanted to ask already answered in the text, so approval becomes routine, which is most of what "corporate default" means.
What GPLv3 changed, and why Linux stayed on GPLv2
TiVo shipped a video recorder running Linux and published the kernel source, exactly as GPLv2 requires. The hardware then checked a cryptographic signature at boot and refused to run a kernel it did not recognise. You could read the source, change it, and compile it. You could not run it on the device it came from. The letter of the licence was met and its purpose was defeated, and the practice picked up the name tivoisation.
GPL version 3, published on 29 June 2007, answers this directly. When you convey the binary inside a consumer device, you must also supply the "Installation Information": the keys or the instructions needed to install a modified version and have it run. Version 3 also added an explicit patent grant, terms written in response to the Microsoft and Novell patent agreement of November 2006, and one-way compatibility with Apache 2.0.
Linux did not follow. The kernel is GPL version 2 only, with no "or any later version" escape clause, and its COPYING file says so. Linus Torvalds objected publicly to the anti-tivoisation terms for signed hardware. The practical barrier is larger than the disagreement: the kernel has thousands of copyright holders, so nobody could collect the permissions a relicence would need even if everyone wanted it. That single fact is the strongest protection a project can have, and it is worth remembering when you look at a project owned by one company.
The other 2007 licence matters more to you. The GNU Affero GPL version 3, published in November of the same year, extends the source obligation to people who interact with the program over a network. Run a modified AGPL service for the public and you owe those users the source. That is why so much self-hosted web software is AGPL. Nextcloud is one example, and if you are comparing the self-hosted alternatives to Nextcloud, the licence line in each candidate's repository tells you more about its next five years than its feature list does.
Which licences can you actually combine?
Compatibility runs one way, from permissive towards copyleft.
- MIT and BSD code can go into anything, including a closed product.
- Apache 2.0 code can be included in a GPLv3 project, and the combined work is GPLv3.
- Apache 2.0 code cannot be included in a GPLv2-only project. Its patent termination and indemnity terms are extra conditions that GPLv2 does not allow you to add. The FSF and the ASF both publish this conclusion.
- GPL code cannot be moved to a permissive licence by you. Only the copyright holders can do that, which brings you back to the question of who they are.
The relicensing era: SSPL, BUSL, and what they are not
The trigger was commercial. A company owns the copyright on a product, a cloud provider sells it as a managed service at scale and contributes little back, and the company changes the licence to stop that. Redis Labs made the first visible move in August 2018 by adding the Commons Clause on top of Apache 2.0 for several of its modules. MongoDB followed on 16 October 2018 by moving from AGPLv3 to the Server Side Public License.
The SSPL is the AGPL with one section rewritten. Offer the program to third parties as a service and you must publish the source of everything you use to offer it, including the management and orchestration software around it. That obligation has no clear edge, and no court has tested it. The OSI never approved the licence, and MongoDB withdrew its application in March 2019. Debian had already said in December 2018 that SSPL software did not belong in its archive, and Fedora ruled in January 2019 that the licence is not free, after which Red Hat dropped MongoDB from Fedora and from Red Hat Enterprise Linux. That is the mechanical result of a relicence: the distribution stops packaging the software, so your upgrades now come from a vendor repository on the vendor's schedule.
The Business Source License is a different device. It came from the MariaDB founders, and version 1.1 dates from 2017. It is not copyleft and it is not open source. The source is public, use is free except for the use the vendor carves out, which is normally running a competing hosted service, and every release converts automatically to a real open source licence on a change date no more than four years after that release. The licence it converts to must be GPLv2-compatible. HashiCorp moved Terraform and its other products to BUSL 1.1 on 10 August 2023. Outline uses it too, which is worth knowing if you are picking from the self-hosted Notion alternatives: running it for your own team is allowed, and building a service on it is not.
Neither licence is dishonest. Both say plainly that they are source available. Neither is open source by the OSI definition, and the difference lands on you rather than on the cloud provider it was aimed at.
OpenSearch: what a licence fork costs the operator
Elastic announced on 14 January 2021 that Elasticsearch and Kibana would leave Apache 2.0 for a choice of the SSPL or the Elastic License, starting with release 7.11. Version 7.10.2 was the last Apache 2.0 release. About a week later AWS said it would create and maintain an Apache 2.0 fork of both. The fork was named OpenSearch on 12 April 2021, with Kibana renamed OpenSearch Dashboards. OpenSearch 1.0 became generally available on 12 July 2021, built from Elasticsearch 7.10.2 and Kibana 7.10.2.
Look at what that cost the people running clusters. Package names and repositories changed. Every reference to Kibana in a runbook became OpenSearch Dashboards. Plugin names moved. Then the split reached application code: from version 7.13 of Elastic's official client libraries, the client checks what it has connected to and refuses to continue against anything that is not Elasticsearch, reporting that the server is an unknown product. A licence decision at a company you do not work for arrived as a failing call inside your own application.
The story then turned twice more. Elastic added AGPLv3 as a third licence option on 29 August 2024, so current Elasticsearch is OSI-approved open source again. On 16 September 2024, AWS transferred OpenSearch to the OpenSearch Software Foundation, hosted by the Linux Foundation, which gave the fork a governance home that is not a single company. Five years after the split both projects are open source, both are maintained, and OpenSearch is on its 3.x series as of August 2026.
The ending is the lesson. The licence came back and the fork stayed. Once an ecosystem has two of everything, undoing the paperwork does not merge them again.
The number that decides how much a relicence hurts is the gap between the announcement and a stable fork you can actually deploy.
The data behind this chart
[
{
"label": "Elasticsearch to OpenSearch 1.0",
"gap_to_stable_fork": 179
},
{
"label": "Terraform to OpenTofu 1.6.0",
"gap_to_stable_fork": 153
},
{
"label": "Redis to Valkey 7.2.5",
"gap_to_stable_fork": 27
}
]Each gap is counted from the vendor's public announcement to the fork's first stable release, using the dates listed below. OpenSearch 1.0 took 179 days, because the fork had to be renamed and rebuilt with no earlier fork to copy from. OpenTofu took 153 days. Valkey took 27 days, because it forked Redis 7.2.4 and kept the protocol and the on-disk format identical. The direction is the useful part: a credible fork now arrives in weeks, with a foundation and paid maintainers attached from the first day.
The relicensing dates behind this post
- 16 October 2018: MongoDB moves from AGPLv3 to the SSPL.
- March 2019: MongoDB withdraws the SSPL from the OSI approval process.
- 14 January 2021: Elastic announces the move off Apache 2.0, from release 7.11.
- 12 July 2021: OpenSearch 1.0, built from Elasticsearch 7.10.2 and Kibana 7.10.2.
- 10 August 2023: HashiCorp moves Terraform to BUSL 1.1.
- 10 January 2024: OpenTofu 1.6.0 reaches general availability.
- 20 March 2024: Redis moves from BSD 3-clause to RSALv2 and SSPLv1.
- 16 April 2024: Valkey 7.2.5, the first stable release, forked from Redis 7.2.4.
- 29 August 2024: Elastic adds AGPLv3 to Elasticsearch and Kibana.
- 16 September 2024: OpenSearch moves to the OpenSearch Software Foundation.
- May 2025: Redis 8 adds AGPLv3 as a third licence option.
Valkey and OpenTofu: the same pattern, faster
Redis Ltd moved Redis from the 3-clause BSD licence to a choice of RSALv2 or SSPLv1 on 20 March 2024. Eight days later the Linux Foundation announced Valkey, forked from Redis 7.2.4 and staying on BSD 3-clause. Valkey 7.2.5 arrived on 16 April 2024 with the same protocol and the same data files, so for most operators the migration was a package name. Redis then added AGPLv3 as a third option in Redis 8 in May 2025, which makes it open source again by the OSI definition, while Valkey continues under its own governance. The shape matches Elasticsearch closely.
Terraform ran the same course with one extra chapter. OpenTofu forked the last Mozilla Public License 2.0 release, joined the Linux Foundation in September 2023 and shipped 1.6.0 on 10 January 2024. On 3 April 2024 HashiCorp's lawyers sent the project a cease and desist letter claiming that code from a BUSL-licensed Terraform release had been copied into the fork. OpenTofu published a detailed response on 11 April 2024 denying it, and traced the disputed code to the MPL-licensed history that both projects share. Nothing further followed in public. The real risk in that episode is the one to remember: an accusation alone can freeze adoption for a quarter, which is the same effect the Berkeley lawsuit had thirty years earlier.
Not every fork starts with a licence. Forgejo forked from Gitea in 2022 after Gitea's development moved under a company, which was a governance dispute rather than a licensing one. Forgejo stayed MIT through its version 8 series, then relicensed to GPLv3 or later from version 9.0 in 2024, so its work could not be pulled back into a commercially controlled product. If you are weighing the self-hosted Git server options, that pair is the clearest live example of one codebase and two philosophies.
The test to run before you adopt anything
Four questions, before the first install rather than after.
- Who holds the copyright? Relicensing needs permission from every copyright holder, so a project with hundreds of independent contributors and no assignment cannot realistically be relicensed. A project where one company owns everything can be relicensed at a board meeting.
- Is there a CLA, and what does it grant? A contributor licence agreement that lets the company relicense your contribution under any terms it likes is the exact mechanism behind every relicence above. A DCO (developer certificate of origin), the sign-off line the Linux kernel adopted in 2004, transfers no rights at all. A CLA held by a foundation is safer than one held by a company, because a company can be sold.
- Who owns the trademark? Elastic kept the Elasticsearch name, so the fork had to rename itself and every runbook that mentioned Kibana had to be rewritten.
- What would a relicence cost you in particular? Count the data format, the client libraries, the configuration you would rewrite, and whether a compatible fork already exists.
Two commands answer part of this in seconds.
head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.mdEvery Debian and Ubuntu package ships a file at /usr/share/doc/<package>/copyright, and it records the licence of the version you installed, not the licence the project uses today. For bash on Ubuntu 24.04 that file names the GNU General Public License version 3. Run the second command inside a source checkout and you get the history of the licence file itself. A commit there in the last two years is worth reading before you build anything on the project. If the command prints nothing, the repository names its licence file something else, so list the root directory and look.
No licence protects you from every outcome, and choosing by ideology is how people end up surprised. Prefer projects whose copyright is spread across many hands or held by a foundation, and keep your data in a format you can export. Then find out which fork you would move to, and write the name down before you need it. Applying that check to each candidate costs less than an hour, and it is what separates an upgrade from a migration when you are deciding what to self host in 2026.
FAQ
Is the MIT licence the same as the BSD licence?
In effect, MIT matches the 2-clause BSD licence: keep the copyright notice and the warranty disclaimer, then do what you like, including building a closed product. The 3-clause BSD licence adds one thing, a ban on using contributors' names to endorse your product without permission. The older 4-clause version also demanded an acknowledgement in advertising material, and UC Berkeley withdrew that clause on 22 July 1999, so almost nothing current still carries it.
Can I put Apache 2.0 code into a GPLv2 project?
No. Apache 2.0 adds conditions that GPLv2 does not permit you to add, chiefly the patent termination clause, so a combined work cannot satisfy both licences at once. The FSF and the ASF both publish this conclusion. The other direction works: Apache 2.0 code can be included in a GPLv3 project, and the result is GPLv3. This is also why Apache 2.0 code cannot be merged into the Linux kernel, which is GPL version 2 only.
Is the SSPL an open source licence?
No, and the answer has practical consequences. The OSI never approved it, and MongoDB withdrew its application in March 2019. Debian said in December 2018 that SSPL software did not belong in its archive, and Fedora ruled in January 2019 that the licence is not free, after which Red Hat dropped MongoDB from Fedora and Red Hat Enterprise Linux. For you that means a package your distribution used to maintain now comes from a vendor repository, on the vendor's support timetable. The Business Source License is also source available rather than open source, although each release converts to an open source licence within four years.
Does a licence change apply to the version I already run?
No. A licence granted with a release cannot be withdrawn from copies already published, which is exactly why forks are possible. OpenSearch was built from Elasticsearch 7.10.2, the last release Elastic published under Apache 2.0. What you lose is the future, because the next security fix arrives under the new terms. Pinning the last permissively licensed version buys you a few months, and it is not a plan.