From BSL Shockwaves to State Encryption: OpenTofu's Open-Source Stand and Technical Breakthrough

In the Infrastructure as Code (IaC) landscape, HashiCorp released Terraform in 2014, and it served as the de facto control plane standard for years. Powered by the declarative HashiCorp Configuration Language (HCL) and a plugin-driven architecture, it laid the foundation for modern multi-cloud orchestration.

However, on August 10, 2023, HashiCorp announced a shift in its core licensing: projects across its portfolio, including Terraform, would move away from the permissive Mozilla Public License 2.0 (MPL 2.0) to the commercially restrictive Business Source License 1.1 (BSL 1.1).

This shift sent shockwaves through the automation ecosystem built around Terraform. Determined to preserve an open-source standard, the community initiated a fork within weeks, establishing OpenTofu under the stewardship of the Linux Foundation.

The Licensing Pivot: BSL Shockwaves and the TACOS Commercial Squeeze

Before the license change, Terraform operated under the weak copyleft MPL 2.0. This license allowed individuals and enterprises alike to use the code commercially, distribute binaries, and even bundle it into proprietary software at zero cost—requiring only that modifications to the MPL-licensed source files themselves remain public. This freedom fueled a massive global ecosystem.

HashiCorp’s transition to BSL 1.1 introduced three core mechanics: source code remains publicly viewable, a change date automatically reverts the code to an open-source license after four years, and—most controversially—an Additional Use Grant imposing explicit commercial restrictions.

The clause explicitly stated that licensees may not use the software to provide hosted services or commercial products that are in “substantial competition” with HashiCorp’s own commercial offerings.

The Open Source Initiative (OSI) promptly pointed out that BSL violates Criterion 6 of the Open Source Definition—“No Discrimination Against Fields of Endeavor.” Consequently, BSL is classified as a “Source-Available” license, not open source.

HashiCorp’s pivot stemmed from commercial pressure exerted by its surrounding ecosystem. Terraform is fundamentally a local CLI tool; team collaboration relies on remote state storage and automated CI/CD pipelines.

This dynamic sparked an entire category of platforms dedicated to remote state coordination and environment management, collectively known as TACOS (Terraform Automation and Collaboration Software), spearheaded by vendors such as Spacelift, env0, Scalr, and Gruntwork.

These vendors built commercial platforms around the open-source Terraform CLI that rivaled or even surpassed Terraform Cloud in capability and flexibility. Meanwhile, public cloud hyperscalers drove immense infrastructure consumption via community providers without contributing licensing fees to HashiCorp.

Facing profitability pressures in public markets, HashiCorp concluded that commercial partners were “free riders” and leveraged licensing restrictions to directly neutralize competitors.

Yet, while the clause ostensibly targeted competing TACOS vendors, it triggered widespread panic among enterprise users. Because HashiCorp retained unilateral authority to define “substantial competition,” internal developer platforms (IDPs), operations scripts delivered by external consultants, and managed service providers (MSPs) were all suddenly pushed into a murky legal gray area.

The OpenTF Manifesto and Foundation Stewardship: Returning Control to the Community

Confronted with licensing pressure from a single commercial entity, ecosystem vendors recognized that resistance required institutional backing. On August 15, 2023—just five days after HashiCorp’s announcement—teams from Gruntwork, Spacelift, env0, Scalr, and Harness published The OpenTF Manifesto.

The manifesto called on HashiCorp to reverse its decision, pledging that if no positive response was received by a set deadline, the community would formally fork the project and donate it to a neutral foundation under a permanent open-source commitment. Within weeks, the manifesto gathered endorsements from over 140 companies and more than 600 engineers.

In early September 2023, after the community confirmed that HashiCorp had no intention of reconsidering, the fork was formally launched. To avoid trademark liabilities, the community moved past “Terraform” and the interim name “OpenTF,” settling on OpenTofu on September 20, 2023, as it officially joined the Linux Foundation.

Joining the Linux Foundation carried critical strategic weight: intellectual property and trademarks were transferred to a neutral, non-profit entity, ensuring no single sponsor could alter the license down the road. The project adopted MPL 2.0 and plugged directly into the Cloud Native Computing Foundation (CNCF) ecosystem.

For governance, OpenTofu established a Technical Steering Committee (TSC) with seats distributed across participating vendors and independent maintainers. Major functional changes were placed under a public Request for Comments (RFC) process, open to community review worldwide.

Preserving the Ecosystem: Binary Compatibility, a Community Registry, and Defusing Copyright Disputes

Terraform’s greatest asset was its thriving ecosystem, spanning thousands of providers and public modules globally. To gain its footing, OpenTofu had to deliver 100% technical compatibility.

Architecturally, Terraform’s core engine and provider plugins operate independently rather than compiling into a single binary. They run as separate local processes that are physically isolated and communicate over inter-process communication (IPC).

The core and providers communicate via Unix domain sockets—or local TCP loopback connections on Windows—using HashiCorp’s go-plugin framework with gRPC protocols and standard Protobuf interfaces.

Because communication occurs purely over network protocols, providers do not care whether their counterpart is Terraform or OpenTofu. As long as OpenTofu maintains strict compatibility with plugin protocol Versions 5 and 6, Terraform provider binaries maintained by cloud vendors or the community run directly on OpenTofu without needing recompilation, preserving the underlying ecosystem intact.

Yet binary compatibility solved the execution problem; the distribution channel hit an immediate roadblock. On August 24, 2023, HashiCorp updated the Terms of Use for the official Terraform Registry, stipulating that registry content was “solely for use with, or in support of, HashiCorp Terraform”—effectively locking out forked projects and third-party clients.

If OpenTofu queried the official registry by default, it risked direct legal liability; but without provider downloads, running tofu init would fail immediately.

Faced with this distribution barrier, the OpenTofu team executed a dual-track strategy:

First, the team launched an independent, neutral registry at registry.opentofu.org. Instead of proxying HashiCorp traffic, the registry directly tracks provider release artifacts from public sources like GitHub Releases. The OpenTofu CLI transparently remaps provider lookups behind the scenes, allowing existing configurations referencing hashicorp/aws to resolve without any manual edits, bypassing the official registry’s restrictive terms.

While the first track secured the public ecosystem, the second track modernized enterprise artifact management. In OpenTofu 1.10, the team adopted Open Container Initiative (OCI) standards, supporting module distribution as container artifacts per the OCI Distribution Spec, with providers additionally available as a secondary installation source via oci_mirror:

module "vpc" {
  source = "oci://ghcr.io/my-org/infrastructure-modules/vpc?tag=v1.2.0"
}

This architecture allows enterprises to reuse existing internal container registries (such as Harbor, GitHub Packages, or AWS ECR) without standing up dedicated IaC registry servers.

Beyond distribution hurdles, the fork also had to withstand legal battles over copyright. OpenTofu branched from Terraform code while it was still licensed under MPL 2.0 (1.5.7 being the final MPL 2.0 stable release) and maintained strict clean-room firewalls for all contributors.

However, following the switch to BSL, HashiCorp introduced the removed block syntax in Terraform 1.7 to mark deleted resources. When OpenTofu subsequently implemented compatible functionality, HashiCorp issued a cease-and-desist (C&D) letter in April 2024, alleging that a core OpenTofu developer copied and improperly used BSL-licensed code.

In response, the OpenTofu team, supported by Linux Foundation legal counsel, publicly released a detailed code provenance report, whose line-by-line analysis demonstrated that their implementation evolved from the earlier moved block mechanism, successfully defusing the legal threat.

Closing the Core Security Gap: Client-Side State Encryption in OpenTofu 1.7

In declarative IaC architectures, the state file (terraform.tfstate) acts as the single source of truth for managed infrastructure. However, state files have long harbored a severe security vulnerability: all sensitive values are stored in plaintext JSON.

Database administrator passwords, TLS private keys, cloud API credentials—all sit exposed in cleartext. Previously, the standard recommendation was to rely on bucket-level server-side encryption (SSE, such as in AWS S3). Yet SSE only protects data at rest against stolen physical drives; any engineer or CI/CD pipeline with bucket read access can download the file and read every secret in plaintext.

Released on April 30, 2024, OpenTofu 1.7 introduced a long-awaited milestone: native client-side state and plan encryption.

This framework implements a decoupled three-tier model inside the core engine, guaranteeing that state data is fully encrypted before leaving local memory:

 +----------------------------------------------------+
 | 1. Key Providers (AWS KMS, GCP KMS, Vault, PBKDF2) |
 +----------------------------------------------------+
                           | provides keys / KEK
                           v
 +----------------------------------------------------+
 | 2. Encryption Methods (AES-GCM-256, unencrypted)   |
 +----------------------------------------------------+
                           | applies cipher to target
                           v
 +----------------------------------------------------+
 | 3. Consumers (state, plan, remote_state)           |
 +----------------------------------------------------+

1. Key Providers: Interface with key management backends, including AWS KMS, GCP KMS, Azure Key Vault, OpenBao (compatible with Vault 1.14 MPL), and local PBKDF2.
2. Encryption Methods: Define cryptographic algorithms, chiefly AES-GCM-256 with authenticated tag verification for payload integrity.
3. Consumers: Specify targets for encryption, covering standard state files (state), binary execution plans (plan), and cross-configuration references (remote_state).

In cloud KMS integrations, encrypting an entire state file directly via KMS calls introduces performance bottlenecks, as KMS APIs have strict payload size limits and incur network latency per operation. To solve this, OpenTofu adopted industry-standard envelope encryption:

 +----------------------------------------------------+
 | Write:                                             |
 | 1. Request DEK from KMS via KEK                    |
 | 2. Encrypt state payload with plaintext DEK (AES)  |
 | 3. Discard plaintext DEK from memory               |
 | 4. Store [Encrypted DEK + Ciphertext + IV] to S3   |
 +----------------------------------------------------+
                           |
                           v
 +----------------------------------------------------+
 | Read:                                              |
 | 1. Fetch envelope package from remote backend      |
 | 2. Decrypt encrypted DEK via KMS KEK               |
 | 3. Decrypt state payload with DEK in memory        |
 +----------------------------------------------------+

Under this architecture, OpenTofu calls cloud KMS to generate an ephemeral, randomly generated Data Encryption Key (DEK). It then leverages the CPU’s hardware acceleration instructions (such as AES-NI) to run AES-GCM state encryption locally at high speed with the plaintext DEK.

Once encryption completes, OpenTofu saves only the envelope—containing the DEK encrypted under the KMS-managed Key Encryption Key (KEK) alongside the ciphertext—to the remote backend. The plaintext DEK is immediately wiped from memory and never touches disk. Users never need to manage or declare DEKs manually in HCL. This design dramatically cuts API latency and cost while preserving precise access audit trails in cloud logging services.

To ensure smooth transitions for established infrastructure, OpenTofu includes a flexible fallback mechanism, allowing configurations to read legacy unencrypted state while seamlessly upgrading writes to strong encryption:

terraform {
  encryption {
    # Declare cloud KMS key provider (KEK source)
    key_provider "aws_kms" "production_kms" {
      kms_key_id = "arn:aws:kms:us-east-1:123456789012:key/my-key-uuid"
      key_spec   = "AES_256"
      region     = "us-east-1"
    }

    # Define AES-GCM-256 symmetric encryption method
    method "aes_gcm" "prod_aes" {
      keys = key_provider.aws_kms.production_kms
    }

    # Apply to state storage and configure fallback strategy
    state {
      method = method.aes_gcm.prod_aes

      # Seamless migration: read legacy unencrypted state, encrypt automatically on write
      fallback {
        method = method.unencrypted.legacy
      }
    }

    # Optionally apply to execution plan files
    plan {
      method = method.aes_gcm.prod_aes
    }

    # Define transitional unencrypted method
    method "unencrypted" "legacy" {}
  }
}

The fallback method applies only when reading legacy state that the primary method cannot decrypt, preserving compatibility with older unencrypted files; writes always use the primary encryption method and never regress to plaintext. Once every legacy state file has been upgraded, removing fallback and setting enforced = true disallows any unencrypted method in the configuration outright.

With this “read old, write new” strategy, teams can migrate thousands of legacy state files without maintenance windows or downtime, automatically upgrading security on their next tofu apply run.

Choosing Tools in a Bifurcated Ecosystem

In April 2024, IBM announced its $6.4 billion acquisition of HashiCorp, which was completed in early 2025. Early on, the open-source community hoped IBM might reverse the BSL licensing switch and return Terraform to community stewardship. However, IBM chose to maintain the BSL framework, integrating Terraform with Red Hat Ansible into a comprehensive enterprise hybrid cloud platform.

This decision closed the door on any potential reunification, firmly establishing two distinct trajectories for the IaC ecosystem.

When evaluating tooling today, organizations can weigh the following criteria:

Both paths address different enterprise needs: Terraform leans into enterprise consolidation and vendor-backed support, while OpenTofu, backed by a neutral foundation, safeguards the open ecosystem through binary compatibility and client-side encryption.