OpenTofu: la respuesta abierta al cambio de licencia de Terraform

Actualizado: 2026-05-03

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], se forkeó el último commit MPL de Terraform (v1.5.5), y 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ó toda 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 — y es la 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:

1. 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.
2. Ejecutar en paralelo. En CI, comparar la salida de terraform plan y tofu plan para detectar diferencias antes de cambiar.
3. Migrar pipeline a pipeline. No es necesario cambiar todo el día uno. OpenTofu y Terraform pueden coexistir mientras los planes coincidan.
4. Actualizar herramientas alrededor. Atlantis, Terragrunt y similares están añadiendo soporte explícito a OpenTofu.

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 — 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 correcta no es solo “¿qué hace?” sino “¿quién gobierna el código y qué incentivos tiene?”.

Conclusión

OpenTofu es una opción técnicamente viable hoy, con compatibilidad total con Terraform existente, y muy 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.

1. OpenTF Manifesto