OSS Licensing: MIT vs Apache vs AGPL in 2026

License choice is one of the highest-leverage decisions an open source project makes. It determines who can use the software, under what conditions, whether cloud giants can productize it without contributing back, and whether enterprise legal teams will approve it. Pick the wrong one and you either give away the farm or freeze out the adopters you need to build momentum. Yet most developers treat it as an afterthought — a checkbox clicked in the GitHub repo-creation wizard.

This guide cuts through the legalese. Whether you are a solo maintainer publishing your first library, a startup deciding how to license your new SaaS alternative, or an engineering manager auditing your dependency stack before a compliance review, here is everything you need to understand MIT, Apache 2.0, and AGPL 3.0 in 2026 — and how to choose between them.

TL;DR

MIT: Maximum permissiveness, zero friction, no patent protection — the default for libraries
Apache 2.0: MIT plus explicit patent grants — the enterprise and foundation standard
AGPL 3.0: Copyleft that closes the SaaS loophole — the commercial OSS standard for web services in 2026
Dual licensing (AGPL + commercial) is how most serious open source SaaS alternatives turn their project into a business
The Google AGPL ban is real but widely misunderstood — it applies to Google engineers, not to companies generally

Key Takeaways

MIT accounts for roughly one-third of all licensed GitHub repositories; it dominates the JavaScript ecosystem and developer tooling
Apache 2.0's explicit patent grant and patent termination clause are why Google, CNCF, and most Fortune 500 OSS projects use it
AGPL's "network use" clause means running a modified AGPL application as a SaaS requires publishing your source — this is the critical difference from GPL
Most major open source SaaS alternatives — Grafana, Mattermost, Bitwarden, Nextcloud — are AGPL with commercial licenses available
The 2024–2026 relicensing wave (HashiCorp BSL, Redis RSAL) shows permissive licensing failing as a business model at scale
95% of codebases rely on open source; the average enterprise contains 500+ OSS components (Sonatype 2025 report)

Why License Choice Matters More Than You Think

The license you put on a project determines its SEO trajectory, enterprise adoption ceiling, contributor dynamics, and long-term financial sustainability. These are not abstract concerns.

On the SEO and discoverability side, license terms affect which third-party package indexes, curated lists, and enterprise procurement tools will list your project. Some enterprise software catalogs filter to permissive-only dependencies. Others specifically seek AGPL projects because they want the copyleft guarantee. Procurement engineers searching for self-hostable alternatives to commercial SaaS tools use license type as a primary filter. Getting that right from day one means your project shows up in the right places.

On enterprise adoption, legal teams at large organizations have established policies around specific licenses. A Fortune 500 company might have a rubber-stamp approval process for MIT and Apache 2.0 but require explicit legal review for any AGPL dependency. Conversely, a European government agency might require AGPL specifically — because it guarantees that vendor modifications stay public, supporting digital sovereignty goals. The wrong license for your target audience means your adoption curve flatlines at individual developers and never reaches the institutional buyers who write large checks.

On contributor rights, the license determines who owns what and under what terms future commercialization is possible. Projects that intend to pursue dual licensing need either a Contributor License Agreement (CLA) or copyright assignment from contributors — because re-licensing requires the consent of every copyright holder. Choosing your license without thinking about contributor mechanics creates a trap you cannot escape later.

On sustainability, the choice between permissive and copyleft licensing is fundamentally a choice about whether your project can be productized by others without returning value to you. This is not a moral argument — it is a business model decision. MIT and Apache are fine if you have other mechanisms for funding development. AGPL becomes essential when license compliance is your primary mechanism for converting commercial users into paying customers or pushing them toward a commercial license.

The Macro Shift Happening Right Now

Four forces are making license choice more consequential in 2026 than it was five years ago.

The first is the cloud monetization problem. In the 2010s, a pattern repeated itself: open source project gains traction under MIT or Apache, a hyperscaler launches a managed version of it, the managed service captures most of the revenue, and the original project struggles to fund ongoing development. Elasticsearch, Redis, and MongoDB all experienced this with AWS. The response — relicensing to BSL, SSPL, or AGPL — is a direct consequence of permissive licenses failing to protect projects from this dynamic.

The second is enterprise compliance maturity. Legal and security teams now audit every dependency in production stacks. This means your license choice gets evaluated by people whose job is to find risk, not to ship features. Apache 2.0's patent grant and AGPL's clear copyleft terms are actually easier for compliance teams to reason about than ambiguous MIT code that might have patent exposure.

The third is the EU regulatory environment. The EU Cyber Resilience Act (CRA), coming into force in 2027, places new obligations on software used in commercial products. Projects with well-documented licenses and clear terms of use are better positioned for this compliance environment than projects with ambiguous licensing histories.

The fourth is the AI training question. As large language models consume open source code, projects are scrutinizing whether their licenses permit use of their code as training data. MIT does not address this. Apache 2.0 is silent on it. Some AGPL projects have argued that training an AI model on their code constitutes "network use" and triggers the share-alike requirement. This remains legally unsettled, but it is adding a new dimension to license choice conversations.

MIT License: Maximum Freedom, Minimum Protection

The MIT License is 171 words. You can read the entire thing in under a minute. That simplicity is both its greatest strength and its most significant limitation.

The core requirement is almost insultingly minimal: if you distribute software that incorporates MIT-licensed code, you must include the original copyright notice and license text. That is the entire obligation. You can use MIT code in a closed-source commercial product. You can modify it and never share your changes. You can build a competing product on top of it. You can sublicense it as part of a larger work under different terms.

In concrete terms: AWS can take your MIT-licensed database engine, run it as a managed service charging enterprise customers millions of dollars per year, and owe you precisely nothing beyond keeping your name in a copyright notice buried in their documentation. This is not a theoretical risk. It has happened repeatedly and at scale.

This is not a bug in MIT — it is a deliberate feature, and it is exactly right for certain use cases. React (MIT, Meta), Vue.js (MIT, Evan You), Ruby on Rails (MIT, David Heinemeier Hansson), Express.js (MIT), Next.js (MIT, Vercel), jQuery (MIT), Lodash (MIT) — the most widely deployed software libraries in the world use MIT because the goal is maximum adoption with absolute minimum friction. When your project is a foundational building block, permissive licensing is what enables it to become infrastructure.

The risks for project maintainers are real. MIT offers no protection against a cloud provider building a competing managed service. It provides no explicit patent protection — if a contributor holds a patent on a technique implemented in your MIT-licensed code, they could in theory still assert that patent against users. There is no obligation for commercial users to contribute improvements back upstream, which means popular MIT projects can have enormous user bases and very thin contributor communities.

For library authors whose primary goal is maximum adoption and who are not direct commercial competitors to any cloud service, MIT remains the sensible default. For anything that could be packaged and resold — databases, message brokers, analytics platforms, collaboration tools, developer infrastructure — MIT is leaving significant leverage on the table.

Apache 2.0: The Enterprise-Grade Permissive License

Apache 2.0 is also permissive — you can use it in commercial closed-source products, you do not have to share modifications. But it adds two important protections that MIT does not include.

The first is an explicit patent grant. By contributing to an Apache 2.0-licensed project, contributors grant all users a royalty-free license to any patents they hold that are necessarily infringed by that contribution. This matters enormously in enterprise contexts where patent litigation risk is taken seriously by legal teams. The MIT license is silent on patents entirely — which creates an ambiguity that enterprise counsel will flag. Apache 2.0 removes that ambiguity with explicit language.

The second is a patent retaliation clause. If you initiate patent litigation against anyone, claiming that the Apache-licensed project (or a contribution to it) infringes your patents, your Apache 2.0 patent license from all contributors terminates automatically. This creates a meaningful deterrent against patent trolls who want both to use the code and to litigate against users of the same code.

Beyond patents, Apache 2.0 requires documenting significant changes to source files and preserving copyright, patent, and trademark notices. These are minor additional requirements compared to MIT, but they create a cleaner audit trail for enterprise compliance.

The projects that use Apache 2.0 read like a catalog of critical production infrastructure: Kubernetes (Google, CNCF), Apache Kafka (LinkedIn, Apache Software Foundation), Apache Spark (UC Berkeley), Flutter (Google), TensorFlow (Google), and the entirety of the Apache Software Foundation's portfolio. The pattern is deliberate — these are projects that expect contribution from employees at large corporations, and those corporations need patent clarity before their engineers can legally contribute.

If you are planning to submit your project to CNCF (Cloud Native Computing Foundation), the Apache Software Foundation, the Eclipse Foundation, or the Linux Foundation, Apache 2.0 is typically required or strongly preferred. These foundations operate on the premise that all contributors must be able to contribute safely across organizational boundaries, which requires the patent grant Apache 2.0 provides.

The one notable incompatibility: Apache 2.0 is not compatible with GPL version 2 due to conflicts between the patent termination clause and GPLv2's terms. It is compatible with GPL version 3 and LGPL 3. For projects mixing Apache 2.0 and MIT dependencies, there is no conflict — MIT is effectively a subset of what Apache 2.0 already permits.

AGPL 3.0: Copyleft Built for the Network Era

To understand AGPL, you need to understand the problem it solves that GPL could not.

GPL (General Public License) has been copyleft's foundation since 1989. Its share-alike principle is clear: if you distribute GPL-licensed software, you must make your source code available under the same terms. This works well for software distributed as binaries — desktop applications, command-line tools, operating system components. But in the early 2000s, a major loophole emerged.

If you run GPL software on a server and let users interact with it over a network — but never distribute the software itself to those users — you are not technically "distributing" under the GPL's definition. You can build an enormously profitable SaaS business on GPL foundations without ever sharing your modifications. This is called the "ASP loophole" (Application Service Provider loophole), and cloud providers figured out how to exploit it at scale.

AGPL 3.0 closes that loophole with a single critical addition: if users interact with your modified AGPL software over a network — via HTTP, WebSocket, API, or any other network protocol — you must offer those users the complete corresponding source code under AGPL terms. The network interaction itself triggers the copyleft obligation, not just binary distribution.

This one clause makes AGPL the most important license for web services and SaaS alternatives in 2026. The list of major open source SaaS alternatives using AGPL is extensive: Grafana (metrics and dashboards), Bitwarden server (password management), Mattermost (team communications), Gitea (git hosting), Nextcloud (file storage), Mastodon (social networking), Plausible Analytics (web analytics), Matomo (analytics), and hundreds more.

The compliance obligation for AGPL is more nuanced than it first appears. Running AGPL software as a network service that external users interact with requires making your source (including modifications) available. But running AGPL software internally, for your organization's own employees, does not trigger the network use clause — internal use is not "conveying" to the public. This distinction is crucial and frequently misunderstood.

For the detailed business case for why OSS companies are gravitating toward AGPL and what the controversy looks like from inside those companies, see our full analysis of the AGPL license debate.

The Google AGPL Ban: What It Actually Means

Google has an internal policy prohibiting Google engineers from adding AGPL-licensed dependencies to Google products without explicit approval from Google's legal team. This is real. It has been confirmed by multiple ex-Googlers, referenced in leaked internal documentation, and is accurately described in various public sources.

What the policy does not mean: that AGPL is unusable by companies generally, that it is legally defective, or that enterprises cannot deploy AGPL software. What it actually means is that Google, as a company building proprietary commercial products and competing cloud services at massive scale, has calculated that its engineers should not accidentally trigger AGPL obligations that could require open-sourcing portions of Google's commercial stack.

This is a perfectly rational policy for Google. Google builds commercial products. AGPL's terms, if an engineer inadvertently incorporated AGPL code into a Google product and that product was offered as a network service, could require open-sourcing significant portions of Google infrastructure. The compliance cost is asymmetric for a company of Google's scale and commercial sensitivity.

For most organizations, the risk profile is completely different. A startup running Grafana for internal metrics dashboards has no AGPL compliance exposure whatsoever — internal use does not trigger the network use clause. A mid-size company using Mattermost for team communications has similarly no exposure. A technology company building and selling a proprietary SaaS product that incorporates AGPL code as a core component has significant exposure and should either comply with AGPL (by open-sourcing their product) or purchase a commercial license.

The "Google bans AGPL" talking point gets repeated in developer circles as if it is a universal signal that AGPL is too risky to touch. In reality, it is a signal that AGPL is working exactly as intended — creating obligations specifically for organizations that would otherwise productize the software commercially without contributing back. For everyone else, AGPL is a fully viable license to use, deploy, and contribute to.

GPL, LGPL, BSL, and SSPL: The Broader Landscape

MIT, Apache 2.0, and AGPL cover the majority of decisions most projects and organizations need to make, but the broader license landscape includes important variations worth understanding.

GPL 3.0 is AGPL's predecessor without the network service clause. It is the right choice for desktop software, command-line tools, and libraries where the primary delivery mechanism is not a network service. Linux kernel (GPL 2.0), GNU toolchain (GPL 3.0), and VLC (GPL 2.0) are canonical examples. GPL is copyleft that triggers on distribution, not network interaction.

LGPL 3.0 (Lesser GPL) is designed specifically for libraries. Linking an LGPL library into your application does not require you to open-source your application — but modifications to the LGPL library itself must be shared. It threads the needle between the full permissiveness of MIT/Apache and the full copyleft of GPL. FFmpeg uses LGPL. Qt uses LGPL with commercial licensing available.

BSL 1.1 (Business Source License) is not technically an open source license — it is "source available." Code is viewable and available for non-production use, but commercial production use is restricted until a specified conversion date (typically four years after each release), at which point the code converts to an approved open source license (usually AGPL or Apache 2.0). HashiCorp adopted BSL for Terraform, Vault, and Consul in 2023. This triggered the OpenTofu fork under the Linux Foundation. BSL sacrifices OSI-certified open source status for stronger commercial protection. For a full analysis of where source-available licensing sits in the ecosystem, see our examination of source-available versus true open source.

SSPL (Server Side Public License) was created by MongoDB and is the most aggressive response to the cloud provider problem. SSPL requires that if you offer a service using SSPL software, you must open-source your entire service stack — not just modifications to the SSPL software itself, but the orchestration, management, and delivery layers too. The Open Source Initiative explicitly rejected SSPL as an open source license. MongoDB uses it for the MongoDB community server. Most enterprise legal teams treat SSPL as even more restrictive than AGPL.

The Dual Licensing Model: AGPL Plus Commercial

Dual licensing is how most serious open source SaaS alternatives turn their project into a sustainable business. The mechanics are straightforward: the project is published under AGPL for the community, and a separate commercial license is sold to organizations that need to use the software in ways that would violate AGPL's copyleft requirements.

What do commercial license buyers actually get?

The right to incorporate the software into a proprietary product without triggering AGPL's share-alike obligations
The right to build and operate a managed cloud service on top of the software without publishing source
Additional enterprise features not available in the AGPL community edition
SLA-backed support and indemnification
Compliance documentation for enterprise procurement and security reviews

Grafana Labs sells Grafana Enterprise licenses, which add enterprise data sources, fine-grained access control, and reporting features on top of the AGPL Grafana core. Mattermost sells Mattermost Enterprise licenses covering SSO, compliance exports, and guest access. MariaDB Corporation sold commercial licenses for MariaDB before its acquisition. GitLab uses a variation where the community core is MIT-licensed but the enterprise feature tier is proprietary.

For dual licensing to work, the project owner must control the copyright or have broad license grants from all contributors. This is why AGPL projects with commercial ambitions use CLAs that grant the project owner the right to sublicense contributions commercially. Without that, a single contributor holding copyright over a significant chunk of the codebase can block a re-licensing. The business model and the contributor agreement are inseparable.

For a comprehensive breakdown of how open-core models work alongside dual licensing, including what features belong in the free tier versus the paid tier, see our guide to the open-core model.

A Decision Framework for Choosing a License

Here is the clearest framework for choosing between the major license families:

Choose MIT if:

Your project is a library, utility, or framework where maximum adoption is the primary goal
You have other funding mechanisms (corporate backing, grants, services) and do not rely on license compliance for revenue
You want the lowest possible friction for enterprise procurement and dependency approval
Your project is not the type of thing a cloud provider would productize as a competing managed service

Choose Apache 2.0 if:

Everything in the MIT category, plus any of the following:
You are submitting to a software foundation (CNCF, ASF, Eclipse Foundation, Linux Foundation)
Your project has or expects multiple corporate contributors and patent clarity matters for participation
Your primary users are enterprises or government organizations that treat Apache 2.0 as the safe permissive baseline
Your project touches areas with known patent thickets (compression, cryptography, machine learning)

Choose AGPL 3.0 if:

Your project is a web application, API service, database, analytics tool, or any software designed to run as a network service
You want commercial users who build products on your project to either open-source those products or purchase a commercial license
You plan to pursue dual licensing as a primary revenue model
You are a solo maintainer or small team and the project's long-term sustainability depends on license-driven revenue creation
You want to prevent the scenario where a cloud provider offers your project as a managed service without contributing back

Choose LGPL 3.0 if:

Your project is a library that you want to protect with weak copyleft
You want applications that link your library to remain proprietary, but modifications to the library itself to stay open

Consider BSL or SSPL only if:

You have legal counsel actively involved in the decision
You have exhausted AGPL plus dual licensing as options
You are prepared to accept that your project will not be considered OSI-certified open source

For Contributors: What to Check Before Submitting a PR

Before contributing to any open source project, check two things: the license and whether there is a CLA or DCO requirement.

The license determines what rights you retain over your contribution and under what terms your code can be used. If a project uses AGPL and requires a CLA that assigns copyright to the project's corporate owner, your code can be sublicensed commercially by that owner while you retain no rights to that commercial revenue. This is common and not inherently unfair — but you should understand what you are agreeing to.

A CLA (Contributor License Agreement) typically asks you to assign copyright or grant a broad sublicense right to your contributions to a specific legal entity. This is what enables the dual-licensing model. Grafana Labs, MongoDB, Mattermost, and GitLab all use CLAs for exactly this reason. When you sign a Grafana CLA, you are enabling Grafana Labs to sell commercial licenses that include your contributions.

A DCO (Developer Certificate of Origin) is simpler: you sign off on each commit certifying that you have the right to submit the contribution under the project's existing license, and that you understand it will be public. Copyright stays distributed across all contributors. This is common in foundation-backed projects (Linux kernel, CNCF projects) and in projects that have no commercial dual-licensing model. With a DCO-only project, re-licensing the entire project later is practically impossible without tracking down every contributor.

Neither is inherently better. They serve different purposes. If you disagree with a company's commercial licensing practices, contributing to a project with a CLA means enabling that practice. Make the choice with open eyes.

For Users: How to Audit Your Dependency Stack

If you are an engineering manager, a startup founder, or a developer building a commercial product, you should have some visibility into what licenses are in your production dependency tree.

MIT and Apache 2.0 dependencies are almost never a compliance risk for web applications. The main scenario where they create obligation is distributing compiled binaries (like embedded hardware or mobile apps) without including copyright notices. For server-side web applications, MIT and Apache 2.0 impose essentially no obligations.

GPL dependencies in a commercial product can be an issue if you distribute binaries, because GPL requires source disclosure for combined works. Most web applications are not distributed — they run on servers — so GPL's distribution clause rarely triggers. The specific GPL version matters too; GPLv2 and GPLv3 have different compatibility profiles.

AGPL dependencies are the primary area to audit carefully. If your production stack includes AGPL-licensed software and you are offering a service that external users interact with, you need to verify you are in compliance. Running AGPL software and offering modified versions to users over a network without publishing your source is a violation. The practical response is either to comply (publish your source under AGPL), replace the dependency, or purchase a commercial license from the project.

Tools that automate this: FOSSA provides automated license compliance scanning for CI/CD pipelines. Snyk includes license compliance in its dependency scanning. The open-source license-checker npm package and Python's pip-licenses tool give you quick inventory of your dependency licenses. For any commercial project of meaningful scale, running automated license scanning in CI is worth the setup cost.

For Companies: Building a License Policy

Every technology company should have a documented open source license policy. It does not need to be a 20-page legal document, but it needs to exist and be consistently applied.

A basic policy covers four tiers:

Tier 1 — Approved without review: MIT, Apache 2.0, BSD-2-Clause, BSD-3-Clause, ISC, CC0. These are approved for use in any context without additional review.

Tier 2 — Approved with review: LGPL 2.1, LGPL 3.0, MPL 2.0 (Mozilla Public License). These have weak copyleft requirements that can interact with your code if you are not careful about linking or code boundaries. Use is approved after engineering confirms correct usage pattern.

Tier 3 — Require legal and engineering sign-off: GPL 2.0, GPL 3.0, AGPL 3.0. These have significant copyleft obligations that require a human to evaluate the specific use case. Internal tooling use (not offered as a service) may be fine. Incorporating into a product offered to external users requires either compliance or a commercial license.

Tier 4 — Case-by-case review: BSL, SSPL, Elastic License, proprietary source-available licenses. These are not OSI-certified open source and require individual evaluation.

The Google AGPL ban is one implementation of this framework, calibrated to Google's specific risk profile. Your company's version should be calibrated to your actual situation. A bootstrapped SaaS startup running Grafana for internal monitoring has no meaningful AGPL compliance exposure. That same startup building a multi-tenant monitoring product on Grafana's AGPL codebase has significant exposure that needs to be resolved — by either open-sourcing their product, replacing the Grafana dependency, or purchasing a Grafana Enterprise commercial license.

Understanding license obligations is also foundational to understanding the broader economics of open source — why projects choose the sustainability models they do, and what those choices mean for the long-term health of the ecosystem. License strategy and funding strategy are deeply intertwined, and companies that want to build sustainably on open source foundations benefit from understanding both dimensions. For a comprehensive look at how these economics play out across the full lifecycle of a project, see our guide to open source sustainability models and funding strategies.

Related reading:

OSS Licensing: MIT vs Apache vs AGPL 2026