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.

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.