redis
Redis changed its licence, and the fork was already warm

I wrote about Valkey appearing two days after the Linux Foundation announced it, which was eight days after Redis left BSD. That post was written inside the event and could only describe what had happened.
Four months on there is enough distance to say what it meant, and the thing worth recording is not the licence. It is that this was the third time in a year I had watched the same sequence — after the Terraform relicensing and the fork that followed it — and how much faster this one went.
The same shape, compressed
The Terraform sequence took from August to January: relicensing, manifesto, fork announced, repository public, foundation, and then four months of work to a stable release. Redis to Valkey reached a foundation with three cloud providers behind it in eight days, skipping the manifesto entirely — nobody bothered asking for a reversal.
Four months later the gap has widened rather than closed. Valkey has shipped releases and is accumulating changes of its own, which is the point at which a fork stops being a copy and starts being a project.
What actually changed for me
Very little, and for the same reason as last time: the restriction is aimed at people offering the software as a service, not at people using it.
Which means the licence text is not what decides this. What decides it is the distribution you get, and for most of us that is not a decision we make directly. The version behind a managed cache is chosen by the cloud provider, and the three providers who sponsored Valkey have an obvious answer to that question. The version in a Docker image is chosen by whoever publishes the image. The version a client library is tested against is chosen by its maintainers.
So the practical form of the question is not "which licence do I prefer". It is "which one am I going to end up on without choosing", and the answer is arriving gradually through infrastructure rather than through a decision anybody makes in a meeting.
The compatibility window, which is the real thing to track
Valkey started as a fork of Redis 7.2.4, which means that at the moment of the fork the two were the same program with different names.
They will not stay that way. Two codebases with separate roadmaps diverge — not maliciously, just because features get built in different orders by different people. The question that matters for anyone with Redis in production is how long "a Redis client works against either" remains true.
For the things I use it for, that window is long. I have written about choosing BullMQ over a Mongo-backed queue, and what that depends on is blocking list operations, sorted sets, and Lua scripts — primitives that have been stable for a decade and are not where divergence will show up first. Anything depending on newer server-side features, or on the modules that were never BSD to begin with, has a much shorter window.
That gives a reasonable way to assess exposure without any licence reading: how old are the Redis features this code actually uses? If the answer is "all of them predate 2015", the fork is somebody else's problem for a long time.
The pattern I am now watching for
Three of these in a year is enough to stop treating each one as news and start treating it as a category.
The shape is consistent. A company builds an open-source project, a commercial ecosystem grows on top, the company concludes that the ecosystem captures value it created, and it relicenses to stop that specifically. Ordinary users are not the target and are told so, truthfully. The ecosystem forks, because it can and because it must.
The question I now ask about any dependency that matters is not whether it is open source today. It is what would happen if it stopped being: is the licence at the time of the last release one that permits a fork, is there a party with both the capability and the commercial motivation to maintain one, and how much of my usage depends on features new enough to diverge.
For Redis, all three answers were comfortable, which is why this was interesting rather than alarming. That will not be true of everything in a dependency list, and it is a much better time to find out now than during the week it happens.
Written by
Deyan Peev
Founding Engineer · Sofia, Bulgaria


