A practical guide to open source licensing in 2026

Quick answer. In 2026, the open-source license landscape has consolidated around three choices for most new projects: MIT (most permissive, smallest compliance burden), Apache-2.0 (permissive with explicit patent grants), and AGPL-3.0 (copyleft that covers SaaS use). Everything else is a niche choice. The three most common mistakes are: (1) picking GPL-3.0 when you wanted to allow commercial use, (2) missing a license file entirely, and (3) not updating the license header when changing project names.

The license landscape in 2026

There are roughly 200 OSI-approved open-source licenses. In practice, 95% of new projects in 2026 ship with one of five: MIT, Apache-2.0, BSD-3-Clause, GPL-3.0, or AGPL-3.0. The GitPop radar tracks license distribution across 50,000 active projects. The numbers:

• MIT — 49.8% of new projects
• Apache-2.0 — 21.3%
• BSD-3-Clause — 6.4%
• GPL-3.0 — 5.1%
• AGPL-3.0 — 2.9%
• Other / no license — 14.5%

The "no license" bucket is the interesting one. In some jurisdictions, an unlicensed project is not open source — by default, all rights are reserved to the copyright holder. We flag unlicensed projects in the methodology so they can be filtered out of due-diligence workflows.

When to pick which

Pick MIT when: you want the lowest friction for downstream use. MIT is a permissive license — anyone can use, modify, and redistribute the code, including in proprietary products, with attribution. This is the right pick for libraries and frameworks that want to maximize adoption. Tradeoff: no explicit patent grant, which matters more in Java / enterprise codebases.

Pick Apache-2.0 when: you want the permissive flow + a patent grant. Apache-2.0 includes an explicit contributor patent license, which protects downstream users from contributor patent claims. This is the right pick for any project that touches enterprise codebases, distributed systems, or anything where patents are a real concern. Used by Kubernetes, TensorFlow, and most CNCF projects.

Pick AGPL-3.0 when: you want copyleft coverage that includes SaaS use. AGPL closes the "ASP loophole" — if someone runs your code as a network service, they have to open-source the modifications. This is the right pick for database engines, search backends, and infrastructure where SaaS hosting is a real business model. Used by MongoDB (now SSPL), Grafana, Nextcloud, and Mattermost.

Pick GPL-3.0 when: you want copyleft for non-SaaS use cases. GPL is the original copyleft license. If you modify and redistribute the code, you have to open-source your changes. But if you just use the code as a network service, you don't have to. This is the right pick for libraries and tools where you want to ensure modifications stay open.

Don't pick BSL (Business Source License) unless you know what you're doing. BSL is technically not open source per OSI definition. It allows non-production use freely and requires a commercial license for production use. MariaDB, CockroachDB, and Sentry have all moved to BSL in the last few years. The right pick only if you have a clear commercialization path.

The three common mistakes

1. Picking GPL-3.0 when you wanted commercial use. Many companies avoid GPL-licensed dependencies because of the copyleft obligation. If you want your library to be adopted in commercial products, MIT or Apache-2.0 is the safer pick. If you want the copyleft protection, AGPL is the modern version of the same idea.

2. Missing the LICENSE file entirely. Roughly 14% of new projects on the radar have no LICENSE file. In some jurisdictions (notably Germany and France), an unlicensed project is not open source — all rights are reserved. The GitPop noise filter flags unlicensed projects so they can be filtered out of due-diligence workflows.

3. Not updating the license header when renaming the project. When you fork a project, the copyright line in every file should be updated to reflect the new maintainer. We have seen forks go to court over the original copyright line never being updated.

How we use licensing data

Every project on the GitPop radar has its license surfaced on the project page. The license is one of the inputs to the health score — projects with a recognized OSI license get a small boost. We also surface the license in the compare matrix so you can see the license of every project you're comparing.

For more on how we measure projects, see What is PopScore?. For a deeper look at the data behind these license distribution numbers, see the State of GitPop H2 2026 data report.