Redis 7 RSAL/SSPL vs Redis 8 AGPL Licensing Decision — what do I need to change?
Teams choosing a Redis version or distribution need a licensing card that reflects Redis's return to AGPL in Redis 8 and the practical implications for hosted and embedded use.
Blockers
- AGPLv3 restored an OSI-approved open-source option for Redis starting with Redis 8.
- Redis 8 is a packaging boundary because former Redis Stack technologies are integrated into core Redis.
Who this is for
- compliance
- enterprise
- cost-sensitive
Candidates
Stay on Redis 7.4.x to 7.8.x under RSALv2 or SSPLv1
As of 2026-03-27, Redis Community Edition 7.4.x to 7.8.x remains dual-licensed under RSALv2 or SSPLv1. This keeps you on the pre-Redis-8 licensing model and avoids the Redis 8 package and feature consolidation changes. It is viable if you already accepted the 2024 source-available terms and do not need Redis 8 features. It is not an OSI-open-source path.
When to choose
Use this when you want minimal operational change and your legal team already approved RSALv2 or SSPLv1. It is the simplest choice for internal deployments that are not offered as a competing hosted Redis service.
Tradeoffs
Lowest migration effort if you already run Redis 7.4+; tradeoff is staying on source-available licensing without the AGPL option and missing Redis 8 feature consolidation.
Cautions
RSALv2 forbids commercializing the software or providing its functionality as a managed service to third parties. SSPLv1 allows service use only if you are prepared to release modifications and the service management layers under SSPL.
Move to Redis 8 and use the AGPLv3 option
As of 2026-03-27, Redis 8 and later are available under a tri-license: RSALv2, SSPLv1, or AGPLv3. AGPLv3 restored an OSI-approved open-source option for Redis starting with Redis 8. Redis 8 also folds former Redis Stack components such as JSON, Time Series, probabilistic data types, and the Redis Query Engine into core Redis, and Redis says the included module version numbers now match the Redis version. This is the clearest path if you want current Redis under an approved open-source license.
When to choose
Use this when open-source approval matters and you can accept AGPL copyleft obligations. It is the strongest fit for self-hosted or embedded use where you do not want RSAL's service restriction and do not want SSPL's broader service-source obligation.
Tradeoffs
You regain an OSI-approved license and current Redis 8 features, but AGPL still creates copyleft obligations for modified network-served versions.
Cautions
Redis states that if you move from 7.2 or earlier with modified code offered as a network server, operators must provide the source code of the modified version to users of that server. Redis 8 is also a packaging boundary because former Redis Stack technologies are now integrated into core.
Use Redis 8 under RSALv2 or SSPLv1
Redis 8 does not force AGPL; as of 2026-03-27, Redis 8 still offers RSALv2 and SSPLv1 alongside AGPLv3. This path is mainly about keeping Redis 8 features while choosing a non-AGPL standard license. It is viable if your legal team already accepts RSALv2 or SSPLv1 and you do not need negotiated commercial terms.
When to choose
Use this when you need Redis 8 but want a standard non-AGPL license option, and your legal team is prepared for RSALv2 or SSPLv1 obligations. Choose this only if you can operate within those published license terms without needing separate contractual rights.
Tradeoffs
You keep access to Redis 8 without AGPL, but you remain on source-available licensing and must accept RSALv2 or SSPLv1 limits.
Cautions
Redis says RSALv2 blocks commercialization or managed-service exposure of Redis functionality to third parties. SSPL is broader for service operators because it requires releasing management layers under SSPL.
Negotiate commercial terms for Redis 8
Redis states that proprietary products require a commercial license and that custom licensing terms are available for use cases beyond RSALv2 or SSPLv1 limitations. This path is mainly about keeping Redis 8 features while getting direct vendor terms for a business model that does not fit the standard licenses.
When to choose
Use this when you need Redis 8 and need contractual clarity for a managed offering, an embedded commercial product, or another use case that does not fit AGPLv3, RSALv2, or SSPLv1.
Tradeoffs
You can align Redis 8 with a commercial model and get clearer contractual rights, but you lose the simplicity of a standard license and may need vendor negotiation.
Cautions
Redis's published source-available licenses are not a substitute for negotiated rights if your product or service falls outside their limits. This path typically adds procurement time, cost, and dependence on vendor terms.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Redis 7 RSAL/SSPL vs Redis 8 AGPL Licensing Decision — what do I need to change?"