Most projects choose a license the way most people choose a default shell: it was already on fire there when they arrived. The LICENSE file came with the project template, or the ecosystem, or the last project, and nobody has opened it since.
That works more often than it should. But the licenses differ from each other on purpose. Each one is somebody’s answer to a specific question, and the questions come in a reasonably fixed order. What follows is that order, written out as a decision tree in prose (a garden of forking paths, and I do mean forking), with the reasons people give at each branch. It describes why projects and individuals end up where they do. It is not legal advice, and it is not a recommendation.
Two ground rules before the first branch.
First, no license does not mean “free for the taking.” Copyright attaches automatically, and the default is that nobody else may copy, modify, or distribute your code. A public repository with no license file is a museum exhibit.
Second, do not write your own. Every license in this piece has been read by a great many lawyers, and a few have been read by judges. A license you wrote over a weekend has been read by you.
The first fork: what happens to other people’s changes?
Someone takes your code, modifies it, and ships the result to a third party. Are they required to offer that third party the modified source, under the same license you used?
If no, you want a permissive license: MIT, BSD, Apache 2.0. If yes, you want copyleft: the GPL and its relatives. Everything else in this piece refines one answer or the other.
Both camps describe their answer as freedom, and they mean different people. Permissive licenses protect the freedom of the next developer, who may do anything at all with the code, including closing it. Copyleft protects the freedom of the eventual user, who is guaranteed the source to whatever they were handed. That is why the argument has run for decades without either side persuading the other. They agree on the facts.
Why people answer “no”
The most common reason is adoption. A permissive license asks almost nothing of the recipient (keep the copyright notice, don’t sue us), so every corporate legal department approves it without a meeting. If the goal is to be everywhere, obligations on downstream users are friction. curl ships under an MIT-style license. SQLite went further and dedicated the whole thing to the public domain. Kubernetes is Apache 2.0.
PostgreSQL is the example I know best. The project describes its license as “a liberal Open Source license, similar to the BSD or MIT licenses.” Any company can build a closed product on PostgreSQL and contribute nothing back, and some do. The bet a permissive project makes is that contribution will come from self-interest instead of obligation: carrying a private fork of a fast-moving codebase is expensive, and upstreaming your changes is cheaper than rebasing them forever.
The second reason is the neighborhood. Ecosystems have conventions, and a library that departs from the local convention is a library people hesitate to depend on.
The third is plain indifference. Some authors do not care what happens downstream, and a permissive license is the honest expression of that.
Why people answer “yes”
Reciprocity is the usual reason: I shared this with you, so you share your version with whoever you ship it to. Nobody gets to take the commons private.
For the Free Software Foundation, which wrote the GPL, the point is the user. Software you cannot inspect or change is software that controls you, and copyleft is the mechanism that keeps that from happening to anything built on GPL code.
There is also a harder-nosed version. Copyleft stops a competitor from taking your work, improving it in private, and selling the improved version against you. The Linux kernel is the standard exhibit: every vendor that ships a modified kernel has to offer the source, and the usual argument is that this is a large part of why so much vendor code ends up upstream.
Finally, copyleft gives a company something to sell. More on that below.
The permissive branch: do you want to say anything about patents?
MIT and the BSD licenses are close to interchangeable. The 3-clause BSD license adds a clause forbidding use of the authors’ names for endorsement; the 2-clause version drops it. The original 4-clause version required an acknowledgement of the University in all advertising materials, which was every bit as practical as it sounds. Berkeley deleted that clause on July 22, 1999.
What these licenses share is silence about patents. The word does not appear in any of them. Whether a grant of the right to “use” software implies a license to the author’s patents is something lawyers can argue about. The text itself offers no help.
For an individual, this doesn’t matter. You have no patents. For a company with a patent portfolio, or one consuming code written by such a company, it is the main question.
Apache 2.0 answers it. Section 3 is an express patent license from every contributor, covering their contributions, and it terminates for anyone who files a patent suit claiming the work infringes. The license also requires that modified files be marked as changed and that a NOTICE file, if there is one, travel with the code.
The cost is length, and one compatibility problem. The Apache Software Foundation’s own summary is that Apache 2.0 code can go into GPLv3 projects, that the reverse is not true, and that the FSF has never considered Apache 2.0 compatible with GPLv2.
Rust is dual-licensed “MIT OR Apache-2.0,” as is most of its crate ecosystem, and the project’s old FAQ explains why in two sentences: “The Apache license includes important protection against patent aggression, but it is not compatible with the GPL, version 2. To avoid problems using Rust with GPL2, it is alternately MIT licensed.”
That is the entire permissive branch. Individuals and small libraries tend toward MIT or BSD, because the license is short and nobody has to think. Corporate-sponsored and foundation-hosted projects tend toward Apache 2.0, because somebody’s lawyer did.
The copyleft branch: how far does it reach?
Copyleft comes in three strengths, distinguished by how much of the surrounding code the obligation covers.
File level. Under the Mozilla Public License 2.0, if you modify an MPL-licensed file and distribute the result, that file’s source stays under the MPL. Put it next to your own files in what the license calls a “Larger Work,” and your files are yours to license as you please. People choose it when they want fixes to their code to come back and have no interest in controlling what gets built around it.
Library level. The LGPL lets a proprietary program link to the library. Changes to the library itself stay under the LGPL, and the user has to be able to swap in a modified version of the library and relink. It began in 1991 as the “Library” GPL and was renamed the “Lesser” GPL in 1999, which is a fair summary of the FSF’s enthusiasm for it. These two are usually called weak copyleft.
Whole program. Under the GPL, if your code and GPL code are distributed together as one work, the whole work is under the GPL. Where “one work” begins (static linking, dynamic linking, plugins, separate processes talking over a socket) is the most-argued question in the field, and there is less case law on it than you would expect. The kernel’s license carries an explicit exception (the Linux-syscall-note) saying that user programs making “normal system calls” are not a “derived work,” which exists to settle exactly one such boundary in advance.
Library authors who want proprietary software to use the library, and who still want the library to stay open, pick the weak forms. Authors who want leverage over the whole program pick the GPL.
GPLv2 or GPLv3?
GPLv3 arrived on June 29, 2007, sixteen years after version 2. It added three things that matter here.
It added an express patent license (section 11). GPLv2 has none; its section 7 says only that if a patent obligation prevents you from honoring the license, you may not distribute at all. It became compatible with Apache 2.0. And section 6 requires that when GPLv3 software ships inside a consumer device, the manufacturer provide the “Installation Information” needed to install a modified version on that device.
That last one is the fork in the road. On January 25, 2006, with GPLv3 still in draft, Linus Torvalds wrote to the kernel list: “I think it’s insane to require people to make their private signing keys available, for example. I wouldn’t do it.” And then: “Conversion isn’t going to happen.” It hasn’t. The kernel’s COPYING file says “GNU General Public License version 2 only.”
Device makers drew the same line. Apple shipped bash 3.2, the last GPLv2 release, for years after bash itself had moved on, and then made zsh the default shell in macOS 10.15. Apple has never said that GPLv3 was the reason. Everyone else has said it for them.
The difference has now reached a courtroom. In Software Freedom Conservancy v. Vizio, a California state court ruled on December 23, 2025 that GPLv2 and LGPLv2.1 do not oblige a television maker to supply what a buyer would need to reinstall modified software on the set and have it keep working. (The Conservancy’s response was that it had never claimed otherwise.) That is the territory section 6 of GPLv3 was written to cover. The rest of the case, which asks whether a purchaser who holds no copyright can enforce the GPL as a contract, is still pending.
One more wrinkle: code licensed “GPLv2 only” cannot be combined with GPLv3 code, since each license forbids adding the other’s terms. Code licensed “version 2 or any later version” can, at the price of trusting the FSF with terms it has not written yet. Some projects consider that trust well placed. The kernel did not.
So: people who care about patents and locked-down hardware choose v3. People who want exactly the bargain they read, or who want device manufacturers as users, choose v2.
Does it run as a service?
Every GPL obligation is triggered by handing someone a copy. GPLv3 says so in as many words: “Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.” In 1991 that was a technicality. Today it describes how most server software reaches its users. A hosting company can modify a GPL-licensed database, run it for ten million customers, and owe nobody a line of source.
The AGPLv3 is GPLv3 plus one section. Section 13 says that if you modify the program, your modified version must offer its source to the users interacting with it over a network. The trigger is modification; running an unmodified copy as a service does not set it off.
The AGPL has a reputation for being radioactive, and that reputation is not undeserved.
Two kinds of people choose it. The first want copyleft to follow the software onto the server, for the same reasons as before. The second are companies that want a license which is unambiguously open source and still unappealing to anyone planning a competing hosted version. Grafana Labs moved Grafana, Loki, and Tempo from Apache 2.0 to AGPLv3 in April 2021.
The cost is that many large organizations will not touch it. Google’s published policy is one sentence long where it counts: “Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.” The ASF places the AGPL, along with the GPL and LGPL, in “Category X,” meaning it may not be included in Apache products at all.
For a community project that wants to be adopted everywhere, that is a serious price. For a company that also sells a commercial license to the same code, it is the business model.
For companies: who owns it?
An individual can skip this branch. A company releasing code has two more questions: how do we get paid, and can we change our minds later?
The classic answer to the first is dual licensing. MySQL AB offered MySQL under the GPL and, for customers who could not live with the GPL, under a commercial license. The copyleft is what makes the commercial license worth buying, which is why a stronger copyleft makes for a better sales tool, and why the AGPL appeals to companies that have no ideological attachment to it.
This only works for the copyright holder. Nobody else can offer the code on other terms. So a project’s contribution rules matter as much as its license, and there are three common arrangements.
- The Linux kernel uses the Developer Certificate of Origin: contributors certify they have the right to submit the patch, and keep their copyright. Nobody holds enough of the kernel to relicense it.
- The ASF uses a contributor license agreement under which contributors keep their copyright and grant the foundation a broad license.
- The FSF historically required copyright assignment for the packages it holds. GCC stopped requiring it on June 1, 2021.
A corporate CLA that gives the company the right to relicense contributions is what keeps the door open. Read it before you read the license.
A permissive license doesn’t even need the CLA: anyone may take BSD-licensed code into a closed product, the original author included. With PostgreSQL, companies do that routinely. What cannot happen is the project itself going closed, because there is no single owner in a position to do it. The licence page says “There are no plans to change the PostgreSQL License or release PostgreSQL under a different license,” and the structure of the project is why you can believe it.
The exit: when open source isn’t the answer you wanted
The last question is whether you are willing to forbid one particular use. In practice the use is always the same one: a competitor offering your software as a hosted service.
If yes, you have left open source by definition. Criterion 6 of the Open Source Definition is “No Discrimination Against Fields of Endeavor.” What remains is called source-available, and it comes in three main designs.
The SSPL. MongoDB wrote the Server Side Public License and moved to it from the AGPL on October 16, 2018. Its section 13 says that if you offer the program as a service, you must release the “Service Source Code” under the SSPL, defined to include “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software.” MongoDB submitted it to the Open Source Initiative for approval and withdrew it in March 2019. The OSI’s later statement on the subject is titled “The SSPL is Not an Open Source License,” which saves me a sentence.
The Business Source License. Created by Michael Widenius and David Axmark and first used for MariaDB’s MaxScale in 2016. It permits non-production use plus whatever “Additional Use Grant” the licensor writes. Each version converts to a GPL-compatible open source license no later than four years after release. The text is candid: “The Business Source License … is not an Open Source license.”
The Functional Source License. Sentry introduced it in November 2023. It permits everything except a “Competing Use,” and each version converts to Apache 2.0 or MIT after two years.
There is also a fourth, cheaper design: take an open source license and bolt a restriction onto it. Neo4j appended the Commons Clause to the text of the AGPLv3. The AGPL says that a recipient who finds a “further restriction” attached may remove it; a federal district court held that Neo4j’s licensees could not. The FSF and the Software Freedom Conservancy both filed briefs in the Ninth Circuit arguing that the court got it wrong.
Companies give one reason for all of these, and they give it openly: a competitor, usually a large cloud provider, can sell the software as a managed service without funding its development.
What happens next has a track record.
Elastic announced on January 14, 2021 that Elasticsearch and Kibana were moving from Apache 2.0 to a choice of the SSPL or its own license. AWS announced OpenSearch, a fork of the last Apache-licensed release, on April 12. On August 29, 2024, Elastic announced that it was adding the AGPL as a third option.
Redis moved from 3-clause BSD to a choice of its own source-available license or the SSPL on March 20, 2024. The Linux Foundation announced Valkey eight days later. On May 1, 2025, Redis 8 added the AGPL.
HashiCorp moved Terraform and its other products from MPL 2.0 to the Business Source License on August 10, 2023. OpenTofu joined the Linux Foundation on September 20. IBM completed its acquisition of HashiCorp on February 27, 2025, and Terraform is still under the BSL.
Three relicensings, three forks within weeks or months, and two returns by way of the AGPL. Whether that record shows the strategy failing or working depends on what the company wanted from it. Elastic’s founder, announcing the return, wrote that the company had changed the license “knowing it would result in a fork of Elasticsearch with a different name and a different trajectory,” and that “while it was painful, it worked.”
What none of these companies could do was take back what they had already shipped. Every release that went out under BSD, Apache 2.0, or MPL is still under that license for anyone holding a copy. A license is easy to change going forward if you own the code. It cannot be changed going backward. Valkey exists because of that.