The Open Source License Wars: How HashiCorp, Redis, and Elastic Changed the Rules

The Pattern That Keeps Repeating

Three of the most widely used infrastructure software projects in the world changed their licenses within a few years of each other. HashiCorp changed Terraform from Mozilla Public License 2.0 to Business Source License (BSL) in August 2023. Redis changed from BSD to Server Side Public License (SSPL) in March 2024. Elastic had already moved Elasticsearch and Kibana to SSPL in 2021. All three companies gave similar explanations: cloud providers were using their software to build competing managed services without contributing back.

All three faced immediate community forks. OpenTofu (Terraform) appeared within weeks of HashiCorp's announcement, backed by the Linux Foundation. Valkey (Redis) launched in March 2024, also under the Linux Foundation, with commits from AWS, Google, Oracle, and Alibaba engineers. OpenSearch (Elasticsearch) had already launched in 2021, led by AWS. The pattern is consistent enough to constitute a playbook — for both sides.

What the License Changes Actually Do

The Business Source License (BSL), developed by MariaDB and adopted by HashiCorp, allows free use for most purposes but prohibits using the software in a competing commercial product without a commercial license. Critically, BSL-licensed software converts to an open source license (usually Apache 2.0) after four years. HashiCorp set a four-year conversion window: Terraform 1.6 released in August 2023 would become Apache 2.0 in August 2027.

SSPL, created by MongoDB, is more aggressive: it requires that anyone offering the software as a managed service must open-source the entire stack used to deliver that service — including orchestration, monitoring, and supporting infrastructure. Because this is essentially impossible for a cloud provider with proprietary infrastructure to comply with, SSPL functions as a practical prohibition on offering managed services. The Open Source Initiative does not recognize SSPL as an open source license. Neither does the Free Software Foundation. Both Redis and Elasticsearch under SSPL are, by the definitions that matter most in the industry, proprietary software that happens to publish its source code.

HashiCorp: The Acquisition That Followed

The most commercially significant development in this story is what happened to HashiCorp after the license change. IBM acquired HashiCorp in April 2024 for $6.4 billion — one of the largest acquisitions in enterprise infrastructure software. IBM operates Red Hat, which is built almost entirely on open source software and is the world's largest enterprise Linux company. The acquisition of HashiCorp brings Terraform, Vault, Consul, and Nomad into IBM's portfolio alongside Red Hat's OpenShift and Ansible.

The OpenTofu fork, meanwhile, reached version 1.7 in May 2024, implementing features that Terraform had not yet shipped. The Linux Foundation's backing means OpenTofu has institutional support and is unlikely to collapse from maintainer burnout — the fate of many community forks. OpenTofu is now a credible long-term alternative to Terraform for organizations uncomfortable with BSL's restrictions or IBM's ownership.

The practical question for teams currently using Terraform is straightforward: if you are not offering Terraform-as-a-service commercially and you are not at a cloud provider, BSL does not restrict you. Most enterprise users are unaffected. The license change matters most to companies that want to build managed Terraform services — and for them, OpenTofu is the obvious path.

Redis: The Fork That Moved Fastest

The Redis license change was the most dramatic in terms of speed and breadth of response. Within a week of the March 2024 announcement, AWS, Google Cloud, Oracle, and Alibaba Cloud had all committed engineering resources to Valkey — a Linux Foundation fork of Redis 7.2.4, the last version under the old BSD license. The Valkey GitHub repository had more contributors in its first month than most open source projects accumulate in years.

Redis Ltd. (the company, distinct from the Redis project) has maintained that Redis was never truly "community open source" in the same way as Linux or PostgreSQL — it was always controlled by the company. This is technically true: Redis Ltd. owned the copyright, required a CLA for contributions, and made all major architectural decisions. The BSD license was a business choice, not a founding principle. When the business calculus changed — specifically, when AWS ElastiCache and other managed Redis services grew large enough to meaningfully reduce Redis Ltd.'s addressable market — the license changed.

Valkey 7.2 is now the default Redis-compatible offering on multiple major cloud platforms. For new projects starting today, the practical choice is between Valkey (Linux Foundation, Apache 2.0, cloud-native support) and Redis 7.4+ (SSPL, Redis Ltd., commercial licensing for managed services). Both are mature, both are performant, and the API is nearly identical. The ecosystem is splitting.

Elastic: The Older Case That Now Looks Like the Template

Elastic's 2021 license change was the earliest and in some ways the clearest case. Elastic moved Elasticsearch and Kibana to SSPL in direct response to Amazon offering a managed Elasticsearch service — Amazon Elasticsearch Service — without substantial contributions back to the project. Amazon's response was to fork Elasticsearch 7.10 (the last Apache 2.0 version) and create OpenSearch, which it now maintains and has contributed to the Linux Foundation.

Four years on, OpenSearch has diverged meaningfully from Elasticsearch. AWS ships features in OpenSearch that have no Elastic equivalent, and Elastic has shipped features in Elasticsearch not in OpenSearch. The two are no longer drop-in compatible for advanced use cases. Teams choosing between them today are effectively choosing between two different products that share a common ancestor, not between "the real thing" and "a fork."

The Open Core Model and Its Limits

The companies that have avoided this dynamic most successfully are those that built open core models from the beginning rather than relying on permissive licenses for popular products they hoped to monetize later. GitLab, Grafana, and HashiCorp's own Vault are examples where the core product is open source but substantial enterprise features (SSO, audit logging, advanced RBAC, compliance tooling) are commercial-only. This creates clear value capture without restricting the community use that drives adoption.

The license-change path — releasing under a permissive license, building massive adoption, then switching to a more restrictive license once a cloud provider is competing — is increasingly seen as a one-way door. Once a community fork exists and has institutional backing, the original project has lost the community goodwill that permissive licensing was generating. It is left with the commercial business, but without the "open source project everyone uses" positioning that drove it.

For developers and infrastructure teams, the practical takeaway is: treat any open source project controlled by a single company with a CLA requirement as potentially proprietary. The license you see today may not be the license that governs the software in three years. The safest open source software, from a licensing risk perspective, is owned by a foundation (Linux Foundation, Apache Software Foundation, CNCF) or has genuine distributed governance rather than single-company control.

What Comes Next

The license wars are not over. Several other widely used infrastructure projects — maintained by well-funded companies with cloud provider competition — face similar dynamics. The companies have watched what happened to HashiCorp, Redis, and Elastic and are making licensing decisions accordingly.

One emerging model: dual licensing from day one, where the software is available under both an open source license for community use and a commercial license for production enterprise use, with clear boundaries that do not shift retroactively. Another: foundation ownership from inception, with no single company controlling the license. Neither model perfectly solves the fundamental tension between open source adoption dynamics and commercial software monetization — but both avoid the trust damage that comes from changing licenses after the community has already built on your software.