Reconstructed from public reporting; not firsthand, no invented people or dialogue.
On March 20, 2024, Redis changed its license. Starting with Redis 7.4, new releases would ship under RSALv2 and SSPLv1 instead of BSD-3. The company did not hide the reason. Most of its commercial sales, it wrote, ran through the largest cloud providers, and those providers "commoditize Redis' investments and its open source community."
Two days later, on March 22, a new repository appeared on GitHub. It was called Valkey. The license was BSD-3. The code was a fork of the last BSD release.
That is the whole story in three sentences. The interesting part is what happened next, because both sides kept receipts.
The fork did not fade
Most forks of a popular project die in a few months. This one did not.
As of October 27, 2026, the Valkey repository has 27,528 stars and 1,431 forks. Redis has 77,130 stars. The fork is smaller, and it is also still here.
More useful than stars: release activity. Valkey 9.1.3 shipped on October 26, 2026. In the same 48 hours, the project also published maintenance releases on four older lines: 9.0.7, 8.1.11, 8.0.12, and 7.2.15. Four live branches is not a museum project. It is a project with users who cannot all upgrade at once.
The 9.x line also carries real engineering claims. The project's site says 9.1 does 2.1 million requests per second on a single server, saves up to 20% memory on small strings, and moves Lua out of the core into an optional module. Treat vendor benchmarks as marketing until you run them yourself. But "Lua is now a module" is the kind of change you only make when you are optimizing a codebase you expect to maintain for years.
Also worth noting: Valkey is a Linux Foundation project. That matters less for code quality than for governance. A foundation cannot unilaterally relicense the project the way a company can.
The reversal, in the company's own words
On May 1, 2025, Redis added AGPLv3 as a licensing option, starting with Redis 8. It kept SSPL. In the announcement, CEO Rowan Trollope wrote the sentence that makes this story worth telling:
"This achieved our goal—AWS and Google now maintain their own fork—but the change hurt our relationship with the Redis community."
Read that twice. The company says the license change worked as intended and still cost it something it cared about. It is rare to get both halves in one sentence from the person who signed the change.
The same post notes that Salvatore Sanfilippo, the original author, rejoined Redis in November 2024 as a developer evangelist. Redis 8 also folded Redis Stack into the core: JSON, time series, probabilistic types, and the query engine now ship together under AGPL. The company claims more than 30 performance improvements, commands up to 87% faster, and twice the throughput. Those are vendor numbers. The date and the license are facts.
What AGPL does and does not fix
Here is the part that gets flattened in arguments. AGPL is OSI-approved. That makes Redis open source again in the formal sense. It does not make Redis BSD again.
AGPL keeps the copyleft trigger, and extends it to the network. If you modify the software and let other people use it over a network, Section 13 requires you to offer them the corresponding source. For most teams running an unmodified cache, nothing changes. For anyone shipping a modified Redis as part of a hosted product, the compliance work is real, and it did not exist under BSD.
One detail gets lost in the argument: Redis 8 is dual-licensed. AGPLv3 is an option, not a replacement for SSPL. If your legal team already approved SSPL terms, nothing forces a change. If they rejected SSPL, AGPL is the path back. That distinction matters in procurement, where the real question is not "is it open source" but "which license will our scanner see on the artifact we deploy."
So the scoreboard is not "open source won." It is narrower. A company traded a permissive license for commercial protection, lost community trust, watched a foundation-backed fork keep shipping, and then added a copyleft license that is open source but stricter than what it removed. Everyone got something. Nobody got 2023 back.
What I would do this week
Audit by version, not by project. Your dependency scanner probably reports "Redis" once. The license depends on which release you actually deploy: 7.2 and earlier are BSD, 7.4 and later are RSALv2/SSPL, and 8.x can be AGPL. Pin the version and record the license next to it.
Ask your managed cache provider two questions: which engine, and which major version. "Redis-compatible" is not an answer. The engine determines your upgrade path if a license or price changes again.
If you host a modified version as a service, read AGPL Section 13 before the next upgrade, not after. The obligation is to offer source to network users, and "we only run it internally" is a different case from "our customers call it."
Keep the exit cheap. The core command surface is largely compatible, but modules and managed features are where migrations get expensive. A thin client abstraction and one tested fallback image cost little now and buy you options later.
None of this requires picking a side. It requires knowing which license is running under your connection string.
The part that generalizes
License changes are cheap to announce and expensive to undo. Redis added AGPL thirteen months after leaving BSD, and the fork from March 2024 is still publishing releases every week.
If you maintain a dependency that a company controls, the lesson is not "avoid company-controlled projects." The lesson is that the license is a versioned artifact, like the code. Treat it that way: record it, diff it, and know what you would do if it changed on a Tuesday.
The fork is what that plan looks like when you did not have one. It works. It is also more expensive than a one-line entry in your dependency policy.
Sources: Redis announcements of 2024-03-20 and 2025-05-01; valkey.io; GitHub repository and release metadata. Figures are as of 2026-10-27.
Top comments (0)