OpenTofu: la respuesta abierta al cambio de licencia de Terraform

OpenTofu es la respuesta organizada de la comunidad al cambio de licencia de Terraform a la Business Source License. El 20 de septiembre de 2023, una coalición de empresas y desarrolladores publicó el OpenTF Manifesto^[1] y se forkeó el último commit MPL de Terraform (v1.5.5). El proyecto fue aceptado por la Linux Foundation semanas después. Si gestionas infraestructura con Terraform, esta historia define qué herramienta usarás los próximos años y bajo qué condiciones legales.

Puntos clave

• OpenTofu es un fork de Terraform 1.5.5 (último commit MPL 2.0), gobernado por la Linux Foundation.

• Compatibilidad de archivo total: .tf, .tfstate y .tfvars funcionan sin modificación.

• Providers de AWS, Azure, GCP y todos los del Terraform Registry son reutilizables tal cual.

• La decisión de migrar depende de tu perfil: usuario interno vs. constructor de producto/servicio sobre Terraform.

• Una estrategia gradual (entorno aislado, CI paralelo, pipeline a pipeline) reduce el riesgo al mínimo.

Contexto: qué pasó con Terraform

En agosto de 2023, HashiCorp cambió su suite de productos (Terraform, Vault, Consul, Nomad, Packer) de la Mozilla Public License v2 (OSI-aprobada) a la Business Source License v1.1. La BSL no es código cerrado en sentido estricto, pero impone una restricción clave:

• Uso libre permitido para cualquier propósito que no compita con las ofertas comerciales de HashiCorp.

• Definición amplia de competencia: ofrecer un servicio gestionado o producto cuyo valor principal derive del software bajo BSL.

• Cambio automático a MPL 2.0 tras 4 años (el código actual vuelve a MPL en agosto de 2027).

Para usuarios que solo aplican Terraform a su propia infraestructura, el impacto es nulo. Para el ecosistema (proveedores de servicios, herramientas que orbitan Terraform, integraciones empresariales), el cambio se percibió como ruptura del contrato implícito de open source.

El nacimiento de OpenTofu

Tras seis semanas de organización pública en GitHub bajo el nombre OpenTF, el proyecto fue:

• Forkeado desde el último commit MPL de Terraform (versión 1.5.5).

• Renombrado a OpenTofu para evitar conflictos de marca.

• Aceptado como proyecto de la Linux Foundation en septiembre de 2023, garantizando gobernanza neutral.

• Respaldado por Spacelift, Gruntwork, env0, Harness, Scalr y decenas más.

La primera versión alpha apareció pocas semanas tras el fork. La arquitectura de gobernanza neutra contrasta con el modelo de empresa individual que controla Terraform, razón por la que proyectos como Vault se evalúan distinto cuando el proveedor cambia sus términos.

Compatibilidad en la práctica

OpenTofu mantiene compatibilidad de archivo completa. El binario tofu reemplaza terraform en los comandos:

tofu init
tofu plan
tofu apply

Los providers (AWS, Azure, GCP, Cloudflare, etc.) son exactamente los mismos: su licencia no cambia, solo la del core de Terraform. OpenTofu puede consumir cualquier provider del Terraform Registry sin modificación.

A medio plazo es esperable cierta divergencia: OpenTofu añadirá funcionalidades que la comunidad solicita pero HashiCorp no priorizó. Esa divergencia será incremental, no disruptiva.

Migrar o no?

La decisión depende del perfil de uso.

Migra a OpenTofu si:

• Tu organización tiene políticas estrictas sobre licencias open source (sectores regulados, organismos públicos).

• Construyes productos o servicios sobre Terraform donde la BSL podría aplicarte como competidor.

• Formas parte del ecosistema (proveedor de herramientas, consultora) y la neutralidad de gobernanza tiene peso legal.

• Quieres apostar por la trayectoria comunitaria a largo plazo.

Sigue con Terraform si:

• Solo lo usas internamente para gestionar tu propia infraestructura.

• Dependes de Terraform Cloud o integraciones específicas de HashiCorp.

• Tienes contratos enterprise activos con HashiCorp.

• Prefieres esperar a que OpenTofu alcance estabilidad probada antes de adoptar.

Estrategia de migración recomendada

Para equipos que decidan migrar, un enfoque gradual reduce el riesgo al mínimo:

• Validar en entorno aislado. Probar tofu init/plan/apply contra un entorno de test; verificar que el state se lee correctamente y los planes son idénticos.

• Ejecutar en paralelo. En CI, comparar la salida de terraform plan y tofu plan para detectar diferencias antes de cambiar.

• Migrar pipeline a pipeline. No es necesario cambiar todo el día uno. OpenTofu y Terraform pueden coexistir mientras los planes coincidan.

• Actualizar herramientas alrededor. Atlantis, Terragrunt y similares están añadiendo soporte explícito a OpenTofu.

Mapa de licencias de software libre y open source: relaciones entre licencias permisivas y copyleft (Imagen: David A. Wheeler, et al., CC BY-SA 3.0, vía Wikimedia Commons)

Implicaciones a largo plazo

Este cambio tiene una lectura más amplia: es una muestra más de la tensión entre creadores de software de infraestructura y los proveedores cloud que lo monetizan. El patrón de cambio de licencia seguido de fork comunitario acogido por una fundación neutral ya lo vimos con Elasticsearch/OpenSearch. Las fundaciones neutrales (Linux Foundation, CNCF, Apache Foundation) protegen mejor la continuidad de proyectos infraestructurales que las empresas individuales. Es un criterio que conviene aplicar al evaluar cualquier herramienta de IaC o de observabilidad para infraestructura crítica.

Para el siguiente proyecto de infraestructura que adoptes, la pregunta adecuada va más allá del qué hace: importa igualmente quién gobierna el código y con qué incentivos.

Conclusión

OpenTofu es una opción técnicamente viable hoy, con compatibilidad total con Terraform existente, y probablemente dominante a medio plazo en el espacio IaC. La neutralidad de gobernanza bajo la Linux Foundation reduce el riesgo de sorpresas futuras. Para la mayoría de organizaciones, la decisión no es urgente, pero conviene tomarla informados, no por defecto.

Preguntas frecuentes

¿Puedo usar mis ficheros `.tf` y mi `tfstate` actuales con OpenTofu sin cambios?

Sí. OpenTofu mantiene compatibilidad de archivo total: .tf, .tfstate y .tfvars funcionan sin modificación, y el binario tofu sustituye a terraform en los comandos (tofu init, tofu plan, tofu apply). Los providers de AWS, Azure, GCP, Cloudflare y el resto del Terraform Registry son exactamente los mismos, porque la licencia que cambió es la del core de Terraform, no la de los providers.

¿Me afecta la licencia BSL de Terraform si solo lo uso para mi propia infraestructura?

No, para quien solo aplica Terraform a su propia infraestructura el impacto es nulo: la BSL permite el uso libre para cualquier propósito que no compita con las ofertas comerciales de HashiCorp. El problema aparece si construyes un producto o servicio gestionado cuyo valor principal derive del software bajo BSL, o si tu organización exige licencias OSI-aprobadas. El código actual vuelve automáticamente a MPL 2.0 en agosto de 2027.

¿Cómo migro de Terraform a OpenTofu sin romper producción?

De forma gradual. Primero valida tofu init/plan/apply en un entorno de test aislado y comprueba que el state se lee bien y los planes son idénticos. Después ejecuta en CI terraform plan y tofu plan en paralelo para detectar diferencias, y luego migra pipeline a pipeline, ya que ambas herramientas pueden coexistir mientras los planes coincidan. Por último actualiza las herramientas alrededor, como Atlantis o Terragrunt, que ya añaden soporte explícito a OpenTofu.

Fuentes

1. OpenTF Manifesto
2. OpenTofu en GitHub