Redis BSL License Change: What It Means for Enterprise Teams

What Changed with the Redis License?

In March 2024, Redis Ltd. announced that Redis 7.4 and all future Redis versions would be released under the Business Source License (BSL 1.1) rather than the BSD-3-Clause license under which Redis had been distributed since 2009. Redis 7.2 and earlier versions remain under the original BSD license.

The Business Source License is not an open source license as defined by the Open Source Initiative. Under BSL 1.1, the source code is available and users can run the software in most contexts — but the license restricts use in certain commercial scenarios, specifically in products that directly compete with the licensor's commercial offerings. The full restrictions convert to the Apache 2.0 license after 4 years.

What Does BSL Actually Restrict?

For most enterprise users, the BSL restriction is specifically: you cannot use BSL-licensed Redis in a product or service whose primary function is to provide a managed Redis-compatible database service that competes with Redis Ltd.'s own cloud offering (Redis Cloud).

The practical implications for enterprise teams:

• Using Redis as infrastructure within your own application: Generally permitted. A bank using Redis for session caching in their internal banking application is not competing with Redis Cloud.
• Building a managed Redis service: Restricted. AWS ElastiCache, Google Cloud Memorystore, and similar offerings were directly affected — which is why Amazon and others forked Redis as Valkey.
• Self-hosting Redis for internal use: Generally permitted, but the license change creates legal uncertainty that many enterprises prefer to avoid entirely.

What Is Valkey?

Valkey is a BSD-3-Clause-licensed fork of Redis, created in April 2024 by Amazon, Google, Oracle, Ericsson, and others, and donated to the Linux Foundation. Valkey is API-compatible with Redis 7.2 — existing Redis clients, applications, and tooling work against Valkey without modification.

As of mid-2026, Valkey 7.2 and 8.0 are available with active community development. For enterprises that need a BSD-licensed Redis-compatible in-memory store, Valkey is the community-recommended path.

What About Redis 6.x and 7.0/7.2?

Redis versions 6.2, 7.0, and 7.2 were released under BSD-3-Clause and remain under that license. However, these versions are now past their active community support window — Redis Ltd. focuses its security patching on the current BSL-licensed versions.

This creates the same EOL exposure problem as other EOL open source: CVEs disclosed against Redis 6.2 or 7.0 may not receive official patches from Redis Ltd. For enterprises that need to remain on BSD-licensed Redis builds for license compliance or legal policy reasons, OSSeva maintains patched builds of Redis 6.2 and 7.0 under their original BSD-3-Clause terms.

Enterprise Options for Redis After BSL

Migrate to Valkey

For most enterprises, this is the recommended path. Valkey is API-compatible with Redis 7.2, is BSD-licensed, has active Linux Foundation governance, and has strong backing from major cloud providers. Migration from Redis to Valkey is typically minimal — primarily a configuration and client library update.

Stay on BSD-licensed Redis with OSSeva extended support

For enterprises with legal or procurement policies that require BSD-licensed dependencies, or for those that cannot complete a migration immediately, OSSeva maintains CVE-patched builds of Redis 6.2 and 7.0 under their original BSD-3-Clause terms. This provides a security backstop while your organization completes the Valkey migration or implements a long-term strategy.

Adopt BSL-licensed Redis

For enterprises whose use case clearly falls outside the BSL restrictions (i.e., you're not competing with Redis Cloud), continuing on BSL-licensed Redis is a viable option, with legal review confirming your use case is permitted.

The SBOM and License Compliance Angle

The Redis license change highlighted a gap in enterprise software supply chain practices: many organizations did not know they were using Redis, or under which license, until the change was announced. SBOM (Software Bill of Materials) practices that inventory all third-party dependencies and their licenses are now explicitly required under several frameworks (EO 14028, EU Cyber Resilience Act) and are best practice for any regulated enterprise.

OSSeva's Assure service includes a software component inventory for all covered technologies, documenting the license, version, and patch status of each component.