Redis, the beloved in-memory data store that’s become as ubiquitous as oxygen in modern application stacks, just dropped a bombshell. As of March 20, all future versions of Redis will be released under a dual license — the Server Side Public License (SSPL) and Redis Source Available License v2 (RSALv2) — instead of the three-clause BSD license that made it one of the most permissively licensed pieces of infrastructure software in existence. And the community’s response has been swift: the Linux Foundation is backing a fork called Valkey, and the open source ecosystem is bracing for another licensing war.
I’ve watched this movie before. Multiple times. And the sequel is never better than the original.
What Actually Changed#
Let me be precise about what happened because the details matter. Redis Labs (now just “Redis”) changed the license for the Redis server itself. Previously, Redis core was BSD-licensed — you could use it, modify it, redistribute it, embed it in proprietary products, host it as a service, literally anything. The new SSPL/RSALv2 dual license restricts one specific use case: offering Redis as a managed service without contributing back or obtaining a commercial license.
The target is obvious. AWS ElastiCache, Google Cloud Memorystore, Azure Cache for Redis — these hyperscalers have built billion-dollar businesses running Redis-compatible services without contributing meaningfully to Redis development (from Redis Labs’ perspective, anyway). The SSPL, originally created by MongoDB, essentially says: “if you offer this software as a service, you must open-source your entire service stack.” It’s a poison pill for cloud providers.
Redis CEO Rowan Trollope’s blog post frames this as a sustainability move, and I understand the business logic. Redis Labs has raised hundreds of millions in venture capital and needs a path to revenue that doesn’t involve competing against the very companies using its open source project as a loss leader.
Enter Valkey#
Within days of the announcement, the Linux Foundation announced Valkey — a community-driven fork of Redis 7.2.4 (the last BSD-licensed version), backed by AWS, Google Cloud, Oracle, Ericsson, and Snap. The project already has maintainers from multiple companies, including former Redis contributors, and has declared its intent to remain under the BSD license.
This is the open source immune system at work. When a widely-used project changes its social contract, the community routes around the damage. We saw it with OpenOffice begetting LibreOffice, MySQL leading to MariaDB, and CentOS spawning Rocky Linux and AlmaLinux. The pattern is so predictable at this point that it should be in every VC’s risk assessment for open source companies.
What makes Valkey interesting is the Linux Foundation’s involvement from day one. This isn’t a scrappy fork maintained by a handful of frustrated developers — it’s a well-funded, organizationally backed project with major cloud providers committing engineering resources. AWS alone has a massive incentive to make Valkey succeed; their ElastiCache service depends on Redis compatibility.
The Sustainability Paradox#
Here’s where I get philosophical — and maybe a bit grumpy. I’ve been building systems with Redis since 2012. It’s genuinely excellent software, and Salvatore Sanfilippo (antirez) deserves enormous credit for creating something that’s simultaneously simple, fast, and versatile. But the fundamental tension in commercial open source has never been resolved.
The paradox goes like this: to build a successful open source project, you need to make it as permissive and easy to adopt as possible. But to build a successful business around that project, you eventually need to restrict that same permissiveness. Every company built on an open source core eventually faces this moment. Some handle it gracefully (Red Hat’s model worked for decades). Others… don’t.
Redis Labs’ frustration is legitimate. They employ many of the Redis core developers. They fund the development of modules, testing infrastructure, and documentation. Watching AWS profit enormously from their work while contributing relatively little back is genuinely unfair. But “fair” and “strategically smart” aren’t always the same thing.
What This Means for Your Stack#
If you’re running Redis in production — and statistically, you probably are — here’s my practical assessment:
Short term (next 6 months): Nothing changes. Your existing Redis deployments continue to work. The license change only affects new versions, and there’s no immediate need to upgrade.
Medium term (6-18 months): You need to make a choice. Continue with Redis under the new license (fine for most use cases — the restrictions only apply to service providers), or start evaluating Valkey as a drop-in replacement. Given that Valkey is forked from Redis 7.2.4, compatibility should be nearly perfect initially.
Long term: This is where it gets murky. Redis and Valkey will diverge. Features will be added to one but not the other. Performance characteristics may differ. The ecosystem will fragment — some client libraries may optimize for Redis, others for Valkey. I’d recommend watching both projects closely and avoiding deep dependencies on features specific to either.
My Take#
I’m disappointed but not surprised. The VC-funded open source model has a fundamental design flaw: it creates a time bomb where the interests of the company and the community inevitably diverge. Redis held out longer than most, but the pattern is clear.
My bet is on Valkey succeeding. Not because it’s technically superior — right now it’s literally the same code — but because the combination of Linux Foundation governance, multi-cloud backing, and genuine community goodwill is a powerful force. LibreOffice overtook OpenOffice. MariaDB became the default in most Linux distributions. The fork, when backed by sufficient institutional support, tends to win.
For Redis Labs, this license change may solve their cloud provider problem in the short term, but at the cost of community trust that took a decade to build. That’s a trade I wouldn’t have made.