The Redis Licence Change, Accurately: RSALv2, SSPLv1, AGPLv3 and What Each Means

What changed, precisely

On 21 March 2024, Redis Ltd. announced that Redis would no longer be released under the BSD-3-Clause licence. Starting with Redis 7.4, releases were dual-licensed under RSALv2 (Redis Source Available License v2) and SSPLv1 (Server Side Public License v1). Neither licence is approved by the Open Source Initiative, which is why the change was widely reported as Redis leaving open source.

With Redis 8.0, Redis added AGPLv3 as a third option. AGPLv3 is OSI-approved. Redis 8 and later are therefore tri-licensed — RSALv2, SSPLv1, or AGPLv3, at the user's choice — and by the OSI's own definition, Redis is open source software again.

From Redis 8, the modules previously known as Redis Stack — RediSearch, RedisJSON, RedisTimeSeries and RedisBloom — are integral components of Redis Open Source and carry the same tri-licence.

The BSL error

A large amount of published material, including vendor pages and analyst commentary, describes this as Redis moving to the "Business Source License" or "BSL". That is a different licence entirely. BSL is used by MariaDB, CockroachDB, Sentry and others, and its defining characteristic is a time-delayed conversion: after a set period, typically three or four years, each BSL release automatically converts to a genuine open source licence.

RSALv2 and SSPLv1 have no such conversion. A release under RSALv2 stays under RSALv2. If your licence assessment assumed a future conversion date because someone told you Redis was BSL, that assessment is wrong and should be redone.

We are pointing this out with some awareness of glass houses: this site published a post with "BSL" in its title until this week. It has been rewritten, and this piece exists partly to correct it.

What each licence actually constrains

RSALv2

Source-available. You may read, modify and redistribute the source. The central restriction is that you may not make the software available to others as a managed service, and may not distribute it as part of a product that competes with Redis Ltd.'s commercial offerings. For an enterprise running Redis for its own applications, RSALv2 imposes essentially nothing. For anyone building a product on top of it, the question is whether that product looks like a database service — and that is a question for counsel, not for an engineering blog.

SSPLv1

A copyleft licence derived from AGPLv3, with a much broader service condition: if you offer the software as a service, you must release the source of the entire service management stack under SSPL. It was written by MongoDB and has been rejected by the OSI. In practice almost nobody chooses SSPL; it exists in the dual-licence to close a gap RSALv2 leaves.

AGPLv3

A genuine OSI-approved open source licence, and strong copyleft. The obligation that matters: if you modify the software and make it available to users over a network, you must offer those users the modified source. If you do not modify it, the network clause largely does not bite — you are running an unmodified upstream binary, and there is no modified source to offer.

This distinction is routinely lost. Many organisations treat AGPL as radioactive on the basis that "using it over a network triggers source disclosure". The obligation attaches to modifications you convey, not to the mere act of running it. An enterprise running stock Redis 8 for internal applications, unmodified, has a far smaller AGPL exposure than a blanket policy implies.

What to actually do about it

There are four positions, and most organisations are in one of them without having consciously chosen it.

1. You run Redis 7.2 or earlier. You are on BSD-3-Clause. Nothing about the licence change applies to you retroactively — licences are not revoked from releases already published. Your problem is not legal, it is that nobody patches your branch any more. That is a security question, and it is the one worth your attention.
2. You run Redis 7.4 – 7.8. You are on a source-available licence with no OSI-approved option. If your organisation has a policy requiring open source components, you are technically out of compliance with your own policy. Moving forward to Redis 8 (AGPLv3) or across to Valkey (BSD) both resolve it.
3. You run Redis 8 or later. You have an OSI-approved option available. Whether you can take it depends on whether your legal team permits AGPL. If they do, you are fine. If they maintain a blanket AGPL ban, you are on RSALv2 by default and should know that.
4. You need BSD specifically. Valkey is the BSD-licensed fork, hosted by the Linux Foundation, created eight days after the licence change by six of the project's active contributors.

The question this usually turns out to be

In our experience the licence conversation is a proxy. Teams arrive asking which licence they are allowed to use, and the real situation is that they are running Redis 6.2 or 7.0, they have been for four years, and a scanner or an auditor has just produced a finding.

For those estates the licence is settled — BSD, permissive, no constraint. What is not settled is patching: 7.0 has received no upstream security fixes since July 2024, 6.2's upstream fixes end on 1 April 2027, and Redis is a C codebase whose recurring advisories are memory-safety issues in command processing, reachable by any client that can issue the relevant command.

Moving major versions to solve a patching problem is a legitimate strategy, but it is a project with a testing cycle and a cutover window, and audit deadlines rarely respect either. OSSeva backports fixes to Redis 6.2.x and 7.0.x so that the security exposure is closed now and the version decision — Redis 8, Valkey, or staying put — gets made on its merits rather than under pressure.

Related reading

• Valkey vs Redis: the licence, the fork, and how to choose — the decision itself, including migration mechanics.
• Redis extended support — CVE backports for 6.2.x and 7.0.x.
• Broadcom TrueSource explained — Broadcom's data-engine offering now includes Valkey, which changes the commercial landscape around this decision.