Redis and Valkey Part 2: The Licensing Shift and the Rise of Valkey
February 02, 2026
The Redis ecosystem's recent upheaval stems from a tension as old as commercial software itself: who pays for critical infrastructure? This is Part 2 of our four-part series on Redis and Valkey. In Part 1, we examined the business value these technologies provide. Now we'll explore the licensing changes that led to Valkey's creation and what they mean for your business.
The Redis Licensing Shift
Of course, technology decisions don't happen in a vacuum — they happen in the context of business incentives, community expectations, and legal frameworks. The Redis licensing story illustrates this dynamic clearly.
Redis was originally released in 2009 under the permissive BSD 3-clause license — a license that allowed companies to use, modify, and integrate it freely, including offering it as a service. This openness was instrumental in Redis's adoption; by 2024, it had become one of the most widely deployed databases in the world, with millions of deployments across organizations of every size.
However, the very openness that fueled Redis's growth also created tension. Major cloud providers — AWS, Google Cloud, Azure — offered managed Redis services without contributing meaningfully back to Redis's development or compensating Redis Labs (now Redis Inc.). This pattern, sometimes called "strip mining" open source, led to a series of licensing changes over several years.
Understanding the BSD License (Original)
The original BSD 3-clause license was about as permissive as open-source licensing gets. Under its terms, you could use Redis for any purpose, modify the source code, distribute modified versions, and offer it as a service — without licensing fees or vendor approval. This meant companies could deploy Redis wherever they needed it, modify it for specific requirements, bundle it with products, or offer it as a managed service.
This openness was a significant factor in Redis's adoption. For many organizations, the BSD license meant one less thing to worry about during procurement and legal review.
The Shift to RSAL for Modules (2018)
In 2018, Redis Labs introduced the Redis Source Available License (RSAL) for several add-on modules — including RedisJSON, RediSearch, RedisGraph, and RedisTimeSeries. The core Redis database itself, though, remained under the BSD license at this stage.
The RSAL restricted offering these modules as competing cloud services, while still permitting internal use and modification. For most organizations using Redis as a cache or session store, this change had minimal practical impact. It primarily affected cloud providers offering managed Redis modules.
Though this change drew criticism from some open-source advocates, it was a targeted move — Redis Labs was protecting specific commercial modules rather than restricting the core technology.
The Move to RSALv2 and SSPL (2024)
The more significant change came in March 2024, when Redis Inc. switched the core Redis database from the BSD license to a dual license: the Redis Source Available License version 2 (RSALv2) and the Server Side Public License (SSPL).
What the New Licenses Allow:
- Internal use within your organization
- Modification for internal purposes
- Hosting Redis for your own applications
- Most typical business uses that don't involve offering Redis as a service to third parties
What the New Licenses Restrict:
- Offering Redis as a database service to others
- Certain types of commercial redistribution
- Competing directly with Redis Inc.'s hosted offerings
You might wonder: does this affect your current Redis deployment? If you're running Redis internally to support your applications — caching, sessions, queues, real-time features — the answer is almost certainly no. The restrictions target organizations offering Redis as a service, not those using it as infrastructure.
Why Redis Inc. Made These Changes
Understanding Redis Inc.'s motivations helps frame the situation honestly:
Cloud Provider Competition: The core issue was straightforward — major cloud providers offered managed Redis services at scale without contributing meaningfully to Redis development or paying Redis Inc. When the companies profiting most from your software aren't funding its development, sustainability becomes a real concern.
Business Sustainability: Developing and maintaining a widely-used database requires significant resources. The permissive BSD license made direct monetization difficult; Redis Inc. needed a path to revenue that didn't rely solely on support contracts and consulting.
The Broader Open-Source Tension: Redis isn't alone here. Elastic (Elasticsearch), MongoDB, and others have faced similar pressures. The fundamental question — how do open-source projects remain sustainable when cloud providers can offer them as commodities? — has no easy answer. Redis Inc.'s approach was one attempt at a solution.
Impact on Different Organizations
The licensing changes don't affect everyone equally. Here's a practical breakdown:
Minimal Impact: If you're using Redis internally for your own applications — caching, session management, real-time features — the new licenses likely don't change anything for you. Most small to medium businesses fall into this category. You can continue using Redis with confidence.
Moderate Impact: Large enterprises with formal licensing review processes may want legal counsel to review the new terms. Organizations building internal "platform" services that teams consume might face questions about whether that constitutes "offering as a service." Companies with strict open-source-only policies, or those subject to regulatory requirements about software licensing, may prefer alternatives.
Significant Impact: Cloud providers offering Redis as a managed service are the primary target of these restrictions. Platform companies reselling Redis capabilities, or organizations competing directly with Redis Inc.'s offerings, need to evaluate their options carefully.
If you're unsure where your organization falls, it's worth having your legal team review the specific license terms against your deployment model.
The Rise of Valkey
When the core licensing change hit in March 2024, the community response was swift. Within weeks, a group of contributors — including several former Redis core developers — forked the project under the name Valkey, maintaining the original BSD license.
The fork was significant not just technically, but politically. It represented a statement about who should control critical infrastructure software: a single commercial entity, or the broader community of users and contributors?
Why Valkey Emerged
Several factors drove Valkey's creation, though the licensing change was the catalyst:
Licensing Concerns: Organizations with strict open-source policies — particularly those subject to procurement requirements or regulatory mandates — needed an alternative with clear OSI-approved licensing. The BSD license Valkey maintains meets these requirements without ambiguity.
Governance: Many contributors and users wanted input into the project's direction. Under Redis Inc.'s commercial control, feature priorities naturally aligned with revenue generation. The community wanted a project where priorities aligned with user needs, not just commercial ones.
Long-term Certainty: There's an understandable concern that license terms could change again. With Redis having moved from BSD to RSAL for modules to RSALv2+SSPL for the core in just six years, some organizations worried about building critical infrastructure on terms that might shift again. A community-controlled project under the Linux Foundation provides more stability.
Cloud Provider Interests: Major cloud providers wanted to continue offering Redis-compatible managed services. Valkey's BSD license allows this without restriction.
Who's Behind Valkey
The Valkey project gained substantial backing quickly. This matters because open-source forks live or die based on sustained contributor commitment — without ongoing development, a fork becomes abandonware within a few years.
Key Supporters:
- Amazon Web Services: The largest contributor and primary advocate; AWS uses Redis-compatible infrastructure extensively in ElastiCache
- Google Cloud: Backing Valkey and planning Memorystore support
- Oracle Cloud: Committed to Valkey for their managed services
- Former Redis contributors: Several core developers who had been working on Redis moved to Valkey
- Linux Foundation: Providing governance structure through the Linux Foundation
This level of backing — three major cloud providers and a neutral governance foundation — provides reasonable confidence in Valkey's longevity. The project isn't dependent on any single company's continued interest.
Valkey's Governance Model
Valkey's governance structure contrasts with Redis Inc.'s commercial control in important ways:
Community-driven development: Feature priorities emerge from community discussion, not a single company's product roadmap. This means decisions about what to build next reflect the needs of users broadly, not just paying customers.
Transparent decision-making: Development happens in the open — public discussions, visible roadmaps, and open pull request reviews. You can see where development is happening on and why.
Meritocratic contributions: Anyone can contribute, and commit access is earned through demonstrated contributions over time. This is the standard open-source meritocratic model.
Linux Foundation oversight: The Linux Foundation provides neutral governance, similar to how it manages Kubernetes, Node.js, and other major projects. This means no single company can unilaterally change the project's direction or licensing.
For organizations that value predictability in their infrastructure software, this governance model offers advantages. The BSD license is unlikely to change — relicensing an open-source project requires broad community consensus, not a board decision.
The Underlying Questions
The Redis/Valkey split raises questions that extend well beyond one database:
Who should control critical infrastructure? When software becomes essential to thousands of businesses, does a single company's commercial interests adequately represent the broader community's needs? Valkey's emergence suggests that many organizations believe community governance better serves long-term interests.
What do cloud providers owe open-source projects? The "strip mining" criticism has merit — cloud providers do profit from open-source work without proportional contribution. Though it's also true that cloud providers have funded significant portions of Valkey's development, suggesting they're willing to contribute when the governance model aligns with their interests.
Is changing licenses on established projects fair? Organizations that built critical systems on Redis's BSD terms reasonably feel that subsequent license changes introduce risk they didn't sign up for. Of course, Redis Inc. had the legal right to make these changes — the question is whether it was wise, not whether it was legal.
How do we ensure critical infrastructure stays maintained? This is the hardest question. Software development requires resources, and "someone else will maintain it" isn't always a reliable answer. Valkey's model — community governance funded by organizations with a stake in its success — is one approach, though it has its own challenges.
There aren't clean answers to these questions. But understanding them helps frame the practical decisions organizations face.
The Practical Reality for Businesses
For most businesses using Redis today, the immediate practical impact is limited. That said, the landscape has changed in ways worth understanding:
If you're using Redis internally: The RSALv2 and SSPL licenses almost certainly don't affect you. Continue using Redis with confidence. Your legal team may want to review the terms — this is reasonable — but for typical internal usage, nothing changes.
If you're planning new implementations: You now have a genuine choice between Redis and Valkey. Both offer similar capabilities today, though they're likely to diverge over time. Evaluate based on your specific needs, risk tolerance, and governance preferences.
If you have strict open-source requirements: Valkey's BSD license may be preferable. Many procurement processes, government contracts, and compliance frameworks require OSI-approved licenses. Valkey meets these requirements; the current Redis licensing does not.
If you're a cloud provider or platform company: Valkey provides a path to continue offering Redis-compatible services. The major cloud providers have clearly signaled their preference.
The choice isn't urgent for most organizations — but it is worth making deliberately rather than by default.
Coming Up
In Part 3, we'll examine the technical differences between Redis and Valkey, including compatibility considerations and how the projects are diverging. Part 4 will provide a framework for making strategic decisions between them.
The licensing shift and Valkey's emergence created choice where none existed before. Understanding the history helps you make decisions based on your organization's needs rather than reacting to market noise.
Navigating the Redis/Valkey landscape? Let our experts help with In-Memory Database Strategy.