On the twentieth of March, Redis moved off the three-clause BSD licence it had used since 2009 and onto a dual arrangement: the Redis Source Available License v2 and the Server Side Public License v1. Neither is an open-source licence.

On the twenty-eighth — eight days later — the Linux Foundation announced Valkey, a fork continuing from Redis 7.2.4 under BSD-3-Clause, with AWS, Google Cloud, Oracle, Ericsson and Snap behind it and several of the people who had been maintaining Redis moving across to it.

I am writing this two days after that second announcement, which means most of what I can usefully say is about what has happened rather than how it turns out.

What the licence actually restricts

Worth being precise, because the first week of commentary was not.

Both licences aim at the same target: offering Redis to third parties as a managed service. RSALv2 forbids that outright for the covered software; SSPL permits it only if you publish the source of everything you use to provide the service, which is a condition nobody has ever met deliberately.

If you run Redis for your own application — in a container, on a machine, behind your own API — you are not the target and nothing about your Monday changes. That was true of the Terraform relicensing last year too, and it is the part that gets lost in the noise every time.

Releases already published stay under the licence they were published with. A licence change is not retroactive, which is precisely why a fork is available at all: Redis 7.2.4 was BSD when it shipped, and it stays BSD.

Why the response was so fast

Seven months ago I watched the same shape play out with Terraform. That sequence ran from August to January: relicensing, a manifesto asking for a reversal, a fork announced a fortnight later, a repository, a foundation, and then four months of work before anything shipped.

This one skipped the asking. There was no manifesto and no campaign for a reversal — the fork was announced eight days after the licence change, already inside the Linux Foundation, already with three cloud providers named.

I do not think that is because forking got easier. I think it is because the question had already been answered once in public. The legal ground was surveyed last autumn, the governance pattern existed, and the companies with a commercial stake had worked out in advance what they would do the next time this happened to something they resell. The first one was a crisis. This one was a procedure.

What exists today, and what does not

A name, a repository, a foundation, a set of sponsors, and a group of maintainers. There is no release.

That is the same position OpenTofu was in last September, and the same caveat applies: choosing Valkey today means choosing a promise rather than a binary. The promise looks well-funded, and it is still a promise.

What makes this one easier than the Terraform case is that the starting point is a drop-in. Valkey begins as Redis 7.2.4 with a different name on it, so on day one there is no compatibility question at all. Clients work. Commands work. The protocol is the protocol.

The question is how long that stays true, and the answer is: it will not. Two codebases with separate roadmaps and separate maintainers diverge, not out of malice but because features get built in different orders by different people. So "Valkey is a drop-in replacement" is a statement with a shelf life, and the useful thing to work out is how long yours is.

The shelf-life question, which is the one I would actually ask

Not "which licence do I prefer". That question has no consequences for most people. The one with consequences is: how old are the Redis features my code actually uses?

For the things I reach for Redis to do — blocking list operations, sorted sets, Lua scripts, the pub/sub primitives underneath a job queue — the answer is that all of it predates 2015. Behaviour that old is not where two forks diverge first. A codebase built on it can ignore this entire story for years.

Code that depends on recently added server-side behaviour, or on the Redis modules that were never BSD in the first place, has a much shorter window. That is worth knowing now rather than at the point where a version bump forces it.

What I am doing

Nothing, which is becoming a habit with these.

What I would not do is make a hurried decision in the first fortnight of a fork. The things that will decide this are which distribution ends up in the managed services, which version the client libraries test against, and whether the divergence stays cosmetic — and none of those are knowable yet. They are observable in about a year.

What is worth doing now is cheap: write down which Redis features the codebase depends on and roughly when each of them was introduced. That single list turns this from a question about licences into a question about compatibility, which is the form it will actually arrive in.