The Eight-Day Fork
Redis just gave the industry another reminder that software licenses are not background noise. On March 20, 2024, Redis announced that future releases of its core software would move from the familiar BSD 3-Clause license to a dual source-available model: RSALv2 or SSPLv1, starting with Redis v7.4 and forward. Redis’s own licensing announcement says the quiet part out loud: this is not the same thing as open source under the OSI definition.
Then, on March 28, 2024, the Linux Foundation announced Valkey, a BSD-licensed fork that continues development from Redis 7.2.4. The timeline between the two announcements was eight days. In software terms, that is barely enough time to finish a couple of meetings, much less rewrite a platform strategy.
So what happened? A license change created a governance event, and the community responded the way open source communities are supposed to respond: by forking.
That is the whole story in one sentence. But the consequences are much broader than one project, one fork, or one press release.
Source-Available Is Not Open Source
“Source-available” sounds harmless if you say it quickly. It is not harmless.
The practical difference is this: you can see the code, but your rights to use, redistribute, or commercialize it may now depend on what you are doing with it. If you are an application developer using Redis as a component, your day may not change much. If you are a cloud provider, a managed service operator, or a company building a Redis-adjacent product, the fine print suddenly matters a lot.
Redis’s announcement is explicit that the new model is designed to address commercial use cases around managed services and competitive offerings. That is a business decision, not just a legal one. It changes the expected value of the open source strategy. In plain English: the company is trying to make sure the economics of the ecosystem work in its favor.
There is nothing mysterious about that. The mystery is why so many companies still act surprised when a license is used as a strategic tool.
The good news, if you want to call it that, is that open source communities now know the playbook. If a project goes from permissive to restrictive, the market can and will respond. Forks are not theoretical. They are the pressure valve.
Why Valkey Appeared So Quickly
Valkey did not emerge from nowhere. The Linux Foundation said the project would continue development on Redis 7.2.4 and remain under the BSD 3-Clause license. It also said the project had support from major industry participants, including AWS, Google Cloud, Oracle, Ericsson, and Snap Inc.
That matters. Forks fail when they are lonely. Forks succeed when they have contributors, corporate backing, and a credible governance story.
Valkey’s launch was essentially a statement: if the community wants the code to remain broadly usable, then the governance model has to remain broadly trustworthy. One company can change a license in a day. A foundation-backed project can make that kind of surprise much harder.
That is why this story feels bigger than Redis.
It is not just about a cache. It is about what happens when a platform dependency becomes a licensing dependency. Redis has long been one of the default infrastructure components in modern software stacks. It sits in caches, queues, session stores, analytics pipelines, and product backends all over the place. If the license changes, the blast radius is not limited to the original maintainers.
If this sounds familiar, it should. Terraform and OpenTofu taught the market that governance can split a project from its users almost overnight. Redis and Valkey are now part of that same pattern: fork governance is becoming a real diligence dimension.
What Buyers Should Be Asking
And this is where technology deals get interesting — by which I mean expensive.
If you are buying a company, or even just reviewing one for an investment committee, “Do you use Redis?” is no longer enough. The right questions are more annoying, and therefore more useful.
Which version is deployed? Is it pinned to a pre-change release? Is the product embedding Redis, exposing it as a service, or simply using it internally? Is any commercial or cloud offering adjacent to Redis in a way that could trigger a license issue? Has anyone actually read the current license terms, or did they just assume that “open source” meant “no problem”?
That last question is where diligence goes to die.
A license issue can affect more than compliance. It can affect roadmaps, integration costs, customer contracts, security review timelines, and valuation. If a company’s architecture depends on software that may need to be replaced, forked, or replatformed, that is not just a legal footnote. That is operational risk. That is financial risk. That is transaction risk.
In a technology due diligence sprint, this is exactly the sort of issue that should surface early. License compliance risk is not separate from technical risk. It is technical risk wearing legal clothes.
The Practical Playbook
So what should a serious team do?
First, inventory the dependency. Not just “we use Redis,” but where, how, and under what deployment model. Internal use, shipped software, managed service delivery, and embedded distribution are different animals.
Second, classify the exposure. A product that merely connects to Redis is not the same as a platform that repackages Redis as part of a commercial offering.
Third, read the actual license language. Do not rely on the summary someone posted in Slack, or the memory of a developer who last looked at this in 2021.
Fourth, ask whether a credible fork exists. If it does, governance becomes a choice, not just a dependency. That is the Valkey lesson. The market does not need a perfect answer; it needs a viable one.
Fifth, connect the legal answer to the valuation answer. If a customer-facing system depends on software with a licensing overhang, the cost of remediation is part of the asset value. Ignoring that does not make it go away. It just makes the surprise larger later.
More disciplined reviews help here: SBOM analysis, license scanning, and architecture-level diligence should live in the same conversation. The old model of “we’ll deal with it if counsel flags something” is too slow for infrastructure software that can fork in less than two weeks.
The Real Lesson
Redis’s license change is not the end of the story. It is the beginning of a new standard for how software buyers, investors, and operators think about dependency risk.
Open source used to mean “someone else has already done the hard work.” Increasingly, it also means “someone else may change the rules.” That is not a reason to panic. It is a reason to pay attention.
Because once a project crosses the line from permissive to source-available, the question is no longer whether the code exists. The question is who controls the terms under which the code can keep earning its keep.
And that is not a philosophical issue. It is a diligence issue.
Related posts
SFC v. Vizio: A Court Says GPL Compliance Is a Contractual Duty
A December 4, 2025 tentative ruling in SFC v. Vizio suggests GPL compliance can sound in contract, not just copyright, with real consequences for end users.
Read moreCISA and FBI Call for Memory Safety Roadmaps: Is C++ on Borrowed Time?
CISA and the FBI are turning memory safety from an engineering preference into a board-level issue, and C/C++ is suddenly on the defensive.
Read moreHashiCorp Goes BSL: What the Terraform License Change Means for Your Infrastructure
HashiCorp's move to BSL 1.1 for Terraform and other core products changes the rules for vendors, integrators, and anyone packaging infrastructure tooling commercially.
Read more