The Redis license change affects far fewer engineers than the headlines implied — but the engineers it does affect have real decisions to make. In March 2024, Redis Ltd relicensed Redis 7.4 and later versions from BSD to a dual SSPL/RSALv2 license. The Linux Foundation forked Redis 7.2.4 — the last BSD-licensed version — into a project called Valkey. Understanding which of these events actually applies to your situation determines what, if anything, you need to do.

Situation

Redis is one of the most widely deployed in-memory data stores in the industry. It runs as a cache, a session store, a message queue, a rate limiter, and more. For most application developers, Redis is a network dependency: you point a client library at a host and port, and it works.

That familiarity is also why the licensing announcement in March 2024 generated so much noise. Engineers who had never thought about Redis licensing suddenly had to decide whether to care. Most of them do not need to. But the engineers who do — platform teams managing self-hosted Redis, teams using managed services, and teams building products that bundle Redis — need a clear picture before their next infrastructure review.

The Problem

The license change created a widely-shared misconception: that all Redis users are now on proprietary software and must act immediately. That is not accurate, and acting on it without understanding the scope leads to unnecessary migration work or, worse, ignored risk where it actually exists.

The SSPL (Server Side Public License) is a copyleft license written by MongoDB. Its key clause is that if you offer Redis as a service to others — meaning you build a product or SaaS on top of Redis and expose it to external users — you must either open-source your entire stack or obtain a commercial license. The RSALv2 (Redis Source Available License v2) restricts using Redis in a competing database product. Neither license affects a team using Redis as an internal application dependency.

The concrete failure mode is a platform team that does not audit its Redis version, does not track the managed service provider’s roadmap, and then discovers that their AWS ElastiCache clusters have been silently migrated to Valkey — or that a Redis module they depend on (RedisSearch, RedisJSON) has incomplete Valkey compatibility.

The decision this forces: what is your organization’s relationship to Redis — user, operator, or distributor?

What the License Change Actually Changes by Role

The answer depends entirely on how your organization uses Redis.

Application developers using Redis as a cache or queue are not affected. Your application connects to Redis over the network — you are not distributing it. Existing deployments continue to work. Redis 6.x and 7.2.x remain under BSD license.

Platform teams running self-managed Redis need to make a decision, but not immediately. Redis 7.2.4 and earlier are BSD-licensed. Options: stay on 7.2.x (accepting it will eventually fall behind on security), migrate to Valkey 7.2 or 8.x, or move to a managed service. Valkey 7.2 was released by the Linux Foundation in May 2024 with backing from AWS, Google, Oracle, and Ericsson. It maintains protocol and API compatibility with Redis 7.2 — most Redis client libraries need no changes.

Teams on AWS ElastiCache or GCP Memorystore should check their provider’s roadmap. AWS made ElastiCache for Valkey generally available in September 2024; new clusters default to Valkey. GCP Memorystore offers both modes. Staying on the default may mean you are already running Valkey without having made an explicit decision.

Teams building a product that includes Redis are in scope for the SSPL. If you expose Redis to external users as part of a service, get a legal opinion before your next release.

RoleLicense riskAction
App developer using Redis as a dependencyNoneNone
Platform team — self-managed Redis 7.2.4 or earlierNone immediatelyPlan migration timeline
Platform team — self-managed Redis 7.4+SSPL applies if distributingEvaluate Valkey or commercial license
AWS ElastiCache or GCP Memorystore userProvider-managedCheck current cluster engine version
Product builder distributing RedisSSPL appliesLegal review required

In Practice

Redis Ltd announced the license change on March 20, 2024. The Linux Foundation announced the Valkey fork the same day, based on Redis 7.2.4. The Valkey repository is at github.com/valkey-io/valkey.

AWS made Amazon ElastiCache for Valkey generally available in September 2024, confirming that Valkey 7.2 is API- and protocol-compatible with Redis 7.2 and that existing applications required no code changes to switch. Valkey 8.0 followed in September 2024, adding features beyond the Redis 7.2 baseline.

The documented pattern from this event: a fork with institutional backing can reach production stability quickly when it starts from a well-tested codebase. The Redis-to-Valkey path is cleaner than many license-driven forks because Valkey explicitly maintains the Redis Serialization Protocol (RESP) and the standard Redis command set.

Where It Breaks

ScenarioWhat breaksWhy
SSPL applicability confusionEngineers treat SSPL as affecting all Redis users and trigger unnecessary migration projectsSSPL copyleft clause is narrow — it targets service providers, not application users
Redis module dependencyTeams using RedisSearch, RedisJSON, or RedisTimeSeries migrate to Valkey and find incomplete or missing module supportValkey compatibility with Redis modules varies; some modules are Redis Ltd proprietary and have no Valkey equivalent
Valkey feature divergence over timeApplications assume long-term Redis and Valkey compatibility, but the projects diverge on new featuresCurrent divergence is minimal; future compatibility depends on both projects’ roadmaps and is unknown

What to Do Next

  • Problem: Platform teams that have not audited their Redis deployments since March 2024 may be running unlicensed Redis 7.4+ in a distribution context, or may be unaware that their managed service has already migrated to Valkey.
  • Solution: Audit your Redis deployment: check the exact version in each environment, identify whether you are distributing Redis to external users, and confirm your managed service provider’s current engine version and roadmap.
  • Proof: Query INFO server on a running instance — the output identifies the fork and exact version unambiguously:
redis-cli INFO server | grep -E "redis_version|redis_git|os:"
# Redis:  redis_version:7.2.4
# Valkey: redis_version:7.2.5  (Valkey still uses the redis_version key for compatibility)
#         valkey_version:7.2.5  (added by Valkey; absent on Redis)
  • Action: This week, run INFO server against each production Redis instance and record the version. If any are 7.4 or later, assess your distribution exposure. If you are on AWS ElastiCache, open the console and check the engine version — you may already be on Valkey and just not know it.

The license change matters for a specific set of roles, and it barely registers for everyone else. The engineers who get hurt are the ones who either ignore it completely when they shouldn’t, or treat it as a fire drill when it doesn’t apply to them. Know which situation you are in before deciding how much energy to spend.