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.
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 does not.
- 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.
- 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.
- Upgrading to a version under a new license — moving from Redis 7.2 (BSD) to Redis 8 (tri-license) or from Terraform 1.5 (MPL-2.0) to 1.6 (BSL) changes your rights; automating updates without checking the license changelog exposes your organization to an unconsented transition.
BSL, SSPL and AGPLv3: what each model allows and forbids
The BSL is a time-limited license: the code is source-available today and will become open source — often Apache 2.0 — after a fixed delay, four years at HashiCorp. Internal use is free, direct competition is blocked. The SSPL goes further: exposing the tool as a service to third parties triggers a full-stack publication obligation. AGPLv3, the only one of the three approved by the OSI, is a network copyleft: it protects end-users' freedoms without prohibiting commercial use, but requires opening the source code of any containing application once it serves users over a network.
BSL vs SSPL vs AGPLv3 vs BSD at a glance
| 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 |
Redis added AGPLv3 as a licensing option in March 2026, joining Elastic which did the same in September 2024. For a self-hoster, 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.
Habits to build before adding a tool to your stack
Before adding a component to your infrastructure, check its license in the repository and in the changelog of recent major versions. Distinguish your actual usage: internal, exposed to partners, or sold to customers. Subscribe to GitHub releases for critical projects to detect a license change before the next automatic update. If a permissively licensed fork exists and is actively maintained — OpenTofu, Valkey, OpenSearch — evaluate it as a sustainable alternative.
