Redis licensing change: what app teams should decide
Redis moved new releases to RSALv2 and SSPLv1 in March 2024. Valkey forked the BSD line. Here is how to pick a path without panic.
On March 20, 2024, Redis Inc. announced that all future Redis releases would ship under a dual source-available license: RSALv2 or SSPLv1, starting with Redis 7.4. The long-familiar BSD 3-clause license stays on 7.2 and earlier, but new upstream features would not land there.
If your app treats Redis as “free software we never read the license for,” this was the week to start reading.
What changed in plain terms
Before: Redis OSS through 7.2.x used a permissive BSD license most internal teams could ignore after a quick legal nod.
After 7.4: You choose RSALv2 or SSPLv1. Both are source-available, not the same as OSI-approved open source. Redis Inc. said the shift targets managed service providers reselling Redis as a competing cloud database without contributing back. Self-hosted internal caches were not the stated audience for restrictions, but your legal team still decides what your use case allows.
SSPLv1 in one sentence: If you offer Redis (or modified Redis) as a service, you may need to release more of your surrounding stack under SSPL. That scares legal departments at SaaS vendors.
RSALv2 in one sentence: Redis’s own source-available terms with explicit limits on who can offer Redis-as-a-service commercially. Easier for many internal deployments, still not BSD.
Enter Valkey
Days later, the Linux Foundation announced Valkey on March 28, 2024: a community fork continuing from Redis OSS 7.2.4 under BSD 3-clause, backed by AWS, Google Cloud, Oracle, and others. Cloud vendors quickly added Valkey options to managed cache services.
Suddenly “Redis upgrade” became a fork decision, not only a semver bump.
Who is actually affected
| Situation | Typical impact |
|---|---|
| Internal session cache on VMs you operate | Often low, but confirm with counsel before jumping to 7.4+ |
| Embedded Redis in a commercial SaaS product | High: SSPL/RSAL review mandatory |
| Managed Redis from AWS/GCP/Azure | Vendor maps licensing; watch SKU names (Redis vs Valkey) |
| Compliance policy requiring OSI licenses | Stay on 7.2.x, move to Valkey, or choose a commercial Redis contract |
| Heavy use of Redis Stack modules | Module licensing already moved earlier; 7.4 merges more capability into core under new terms |
Most SMBs we work with use managed cache or a single internal Redis for app sessions. They feel this as a roadmap conversation, not a midnight outage. Product companies feel it as a legal gate on every upgrade.
Decisions app teams should make now
1. Freeze the license line in writing. Document whether production is allowed on 7.2.x/BSD, 7.4+/RSAL or SSPL, Valkey/BSD, or Redis Enterprise. “Whatever apt installs” is how surprises happen.
2. Pick an upgrade owner. Licensing, not only semver, should sit with engineering and whoever signs vendor contracts.
3. Test Valkey if you self-host. Protocol compatibility with Redis 7.2-era clients is the point. Run integration tests on staging before you rename containers in prod.
4. Ask your cloud vendor the boring question: “If I click upgrade on ElastiCache/Memorystore/Azure Cache, which project and license am I on?” Names changed fast in 2024.
5. Do not confuse trademark with protocol. You can run Valkey with Redis clients. Marketing slides may still say “Redis” when they mean “Redis-compatible.”
What we are not doing
- Panic fork on Friday. If 7.2.x meets your needs and gets security patches from your vendor path, stability beats ideology.
- Assume BSD forever on Valkey. Read governance docs; the point is community control, not a magic guarantee.
- Ignore Redis Enterprise. Some teams were always going to pay for support. The license change clarifies who pays for what.
Bottom line: Redis’s March 2024 move to RSALv2/SSPLv1 split “stay on BSD” teams from “take new Redis features under new terms” teams. Valkey gives a BSD continuation for most protocol-compatible workloads. Decide explicitly where your apps live, test before you migrate, and let legal classify anything customer-facing. This is a roadmap choice, not a fire drill, unless you ignored licensing for a decade.