Is your Redis use affected by the license change?

When teams ask whether their Redis use is affected by the license change, the honest answer for most of them is reassuring, but only after a short check. As of March 2024, Redis moved from an open source license to a dual model of the Redis Source Available License version 2 and the Server Side Public License, and later added an open license option. The change does not make every Redis deployment a problem. It draws a line, and the practical task is to work out which side of the line your use sits on. That requires two facts: what you actually do with Redis, and which version you run.

This article gives you a clear test rather than a vague warning. For the underlying mechanics of each license, the companion piece on the Redis license change and what RSALv2 and SSPL mean sets out the detail, and the pillar on Redis, Elastic, and database license risk is the hub.

The use test: how you run Redis

Start with how Redis serves your business. The most common pattern by far is internal: Redis runs as a cache, a queue, a session store, or a fast data layer behind your own applications. That use is internal use, which the Redis Source Available License version 2 permits. If this describes you, the license change is unlikely to create a direct restriction on what you already do, although your version still matters and the open posture you once relied on has changed.

The case the dual license model is written to reach is different. It is the organization that offers Redis itself to others, as a managed service or a hosted product where the Redis functionality is the thing being sold. If you operate a platform that exposes Redis to outside parties, you are in the territory the restriction targets, and both RSALv2 and the Server Side Public License become live considerations. Between these two poles sit harder cases, such as a product that embeds Redis and is delivered to customers, where the question of whether you are offering Redis as a service is genuinely arguable. That interpretation belongs with your own counsel, and it is the same shape of question we examine for service providers in MongoDB SSPL and service providers.

The version test: which Redis you run

The second fact is your version. The license change applies to releases from the change forward, as of March 2024, not retroactively to earlier versions. A deployment pinned to a pre change release continues under its prior open license. The terms attach when you take a newer release. This means your exposure is partly a function of your upgrade behavior, and it can change quietly the next time a team bumps a version for a feature or a fix. A team that believes it is safe because it adopted Redis years ago can move itself under the dual license terms simply by upgrading without noticing the license boundary.

Because of this, a version inventory is not optional. You need to know which Redis version each deployment runs, whether it sits before or after the change, and what your upgrade pipeline will pull in next. Without that map, any statement about your exposure is a guess.

Sizing the risk and the options

Put the two tests together and your position becomes clear. Internal use on a pre change version carries little direct exposure today, though it is worth watching. Internal use on a post change version is generally permitted but now governed by source available terms rather than open source ones, which can matter for policy and for downstream distribution. Service provider use on a post change version is where the real weight sits, and it deserves a careful read of both RSALv2 and the Server Side Public License with counsel involved.

Where exposure exists, the options are the familiar set. You can migrate to the Valkey fork for an openly licensed path that behaves like Redis, adopt the open license option Redis later added where it suits, hold a clean earlier version while accepting the security trade, or negotiate commercial terms where hosting Redis is central to your business. The same logic extends to the other relicensed data stores covered in time series and analytics database relicensing risk.

What to do next

The work is concrete and bounded. Inventory every Redis deployment, record the version and the use pattern of each, and flag any deployment that offers Redis functionality to outside parties. That single map answers the question this article poses, and it turns a vague worry into a short list of deployments that need a decision. Most organizations find that the large majority of their Redis use sits comfortably inside permitted internal use, with exposure concentrated in a small number of places that are then easy to address. This article is commercial and licensing risk advisory, not legal advice. For interpretation of RSALv2, the Server Side Public License, and whether your use is affected, your own counsel is the right place to turn.