On the first of May, Redis 8 shipped with AGPLv3 added to its licence options, alongside RSALv2 and SSPLv1. Salvatore Sanfilippo, who wrote Redis and rejoined the company in November, led the change and contributed the release's vector set type.

So Redis is open source again — fourteen months after leaving BSD, and by the same mechanism Elasticsearch used when it came back last August: add a copyleft licence that answers the original commercial objection, rather than return to the permissive one.

That is four of these in two years. At this point the individual events are less interesting than what they have collectively taught me to check.

The shape, one more time

Terraform, Redis, Elasticsearch, Redis again. The pattern held every time.

A company builds an open-source project. A commercial ecosystem grows on top of it. The company decides the ecosystem is capturing value it created, and relicenses to stop that specifically — ordinary users are not the target, and are told so, and it is true. The ecosystem forks, because it can and because it must. Some time later, if the original goal was achieved, the licence softens again.

Elasticsearch took three and a half years to come back. Redis took fourteen months, which I suspect is less about a change of heart than about Valkey having arrived within weeks rather than years, with three cloud providers and a foundation behind it. When the fork is credible immediately, the licence stops being leverage immediately.

What Valkey being real changes

The two projects have been diverging for over a year now, and the honest position is that this is no longer one program with two names.

If you are on Valkey, coming back is a migration with no obvious return, and the reason to be there — a BSD licence and a foundation — has not changed. If you are on Redis, the licence objection is gone and the new work is happening where you already are. Both of those are fine, and neither is a mistake.

The compatibility window I mentioned last year still seems like the right way to think about exposure. The primitives I actually use through BullMQ — blocking list pops, sorted sets, Lua scripting — are a decade old and behave identically on both. A codebase built on those is insulated from this entire story. A codebase built on newer server-side features is not, and that gap will widen.

The checklist, which is the actual output

I have stopped forming opinions about these announcements and started running the same four questions, which take about twenty minutes for any dependency that matters.

Who owns it? A project held by a company that needs revenue from it is in a different position from one held by a foundation. This is the question that predicts everything else, and it is answerable today without any licence changing.

Was the last release forkable? A licence change is not retroactive. If the code at the last release was under something permissive or copyleft, a fork is legally available — which is why every one of these produced one.

Is there anybody who would? A fork needs someone with the capability and a commercial reason. Terraform had the ecosystem vendors. Redis had the cloud providers. A niche library with three maintainers and no commercial users has neither, and that is the dependency to worry about — not the famous one.

How old are the features I use? This decides how long a fork stays a drop-in. Long-stable primitives buy years. Recent features buy months.

Why I am not writing the fifth one

Because the answer stopped changing. Each of these felt like news at the time and none of them changed what I did on Monday, which is the clearest signal available that the individual event is not the thing worth tracking.

What is worth tracking is the four questions, asked before anything happens, about the dependencies that would actually hurt. The famous licence changes are loud precisely because the projects are large enough to be forked. The risk sits with the ones that are not — and those never make the news at all.