-
Notifications
You must be signed in to change notification settings - Fork 0
ADR 0009 BSL vs AGPL
Status: Accepted Date: 2026-04-25 Decider: Maintainer
The licensing decision in ADR-0002 chose BSL 1.1 with 4-year change to Apache 2.0. The most plausible alternative - chosen by some other anti-fork-conscious projects - is AGPL 3.0. This ADR documents the comparison in detail because some adopters and contributors will ask.
Both BSL and AGPL aim to prevent hyperscaler "Open"X forks while keeping code public. They achieve this through opposite mechanisms:
- AGPL triggers a viral copyleft when used over a network - anyone using AGPL software in a SaaS service must release their entire stack as AGPL. This scares hyperscalers off entirely (they can't quarantine).
- BSL explicitly prohibits competitive commercial use until the change date, then becomes Apache 2.0. Adopters can use it internally without copyleft contagion.
Use BSL 1.1, not AGPL.
| Criterion | BSL 1.1 | AGPL 3.0 | Winner |
|---|---|---|---|
| Anti-hyperscaler | Yes via explicit clause | Yes via copyleft viral effect | Tie |
| Adopter legal team approval | Yes predictable, no copyleft fear | No many companies blanket-ban AGPL | BSL |
| Auto-conversion to permissive | Yes 4 years to Apache 2.0 | No stays AGPL forever | BSL |
| Internal use friction | Yes free to embed in your stack | Note: technically OK but legal teams nervous | BSL |
| Network use trigger | No no copyleft on network use | Yes copyleft triggered | (depends on goal) |
| OSI-approved | No source-available, not OSI | Yes OSI-approved | AGPL |
| Commercial license offering | Yes enables commercial dual-license | No AGPL is single-track | BSL |
| Industry precedent (fintech) | Yes Sentry, MariaDB, CockroachDB, HashiCorp | Note: MongoDB tried, switched to SSPL, controversy | BSL |
| Contribution welcome | Yes no copyleft fear from contributors | Note: contributors must agree to AGPL terms | BSL |
| Linux distro packaging | No many distros refuse non-OSI | Yes AGPL fine | AGPL |
Our target users are:
- Senior engineers at fintech startups
- Engineering managers at neobanks / payment processors
- Architects at banks evaluating modernization
Their legal teams matter as much as their preferences. AGPL triggers an instant ban at most banks and many fintechs. BSL doesn't, because:
- BSL doesn't propagate to the user's code (no copyleft on internal use)
- BSL is written in plain English with explicit "Additional Use Grant"
- BSL has a guaranteed 4-year horizon to permissive
We'd lose ~40% of potential adopters going AGPL. We don't accept that cost.
The code must be read and tried by many engineers. Anything that adds friction (legal, conceptual, perceptual) reduces adoption.
BSL has friction (it's not OSI-approved, some purists complain). AGPL has more friction (legal teams refuse it).
The 4-year change-date is a commitment: "this code will become fully OSS in 2030." Community trusts that. AGPL stays AGPL forever - there's no commitment to ever become permissive.
For long-term ecosystem trust, the temporal nature of BSL is honest: "we're protecting the project during its commercially-vulnerable phase, then handing it over."
A small but real fraction of adopters will pay for:
- Commercial support contracts
- Custom feature development
- Hosted SaaS (FinCore Cloud, eventually)
AGPL hurts this - adopters with commercial offerings are afraid the AGPL will infect their other code. BSL with explicit "Additional Use Grant" doesn't.
Fintech / dev-tools projects that chose BSL:
- Sentry (BSL since 2019 - large successful business)
- MariaDB MaxScale (BSL 1.1 with 4-year Change Date - same model we're using)
- CockroachDB (BSL until Apache conversion in 2024)
- HashiCorp Terraform (BSL since 2023 - controversial but broad adoption continues)
- Couchbase (BSL)
- Sentry's Codecov (BSL)
Fintech projects that chose AGPL: very few, and most have had adoption pain.
MongoDB tried AGPL, hit hyperscaler problem anyway (DocumentDB), switched to SSPL (more restrictive than BSL). Their journey vindicates BSL as the right starting point.
- Enterprise adopters more comfortable evaluating
- Path to commercial revenue (support, SaaS) preserved
- 4-year permissive conversion builds trust
- Wider potential audience
- Plain-English license terms reduce legal back-and-forth
- Some open-source purists (and a few prominent FOSS advocates) will publicly criticize "BSL isn't open source"
- Linux distros may refuse to package - minor blocker for our K8s/Docker target audience
- Some startup founders default to AGPL out of philosophical alignment - they'll be surprised by our choice
- README has a clear "Why BSL?" section explaining the choice and pointing to this ADR
- Rationale documented in this ADR and ADR-0002
- We engage with criticism politely and substantively in HN/Reddit/Twitter
- LICENSE file is verbatim BSL 1.1 template
- Every source file has SPDX header
BUSL-1.1 - README explains license in plain English
- A FAQ entry addresses common license questions
- ADR-0002 - primary license decision
- LICENSE file at repo root
- BSL FAQ at MariaDB - authoritative reference
- Sentry's BSL announcement - useful precedent
- Overview
- Services
- Data Model
- Domain Model
- Event Flow
- Security
- Observability
- Resilience
- SLA / SLI / SLO