The OpenTofu and Valkey Fork Story

A fork is not a protest. It is a practical answer to a licensing change, and it is the option that most directly preserves the freedom the relicense removed. The OpenTofu and Valkey forks both followed the same pattern: take the last code released under a recognized open source license, place it under a neutral foundation, and continue development in the open. Understanding how each came about, and what it does and does not solve, is essential for any buyer deciding between a fork and a commercial license.

How OpenTofu came about

As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer from an open source license to the Business Source License 1.1, which restricts competitive production use and converts to an open license after a delay, commonly four years. A group of users and vendors who depended on Terraform responded by forking the last openly licensed version and continuing it as OpenTofu under a neutral foundation. The fork preserved an openly licensed path for organizations that did not want to accept the Business Source License terms. IBM later acquired HashiCorp, which did not change the status of the fork. OpenTofu remains the community continuation of the openly licensed Terraform code.

How Valkey came about

As of March 2024, Redis moved from an open source license to a dual model that includes the Redis Source Available License and the Server Side Public License, and later added an open license option. In response, contributors forked the last openly licensed Redis code and continued it as Valkey under a neutral foundation, with backing from several large infrastructure providers. The pattern mirrors OpenTofu: preserve an openly licensed continuation so that users who cannot accept the source available terms keep an alternative. This is the same dynamic that produced OpenSearch after Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License as of 2021.

What a fork solves and what it does not

A fork solves the licensing problem cleanly. Because OpenTofu and Valkey continue under recognized open source licenses, moving to them removes the competitive use and service obligations that attach to the relicensed originals. What a fork does not remove is engineering work. A buyer still has to confirm compatibility with an existing deployment, migrate configuration and data, and accept that the fork may diverge from the original over time. The fork answer trades a licensing risk for a migration cost and a governance question about the project's direction. Those are real costs, but they are the kind a buyer can plan and bound, which is exactly what makes a fork attractive.

The mechanics of the underlying license changes are set out in the Server Side Public License explained, and the deployment patterns that decide whether you need to move at all are covered in relicensing and cloud and managed service use.

Fork or pay: how a buyer should decide

The decision between moving to a fork and paying for a commercial license is a cost to cure comparison, not an ideological one. A fork removes the licensing exposure but carries migration and divergence cost. A commercial license keeps the original you already run but locks in a price set against your usage. The right answer depends on the blast radius of the affected component, your tolerance for migration work, and the leverage your actual usage gives you at the negotiating table. The way that comparison is structured is covered in relicensing and procurement approval processes, and the wider landscape sits on the relicensing pillar.

We are independent and buyer side. We take no vendor fees and resell no software, and we do not favor a fork or a commercial license as a matter of course. We size both against your exposure and recommend the cheapest defensible path. A relicensing exposure review produces that comparison. This is commercial and licensing risk advisory, not legal advice. For interpretation of specific license terms and your compliance position, engage your own counsel.