The concept of vendor lock-in existed for many years; organizations chose commercial, and in many cases expensive license to use proprietary software products to run their production workloads.
In the past, there was the notion that using a product from a well-known vendor was the best solution, due to support, a large customer base, and, as the famous quote says, "Nobody gets fired for buying IBM."
This was all true for decades, but as the software world matured, organizations began migrating workloads to the public cloud and began building modern or cloud-native applications based on open-source alternatives.
In this blog post, I will discuss some of the well-known case studies of switching from commercial products to open-source.
From Elasticsearch to OpenSearch
Elasticsearch is a distributed search and analytics engine that stores data as JSON documents and lets you run fast full‑text search, aggregations, and log or metrics analysis across large datasets.
Elasticsearch, prior to 7.11, used Apache License 2.0, a permissive license allowing commercial use, modification, and distribution with minimal restrictions.
In January 2021, Elastic announced that starting with version 7.11, it would be relicensing its Apache 2.0 licensed code in Elasticsearch to be dual licensed under SSPL (Server-Side Public License) and the Elastic License, a strong copyleft license that requires anyone offering the software as a service to open-source the entire service stack.
In August 2024, the GNU Affero General Public License was added to Elasticsearch version 8.16.0 as an option, making Elasticsearch free and open-source again.
Elastic argued that large cloud providers were taking the open‑source Elasticsearch, offering it as a commercial managed service (e.g., Amazon Elasticsearch Service) and capturing much of the value without sufficient reciprocity.
The license change was positioned as protecting Elastic’s SaaS/Elastic Cloud business and long‑term sustainability.
OpenSearch was launched by AWS and partners as a fork later in 2021, based on Elasticsearch 7.10 and Kibana 7.10, the last Apache‑2.0 versions.
Today, OpenSearch is no longer just an AWS side‑project; it is governed by the OpenSearch Software Foundation, a Linux Foundation project that provides vendor‑neutral governance and long‑term stewardship. Premier foundation members include AWS, SAP, and Uber, all of whom either run OpenSearch in production, build products on top of it, or contribute engineering resources.
Among the benefits of switching to OpenSearch:
- Licensing - OpenSearch is Apache 2.0, so there are no SSPL/Elastic License obligations or restrictions on offering it as a managed service or embedding it in SaaS products.
- Vendor neutrality - OpenSearch’s open ecosystem (self‑managed on Kubernetes/VMs or via providers like Amazon OpenSearch Service and others) reduces dependence on a single vendor and improves negotiating leverage.
- Migration - OpenSearch was designed as a near drop‑in replacement for Elasticsearch 7.10, so many clients, APIs, and index formats are compatible, which lowers migration effort and risk.
- Scalability - OpenSearch retains Elasticsearch’s horizontally scalable architecture and adds features like vector search, observability improvements, and integrations driven by a multi‑vendor community, not just one company’s roadmap.
From Terraform to OpenTofu
HashiCorp Terraform is an infrastructure as code tool that lets you define, provision, and manage cloud and on‑prem resources using declarative configuration files, enabling consistent, repeatable deployments across multiple providers.
HashiCorp announced the Terraform license change in August 2023, and it applies starting with versions after 1.5.x (i.e., from 1.6 onward).
Terraform was originally licensed under the Mozilla Public License 2.0 (MPL 2.0), a weak copyleft license requiring modifications to licensed files to be open-sourced while allowing proprietary code alongside, and was then relicensed to the Business Source License (BSL/BUSL 1.1), which is a source‑available but not OSI‑approved open‑source license, introduced to restrict certain commercial/competitive uses while remaining free for typical internal infrastructure use.
HashiCorp stated it wanted to prevent other companies, particularly cloud vendors and platforms, from offering competing managed services built directly on top of Terraform without commercial agreements, arguing this threatened HashiCorp’s ability to invest in the product.
The move was framed as protecting the “commercial viability” of Terraform and other HashiCorp tools, but triggered ecosystem concerns over neutrality, long‑term trust, and vendor lock‑in.
In response, a group of companies and maintainers drafted the “OpenTF” manifesto and, after HashiCorp declined to revert or donate Terraform to a foundation, forked the last MPL‑licensed version (1.5.6) into a new project later named OpenTofu, donated it to the Linux Foundation, and committed to keeping it under MPL 2.0 with neutral, community‑first governance. OpenTofu fork announced in 2023, GA in 2024.
The founding vendors behind OpenTofu include Gruntwork, Spacelift, Harness, env0, and Scalr, all of whom depended heavily on open Terraform and now fund or employ core maintainers for OpenTofu.
Among the benefits of switching to OpenTofu:
- Licensing - OpenTofu keeps the original MPL 2.0 open‑source license, so there are no "source‑available" or BSL terms restricting competitive SaaS or internal platform use.
- Vendor neutrality - OpenTofu is governed under a neutral foundation, not a single commercial vendor, which lowers the risk that future business decisions (price, license, roadmap) will disrupt users.
- Migration - OpenTofu is intentionally Terraform‑compatible (config syntax, state format, providers), so most organizations can switch with minimal changes to modules, backends, and pipelines.
- Community‑driven features and transparency - OpenTofu’s roadmap and code are driven by a broad contributor base, so features like client‑side state encryption and other safety improvements tend to align closely with practitioner needs.
From Redis to Valkey
Redis is an in-memory key–value data store that can act as a database, cache, and message broker, optimized for extremely low‑latency reads and writes and supporting rich data structures like strings, lists, sets, and hashes.
Redis changed its license in March 2024, moving from the BSD‑3‑Clause open‑source license to a dual "source‑available" model using the Redis Source Available License v2 (RSALv2), a source-available license that permits use, modification, and redistribution but restricts offering the software as a competing managed service, and the Server-Side Public License (SSPLv1), primarily to stop cloud providers from offering Redis as a managed service without paying or sharing more of their own code and revenue with Redis Ltd.
In response, in 2024, major contributors and users of Redis—including engineers from AWS, Alibaba, Google, Ericsson, Huawei, Tencent, Oracle and others—took the last BSD‑licensed Redis 7.2.4 code, forked it under the new name Valkey, and placed it in a Linux Foundation–governed project to preserve a fully open, high‑performance in‑memory key–value store that remains free from vendor lock‑in and can be safely embedded in cloud platforms, SaaS products, and managed services.
Valkey uses the BSD 3‑Clause license, which is a permissive, OSI‑approved open‑source license that allows free use, modification, and redistribution, including in commercial and cloud/SaaS offerings.
Among the benefits of switching to Valkey:
- Licensing - Valkey keeps a permissive BSD‑3‑Clause license, so teams avoid Redis’s newer source‑available terms and can freely offer Valkey as a managed service or embed it in SaaS without SSPL‑style obligations or commercial negotiations.
- Vendor neutrality - Valkey is governed under a neutral foundation with a multi‑vendor contributor base, which reduces dependence on a single company’s business decisions and gives organizations more confidence in long‑term roadmap stability.
- Migration - Because Valkey started from the last BSD‑licensed Redis 7.2 codebase, existing clients, data structures, and usage patterns generally continue to work with minimal changes, making migrations relatively low‑risk.
- Scalability - Valkey’s roadmap emphasizes core engine efficiency (e.g., improved multithreading, better memory usage, and clustering enhancements), so many users get similar or better performance and scalability for classic caching and queueing workloads without paying for an enterprise Redis tier.
Summary
Migrations from Elasticsearch to OpenSearch, Terraform to OpenTofu, and Redis to Valkey all stem from the same story: vendors tightened licenses to protect their commercial cloud offerings, and the ecosystem responded by creating fully open forks that restore freedom to run, modify, and offer these technologies as services.
These community‑governed projects preserve familiar APIs and architectures while removing restrictive licenses, so customers keep the functionality they rely on and gain long‑term legal clarity and vendor‑neutral governance.
For users, the benefits include reduced lock‑in, simpler compliance, and the ability to standardize on open cores that any provider can host, extend, and support, rather than being bound to a single company’s roadmap or pricing.
All of these points are in the same direction: the future of core cloud‑native tools lies in truly open‑source projects backed by strong communities and foundations, not in proprietary products pretending to be open, so organizations get more control, stronger resilience, and real choice in how they run their infrastructure.
About the author
Eyal Estrin is a seasoned cloud and information security architect, AWS Community Builder, and author of Cloud Security Handbook and Security for Cloud Native Applications. With over 25 years of experience in the IT industry, he brings deep expertise to his work.
Connect with Eyal on social media: https://linktr.ee/eyalestrin.
The opinions expressed here are his own and do not reflect those of his employer.
Top comments (0)