Every few months, another beloved open source project announces a license change. The blog post is polished, the reasoning sounds reasonable, and within days a community fork appears. HashiCorp did it with Terraform. Redis did it with their namesake database. Elastic did it, reversed it, and now watches a fork thrive without them. This isn’t a series of isolated incidents — it’s a pattern, and understanding it matters when you’re betting your infrastructure on software that could change terms overnight.
The cycle is remarkably consistent. A company builds a successful open source project under a permissive license. Cloud providers offer it as a managed service and capture most of the revenue. The original company, under financial pressure, switches to a “source-available” license like the Business Source License (BSL) or Server Side Public License (SSPL). The community forks the last truly open version. Both projects diverge, and developers are left choosing sides.
The Trigger: Cloud Providers and the 1% Problem
The root cause is economic. When MongoDB went public, when HashiCorp filed for an IPO, when Redis Ltd. took venture funding — each discovered that roughly 1% of users converted to paid offerings. Meanwhile, AWS, Google Cloud, and Azure offered managed versions of these projects and captured the infrastructure revenue without contributing proportional engineering effort back. The open source support-and-services model that worked for Red Hat in the 2000s collapsed when cloud providers handled operations better than anyone else.
SSPL requires anyone offering the software as a managed service to open source their entire service infrastructure — including orchestration, monitoring, and storage layers. No cloud provider would do that, so AWS DocumentDB became a reimplementation instead. The Open Source Initiative reviewed SSPL and concluded it doesn’t meet the Open Source Definition. MongoDB was no longer technically open source.
The License Landscape: Three Restrictive Models
Three “source-available” licenses dominate this space, each with different mechanics:
SSPL (Server Side Public License), used by MongoDB, requires you to open source your entire service stack if you offer the software as a service to others. It’s the most restrictive — even your monitoring tools and storage backends must be published. The full text is at the SSPL definition page.
BSL / BUSL (Business Source License), used by HashiCorp (Terraform, Vault, Consul, Boundary), restricts competitive production use for a defined period — typically four years — before automatically converting to an open source license (usually MPL). You can read, modify, and test the code freely, but using it to build a competing product triggers the restriction. HashiCorp published the full list of affected repositories on their licensing page, and their SDKs and APIs remained MPL.
RSALv2 (Redis Source Available License), created by Redis Ltd., specifically prohibits offering Redis as a managed service to third parties. Internal use, building applications on Redis, and even commercial products that happen to use Redis internally are all permitted. The restriction targets only direct service providers.
The Forks That Stuck
Not every license change produced a viable fork. MongoDB’s SSPL switch generated no major community fork — the complexity of the document database and AWS’s willingness to build DocumentDB independently made it impractical. But three forks did stick, and each tells a different story.
OpenTofu forked Terraform 1.5.7 (the last MPL version) in September 2023, weeks after HashiCorp’s BSL announcement. The Linux Foundation provided governance. Over 40 companies joined the OpenTofu Consortium, including CNCF, Gruntwork, and Spacelift. OpenTofu shipped version 1.6 within months, added features Terraform lacked (native state encryption, provider-defined functions), and has diverged enough that the two are no longer drop-in replacements. IBM acquired HashiCorp in December 2024 for $6.4 billion — a move some saw as vindicating the license change, others as proof it was about the acquisition, not the community. You can compare the two directly at the OpenTofu project site.
Valkey forked Redis 7.2.4 (the last BSD version) in March 2024, again under the Linux Foundation. What’s remarkable about Valkey is the speed. Within 30 days, AWS, Google Cloud, Oracle, and Ericsson were contributing. Within the first year, Valkey had 150+ contributors, 1,000+ commits, and nearly 20K GitHub stars. Valkey 8.0 shipped with multi-threaded I/O and performance improvements that independent benchmarks showed running 16–37% faster than Redis 8.0 on key operations. Redis Ltd. responded by adding AGPLv3 as an additional license option for Redis 8 in May 2025 — bringing it back to OSI-approved territory. Salvatore Sanfilippo (antirez), Redis’s original creator, rejoined the company as a developer evangelist.
OpenSearch forked Elasticsearch 7.10.2 (the last Apache 2.0 version) after Elastic’s January 2021 SSPL switch. AWS led the fork, and OpenSearch grew into a full suite with OpenSearch Dashboards, security plugins, and a thriving ecosystem. Then, in August 2024, Elastic added AGPLv3 back as a license option — the first reversal in the cycle. Elasticsearch is technically open source again, but OpenSearch had already built its own community and shows no signs of merging back.
What Actually Happened to Revenue
Here’s the uncomfortable truth: there’s no clear evidence that license changes improved revenue trajectories. MongoDB’s growth predated SSPL and continued at a similar pace. Elastic’s growth declined post-change and only recovered after the AGPLv3 reversal. HashiCorp was acquired rather than achieving independent growth. Redis Ltd. added AGPLv3 within 14 months of the SSPL switch, suggesting the original change didn’t deliver the expected outcomes.
The license changes did succeed at one thing: forcing cloud providers to invest in their own implementations or fund community forks. AWS built DocumentDB and OpenSearch. Google and AWS jointly back Valkey. The cloud provider free-rider problem was solved — but at the cost of community trust and ecosystem fragmentation.
Assessing Your Own Risk
If you’re building on single-vendor open source today, ask three questions. Who controls the copyright? Is the project under a neutral foundation? Does a cloud provider offer it as a managed service? Single-vendor control with active cloud competition is the highest-risk combination. Projects with distributed governance — like PostgreSQL, where no single company can unilaterally change the license — are structurally safer.
For most teams running these tools internally, the license changes have minimal direct impact. BSL, SSPL, and RSALv2 all permit internal use and building applications on top of the software. The restrictions target service providers offering the software as a managed product. But the downstream effects — client library fragmentation, procurement freezes while legal reviews the new terms, and the long-term question of whether to track the original or the fork — are real operational costs that fall on everyone.
The lesson isn’t that source-available licenses are evil or that companies shouldn’t monetize their work. It’s that infrastructure decisions are governance decisions. The license file in the root of a repository tells you what you can legally do today. The governance structure tells you what you’ll be able to do tomorrow.
Choosing Sides in 2026
If you’re evaluating Terraform vs OpenTofu, Redis vs Valkey, or Elasticsearch vs OpenSearch today, the technical differences are increasingly secondary to the governance question. OpenTofu has features Terraform doesn’t. Valkey benchmarks faster than Redis. OpenSearch has its own ecosystem. The original projects have corporate backing and faster feature development in some areas. Both sides are viable, and the right choice depends more on your organization’s risk tolerance for future license changes than on any benchmark.
The open source license wars aren’t over. Projects like MinIO and ScyllaDB show similar risk patterns. What’s changed is that the community now has a playbook: fork fast, find foundation backing, and let the fork compete on merit. Whether that’s sustainable for the broader ecosystem remains an open question — but for now, developers have more choices than ever, and that’s worth something.