IBM just dropped $6.4 billion to acquire HashiCorp. And the infrastructure automation world is asking: will Big Blue restore Terraform‘s open-source licence, or are we doubling down on commercial restrictions?
The acquisition closed on 27 February 2025, throwing a wild card into an already tense situation. HashiCorp’s Business Source Licence change back in August 2023 already triggered a community fork. OpenTofu emerged under Linux Foundation governance, keeping the original MPL 2.0 licence alive. Now IBM calls the shots on HashiCorp’s licencing decisions, and the community’s waiting to see which way they’ll jump.
You’ve got a choice to make: stick with Terraform, migrate to OpenTofu, or wait it out. We’re going to walk through HashiCorp’s rationale for the licence change, how the community responded with OpenTofu, where feature parity sits in 2026, what the IBM acquisition means, governance models, and how to actually migrate if you decide to.
This case study is part of our comprehensive open source licensing wars resource, where we explore how vendor-controlled open source projects are turning to restrictive licences when cloud economics squeeze their business models. The HashiCorp-OpenTofu split mirrors the broader pattern reshaping infrastructure tooling.
What Caused HashiCorp’s Licence Change from MPL 2.0 to BSL in August 2023?
On 10 August 2023, HashiCorp announced adoption of Business Source Licence 1.1 for all products. Terraform, Vault, Consul, Nomad—everything switched immediately. Existing versions stayed MPL 2.0 under perpetual licence, but going forward? BSL.
HashiCorp’s stated reason came down to revenue pressure from the cloud providers. AWS, Azure, and GCP were allegedly repackaging HashiCorp tools into managed services without contributing back. HashiCorp poured resources into developing Terraform yet struggled to monetise it profitably. As a publicly traded company with shareholder obligations, HashiCorp needed to address market dynamics.
BSL 1.1 sits in the middle ground between open source and proprietary. You can view, use, modify, and copy the code for non-production purposes, but commercial production use is restricted. You can’t offer Terraform as a competitive service, use it in products that compete with HashiCorp, or repackage and redistribute it commercially. The code’s visible but usage is restricted—that’s source-available, not open-source.
The licence includes a time-delayed conversion mechanism. BSL automatically converts to GPL-compatible open source within four years after release. Software licenced under BSL on 1 January 2025 must convert to GPL-compatible by 1 January 2029.
HashiCorp wasn’t alone in this. Redis, MongoDB, Elasticsearch, CockroachDB—they all went source-available. AWS alone controls 32% of the cloud market and can outspend infrastructure startups on managed services all day long. The challenge facing open-source infrastructure companies is explored in depth in our analysis of cloud provider economics and open source sustainability: how do you capture value when hyperscale cloud providers can commoditise your work overnight?
For most Terraform users, the immediate impact was minimal. If you’re just deploying infrastructure—not building a competitive product—BSL doesn’t restrict you. But long-term concerns started bubbling up. Vendor lock-in risk, potential future restrictions, loss of community control. Trust eroded. Single-vendor control means future licence changes are always on the table.
How Did the Community Respond with the OpenTofu Fork Under Linux Foundation Governance?
Within weeks of the BSL announcement, the community organised a response. A coalition of 140+ companies and contributors formed around returning to MPL 2.0 and ensuring permanent open-source status. The fork decision came together in September 2023.
They called it OpenTofu. Five principles drove it: truly open-source under MPL 2.0, community-driven development with no single vendor calling the shots, Linux Foundation neutral stewardship, backwards compatibility as a drop-in replacement, and a fair contribution model.
OpenTofu operates under MPL 2.0 open-source licence, enabling community-driven development. The Linux Foundation adopted the project in September 2023. Under Cloud Native Computing Foundation stewardship, OpenTofu became a CNCF project with formal governance protections.
The Technical Steering Committee structure matters here. The TSC requires multi-company representation with no single vendor controlling more than 50% of seats. Contributors elect members annually. The TSC controls the technical roadmap, feature priorities, and architecture. All meetings are public. Consensus-based governance prevents unilateral changes.
This governance structure means OpenTofu cannot unilaterally change licence like HashiCorp did. The Linux Foundation owns the copyright—not a single vendor. The OpenTofu trademark prevents hostile takeover.
Major infrastructure platforms backed the fork. Gruntwork, Spacelift, env0, Scalr, and Harness all pledged support. Oracle Cloud Infrastructure joined. These major IaC tooling vendors betting on OpenTofu’s viability sent a market signal.
OpenTofu began mirroring Terraform closely as a drop-in replacement. First stable release came in January 2024—OpenTofu 1.6.0. Monthly releases followed with 100+ contributors joining in six months.
Official documentation covers all use cases. Provider registry compatibility means 3,000+ providers work with both tools. Migration guides provide step-by-step walkthroughs. The governance structure demonstrates the Linux Foundation model that prevents vendor control—a contrast to the single-vendor control that triggered the HashiCorp licence crisis.
Terraform vs OpenTofu Feature Parity Analysis in 2026—Which Tool Wins?
With both tools under active development in 2026, teams evaluating the fork need to understand what each brings to the table. OpenTofu maintains 100% command compatibility with Terraform. Commands like terraform init, terraform plan, and terraform apply work identically when you swap in the opentofu binary. HCL configuration language syntax is identical—no rewrites needed. Provider interface is shared, so 3,000+ providers work with both.
Where they differ matters for specific use cases.
Licencing: Terraform uses BSL 1.1 source-available. OpenTofu uses MPL 2.0 open-source. OpenTofu wins on licence freedom.
Governance: Terraform is HashiCorp/IBM-controlled. OpenTofu is Linux Foundation/CNCF governed. OpenTofu wins on neutral governance.
State Encryption: Terraform requires Vault or encrypted S3. OpenTofu provides native end-to-end encryption. This was a feature the Terraform community requested for the last five years but never received. OpenTofu wins here.
State files contain sensitive data—API keys, database passwords, infrastructure topology. Platform teams managing multi-tenant environments or operating under strict compliance regimes like HIPAA, SOC 2, or PCI-DSS need encryption by default. OpenTofu’s built-in encryption reduces the security surface area and simplifies compliance. No Vault dependency required.
Provider Ecosystem: Both share 3,000+ official providers. Tie.
Commercial Support: Terraform offers HashiCorp enterprise support. OpenTofu offers multiple vendor options through Spacelift, env0, and Gruntwork. Tie.
Early Variable Evaluation: Terraform doesn’t have it. OpenTofu 1.8 enables variables and locals within terraform blocks and module sources. OpenTofu wins.
Documentation: Terraform has 10+ years of maturity. OpenTofu is growing rapidly after 2+ years. Terraform wins on depth.
Enterprise Features: Terraform Cloud provides SaaS including Sentinel policy-as-code, remote operations, state management, team collaboration, and cost estimation. OpenTofu relies on self-hosted plus third-party platforms. Context-dependent.
Community Size: Terraform is larger with a 10-year head start. OpenTofu is growing with broad industry backing. Terraform wins for now.
OpenTofu’s faster release cycle shows in monthly feature releases versus Terraform’s quarterly major releases. Under IBM, Terraform’s cadence may slow further.
The long-term compatibility question looms. Today in 2026, feature parity sits at 95%+ with shared providers. But looking at 2027-2028, you can see inevitable divergence as the tools pursue different priorities. OpenTofu can read Terraform state files directly but the reverse isn’t guaranteed. Once you migrate to OpenTofu and use OpenTofu-specific features like native encryption, rolling back becomes complex.
The IBM Acquisition Wild Card—What Will Big Blue Do With HashiCorp’s Licence?
IBM completed the acquisition of HashiCorp on 27 February 2025 for $35 per share in cash, representing $6.4 billion enterprise value. The acquisition rationale centres on strengthening IBM’s hybrid cloud portfolio and integrating with Red Hat Ansible. Nearly 75% of enterprises operate hybrid cloud environments—IBM’s target market.
HashiCorp’s infrastructure automation tools—particularly Terraform and Vault—will integrate with IBM’s existing portfolio. These products complement Red Hat’s Ansible Automation Platform. By 2028, generative AI is projected to drive creation of one billion cloud-native applications, intensifying demand for infrastructure automation at scale.
The acquisition announcement generated a sceptical reception in developer communities.
Three possible strategies emerge.
Strategy 1: Restore MPL 2.0. Red Hat maintained its open-source ethos after IBM’s 2019 acquisition. Likelihood: 30%. This would require admitting BSL was a mistake. Impact: OpenTofu becomes redundant as the community reunites.
Strategy 2: Maintain BSL. IBM’s software business still uses commercial licencing. Likelihood: 50%. This is conservative and low-risk. Impact: OpenTofu continues growing as the open-source alternative.
Strategy 3: Hybrid Model. Dual licencing following MySQL‘s pre-Oracle GPL/commercial model. Likelihood: 20%. This is complex to execute. Impact: market fragments further.
Those probability estimates reflect current market signals, IBM’s historical acquisition patterns, and OpenTofu’s competitive momentum as of February 2026.
IBM’s acquisition of Red Hat in 2019 shows what IBM got right and where they stumbled.
What IBM got right: Red Hat maintains independent branding and culture. RHEL is still based on CentOS Stream. Fedora and Ansible communities remain healthy. IBM allowed Red Hat’s independent culture to flourish.
Where IBM stumbled: the 2020 CentOS Linux discontinuation angered the community, leading to AlmaLinux and Rocky Linux forks. Mixed signals emerged about whether IBM prioritises commercial interests despite open-source rhetoric.
Applying Red Hat lessons to HashiCorp gives us three scenarios. Best case: IBM treats HashiCorp like Red Hat with independent operation and eventual licence restoration. Worst case: IBM treats it like Watson acquisitions with tight integration and commercial focus. Realistic case: hybrid approach maintaining BSL short-term while evaluating based on OpenTofu threat.
IBM has 16 open engineering requisitions for Vault and Terraform teams, indicating they’re planning to increase development velocity.
Watch for these signals. Signs IBM might restore MPL 2.0: public statements emphasising open-source values, Jim Whitehurst involvement in HashiCorp integration, community outreach and governance discussions. Signs IBM will maintain BSL: silence on licencing questions, focus on Terraform Enterprise commercial features, integration with IBM’s commercial stack.
Don’t wait for IBM’s entire evaluation process. They may take 12-18 months to clarify strategy. Test OpenTofu in parallel to minimise risk while gaining optionality. Do scenario planning that prepares for multiple outcomes.
Governance Showdown—Technical Steering Committee vs Corporate Control
Beyond technical features, the governance model determines who controls your infrastructure’s future. OpenTofu operates under Linux Foundation governance with a Technical Steering Committee drawn from multiple organisations. Decisions happen in public. HashiCorp controls Terraform’s roadmap, prioritisation, and contribution acceptance.
The Technical Steering Committee has 9-11 elected members from contributing organisations. No single company controls more than 50% of seats. Contributors vote annually. The TSC controls technical roadmap and architecture. All meetings and GitHub discussions are public.
The Linux Foundation provides neutral hosting, infrastructure, legal framework, and brand protection. Copyright is owned by the foundation, not a vendor. Trademark protection prevents hostile takeover.
For you as a user, this means licence stability. OpenTofu’s governance provides the structural protections outlined in our comprehensive guide to open source governance models. The community has veto power where major changes require consensus, not top-down decree. Contributor equality means all contributions are judged on merit, not company affiliation.
HashiCorp’s corporate control model works differently. The CEO and Board set strategic direction. Shareholder primacy means decisions optimise for IBM investor returns. Top-down roadmap prioritises commercial features. Community feedback is advisory only, not binding.
Historical precedent speaks volumes. The BSL change was announced without community consultation. Terraform Cloud focus prioritises commercial features over open-source core.
For you, this creates licence uncertainty. IBM can change terms at will. Commercial prioritisation means features that drive Terraform Cloud revenue come first.
OpenTofu guarantees licence stability by charter. Terraform’s licence serves business needs. OpenTofu provides binding community voting. Terraform offers advisory feedback only. OpenTofu decisions require consensus. Terraform uses executive decree. OpenTofu guarantees vendor neutrality. Terraform depends on IBM philosophy. OpenTofu offers multi-vendor support. Terraform provides single-vendor accountability.
Why does governance matter? IaC codebases live 5-10+ years. Migration costs are expensive. Licence changes can block operations.
Open-source provides insurance. MPL 2.0 allows community fork if OpenTofu pivots. Multiple support vendors prevent single vendor lock-in. Ecosystem diversity ensures sustainability.
For platform teams burned by the licence change, structural guarantee matters more than any technical feature.
Migrating from Terraform to OpenTofu Without Breaking Infrastructure
If you’re choosing OpenTofu based on governance or licencing concerns, understanding the migration path reduces perceived risk. Command-line compatibility means commands work identically between tools. For most codebases, migration centres on replacing the Terraform binary with OpenTofu, updating CI/CD pipelines, migrating state files, and verifying provider compatibility.
Organisational Planning
Team preparation matters more than technical complexity. Update documentation before migration—rewrite runbooks and guides before cutover. Run overview sessions covering OpenTofu’s compatibility and governance. Plan two weeks for technical migration plus two weeks for adoption.
Risk management requires rollback procedures. Maintain Terraform binaries and state backups for 30 days post-migration so you can roll back cleanly if needed.
Technical Complexity Assessment
Project size determines timeline expectations. Small projects under 10 resources take 1-2 days. Medium projects with 10-100 resources take 1 week. Large projects with 100+ resources and multiple environments take 2-4 weeks. Enterprise with 1,000+ resources takes 4-8 weeks.
State backend considerations vary by platform. S3, Azure Blob Storage, and GCS are fully compatible. Terraform Cloud is not compatible because it’s proprietary—you’ll need to migrate to an alternative backend. Migrating from Terraform Cloud requires exporting state and configuring a new backend like S3.
Provider compatibility checking happens in staging environments first. Most providers work identically since both tools use the same provider protocol. The OpenTofu registry is compatible with Terraform’s provider ecosystem.
Migration Timing
Pilot on non-critical infrastructure—test OpenTofu on development environments before production. Run OpenTofu plan on staging and verify no unexpected changes. Once you use OpenTofu-specific features like native encryption, rolling back becomes complex. Treat migration as a one-way door.
For comprehensive migration decision frameworks and risk assessment methodologies, see our detailed migration and risk assessment playbook for CTOs. Official OpenTofu migration documentation provides detailed technical guidance.
What Comes Next—Predicting IBM’s Strategic Direction for Terraform and OpenTofu
Having evaluated the technical and governance landscape, the remaining question is IBM’s next move. The 12-18 month outlook breaks into four scenarios.
Best Case: IBM Restores Open Source (20% probability). Trigger: IBM leadership recognises BSL damaged community trust. Action: announce MPL 2.0 restoration for Terraform. Impact on OpenTofu: reduced urgency but continued existence as insurance policy. Your response: you can safely return to Terraform but maintain OpenTofu testing cadence.
Base Case: Status Quo Continues (50% probability). Trigger: IBM takes “wait and see” approach. Action: maintain BSL and focus on Terraform Enterprise revenue. Impact on OpenTofu: continued growth as open-source alternative. Your response: migration to OpenTofu becomes increasingly attractive.
Worst Case: Increased Restrictions (20% probability). Trigger: IBM tightens BSL interpretation. Action: clarify “competitive use” definition and restrict more use cases. Impact on OpenTofu: accelerated migration. Your response: immediate migration planning becomes necessary.
Wild Card: IBM Discontinues Terraform (10% probability). Trigger: IBM decides to sunset Terraform in favour of Ansible-based IaC. Action: announce deprecation timeline. Impact on OpenTofu: becomes de facto standard. Your response: OpenTofu migration becomes mandatory.
Migrate to OpenTofu now if you value open-source licence stability over vendor relationship, your organisation has OSPO requirements, native state encryption solves compliance challenges, you’re concerned about IBM’s long-term Terraform commitment, you have 2-4 weeks for a migration project, or multi-vendor support options matter to you.
Stay with Terraform if you have an existing HashiCorp Enterprise Agreement with favourable terms, deep integration with Vault, Consul, and Nomad is required, Terraform Cloud features like Sentinel and remote operations are needed, risk tolerance for vendor lock-in is high, your team prefers mature documentation and larger community, or waiting for IBM strategic clarity is acceptable.
The hybrid approach is recommended. Run OpenTofu in development and staging. Maintain Terraform in production short-term. Test feature parity quarterly. Build capability with both tools. Retain flexibility to switch based on IBM’s actions.
Q2-Q3 2026 represents a key period. Watch IBM Developer Conference keynotes on HashiCorp integration. Monitor Red Hat Summit discussions on Ansible plus Terraform or OpenTofu. Pay attention to HashiConf 2026 licencing announcements.
Market signals matter. OpenTofu adoption metrics show growth through GitHub stars, downloads, and corporate backing. Terraform Cloud revenue indicates whether BSL works. IBM executive statements signal direction.
The long-term outlook for 2027-2030 suggests Terraform and OpenTofu will coexist as stable alternatives. Provider ecosystem remains compatible. Enterprise market splits: IBM and HashiCorp customers stay with Terraform, open-source advocates choose OpenTofu. Both tools remain viable with choice driven by governance philosophy versus vendor relationship.
Don’t treat this as a binary choice. Build organisational capability with both tools. The cost of migration proficiency is lower than the risk of backing the wrong horse. In infrastructure automation, optionality is worth the investment.
The IBM acquisition creates uncertainty in IaC tooling. Treat 2026-2027 as an evaluation period. Test OpenTofu seriously while monitoring IBM’s strategic signals. The “wait and see” approach only makes sense if you’re actively preparing migration capability in parallel.
The IBM wild card means you should build optionality. Test OpenTofu in non-production while monitoring IBM’s 2026 strategic announcements. Infrastructure decisions require 5-10 year timelines.
Start OpenTofu testing in your development environment this quarter. Document the migration process. Attend HashiConf 2026 to hear IBM’s vision. Make an informed decision based on governance philosophy, technical requirements, and risk tolerance—not fear or inertia.
For a comprehensive overview of how the HashiCorp case fits into the broader licensing transformation, explore our complete guide to open source licensing wars, where we examine all the major cases and provide strategic frameworks for navigating this new reality.
