Redis 8 AGPLv3 vs RSAL/SSPL — what do I need to change?
Teams choosing how to adopt Redis 8 need a current licensing card because Redis added AGPLv3 back alongside source-available terms, changing self-host and redistribution risk calculations.
Blockers
- Redis added AGPLv3 back alongside RSALv2 and SSPLv1 starting with the general availability release of Redis 8.
- requires_version: vendor/redis → package/redis-8
- requires_version: vendor/redis → package/redis-7-4
- requires_version: vendor/redis → package/redis-7-2
Who this is for
- compliance
- enterprise
- cost-sensitive
Candidates
Use Redis 8 under AGPLv3
As of 2026-03-29, Redis 8 and later are available under a tri-license, and AGPLv3 is the OSI-approved open source option Redis added on May 1, 2025. Redis states this applies starting with the general availability release of Redis 8, and that Redis 8 also folds former Redis Stack components such as RedisJSON, RedisTimeSeries, RedisBloom, and the Redis Query Engine into Redis Open Source under the same tri-license. Redis also states that Redis 7.2.x and earlier remain BSD-3-Clause, while Redis Community Edition 7.4.x through 7.8.x remain dual-licensed under RSALv2 or SSPLv1. The main adoption change versus 2024 is that teams can now choose an OSI-approved license, but AGPLv3 is still strong copyleft with a network-use trigger.
When to choose
Use this when you need Redis 8 features and want an OSI-approved license for procurement, distro, or policy reasons. It is the cleanest choice for self-hosted internal use or redistribution when your team can comply with AGPLv3 source-disclosure obligations for modified networked deployments.
Tradeoffs
Restores an open source path for Redis 8 and reduces the policy friction of RSAL/SSPL, but it is materially less permissive than the old BSD license. If you modify Redis and expose that modified server over a network, Redis says AGPLv3 requires making the complete corresponding source available.
Cautions
Do not treat AGPLv3 as equivalent to pre-7.4 BSD Redis. Redis explicitly says AGPLv3 differs from BSD-3-Clause because of copyleft and the network clause, so legal review is still needed for embedded products, hosted offerings, and modified forks.
Use Redis 8 under RSALv2
As of 2026-03-29, RSALv2 remains one of the three license options Redis offers for Redis 8 and later. Redis describes RSALv2 as a permissive, non-copyleft source-available license, but explicitly says it is not an open source license. Redis also states RSALv2 has two primary limitations: you may not commercialize the software or provide it as a managed service in a way that makes Redis functionality available to third parties, and you may not remove license notices. This makes RSALv2 the narrowest path for teams that want to avoid AGPL copyleft but are not building a Redis-like service.
When to choose
Use this when your main blocker is avoiding AGPL/SSPL copyleft obligations and your use is strictly internal or bundled in a way that does not cross Redis's commercialization and managed-service limits. It fits enterprises that can accept source-available terms and want the least disclosure burden, but only if product counsel agrees the business model is safely outside Redis's restricted zone.
Tradeoffs
Lower disclosure burden than AGPLv3 or SSPLv1 for many internal deployments, but it is not OSI-approved and can fail open-source policy checks. The commercial-use and managed-service restrictions are the core risk and may be unacceptable for hosted platforms, OEM redistribution, or anything that could be seen as competitive.
Cautions
RSALv2 is not a safe default for SaaS vendors without legal review. Redis's 2024 FAQ says organizations providing competitive offerings to Redis cannot use new Redis versions free of charge under the dual licenses, and points to custom licensing for cases outside the standard terms.
Use Redis 8 under SSPLv1
As of 2026-03-29, SSPLv1 is still a selectable license for Redis 8 and later alongside RSALv2 and AGPLv3. Redis says SSPLv1 is source-available, not open source, and is based on GPLv3 with a broader service-side disclosure requirement than AGPLv3. Redis's 2024 licensing FAQ states that if you provide SSPL-licensed software as a service, you must release not only modifications to Redis but also the source code for the management and hosting layers needed for users to run the service. This makes SSPLv1 the highest-disclosure option of the three for service providers.
When to choose
Use this only if your organization already has a deliberate SSPL posture and wants a clearly copyleft, source-available license rather than AGPLv3 or RSALv2. In most teams choosing among Redis 8 license options, SSPLv1 is the least attractive default because it combines non-OSI status with expansive service-source obligations.
Tradeoffs
It can be simpler than negotiating a commercial agreement if you are willing to publish broad service-side source, but that is a large concession. Compared with AGPLv3, SSPLv1 is usually harder for legal, distro, and procurement teams to accept.
Cautions
Assume extra friction for cloud, marketplace, and enterprise review. Redis explicitly says SSPLv1 is not an open source license, and its FAQ describes service disclosure obligations that extend beyond the Redis code itself.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Redis 8 AGPLv3 vs RSAL/SSPL — what do I need to change?"