If you have screened for an infrastructure role in the last year, you have probably noticed the phrasing change. Reqs used to just say Terraform. Now you see Terraform or OpenTofu, sometimes both in the same bullet, sometimes a vague mention of HCL-based IaC. That shift is not sloppy writing. It reflects a real licensing event that split the ecosystem, and clients are quietly screening for whether you understand why.
This matters for your next 90 days of contracting. The split changed how some organizations buy tooling, how modules get versioned, and how policy as code gets enforced. If you can speak to the mechanism instead of just repeating the headline, you separate yourself from candidates who learned the word OpenTofu from a job posting.
The licence change and the fork, factually
In August 2023, HashiCorp moved Terraform (and several other products) from the Mozilla Public License 2.0 to the Business Source License 1.1. BUSL restricts certain commercial uses, specifically competing with HashiCorp's own commercial offerings, while still allowing free use for most internal and operational purposes. It is not open source under the OSI definition, and that distinction is the whole story.
In response, a group of companies that had built businesses around Terraform tooling, including Gruntwork, Spacelift, env0, Harness, and others, forked the last MPL-licensed version of Terraform core and formed OpenTofu. The project was donated to the Linux Foundation and now runs as a Linux Foundation project with its own governance, release cadence, and contributor base.
Both tools share a common ancestor and, as of now, largely compatible HCL syntax and provider ecosystems. They have diverged in release velocity, some newer language features, and registry infrastructure. Verify current feature parity directly against the OpenTofu and Terraform changelogs before you commit to a specific claim in an interview; this area moves fast enough that a six-month-old blog post can be stale.
What reqs are actually asking for now
Read past the tool name. Most infrastructure reqs in 2025 and into 2026 are really asking about three things: module design discipline, state management maturity, and policy enforcement. The tool is almost secondary to whether you can demonstrate those three.
- Module reuse: Can you design a module with clear input variables, sensible defaults, and output contracts that a second team can consume without reading your source code?
- State backend patterns: Do you understand remote state with locking, workspace separation, and blast-radius containment, regardless of whether the backend is S3 with DynamoDB locking, Terraform Cloud, or an OpenTofu-compatible backend?
- Policy as code: Can you show how guardrails get enforced before apply, not after an incident?
A consultant who answers all three fluently, using Terraform vocabulary, will usually clear a screen that nominally asked for OpenTofu, and vice versa. Hiring managers know the skills transfer. What they are testing is whether you understand the discipline underneath the tool.
Policy as code in a mixed estate
This is where the fork creates genuine day-to-day friction. HashiCorp's policy layer, Sentinel, is tied to Terraform Cloud and Enterprise. OpenTofu does not support Sentinel. Instead, OpenTofu shops typically lean on Open Policy Agent with Conftest, or on Checkov and tfsec style static scanning run against the plan JSON output, which both tools can still produce.
If a client runs both Terraform and OpenTofu across different business units, which is increasingly common after an acquisition or a platform team split, you will likely find two parallel policy pipelines rather than one unified one. Know how to:
- Generate and parse plan JSON output consistently across both tools for a shared OPA policy set
- Explain the practical difference between policy enforced at the CI pipeline stage versus policy enforced inside a managed run environment like Terraform Cloud
- Flag where a Sentinel policy will simply not port to an OpenTofu pipeline and needs a rewrite in Rego
Naming this tension unprompted, in a screen, signals that you have actually operated in a mixed estate rather than read about one.
Drift management when you run both
Drift detection gets harder, not easier, when half your estate is on Terraform and half is on OpenTofu, especially if they point at shared cloud accounts or shared modules published to different registries. Practical patterns worth having ready to discuss:
- Running scheduled plan-only jobs on both toolchains against the same state to catch manual console changes before they compound
- Treating the public Terraform Registry and the OpenTofu Registry as separate dependency sources, and pinning module versions explicitly rather than trusting implicit compatibility
- Using a module compatibility matrix, even a simple spreadsheet, when a shared module is consumed by both Terraform and OpenTofu pipelines, since provider version constraints can diverge over time
Clients care less about which tool you prefer and more about whether drift gets caught before it becomes an incident ticket.
Quick comparison for screen prep
| Dimension | Terraform | OpenTofu |
|---|---|---|
| License | Business Source License 1.1 | Mozilla Public License 2.0 |
| Governance | HashiCorp (private, now part of IBM) | Linux Foundation project |
| Native policy as code | Sentinel (Cloud/Enterprise only) | None native; OPA/Conftest common |
| Registry | Terraform Registry | OpenTofu Registry (mirrors most public providers) |
| State backends | S3, GCS, Azure, Terraform Cloud, others | Same backend types, compatible config |
Confirm license and governance details against HashiCorp's and the Linux Foundation's own published statements before quoting them verbatim; both organizations have published clarifications since the initial 2023 announcement.
How to describe your IaC depth on a screen
When a client mentions they run both, do not lead with a tool preference. Lead with the pattern you own. Something like: I design modules with versioned semver tags and documented input contracts, I run plan-only drift jobs on a schedule, and I enforce policy with OPA so the same ruleset works whether the pipeline calls terraform or tofu underneath.
That answer works for a Terraform-only shop, an OpenTofu-only shop, or a mixed one. It also quietly tells the screener you have done this for real, because nobody invents the phrase plan-only drift job unless they have been paged for drift before.
Avoid stating or implying a preference for one tool's licensing model as a condition of taking an assignment. Clients make their own tooling and licensing decisions; your job is to be fluent in the pattern underneath whichever tool they have standardized on.
The Josh Pros LLC team places infrastructure consultants into contracts where this exact distinction comes up on the first technical call. If you want a read on how a specific client describes their IaC stack before you walk in, email contact@joshpros.com or visit https://joshpros.com.
#Terraform #OpenTofu #InfrastructureAsCode #PolicyAsCode #CloudEngineering #DevOps #SRE #PlatformEngineering #ITContracting #TechConsultants #OpenPolicyAgent #StateManagement #CloudSkills #ContractTech
Talk to a real recruiter, not a bot.
We'll tell you the rate, the client, and the terms before you interview. And if we're not the right fit, we'll say so.