Why license changes matter even for self-hosters
A license change applies to new versions of the software, not retroactively to what you have already deployed. But staying on an older version means forgoing security patches. The real risk is not an immediate lawsuit: it is the technical debt that accumulates while you wait for legal clarification.
Even purely internal usage can be affected if your organization bills services to third parties or exposes the tool via an external API. And the boundary between "internal use" and "exposed service" is precisely where SSPL and BSL diverge — one focusing on commercial competition, the other on who consumes the service.
Since 2021, four waves of relicensing have hit components present in thousands of production stacks: Elasticsearch (January 2021 → SSPL), Redis (March 2024 → RSALv2+SSPL, then May 2025 → AGPLv3 available), Terraform (August 2023 → BSL), MariaDB MaxScale (January 2025 → fully proprietary). Each time, the change was announced with less than a month of effective notice before the next version.
The four situations where a license creates a real constraint
- Reselling a competing cloud service — the BSL explicitly prohibits offering third parties a commercial service that competes with the original product. Hosting Terraform for your own infrastructure remains allowed; offering it as a managed platform to your customers has not been allowed since version 1.6 (August 2023). This is exactly what AWS, Google and Azure were doing with Redis, which motivated the March 2024 relicensing.
- Exposing a third-party service under SSPL — if you build a service consumed by external users that relies on an SSPL component, you are required to publish your entire software stack, including your provisioning and orchestration scripts. MongoDB has applied the SSPL since October 2018; the obligation only activates when you offer MongoDB "as a service" to others.
- Integrating into a SaaS product under AGPLv3 — any publisher that embeds an AGPLv3 library into a network-accessible application must distribute the complete source code of that application. For an internal self-hoster the constraint is light; for a SaaS publisher it is structural. Since August 2024, Elasticsearch again offers AGPLv3, which distinguishes it from the SSPL it left in 2021.
- Upgrading to a version under a new license — moving from Redis 7.2 (BSD) to Redis 7.4+ (RSALv2+SSPL) or from Terraform 1.5 (MPL-2.0) to 1.6+ (BSL) changes your rights without your automatic update pipeline noticing. Redis 8.0 (2025) introduces a third AGPLv3 option — but the default package on Ubuntu 24.04 is now Valkey (BSD-3-Clause), not Redis.
Timeline of major relicensing events (2021–2025)
Understanding the context of each decision helps anticipate the next ones. Here is the sequence that reconfigured the open source infrastructure ecosystem:
January 2021 — Elasticsearch and Kibana (Elastic). Elastic moves from Apache 2.0 to a dual SSPL / Elastic License 2.0 starting with version 7.11. The official reason: AWS was offering managed Elasticsearch without contributing back. AWS responds by forking Elasticsearch 7.10.2 (last Apache 2.0 version) to create OpenSearch, launched in April 2021 under Apache 2.0 and transferred to the Linux Foundation in September 2024. In August 2024, Elastic partially reverses course and adds AGPLv3 as a license option — Elasticsearch is open source again in the OSI sense.
October 2018 / March 2024 — MongoDB and Redis (SSPL). MongoDB was the first to adopt the SSPL in 2018, setting a precedent that Redis eventually followed on March 20, 2024, moving from BSD-3-Clause to RSALv2+SSPL starting with version 7.4. The Linux Foundation launches Valkey on March 28, 2024 — four days after the Redis announcement — as a fork of Redis 7.2.4 under BSD-3-Clause. Ubuntu 24.04, released in April 2024, adopts Valkey as its default package. In May 2025, Redis adds AGPLv3 to its license portfolio, notably under the influence of original creator Salvatore Sanfilippo (antirez), who had rejoined Redis Inc. in November 2024.
August 2023 — Terraform and HashiCorp (BSL). On August 10, 2023, HashiCorp switches Terraform from MPL-2.0 to BSL 1.1 starting with version 1.6. The OpenTF manifesto appears on August 15, gathers 32,000 GitHub stars in ten days, and OpenTofu is accepted by the Linux Foundation on September 20, 2023. OpenTofu 1.6.0 (first release under Linux Foundation governance) ships in January 2024 under MPL-2.0.
January 2025 — MariaDB MaxScale (fully proprietary). MariaDB goes a step further: MaxScale 25.01 moves from BSL to a fully proprietary license requiring an active MariaDB subscription. Older versions (24.02, 23.08) remain under BSL and will convert to GPL according to the time-based conversion clause.
BSL, SSPL and AGPLv3: what each model allows and forbids
The BSL (Business Source License) is a time-limited license: the code is source-available today and will become open source — often Apache 2.0 or GPL — after a fixed delay (four years at HashiCorp, two to three years at MariaDB for its older versions). The restriction clause targets an "additional use grant" defined by the vendor: at HashiCorp, that is providing a competing managed service. Internal use, even commercial, remains free.
The SSPL (Server Side Public License, version 1) goes further: exposing the tool as a service to third parties triggers a total stack publication obligation — management software, user interfaces, APIs, automation tools, monitoring, backup and hosting software. MongoDB publishes an FAQ clarifying that the obligation only activates when you offer MongoDB "as a service"; using MongoDB as a database in your own SaaS does not trigger it. The SSPL is not recognized by the OSI as an open source license.
AGPLv3, the only one of the three approved by the OSI, is a network copyleft: it does not restrict commercial use, but requires opening the source code of any application that integrates an AGPLv3 component when it serves users over a network. For a self-hoster who does not distribute their application, the constraint is nearly zero. For a SaaS publisher integrating an AGPLv3 library into a closed product, the constraint is existential.
BSD / MIT / Apache 2.0 licenses remain free of any publication obligation in all use cases: commercial, SaaS, managed service. This is why community forks (Valkey, OpenTofu, OpenSearch) choose BSD-3-Clause or Apache 2.0.
BSL vs SSPL vs AGPLv3 vs BSD at a glance
Scroll the table
| License | Internal self-hosting | SaaS use (resale) |
|---|---|---|
| BSL | Allowed with no conditions | Prohibited if the service competes with the original vendor |
| SSPL | Allowed with no conditions | Allowed if you publish your entire software stack |
| AGPLv3 | Allowed with no conditions | Allowed if you distribute your application's source code |
| BSD / MIT / Apache 2.0 | Allowed with no conditions | Allowed with no publication requirement |
Per tool: what the relicensing changes in practice
Redis → Valkey or Redis 8 AGPLv3.
Redis 7.2.x (BSD-3-Clause) remains freely usable as-is. From Redis 7.4, you are under RSALv2+SSPL: if your use is internal, there is no immediate constraint, but you can no longer redistribute it under BSD. The practical choice: migrate to Valkey (BSD fork, API-compatible with Redis 7.2, default package on Ubuntu 24.04 and Debian 13, maintained by AWS, Google and Oracle) or, if you wish to stay on the official codebase, choose the AGPLv3 variant of Redis 8 (available since May 2025). The Valkey migration is non-destructive: the RESP protocol and commands are identical, and existing Redis clients (redis-py, ioredis, Jedis) work without modification.
Elasticsearch → OpenSearch or Elasticsearch AGPLv3.
OpenSearch 1.0 (fork of Elasticsearch 7.10.2, Apache 2.0) has been in production since July 2021. It supports Elasticsearch indices up to version 7.10. If you are on Elasticsearch 7.x and not migrating, you are on a version without security patches since mid-2023. If you want to continue with Elastic, the AGPLv3 variant of Elasticsearch 8.x (available since August 2024) is the cleanest option: no redistribution obligation for an internal self-hoster. OpenSearch remains relevant if you have plugins or pipelines built on its API.
Terraform → OpenTofu.
OpenTofu 1.6+ is the direct continuation of Terraform 1.5 under MPL-2.0. HCL syntax is identical, Terraform Registry providers are compatible (OpenTofu maintains its own registry since 2024). If your use is limited to managing your own infrastructure, Terraform BSL is technically still free — but you give up redistribution freedom and depend on a restrictive clause that HashiCorp can modify. OpenTofu is the friction-free choice for a VPS operator automating their infra.
MongoDB → internal use free, managed service to cover.
For a self-hoster using MongoDB as the database for an internal application or their own SaaS (where you are the service operator), the SSPL does not activate. If you plan to offer "MongoDB as a Service" to third parties, either you open your complete stack (SSPL), or you take a MongoDB Enterprise commercial license. FerretDB (Apache 2.0) is a wire-protocol-compatible alternative backed by PostgreSQL, but does not yet support all MongoDB 6+ operators.
MariaDB MaxScale 25.01 → older BSL version or alternative.
MaxScale 24.02 remains under BSL and will convert to GPL. If you depend on MaxScale for routing or replication, freezing on 24.02 is the path without a commercial license. ProxySQL (GPL-2.0) and HAProxy with the MySQL module are established alternatives for MySQL/MariaDB traffic routing.
Redis added AGPLv3 as a licensing option in May 2025, joining Elastic which did the same in August 2024. For a self-hoster who does not expose their application to third parties, choosing the AGPLv3 variant of Redis 8 is now possible without resorting to the Valkey fork — even though Valkey remains under BSD-3-Clause and is the default package on Ubuntu 24.04 and Debian 13. The decision criterion: if you need the new features of Redis 8 (Vector Sets, improved RESP3), stay on Redis AGPLv3; if you want the most permissive license with no network constraints, Valkey is the friction-free path.
Decision matrix: which fork for which use case
Before choosing between the original tool and its fork, ask three questions in order:
1. What is my actual use? Internal only (no third party consumes the service) → BSL and SSPL create no immediate obligation, but you lose redistribution freedom. Service exposed to partners or customers → check whether your case falls under the "competing service" definition (BSL) or "offering the service to third parties" (SSPL).
2. Is there an actively maintained fork? For Terraform → OpenTofu (Linux Foundation, 12,000+ stars in 2024). For Redis → Valkey (Linux Foundation, AWS + Google + Oracle). For Elasticsearch → OpenSearch (Linux Foundation since September 2024). These three projects have published security patch SLAs and release cycles — minimum criteria for a production component.
3. Is the fork API-compatible? Valkey and Redis 7.2: 100% compatible (RESP protocol, same commands). OpenTofu and Terraform 1.5: compatible HCL, identical providers. OpenSearch and Elasticsearch 7.10: compatible for most DSL queries, but Elasticsearch 8.x plugins are not portable.
If a maintained fork exists, is API-compatible and maintains a security cadence: switch to it. The cost of a preventive migration is measurable; the cost of compliance under pressure — especially if an SSPL clause is activated by a usage change — is not.
Habits to build before adding a tool to your stack
Check the license before adding a dependency. The license lives in the LICENSE file at the root of the repository and in the changelog of recent major versions. A tool that was under MIT two years ago may be under BSL today — updating your docker-compose.yml will not flag this.
Subscribe to GitHub releases. The "Watch → Custom → Releases" button on a critical component's repository sends you an email for each new version. It is the only channel that guarantees you see a license change before it is shipped in your next apt upgrade or helm upgrade.
Distinguish your actual use case from what the license targets. HashiCorp's BSL targeted AWS, Azure and Google — not teams automating their own infrastructure. MongoDB's SSPL targeted cloud providers — not developers using MongoDB as the database for a SaaS product. Reading the official FAQ for each license (MongoDB publishes a detailed one) avoids unnecessarily conservative decisions.
Evaluate the fork proactively, not under pressure. Valkey, OpenTofu and OpenSearch exist precisely so a team can migrate without urgency. Testing compatibility in a development environment takes a few hours; migrating in production over a week after a relicensing announcement is a different matter.
Document the license of each dependency in your inventory. A simple table — tool, version in production, license, date of last check, fork available — turns a one-time audit into ongoing maintenance. Update it at every major version bump.
