Redis was the golden child of open source infrastructure. For fifteen years, it operated under the permissive BSD-3 license, building a community that contributed features, fixed bugs, and evangelized the technology across the industry. Then in March 2024, Redis Ltd. abandoned open source entirely, switching to restrictive source-available licenses that prohibited competitive use. The betrayal was swift, calculated, and complete—exactly the pattern that’s destroying trust in “open” infrastructure across the industry.
The community response revealed the depth of damage. Within weeks, the Linux Foundation announced Valkey, a true open source fork backed by AWS, Google Cloud, Oracle, Ericsson, and Snap. A year later, Valkey has grown to 25,000+ GitHub stars and nearly 50 contributing companies. The mass exodus demonstrates what happens when companies build communities under open source licenses, then yank those licenses once adoption reaches critical mass. Developers don’t forget betrayal—they fork and move on.
This isn’t isolated. HashiCorp’s 2023 license change sparked similar revolt—the OpenTofu manifesto gathered pledges from 140 companies and 700 individuals within weeks, resulting in more than 160 contributors within eighteen months. ScyllaDB’s 2024 switch to source-available licensing continued the pattern. Each change follows the same playbook: build adoption under permissive licenses, wait for community investment, then restrict usage to protect commercial revenue. The strategy destroys trust while fragmenting ecosystems through competitive forks.
The phenomenon has a name: fauxpen source—software that masquerades as open source while imposing restrictions that violate open source principles. Understanding why companies make these changes, what damage they cause, and how to identify license risk before investing in infrastructure matters for anyone building on open source foundations. The pattern is accelerating, the costs are real, and the alternatives exist for those willing to prioritize actual openness over marketing claims.
The License Change Playbook
The pattern across Redis, Terraform, Elasticsearch, and MongoDB follows a consistent sequence that’s become predictable enough to map in advance. Companies don’t stumble into license changes—they execute deliberate strategies that maximize extraction from open source communities before restricting future use.
Stage one begins with permissive licensing to accelerate adoption. Companies choose MIT, Apache, or BSD licenses specifically because they lower adoption friction. Developers trust that code under these licenses won’t impose future restrictions, competitors can build on the technology without legal risk, and enterprises can deploy without procurement concerns about vendor lock-in. This trust drives organic adoption that would be impossible under restrictive licensing from day one.
Stage two builds community contribution to share development costs. HashiCorp’s Terraform attracted contributions from practitioners solving real infrastructure problems—better AWS resource support, improved state management, enhanced module systems. These contributions came from users who assumed their work would remain freely available under Terraform’s original Mozilla Public License. The company benefited from distributed development while maintaining control over the core project.
Stage three waits for critical mass before restriction. The timing isn’t random—companies change licenses after achieving sufficient market position that users face significant switching costs. Redis’s March 2024 switch happened after the database had become embedded in countless production systems where migration would require substantial engineering effort. The embedded position creates leverage that companies exploit through licensing restrictions.
Stage four imposes restrictions that kill the ecosystem built under permissive terms. The new licenses typically prohibit competitive commercial use, block cloud providers from offering managed services, or impose usage restrictions that contradict open source principles. MongoDB’s 2018 shift to Server Side Public License pioneered this approach, requiring companies offering MongoDB as a service to open source their entire stack—a poison pill designed to block competition rather than promote openness.
The justification follows a consistent narrative: companies claim they’re “protecting” open source from “strip-mining” by cloud providers. This framing ignores that cloud hosting creates demand, that truly open licenses permit commercial use by design, and that companies chose permissive licenses initially to build adoption they’re now restricting. The real motivation is extracting maximum commercial value from community-built software after competitors demonstrate the technology’s market value.
The True Cost of License Betrayal
The damage from license changes extends far beyond the immediate disruption of migration or fork decisions. Trust destruction creates systemic costs that compound over time, affecting how developers evaluate any infrastructure built by venture-backed companies regardless of current licensing.
Migration costs provide the most obvious impact. When enterprises must migrate from Redis to Valkey or Terraform to OpenTofu, they incur testing overhead, deployment changes, documentation updates, and team training—costs unrelated to technical improvements or new capabilities. These migrations deliver negative value; they preserve existing functionality under different licensing rather than advancing capabilities. The opportunity cost of engineering time spent on defensive migrations rather than feature development never appears in licensing discussions but represents substantial waste.
Community fragmentation splits development effort across incompatible forks. Before HashiCorp’s license change, Terraform improvements benefited all users regardless of vendor. After the split, OpenTofu and Terraform diverge—features developed for one don’t automatically help the other, bug fixes require duplicate effort, and the ecosystem fractures between competing implementations. OpenTofu’s 160+ contributors and Terraform’s ongoing development both represent substantial engineering investment, but the duplication wastes collective resources that could have advanced a unified project.
Future caution damages all commercial open source companies, including those that maintain permissive licensing. When developers evaluate infrastructure choices, license change history creates wariness about any venture-backed open source company. The question becomes not “is this currently open source” but “will this company change licenses once I’m locked in?” This skepticism increases evaluation friction even for companies that genuinely commit to open source principles, creating a tragedy of the commons where betrayals by some damage trust in all.
Innovation slowdown results from reduced investment in projects with license uncertainty. Contributors think twice before investing time in projects where their work might get relicensed, enterprises hesitate to build deeply integrated systems on potentially unstable foundations, and competitive pressure to develop alternatives diverts resources from advancing the state of the art. The Redis/Valkey split means two projects rebuilding rather than one project innovating.
The Fork Response and Community Resilience
The speed and effectiveness of community forks in response to license changes reveals both the strength of open source development models and the completeness of trust destruction that licensing changes create. When companies betray open source principles, communities don’t negotiate—they fork.
The pattern accelerated dramatically in 2023-2024. HashiCorp changed Terraform’s license from MPL 2.0 to BSL on August 10, 2023, with minimal warning. The community mobilized immediately—the OpenTF manifesto gathered 33,000 GitHub stars and pledges from 140 companies and 700 individuals within weeks. HashiCorp’s refusal to reverse course led directly to OpenTofu, which the Linux Foundation accepted in September 2023 and the CNCF accepted in April 2025. The fork demonstrated that communities value open source principles over code continuity.
Redis’s March 2024 license change to RSALv2 and SSPLv1 triggered the most dramatic community response yet. Former Redis maintainers immediately forked the project, and the Linux Foundation launched Valkey within days. The project quickly attracted major technology companies as contributors and has grown to 25,000+ GitHub stars and nearly 50 contributing companies. The completeness of the community migration forced Redis Ltd. to partially reverse course—in November 2024, the company added AGPLv3 as a licensing option, creating a triple-licensed situation where users can choose SSPL, RSALv2, or AGPLv3. The reversal acknowledged that the initial change destroyed community relationships beyond repair.
Elasticsearch’s 2021 license change from Apache 2.0 to dual SSPL/Elastic License triggered an immediate AWS fork called OpenSearch. The fork succeeded to the point that Elastic later returned Elasticsearch to open source under AGPLv3 in 2024—an extremely rare example of a company reversing a license restriction after realizing the commercial damage exceeded the protection value. The reversal validated what the community had argued: that open source benefits exceeded the risks that restrictions aimed to prevent.
The fork velocity demonstrates the depth of mistrust. OpenTofu attracted more than 160 contributors within eighteen months, many of them former Terraform contributors who immediately migrated their participation to the fork. Valkey’s nearly 50 contributing companies indicate that enterprises preferred investing in new forks over continuing with now-restricted original projects. These aren’t small hobby projects—they’re major infrastructure components with hundreds of person-years invested. The willingness to fork rather than accept new licensing terms signals that license trust matters more than code continuity.
Identifying License Risk Before You’re Locked In
The license change pattern is predictable enough that developers can assess risk before building critical dependencies on projects likely to restrict licensing. Specific indicators correlate with future license changes, enabling preemptive evaluation of alternatives.
Funding source and investor pressure create the primary risk factor. Venture-backed companies face pressure to demonstrate defensible moats and recurring revenue streams. When growth slows or competitors successfully leverage open source technology, license changes become attractive options for creating artificial scarcity. Projects backed by firms emphasizing “commercial open source” strategies face higher risk than those funded by foundations or sustained through services without VC backing.
License choice reveals company intentions. Projects launching under SSPL, BSL, or other restrictive licenses signal upfront that they prioritize vendor control over community openness. These projects may call themselves “open source” but violate the Open Source Definition. The Parse Server project (97 health, 76.8 technical) maintains MIT licensing, demonstrating commitment to genuine openness. When evaluating infrastructure, check actual license terms rather than trusting “open source” marketing claims.
Competitive positioning influences license stability. When multiple well-funded companies compete in a category, and cloud providers offer managed versions of the technology, license change risk increases. MongoDB changed licenses when AWS DocumentDB provided MongoDB-compatible interfaces. Redis restricted licensing after cloud providers offered managed Redis. The competitive threat created pressure to restrict community-built technology rather than compete through superior service or features.
Revenue model sustainability affects license decisions. Companies dependent on selling software licenses face pressure to restrict open source alternatives. Companies generating revenue through services, support, or enterprise features on top of truly open foundations demonstrate more sustainable models. Mautic (96 health, 66.8 technical) funds development through services while keeping code truly open. Revenue models that require restricting the core technology signal future license risk.
Contributor diversity indicates community health and resistance to single-vendor control. Projects with contributions from dozens of companies and hundreds of individuals distribute control in ways that make licensing changes harder to execute. Valkey’s nearly 50 contributing companies represent diverse interests that would need to agree on any license changes—a high bar that protects against unilateral decisions. Projects where 80%+ of contributions come from a single vendor face concentrated control that enables quick licensing pivots regardless of community preferences.
Foundation governance provides structural protection against licensing changes. Projects governed by the Linux Foundation, Apache Software Foundation, or CNCF operate under bylaws that make license changes extremely difficult. NodeBB (96 health, 65.8 technical), while not foundation-governed, maintains GPL-3.0 licensing that provides copyleft protection. When critical infrastructure decisions are at stake, foundation-governed alternatives reduce risk compared to vendor-controlled projects regardless of current licensing.
The True Open Source Alternatives
The license change pattern creates opportunity for projects that commit genuinely to open source principles. Developers burned by licensing betrayals seek alternatives where license stability provides competitive advantage over technical features.
Foundation-backed infrastructure projects demonstrate the strongest license commitment. The Linux Foundation’s role in launching Valkey provided governance structure that prevents future licensing restrictions. Foundation bylaws create processes that make unilateral license changes impossible, protecting against the single-vendor control that enabled licensing betrayals elsewhere. When choosing between technically similar alternatives, foundation governance provides insurance against future betrayal that vendor-controlled projects can’t match.
Parse Server exemplifies commitment to genuine openness through consistent MIT licensing and distributed development. The project provides backend-as-a-service infrastructure—REST APIs, GraphQL, real-time subscriptions, cloud code—as truly open source without licensing restrictions. The MIT license permits commercial use, modification, and redistribution without constraints. Projects maintaining permissive licenses through multiple years and version releases signal credible commitment rather than temporary positioning.
OpenProject (96 health, 72.5 technical) demonstrates how genuine open source competes effectively against proprietary project management tools without restrictive licensing. The project maintains GPL-3.0 licensing while offering commercial hosting and enterprise features as value-add services. This model—truly open core with commercial services layered on top—avoids the license bait-and-switch that destroys trust. Users know exactly what they’re getting: software that will remain open regardless of market conditions or competitive pressure.
EspoCRM (94 health, 65.8 technical) provides CRM infrastructure under GPL-3.0, competing against both proprietary CRM systems and “open core” vendors whose licensing creates lock-in. The copyleft license ensures that improvements remain available to all users while preventing proprietary forks that could fragment the ecosystem. For categories where licensing changes have damaged trust—databases, infrastructure tools, developer platforms—copyleft alternatives provide stronger guarantees than permissive licenses that companies can later restrict.
GitLab maintained the delicate balance of open source core with proprietary enterprise extensions, though not without controversy. The company kept core features under MIT license while selling proprietary enterprise capabilities. This model works when the line between open and proprietary remains clear and stable. Projects blur this line or migrate features from open to proprietary face the same trust destruction as those changing licenses outright. True commitment means keeping the line stable even when commercial pressure suggests moving features behind paywalls.
The opportunity cost of choosing restricted-license projects over true alternatives deserves explicit consideration. Technical features matter, but license trust creates durable competitive advantage when alternatives exist. A technically superior project with licensing risk carries hidden costs that appear when the license changes and migration becomes necessary. A slightly less feature-rich alternative with credible open source commitment avoids future migration costs while supporting an ecosystem that won’t betray users for commercial gain.
What This Means for Infrastructure Choices
The license wars create a permanent shift in how developers must evaluate infrastructure decisions. “Open source” as marketing claim no longer suffices—actual license terms, governance structure, and funding models determine whether projects will remain open when commercial pressure increases.
The pattern recognition changes evaluation criteria. Before license betrayals became common, developers could reasonably trust that permissive licenses would remain stable. That trust is gone. Now, evaluation requires assessing whether a vendor-controlled project will resist pressure to restrict licensing when competition threatens revenue. The track record suggests most won’t resist—the financial incentives favoring restriction outweigh community goodwill when investors demand defensibility.
For categories where license changes have already occurred—databases, infrastructure-as-code, search, caching—forks created by those changes now offer more stable licensing than original projects attempting reversals. Valkey’s Linux Foundation governance provides stronger guarantees than Redis’s triple-licensing compromise. OpenTofu’s CNCF backing beats Terraform’s BSL restriction. The forks exist specifically because communities prioritized license openness over vendor convenience, creating options for those who learned this lesson.
The defensive architecture question shifts from “should I use open source” to “which open source projects won’t betray their communities.” The answer correlates strongly with governance structure and funding model. Foundation-governed projects with diverse contributor bases and revenue models based on services rather than license restrictions demonstrate credible commitment. Vendor-controlled projects dependent on selling software licenses face structural pressure to restrict whenever market conditions change.
The cost of being wrong about license stability exceeds the cost of choosing slightly less optimal technical solutions upfront. Migration from Redis to Valkey or Terraform to OpenTofu required substantial engineering effort for zero functional gain—pure waste driven by licensing betrayal. Choosing Valkey initially, even if Redis had slightly better features, avoids that waste. The insurance value of license stability justifies accepting minor technical trade-offs when alternatives exist.
The community response to license changes demonstrates that open source resilience exceeds vendor control. Companies that betrayed open source principles lost their communities to forks that rebuilt the same capabilities under stable licensing. The message is clear: infrastructure built on genuine open source principles survives, while projects using open source tactically until restriction becomes profitable face community abandonment and competitive forks. For developers choosing infrastructure, that pattern indicates which projects deserve trust and which represent ticking license bombs waiting for commercial pressure to trigger restriction.
The license wars accelerated the maturation of commercial open source business models. Companies that maintain genuine open source commitment while building sustainable service-based revenue demonstrate that restriction isn’t necessary for profitability. Those that changed licenses revealed that they never truly committed to open source principles—they used openness tactically for adoption, then restricted when convenient. The market now distinguishes between these models, creating competitive advantage for companies that maintain their open source principles when others abandon them for short-term commercial protection.