SSPL vs AGPLv3 vs BSD: The Tri-License Compared
Redis 8.0 ships under three licenses and you pick one. Valkey ships under one (BSD-3). Memcached has always been BSD. Understanding the differences matters because the right pick depends on what you are building and what your legal team will approve.
The full comparison matrix
| Aspect | BSD-3 | AGPLv3 | SSPL | RSALv2 |
|---|---|---|---|---|
| OSI-approved | Yes | Yes | No | No |
| Run unmodified | Yes | Yes | Yes | Yes |
| Modify internally | Yes | Yes | Yes | Yes |
| Modify + offer as service | Yes | Must share source | Must share service stack | Restricted |
| Build commercial managed service | Yes | Yes (with source share) | Yes (with full stack share) | No (non-compete) |
| Use in proprietary product | Yes | Caution (network clause) | Caution (broad copyleft) | Yes (small operators) |
| Used by | Valkey, Memcached | Redis 8.0 option | Redis (since Mar 2024) | Redis (since Mar 2024) |
| Corporate legal friction | None | Low to medium | High | Medium |
BSD: the gold standard for OSS infrastructure
The Berkeley Software Distribution license dates to the 1970s and is one of the original open source licenses. The BSD-3 variant (used by Valkey and Memcached) says, paraphrased: do whatever you want with this software, keep our copyright notice, do not claim we endorse your modifications. That is the entire substantive content of the license.
For infrastructure software (databases, web servers, kernels, runtimes), BSD has been a popular choice because it lets commercial vendors embed and modify the software without forced source disclosure. FreeBSD, OpenBSD, and parts of the macOS / iOS kernel use BSD-family licenses. From an enterprise legal perspective, BSD is the lowest-friction OSS license: there is nothing to analyse, no copyleft, no network clause.
The downside of BSD for the upstream maintainer is that it allows competitive forks and commercial products to be built on top without any obligation to contribute back. This is what motivated the Redis license switch in March 2024: Redis Inc. felt that cloud providers were monetising Redis as a managed service without contributing development effort proportional to the revenue extracted. The SSPL and RSALv2 licenses are attempts to capture that value via copyleft on the service infrastructure or via direct non-compete provisions.
AGPLv3: open source with the SaaS loophole closed
AGPLv3 takes GPLv3 and adds section 13, which addresses what is colloquially called the "ASP loophole" or "SaaS loophole": under GPL, distributing software triggers source-disclosure, but offering the software as a network service does not, so cloud providers could and did monetise GPL software without giving anything back.
The AGPL clause requires that if you modify AGPL software and run the modified version as a network service, you must offer users of that service access to the modified source. Crucially, this triggers only on modification: running unmodified AGPL software has no source-disclosure obligation, and modifications kept entirely internal (not exposed to external users) also do not trigger it. For most application teams, AGPL is effectively as permissive as BSD because they neither modify the software nor expose modifications externally.
For Redis 8.0+ under the AGPLv3 license option, the practical implication is that cloud providers (or any commercial entity) running modified Redis as a service must publish their modifications. This is the lever Redis Inc. wanted to gain against AWS / GCP / Azure modifying Redis without contributing back. In practice, the major cloud providers responded by switching to Valkey rather than dealing with the AGPL obligations, which validates the strategic reasoning even if it does not capture the value Redis Inc. hoped for.
SSPL and RSALv2: the source-available options
SSPL is MongoDB's invention. It is GPLv3-like but extends copyleft beyond the software itself to the entire stack that supports running the software as a service. Specifically, if you offer SSPL software as a service, you must publish under SSPL not just any modifications to the software but also "all source code for the management and configuration of the service, hosting infrastructure, monitoring tools, and backup systems." The scope is broad enough that most cloud providers will not touch SSPL software at all.
The OSI explicitly declined to recognise SSPL as open source on the grounds that the copyleft scope is too broad. Several distributions (Debian, Fedora) have refused to ship SSPL software. The license is functional and enforceable, but it has the operational characteristics of a proprietary license for most commercial purposes. Most teams who pick the SSPL Redis option are doing so for legacy reasons or because the AGPLv3 option had not been added when they made the choice.
RSALv2 (Redis Source Available License v2) is Redis Inc.'s own creation, specifically designed to allow most uses while prohibiting commercial managed-Redis services that compete with Redis Cloud. The license text explicitly enumerates "providing the licensed work as a commercial managed database service" as a prohibited use. For small operators and most non-cloud-provider companies, RSALv2 is functionally equivalent to a permissive license; the prohibition only bites for cloud providers.
FAQ
What is the SSPL?
Server Side Public License, created by MongoDB in 2018. Similar to GPL but extends copyleft to the entire service that runs the software, including management code, build tools, and infrastructure. The OSI explicitly does not recognise SSPL as open source because the copyleft scope is too broad.
What is RSALv2?
Redis Source Available License v2, Redis Inc.'s own license. Allows use, modification, and redistribution but prohibits offering Redis as a commercial managed database service that competes with Redis Cloud. Effectively a non-compete provision targeted at AWS / GCP / Azure managed Redis offerings.
Which license should I pick if I am using Redis 8.0?
Pick AGPLv3 for the broadest permissions and OSI-approved open source status. SSPL only if you specifically need to redistribute modified Redis without the AGPL's narrow source-disclosure requirements. RSALv2 only if you are a small operator who will never offer Redis as a competing managed service. For most users AGPLv3 is the default choice.
Why does BSD matter?
BSD-3 (the Valkey license) is the simplest possible OSS license: do whatever you want, just keep the copyright notice. No copyleft, no network clause, no source disclosure, no competition restrictions. Corporate legal teams know BSD and approve it without analysis. The simplicity is the feature.
Can I dual-use Redis and Valkey?
Yes. You can run Redis for some workloads (where you want Redis 8.0 features) and Valkey for others (where you want BSD posture). Many production environments do exactly this. The licenses are independent; using one does not affect the other. Client code can connect to either without modification because the RESP protocol is shared.