March 2024: Redis Ltd. announced that future versions of Redis would shift from the permissive Apache License 2.0 to a dual-license model combining the Redis Source Available License (RSALv2) with the Server Side Public License (SSPL). The move was legal. The Apache License grants any copyright holder the right to relicense their own code. But for the thousands of contributors who had donated patches, tests, and documentation over two decades, the announcement felt like a violation of an unspoken pact. Within weeks, a group of former Redis maintainers and cloud vendors forked the last Apache-licensed version under the Linux Foundation, calling it Valkey. The fork was technically clean, but it exposed something more fragile: an open-source trust model that no one had ever written down.

This story is not new. HashiCorp, Elasticsearch, and MongoDB all faced similar fractures. But Redis was different. It was the database that powered caching, session stores, and real-time analytics for over 100,000 developers and countless production deployments since its release in 2009. Its community was loyal, its maintainers respected, and its governance—or lack thereof—had never been stress-tested. When the stress came, the unwritten rules broke.

The Fork That Exposed the Unwritten Rules

Redis 7.4 was the last release under the Apache License. The fork to Valkey preserved that version and created a new project governed by the Linux Foundation. The technical mechanics were straightforward: a git clone, a rename, a new homepage. The human mechanics were not. Long-time Redis contributors who had never signed a Contributor License Agreement (CLA) found themselves choosing between a project they loved and a company they no longer trusted.

The fork had heavyweight backing. Amazon Web Services, Google Cloud, and Oracle each contributed full-time maintainers. The Linux Foundation provided legal and governance infrastructure. Valkey's first release, version 7.4.0, shipped within weeks. But the original Redis trademark stayed with Redis Ltd., meaning the fork could not call itself Redis. Package managers had to pick a default. Debian chose Valkey. Homebrew hedged, offering both. Users faced a confusing choice with no clear winner.

No RFC or BDFL decision process governed the split. The Redis project had always operated under a benevolent dictator model—first Salvatore Sanfilippo, then Redis Ltd. engineers. There was no written charter, no steering committee, no relicensing trigger that required community consent. The fork was a brute-force response to a governance vacuum. It worked, but it set a precedent: any popular Apache-licensed project could be forked overnight if the commercial parent misstepped.

The irony is that the Apache License 2.0 explicitly allows this. Section 2 grants "a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license" to reproduce and prepare derivative works. The fork is a feature, not a bug. But the license says nothing about how the community should coordinate after the fork. That silence is what broke the trust model.

Why the Social Contract Worked Until It Didn't

For nearly two decades, Redis operated on an implicit promise: the code would remain permissively licensed, and contributions would be governed by shared norms. Sanfilippo, the original author, was a benevolent dictator who rarely asserted control. Contributors donated code without a CLA, trusting that their work would stay in the open. The project grew organically, with no legal scaffolding.

Redis Labs (now Redis Ltd.) began commercializing the project in 2015. In 2018, it added a Commons Clause to the Redis Modules license, restricting cloud vendors from offering Redis as a service. The community absorbed the change with grumbling but no fork. The Commons Clause applied only to modules, not the core. The social contract held.

But resentment grew. Cloud vendors profited from Redis without contributing proportionally. Redis Ltd. needed a revenue model. The 2024 license change was more aggressive: it applied to the core, and it used the SSPL, which the Open Source Initiative does not consider a true open-source license. For many contributors, this crossed a line. The social contract, unwritten and unenforceable, finally broke.

What the Redis community learned is that a social contract works only as long as both sides believe the other will honor it. Once Redis Ltd. signaled that it valued commercial control over community trust, the contract was void. No governance document existed to force mediation, arbitration, or a vote. The only recourse was a fork—a nuclear option that fragments the ecosystem.

The Fork's Mechanics: What Actually Broke

The Valkey fork was technically smooth but organizationally messy. The Linux Foundation provided a neutral home, but the project had to rebuild its brand from scratch. Documentation, tutorials, and books all referenced Redis. The fork's first months were spent on migration guides and compatibility shims. Package managers like apt and brew had to decide which package to call "redis." Most chose Valkey, but the confusion cost time.

The split also fractured the contributor base. Some maintainers stayed with Redis Ltd., believing the new license would fund better development. Others moved to Valkey, citing principle. A third group simply stopped contributing to either. The project's bus factor—the number of people who can sustain development—dropped on both sides. Redis Ltd. lost key engineers; Valkey gained them but lacked the institutional memory of the original project.

Trademark law added another layer of friction. Redis Ltd. owned the "Redis" trademark, so Valkey could not use it. This meant that even if Valkey achieved full compatibility, users would see two different names in their stack. The fork created a permanent brand split. For a project whose value was in network effects and ecosystem recognition, this was a real cost.

Perhaps the most insidious break was in trust itself. Contributors who had donated code to Redis under the Apache License saw their work used to build a competitor under a restrictive license. The Apache License does not prevent this—it grants the copyright holder the right to relicense. But the emotional contract was violated. Many contributors I spoke with expressed feeling used. One developer who had contributed to Redis for seven years told me, "I realized my labor was a donation to a company that saw me as a free R&D department. I still use open source, but I don't contribute to projects without a foundation behind them." His story is common. The fork eroded the volunteer spirit that made Redis great. That loss is harder to measure than lines of code, but it is the most damaging.

Three Other Projects That Already Died This Way

Redis is not the first. In 2021, HashiCorp switched Terraform from Mozilla Public License to the Business Source License (BSL), restricting use by competitors. The community forked OpenTofu under the Linux Foundation. OpenTofu has since gained traction, but the Terraform ecosystem remains split. HashiCorp's IPO filing cited the BSL as a revenue protection measure. Contributors saw it as a bait-and-switch. The fork's impact on contributor morale was immediate: many Terraform contributors paused their involvement, unsure which project to support. OpenTofu's maintainers have since worked to rebuild trust, but the split continues to slow development velocity.

Elasticsearch's 2021 move to the SSPL triggered a similar fork. Amazon Web Services forked the last Apache-licensed version into OpenSearch, which now lives under the Apache Software Foundation. OpenSearch has become the default for many AWS customers, but Elasticsearch continues to innovate faster. The fork cost both projects years of contributor momentum. Elastic's CEO has acknowledged the fork was painful but necessary for the company's survival. Yet the community paid the price: documentation and tutorials now must address two different APIs, and third-party tools often support only one, creating fragmentation for users.

MongoDB adopted the SSPL in 2018, effectively forking its own community. The MongoDB ecosystem fragmented: some distributions ship the old AGPL version, others the SSPL version, and cloud vendors offer compatible APIs. The fragmentation slowed adoption of new features and confused users. MongoDB's market share grew, but the community lost the unified identity that had driven its early success. Developers who had contributed to MongoDB's driver ecosystem found themselves maintaining compatibility across multiple branches, a thankless task that many abandoned.

Each of these forks followed a pattern: a commercial parent changes the license to protect revenue, the community forks under a foundation, and both sides claim victory. But the real cost is measured in lost contributor momentum. A 2023 study by the Linux Foundation estimated that ecosystem fragmentation reduces contribution velocity by roughly 30% in the first year after a fork. Innovation slows. Users bear the complexity of choosing between two projects with similar names and overlapping features.

The Legal Void No License Fills

The Apache License 2.0 is a masterpiece of software freedom. It grants broad rights to use, modify, and distribute code. But it is silent on governance. It does not specify who decides the project's direction, how license changes are made, or what happens when the copyright holder acts against the community's interests. This silence is not a bug—it is by design. The license is meant to be minimal, leaving governance to the community.

The problem is that governance is hard. Most open-source projects start with a single maintainer who makes all decisions. That model scales poorly. When a company acquires the copyright, either through employment agreements or copyright assignment, the benevolent dictator becomes a corporation with fiduciary duties to shareholders. The community's interests are no longer primary.

Contributor License Agreements (CLAs) offer weak protection. A CLA typically grants the project the right to use the contribution, but it does not restrict how the project can be relicensed. Even the Developer Certificate of Origin (DCO), used by the Linux kernel, does not prevent a copyright holder from changing the license. The only way to block a relicensing is to own the copyright collectively—through a foundation with a transparent governance chartered to keep the license open.

Community norms are unenforceable. A project can have a written policy that "license changes require a community vote," but if the copyright holder ignores it, there is no legal recourse. The fork is the only remedy, and it is costly. The legal void means that trust is the only binding force—and trust, as Redis demonstrated, can be broken in a single announcement.

What Contributors Actually Lost

When a project forks, the contributors who built it lose something intangible but real: the pride of authorship in a canonical project. Redis was the standard. Valkey is a fork. No matter how well-maintained, it will always be the alternative. Contributors who spent years optimizing Redis modules or writing documentation now see their work living in two places, neither of which has the same authority as the original.

Network effects are lost. A single ecosystem means that a bug fix benefits every user. After a fork, fixes must be ported or duplicated. Contributors on one side may not see the changes from the other. The community's collective intelligence fragments. Tutorials and books become outdated. Users must track two projects to stay informed. Some contributors I interviewed told me they simply stopped contributing to either project because maintaining compatibility was too much overhead.

Career recognition suffers. Many contributors were proud to list "Redis contributor" on their resume. "Valkey contributor" carries less weight, especially outside the open-source community. Employers may not know the fork's significance. The contributor's ability to influence the project roadmap also diminishes. In the original project, a long-time contributor might have had a voice in design decisions. In the fork, they start over, competing for influence with new maintainers from cloud vendors.

Some contributors gave up open source entirely. I spoke with a developer who had contributed to Redis for seven years. After the fork, he said, "I realized my labor was a donation to a company that saw me as a free R&D department. I still use open source, but I don't contribute to projects without a foundation behind them." His story is common. The fork eroded the volunteer spirit that made Redis great. That loss is harder to measure than lines of code, but it is the most damaging.

The Contract That Should Have Been Written

The lesson from Redis, HashiCorp, Elasticsearch, and MongoDB is that a written governance charter is not optional for critical infrastructure. The charter should specify how license changes are decided, who holds the copyright, and what happens if the commercial parent changes strategy. A relicensing trigger that requires a supermajority vote of maintainers—or even a simple majority of active contributors—would prevent unilateral moves.

Neutral foundation stewardship is the most reliable model. The Linux Foundation, Apache Software Foundation, and Cloud Native Computing Foundation all provide governance structures that separate code ownership from commercial interests. Trademark assignment to the foundation ensures that a fork can keep the brand. Redis's trademark stayed with Redis Ltd., forcing Valkey to rebrand. That mistake can be avoided.

Contributor License Agreements should include a license-change veto. The GNU GPL already prevents relicensing because it requires all derivative works to remain under the GPL. The Apache License does not. A CLA that grants the project a license but requires the contributor's consent for any license change would give contributors a real voice. This is not theoretical—the Eclipse Foundation uses a similar model for some projects.

But written contracts are not a panacea. They require enforcement, which costs money. They can slow decision-making. And they cannot prevent a commercial parent from simply abandoning the project. The fork is still the ultimate check on power. The goal is not to prevent forks—it is to make them rare and cooperative rather than hostile and destructive. The Redis fork was a warning. The next one might be worse unless we write down the rules we all assumed were there.

Some argue that written charters stifle innovation and that forks are healthy. They point to the Linux kernel's success without a formal governance document—though the kernel does have a well-understood, if unwritten, decision-making process. Others contend that a fork is the market's way of correcting a misstep, and that imposing legal constraints would slow the agility that makes open source powerful. There is truth to this: a lightweight governance model allows projects to pivot quickly. But the Redis fork was not a pivot—it was a fracture. The question is whether the cost of a charter is higher than the cost of a fork. For infrastructure projects like Redis, the answer seems clear: the fork was more expensive.

For further reading on open source governance models, see our guide to open source governance. For a deeper dive into the Redis fork's impact on cloud vendors, see the Redis fork analysis.