What about source-available licenses (BSL, SSPL, Elastic)?

Source-available licenses (BSL = Business Source License, SSPL = Server Side Public License, Elastic License) are NOT open source by the OSI definition. They allow you to read the code but restrict commercial use. Companies like HashiCorp and Elastic have moved from Apache 2.0 to source-available to prevent cloud providers from monetizing their work without contributing back. If you want true open source, use MIT/Apache/GPL. If you want source-available, use BSL/SSPL/Elastic — but be aware that forking is harder.

Blog · Licensing

How to choose an open source license

Q: What license should I use for a new open source project?

The 80% answer: MIT or Apache 2.0. MIT is the most permissive (anyone can do anything with the code). Apache 2.0 is similar but adds an explicit patent grant. For most projects, pick one of these and move on. The other licenses (GPL, AGPL, BSD, MPL) are for specific use cases.

Q: What about GPL vs MIT?

MIT is permissive — anyone can use, modify, and redistribute the code, including in proprietary software. GPL is copyleft — anyone who distributes a derivative work must also distribute the source under GPL. AGPL is the most restrictive: it requires the source of any network service that uses the code to be published. Most libraries should be MIT or Apache. Most applications should be MIT or Apache. Copyleft is mostly relevant for projects that want to ensure derivatives stay open.

Q: Does the license matter for adoption?

Yes. AGPL is a deal-breaker for many companies. SSPL is a deal-breaker for most companies that use MongoDB-style infrastructure. BSL is a deal-breaker for some companies. MIT/Apache/BSD/GPL are all safe. If you're trying to maximize adoption, MIT is the safest choice — it's the most permissive and the most familiar.

MIT, Apache 2.0, BSD, GPL, AGPL, BSL, SSPL, Elastic — which license should you pick? The 2026 decision tree.

Published July 13, 2026 · ~6 min read

The 80% answer

MIT or Apache 2.0. MIT is the most permissive (anyone can do anything with the code). Apache 2.0 is similar but adds an explicit patent grant. For most projects, pick one of these and move on. The other licenses (GPL, AGPL, BSD, MPL) are for specific use cases.

The 2026 license landscape

There are three categories of license to consider:

1. Permissive (MIT, Apache 2.0, BSD)

Anyone can do anything with the code, including using it in proprietary software. The most popular licenses in modern OSS. Apache 2.0 is slightly more "corporate" — it includes a patent grant, which is important for companies that want to use the code without patent risk. MIT is the most familiar and the most universally accepted. Both are safe for adoption.

2. Copyleft (GPL, LGPL, AGPL, MPL)

Anyone who distributes a derivative work must also distribute the source under the same license. GPL is the original copyleft license — it's why Linux is open. LGPL is a weaker version for libraries. AGPL is the strongest — it requires the source of any network service that uses the code to be published, which is why some companies refuse to touch AGPL-licensed code. MPL is file-level copyleft — modifications to MPL files must be shared, but the rest of the project can be proprietary.

3. Source-available (BSL, SSPL, Elastic)

NOT open source by the OSI definition. You can read the code but commercial use is restricted. BSL (Business Source License) is used by HashiCorp — converts to Apache 2.0 after a few years. SSPL (Server Side Public License) is MongoDB's license — requires the source of any service that uses the code to be published. Elastic License is Elastic's — restricts hosting by cloud providers. If you want true open source, use MIT/Apache/GPL. If you want source-available, use BSL/SSPL/Elastic — but be aware forking is harder.

The 2026 decision tree

Want maximum adoption? MIT.
Want patent safety for corporate users? Apache 2.0.
Want to ensure derivatives stay open? GPL (libraries → LGPL, network services → AGPL).
Want to monetize the cloud version while keeping the code source-available? BSL with a future Apache 2.0 conversion.
Want to prevent cloud providers from monetizing your work? AGPL (or move to BSL/SSPL like MongoDB and Elastic did).

The maintainer-handoff angle

The license you pick affects how easy the handoff is. MIT and Apache 2.0 are the easiest to fork — anyone can take the code, change the name, and ship a derivative. GPL is harder — the derivative must also be GPL, which limits who can adopt. AGPL is hardest — most companies won't touch it. BSL and SSPL are even harder — the new maintainer may have to negotiate a license change with the original maintainer or the foundation.

If you want the handoff to be frictionless, pick MIT or Apache 2.0. The 41% revival rate from the 2019 arXiv study assumes a permissive license. With a copyleft or source-available license, the rate is much lower.

Frequently asked questions

What license should I use for a new project?

MIT or Apache 2.0. For most projects, pick one and move on.

What about GPL vs MIT?

MIT is permissive (anyone can use in proprietary). GPL is copyleft (derivatives must also be GPL). AGPL is the strongest.

What about source-available licenses?

Not OSI-open-source. BSL, SSPL, Elastic all restrict commercial use. Forking is harder.

Does the license matter for adoption?

Yes. AGPL, SSPL, BSL are deal-breakers for many companies. MIT/Apache/BSD/GPL are safe.