MIT, Apache 2.0 or AGPL? Picking an Open Source License Before You Ship

What does a license decide, and what if you have none?

A license is the permission slip for your code. Without one, nobody may legally reuse it. GitHub's documentation says that without a license "the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work" (GitHub Docs, Licensing a repository). Public GitHub repositories can still be viewed and forked, because that is part of GitHub's terms of service (choosealicense.com, No License).

It matters to the people you want as users: in GitHub's 2017 Open Source Survey, 64% said an open source license is very important in deciding whether to use a project (Open Source Survey 2017).

Five terms cover every license in this post:

Permissive

Use it for anything, closed products included, as long as you keep the copyright notice. MIT and Apache 2.0.

Weak copyleft

Changes to the licensed files stay under the same license; your own new files can use any license. MPL 2.0.

Strong copyleft

Whoever distributes a changed version must release the whole program, with source, under the same license. GPL 3.0.

Network copyleft

Strong copyleft that also counts letting people use a changed version over a network. AGPL 3.0.

Source-available

You can read the code, but the license limits who may use it and how, so it is not on the Open Source Initiative (OSI) list of approved licenses. BSL 1.1 and SSPL.

What does each license ask of the people who use your code?

All six licenses below let people read, change and redistribute your code. They differ in what they ask in return. Read across a row to see one license, or down a column to compare one duty.

Sources: the license texts (MIT, Apache 2.0, GPL 3.0, AGPL 3.0, BSL 1.1), the MPL 2.0 FAQ, the patent column from choosealicense.com, and the OSI license list, all read on 2026-10-16.

The one line that separates GPL from AGPL is in the GPL itself: "Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying" (GPL 3.0, section 0). So a company can run a changed GPL program on its servers and keep the changes. AGPL section 13 closes that gap: a changed version must "prominently offer all users interacting with it remotely through a computer network" its source (AGPL 3.0, section 13).

Which license does your package ecosystem expect?

A tool usually ships into one ecosystem first, and each ecosystem has its own default. An analysis by the Open Source Initiative of the ClearlyDefined dataset found that "MIT and Apache 2.0 are by far the most popular licenses", but in very different shares per package manager (OSI, The most popular licenses for each language in 2023).

Read it as a default to start from: MIT for JavaScript, Ruby and PHP, Apache 2.0 for Java and Go, either for Python. For Rust crates, MIT and Apache 2.0 together cover 83.52%, and the Rust API guidelines recommend the pair as MIT OR Apache-2.0 for "maximum compatibility with the Rust ecosystem" (Rust API Guidelines, C-PERMISSIVE). The same OSI data also shows how often the license is simply missing: 8% of npm components, 23.69% of PyPI and 29.67% of Go.

MIT or Apache 2.0: what actually differs?

Both let anyone use your code in a closed, paid product. The difference is how much the license says.

One more difference matters if GPL projects might use your code. The Apache Software Foundation says Apache 2.0 code "can therefore be included in GPLv3 projects", and that the Free Software Foundation has never considered it compatible with GPL version 2 (ASF, Apache License v2.0 and GPL Compatibility).

Why did Elastic, HashiCorp and Redis change their licenses?

All three were popular open source infrastructure that moved to source-available licenses, and two of them later added an open source option back. Elastic said its change was about "restricting cloud service providers from offering Elasticsearch and Kibana as a service without contributing back" (Elastic, 2021); Redis pointed to "the largest cloud service providers" (Redis, 2024).

1. 2018-10-16

   MongoDB releases the Server Side Public License (SSPL) for MongoDB Community Server (MongoDB press release). The OSI later published "The SSPL is Not an Open Source License" (OSI, 2021).

2. 2021-01-14

   Elastic announces a move of Elasticsearch and Kibana from Apache 2.0 to a choice of SSPL or the Elastic License (Elastic blog).

3. 2023-08-10

   HashiCorp moves all future releases of its products, Terraform among them, from MPL 2.0 to the Business Source License; its APIs, SDKs and almost all other libraries stay MPL 2.0 (HashiCorp blog).

4. 2023-09-20

   OpenTofu, an open source successor to the MPL-licensed Terraform, joins the Linux Foundation (Linux Foundation). It was accepted into the CNCF on 2025-04-23 (CNCF).

5. 2024-03-20

   Redis drops the BSD 3-clause license: from Redis 7.4, users choose RSALv2 or SSPLv1 (Redis blog).

6. 2024-03-28

   Valkey launches at the Linux Foundation from Redis 7.2.4, under the BSD 3-clause license (Linux Foundation).

7. 2024-08-29

   Elastic announces AGPL as a third license option for Elasticsearch and Kibana (Elastic blog).

8. 2025-05-01

   Redis adds AGPLv3 as an option, starting with Redis 8 (Redis blog).

License changeCommunity forkOpen source option added back

The lesson for a small team: a license change applies to new versions only. Redis said versions released before its change stayed under BSD (Redis blog), and both forks started from the last open source version. Pick the license you can keep. If hosted competitors are your real risk, AGPL is the open source answer both Elastic and Redis ended up offering.

Which license should you pick? Answer two questions

Open the first question and follow your answers.

How do you apply the license once you have picked it?

Three files: the license text, plus the same SPDX identifier in your package manifest and at the top of each source file. SPDX identifiers are short standard names such as MIT or Apache-2.0. The example below is an MIT-licensed npm package.

LICENSE
The full license text, copied unchanged, with your year and name.

package.json
"license": "MIT"

src/index.ts (first line of each source file)
// SPDX-License-Identifier: MIT

A Rust crate with the usual dual license changes all three: license = "MIT OR Apache-2.0" in Cargo.toml, two text files named LICENSE-MIT and LICENSE-APACHE instead of one LICENSE (Rust API Guidelines), and // SPDX-License-Identifier: MIT OR Apache-2.0 at the top of each source file (SPDX).

GitHub notes that most projects put the text in a file named LICENSE.txt, LICENSE.md or LICENSE.rst in the root of the repository (GitHub Docs). For a private package you do not want anyone to reuse, npm asks for "license": "UNLICENSED" (npm docs). If you list your tool on a directory or launch site, name the license on the listing too, next to the link to the code.