The AGPL License Debate: Why OSS Companies Are Choosing It

MIT and Apache used to dominate open source licensing. Now AGPL is the default for new OSS SaaS alternatives. Here's why — and what it means for you.

The License Landscape (2026)

License	What It Allows	Who Uses It
MIT	Anything — commercial use, modification, no obligations	React, Vue, Next.js
Apache-2.0	Like MIT + patent protection	Kubernetes, Spark, Meilisearch
GPL-3.0	Must share source if distributed	Linux, Vaultwarden
AGPL-3.0	Must share source if used over a network	Grafana, Mattermost, Bitwarden
BSL	Source available, but restricted commercial use	Sentry, Cockroach, HashiCorp
SSPL	Like AGPL but stricter (controversial)	MongoDB, Elastic (then reverted)

Why AGPL Is Rising

The AWS Problem

In the mid-2010s, a pattern emerged:

Company builds open source tool (MIT/Apache)
Tool gets popular
AWS launches managed version of the tool
AWS captures the revenue, original company gets nothing
Original company struggles to fund development

Examples:

Elasticsearch → AWS OpenSearch
Redis → AWS ElastiCache
MongoDB → AWS DocumentDB

AGPL prevents this: if you offer the software as a service, you must release your modifications. AWS doesn't want to do that, so they can't just host it.

The Business Logic

For companies building open source SaaS alternatives:

License	Can cloud providers clone your hosting?	Can enterprises use freely?	Must share modifications?
MIT	✅ Yes	✅ Yes	❌ No
Apache	✅ Yes	✅ Yes	❌ No
AGPL	❌ Not without releasing code	✅ Yes (self-hosted)	✅ Yes (network use)

AGPL says: "Use our software freely, but if you modify it and offer it as a service, share those modifications."

This is the sweet spot for open source companies:

Users can self-host freely ✅
Companies can use it internally ✅
Competitors can't just host a managed version without contributing ✅
Enterprise customers who don't want AGPL buy commercial licenses 💰

Who's Choosing AGPL

Project	License	Previous License
Grafana	AGPL-3.0	Apache-2.0 (pre-2021)
Mattermost	AGPL-3.0	MIT (server) + Apache (mobile)
Bitwarden	AGPL-3.0	—
Chatwoot	MIT → proprietary features	MIT core
Appwrite	BSD-3	—
Outline	BSL	—

The trend: new projects start AGPL, older projects migrate to it.

The AGPL Controversy

The Fear

Some companies won't touch AGPL because of concerns:

"AGPL is viral — it'll infect our code"
- Reality: AGPL only triggers if you modify the AGPL software AND provide it as a service. Using an AGPL tool (like Grafana) as-is doesn't affect your proprietary code.
"Google bans AGPL"
- Reality: Google bans AGPL for code that runs in Google's infrastructure. Most companies aren't Google. And Google's concern is specifically about offering modified AGPL code as a service.
"We can't use AGPL in enterprise"
- Reality: Self-hosting an AGPL tool internally doesn't trigger any obligations. It only triggers if you modify it and provide it to others over a network.

When AGPL Actually Matters

AGPL obligations trigger when ALL of these are true:

You modify the AGPL software
You make it available to users over a network
Those users are outside your organization

Doesn't trigger:

Using AGPL software unmodified (even as a service internally)
Running AGPL software on your own servers for your own team
Connecting your proprietary software to AGPL software via APIs

Does trigger:

Forking Mattermost, adding features, and selling hosted Mattermost
Taking Grafana, modifying it, and offering "Grafana Cloud" (which is why Grafana Labs has a CLA)

The Practical Impact for Users

You Want To...	MIT/Apache	AGPL	Impact
Self-host for your team	✅	✅	None
Use unmodified as SaaS	✅	✅	None
Modify and use internally	✅	✅	None
Modify and offer as SaaS	✅	Must share code	Significant
Embed in proprietary product	✅	Depends on integration	Consult lawyer

For 95% of users: AGPL = MIT in practice. The obligations only matter if you're trying to compete with the original company.

AGPL vs BSL vs SSPL

Business Source License (BSL)

Used by: Sentry, CockroachDB, HashiCorp Terraform

Year 1-3: Source available, but can't compete with us
Year 4+: Becomes open source (usually Apache-2.0)

Pros: Clear commercial protection Cons: Not truly open source during the BSL period. OSI doesn't recognize it.

Server Side Public License (SSPL)

Used by: MongoDB (originally), Elastic (then abandoned)

If you offer this as a service, you must open source your ENTIRE stack
(not just modifications — everything: monitoring, deployment, etc.)

Pros: Maximum protection against cloud providers Cons: So restrictive it's practically proprietary. OSI explicitly rejected SSPL.

Comparison

Factor	AGPL	BSL	SSPL
OSI-approved open source	✅	❌	❌
Self-host freely	✅	✅	✅
Modify freely (internal)	✅	✅	✅
Offer as a service	Share modifications	Can't compete	Share entire stack
Community perception	Open source	"Source available"	"Basically proprietary"

What This Means for Your Stack

If You're Choosing Tools

AGPL tools are fine for self-hosting. No obligations unless you modify and redistribute.
BSL tools are fine too — just can't compete with the vendor's cloud offering.
Check the license if you plan to resell — AGPL and BSL have restrictions.

If You're Building a Product

Using AGPL tools as services (API calls, database connections) doesn't affect your code.
Embedding AGPL code in your product requires careful analysis.
When in doubt: Buy a commercial license (most AGPL projects offer one).

If You're Evaluating for Enterprise

Legal teams often have blanket "no AGPL" policies based on outdated fears.
Ask: "Are we modifying the software and offering it as a service to external users?"
If no → AGPL is identical to Apache in practice.

Why the AGPL Rise Matters for the Open Source Ecosystem in 2026

The shift toward AGPL as a default license for new open source SaaS alternatives isn't just a legal change — it reflects a maturing understanding of how open source businesses work in a cloud-dominated infrastructure market.

The projects choosing AGPL in 2026 aren't making an ideological statement. They're making a business decision grounded in the economics of the previous decade. The companies that watched AWS clone their products without contributing back — Elastic, MongoDB, Redis Labs — provide the cautionary example. AGPL is the structural response: a license that says "our software is freely available, but the cloud platform economy requires you to contribute back what you modify."

This matters for the ecosystem because AGPL keeps more value circulating within the open source community. When modifications must be shared, improvements that Grafana Labs makes to Grafana's AGPL core benefit everyone running self-hosted Grafana. When HashiCorp switched Terraform to BSL (not AGPL, but a similar protective intent), the community forked OpenTofu precisely because they valued the open contribution model. The fork's rapid adoption validated that users prefer genuine open source over source-available licensing.

The broader implication is that AGPL's growing adoption signals that open source sustainability as a field has reached a new consensus: permissive licensing is appropriate for libraries and frameworks where widespread adoption without contribution creates network effects (React, TypeScript), but copyleft licensing is more appropriate for complete applications and platforms where cloud providers could otherwise extract value without reinvesting.

Understanding how AGPL fits into the broader open source business model landscape is essential for evaluating tools. The open core model and AGPL licensing often work together: the AGPL core is free for self-hosting, while commercial licenses are available for organizations that need to use the software in ways that would trigger AGPL obligations.

How AGPL Affects Enterprise Procurement Decisions

The most practical challenge AGPL creates is navigating corporate legal policies that haven't kept pace with how AGPL actually works.

Many enterprise legal teams implemented blanket "no AGPL" policies during the early 2010s, based on a fear of "viral" licensing that would "infect" proprietary code. These policies were often overly conservative interpretations of AGPL's network use clause. The clause says: if you modify AGPL software and provide it as a service to external users, you must share your modifications. Most internal enterprise uses of AGPL tools — deploying Grafana for internal metrics, using Mattermost for team chat, running SigNoz for observability — don't come anywhere near this trigger.

The companies with legitimate AGPL concerns are those trying to offer hosted versions of AGPL tools as commercial products — exactly the scenario AGPL is designed to address. An internal enterprise deployment of Grafana carries exactly the same AGPL obligations as an MIT-licensed tool: none for internal use, none for API consumption, none for running unmodified.

Practical advice for navigating enterprise procurement: prepare a one-page analysis for each AGPL tool that explicitly answers the three trigger questions (Are we modifying it? Are we providing it as a service to external users? Do those external users have accounts?). For most internal tool deployments, all three answers are "no," and the AGPL analysis is closed. Legal teams respond better to specific factual analysis than to general reassurances.

The hidden costs of SaaS vendor lock-in context matters here too. Teams that avoid AGPL tools entirely due to overcautious legal policies often end up paying significant SaaS premiums for alternatives when AGPL self-hosted tools would have served their needs without license obligations.

Real-World AGPL Compliance for Self-Hosters

For the vast majority of organizations evaluating AGPL tools, compliance is simple: deploy the unmodified tool, and there are no compliance obligations beyond keeping the original license and copyright notices intact.

The scenarios where compliance requires more attention are narrow but worth understanding. If your team maintains a fork of an AGPL tool — adding custom features, fixing bugs specific to your environment, or integrating with internal systems through code modifications — those modifications must be shared if you distribute the software or provide it as a service externally. "Internally" means within your legal entity: a single company with multiple offices is one organization. A company that white-labels an AGPL tool for customers has external users and would need to share modifications.

In practice, most modifications that enterprise organizations make to AGPL tools are configuration (setting environment variables, writing config files) rather than code. Configuration doesn't trigger AGPL's share-alike requirement. Code changes embedded in the deployed binary do. If you're not sure where the line is for a specific modification, the tool vendor often provides guidance — most AGPL projects want enterprises using their software and will help clarify compliance questions rather than create obstacles.

The dual licensing structure that many AGPL projects offer provides a clean commercial exit for organizations that need it. Grafana Labs, Mattermost, and others offer commercial licenses that replace the AGPL terms entirely, eliminating any share-alike obligations in exchange for a license fee. This is usually priced for organizations that are competing with the vendor's cloud offering, not for internal deployments — but it's available for organizations whose legal teams require it.

For teams working through their open source tool selection process, How to Evaluate Open Source Alternatives covers the full evaluation framework including how to assess licensing risk as part of a systematic selection process.

The Bottom Line

AGPL is becoming the standard license for open source SaaS alternatives because it solves a real problem: letting companies build sustainable businesses around open source without being cloned by cloud providers.

For users and self-hosters, AGPL changes nothing about how you use the software. The obligations only kick in if you try to compete with the original company — which is exactly the point.

Find the best open source alternatives regardless of license at OSSAlt.

AGPL License Debate: Why OSS Companies Are 2026