OpenTofu vs. Terraform: qué herramienta de IaC realmente se sostiene
Los cambios de licencia y la adquisición por parte de IBM han convertido a OpenTofu en un fork serio de Terraform. Qué separa a ambas herramientas y qué realmente importa en DACH.
Desde que Terraform cambió a una licencia más restrictiva y HashiCorp pertenece a IBM, todo equipo que trabaje con código Terraform debe evaluar seriamente OpenTofu: código abierto bajo MPL 2.0, operado por la Linux Foundation. En 2026, por tanto, no se trata de una herramienta objetivamente superior, sino de alinear correctamente operación, cumplimiento y cadena de suministro.
Lo más importante en resumen
- La licencia es el desencadenante, no una característica: Terraform se encuentra desde la versión 1.6 bajo la Business Source License, OpenTofu bajo MPL 2.0 en la Linux Foundation. Para la gran mayoría de las configuraciones existentes, el cambio es un simple intercambio de binario.
- En 2026 los proyectos divergen: OpenTofu cuenta con cifrado nativo del State y funciones definidas por el proveedor, Terraform tiene valores efímeros y HCP Stacks. En la sintaxis HCL y el formato del State se mantiene la paridad.
- La decisión en la región DACH es de gobernanza, no de CLI: La cadena de suministro NIS2, el riesgo de terceros DORA y la concentración de proveedores pesan para muchos más que una única función de línea de comandos.
Relacionado:La soberanía de la IA comienza en la infraestructura / Lo cloud-native madura con Kubernetes 1.34
Por qué una licencia se convirtió en una cuestión de arquitectura
En agosto de 2023, HashiCorp cambió la licencia de Terraform de la Mozilla Public License a la Business Source License. La BSL prohíbe su uso en competencia directa con los propios productos de HashiCorp y solo vuelve a ser verdadero código abierto cuatro años después de cada lanzamiento. Para los usuarios finales puros, esto parece al principio una nota al pie. Para cualquiera que integre Terraform en un producto, una plataforma o un servicio gestionado, surge así un riesgo legal.
La reacción llegó rápidamente. Una alianza de proveedores y la comunidad ha bifurcado Terraform 1.5, la última versión bajo MPL. De OpenTF surgió OpenTofu, en septiembre de 2023 bajo el paraguas de la Linux Foundation, y desde abril de 2025 también en la CNCF. Paralelamente, IBM adquirió HashiCorp por alrededor de 5,9 mil millones de euros, operación cerrada a finales de 2024. Así, detrás de Terraform hay hoy un único gran proveedor y detrás de OpenTofu una fundación con gobernanza multiparte. Para equipos con requisitos de gobernanza, esta estructura de titularidad es un criterio de decisión central.
¿Qué es OpenTofu? OpenTofu es un fork de código abierto de Terraform bajo la MPL 2.0, separado de la última versión de Terraform con licencia libre. El proyecto es dirigido por un Technical Steering Committee bajo la Linux Foundation; ninguna empresa individual controla la hoja de ruta. La línea de comandos, el lenguaje HCL y el formato del State son en gran medida compatibles con Terraform.
Dónde se separan OpenTofu y Terraform
Hasta 2025, OpenTofu se podía describir principalmente como una alternativa a Terraform con licencia limpia. Desde entonces, los proyectos se han separado funcionalmente. Ambos proyectos publican sus propias versiones a su propio ritmo; los perfiles de funciones se alejan. OpenTofu se encuentra actualmente en la versión 1.9, Terraform en la 1.14. Quien tome una decisión debe basarla en funciones concretas, consecuencias de la licencia y dependencias operativas.
La diferencia más importante es el cifrado del State. OpenTofu cifra los archivos de State y Plan del lado del cliente antes de que abandonen la máquina, de forma opcional frente a un proveedor KMS. Terraform lo deja tradicionalmente al backend, por ejemplo el cifrado del lado del servidor de un bucket S3. Quien gestione datos regulados en el State obtiene con OpenTofu una capa de protección adicional. Esto es relevante porque en la práctica los secretos terminan allí con más frecuencia de lo planeado. Además, se suman funciones definidas por el proveedor y una evaluación más temprana de variables en el lado de OpenTofu. Terraform apuesta por valores efímeros y la integración estrecha en HCP Stacks.
| Criterio | OpenTofu | Terraform |
|---|---|---|
| Licencia | MPL 2.0, reconocida por OSI | BSL 1.1, no reconocida por OSI |
| Gobernanza | Linux Foundation, multiparte | IBM / HashiCorp, proveedor único |
| Cifrado del State | nativo, del lado del cliente | a través del backend |
| Fortalezas propias | funciones definidas por el proveedor, evaluación temprana de variables | valores efímeros, HCP Stacks |
| Formato HCL y State | compatible | Referencia |
La tabla marca la línea divisoria: OpenTofu es más fuerte en apertura y seguridad del State, Terraform en su propia plataforma en la nube. De ello no se deriva una recomendación general. Quien no utilice HCP Stacks no pierde funcionalidad con el cambio. Quien lo utiliza tiene una dependencia que primero debe resolverse.
Migración: qué cuesta en la práctica el cambio
El cambio es técnicamente en la mayoría de los casos manejable. El formato del State, HCL y el protocolo del proveedor son compatibles; en muchas configuraciones existentes basta con sustituir el binario. De terraform init pasa a tofu init; muchos flujos permanecen sin cambios. El riesgo no está en el código, sino en los márgenes: en las dependencias de Terraform Cloud, HCP Stacks o wrappers propios adaptados al stack de HashiCorp.
Quien migra no debería convertir todo el patrimonio de una vez. Primero un módulo, luego un State, a continuación un Plan-Diff limpio antes y después del intercambio. Este orden reduce el riesgo de que un cambio de herramienta en realidad pequeño se convierta en un problema operativo. El aspecto de los costes rara vez es el motor en este caso; ambas herramientas están disponibles de forma gratuita; los costes surgen sobre todo por las plataformas e integraciones que las rodean.
Razones a favor del cambio
- Claridad de la licencia para productos y servicios gestionados
- Cifrado nativo del State sin rodeo por el backend
- Gobernanza multiparte en lugar de hoja de ruta de proveedor único
Razones en contra del cambio
- Dependencia de HCP Stacks debe resolverse primero
- Adquisición que exige HashiCorp como proveedor
- Cadena de herramientas con suposiciones de Terraform cableadas
La decisión en DACH: NIS2, DORA y la cadena de suministro
En la región DACH, la cuestión se desplaza de la técnica a la gobernanza. NIS2 exige un deber de diligencia documentado sobre la cadena de suministro de software, DORA aborda para el sector financiero el riesgo de terceros y explícitamente el riesgo de concentración en proveedores de servicios de TIC. Una herramienta de infraestructura bajo control de fundación, de código abierto y sin un único propietario comercial, es en esta lógica más fácil de defender que un producto cuya licencia y hoja de ruta dependen de un proveedor.
Eso no significa que OpenTofu sea automáticamente la elección conforme al cumplimiento. Significa que la cuestión de la licencia y el control surge en una auditoría NIS2 o DORA y debe responderse. El movimiento del mercado es aún moderado: alrededor del 12 % de los profesionales de IaC ya utilizan OpenTofu, aproximadamente una cuarta parte examina o amplía su uso. No es un terremoto, pero sí una tendencia constante en una dirección.
A la inversa, existen razones claras para quedarse con Terraform. Quien construye sobre HCP Stacks, trabaja en un entorno IBM Cloud Pak o tiene una adquisición que exige expresamente HashiCorp como proveedor, avanza de forma más directa con Terraform. La decisión no es una cuestión de fe. Es un balance entre riesgo de licencia, gobernanza de la cadena de suministro y dependencias concretas de plataforma, y este balance resulta diferente según la organización.
Preguntas frecuentes
¿Se puede sustituir Terraform por OpenTofu sin modificaciones?
Para la gran mayoría de las configuraciones, sí. El formato del State, la sintaxis HCL y el protocolo del proveedor son compatibles; en la práctica suele bastar con el intercambio del binario. La fricción surge en las dependencias de Terraform Cloud, HCP Stacks o wrappers propios. Una migración módulo por módulo con Plan-Diff antes y después del cambio captura los casos límite.
¿Qué ha pasado exactamente con la licencia de Terraform?
HashiCorp cambió Terraform en agosto de 2023 de MPL 2.0 a Business Source License 1.1. La BSL restringe el uso en competencia con los productos de HashiCorp y solo vuelve a ser código abierto libre cuatro años después de cada lanzamiento. Ese fue el detonante del fork de OpenTofu.
¿Qué funciones tiene OpenTofu que le faltan a Terraform?
Lo más visible es el cifrado nativo del lado del cliente de los archivos State y Plan. Además se añaden funciones definidas por el proveedor y una evaluación más temprana de las variables. Terraform, por su parte, tiene funciones propias como valores efímeros y la estrecha integración con HCP Stacks. La sintaxis central permanece igual en ambos lados.
¿Cuándo es Terraform la mejor opción?
Cuando la operación se basa en HCP Stacks, se ejecuta en un entorno IBM Cloud Pak o las adquisiciones exigen expresamente HashiCorp como proveedor. En estos casos, un cambio genera más esfuerzo del que devuelve en ventajas de licencia y gobernanza.
¿Qué significa la elección para el cumplimiento de NIS2 y DORA?
NIS2 exige una diligencia documentada sobre la cadena de suministro de software, DORA aborda el riesgo de terceros y de concentración en proveedores de servicios TIC. Una herramienta de código abierto bajo control de fundación es más fácil de justificar en una auditoría que un producto de proveedor único. La pregunta debe responderse en ambos casos, independientemente de la herramienta elegida.
Más de la red de medios MBF
Fuente de la imagen: Imagen de portada generada por IA (junio de 2026), certificado C2PA incrustado en la imagen
