OpenTofu als Terraform-Alternative: die Lizenzfrage für Unternehmen

Im August 2023 hat HashiCorp die Lizenz von Terraform geändert: weg von der Mozilla Public License 2.0, hin zur Business Source License 1.1. Seither taucht in Architektur-Reviews regelmäßig dieselbe Frage auf — dürfen wir das noch einsetzen?

Was sich geändert hat

Terraform bis einschließlich Version 1.5.x steht unter MPL 2.0 und bleibt es auch. Alle späteren Versionen stehen unter der BUSL: quelloffen einsehbar, aber mit einer Nutzungseinschränkung. Untersagt ist die Verwendung für ein „konkurrierendes Angebot“ zu HashiCorp-Produkten. Nach vier Jahren fällt eine Version jeweils auf eine Open-Source-Lizenz zurück.

Für den überwiegenden Teil der Unternehmen ist der interne Betrieb von Terraform davon nicht betroffen — wer Infrastruktur für das eigene Haus verwaltet, konkurriert nicht mit HashiCorp. Kritisch wird es in Graubereichen:

• Managed-Service-Provider und IT-Dienstleister, die Terraform als Teil eines Produkts für Kunden betreiben
• Interne Entwickler-Plattformen, die Terraform als Self-Service-Dienst anbieten
• Software-Produkte, die Terraform bündeln oder integrieren

Was genau „konkurrierend“ heißt, entscheidet nicht der Text allein, sondern die Auslegung. Genau diese Unschärfe ist für viele Rechtsabteilungen das eigentliche Problem — nicht die Kosten. Hinweis: Das ist eine technische Einordnung, keine Rechtsberatung; die Bewertung für Ihr Haus gehört zur Rechtsabteilung.

Was OpenTofu ist

Als Reaktion entstand OpenTofu — ein Fork von Terraform 1.5.x, der unter MPL 2.0 weiterentwickelt wird. Das Projekt liegt bei der Linux Foundation, also bei einer neutralen Stiftung statt bei einem einzelnen Anbieter. Die Governance ist offen, die Roadmap öffentlich, mehrere Firmen stellen Entwickler.

Für Unternehmen ist genau das der Kern: Die Lizenz kann nicht durch eine einzelne Firmenentscheidung erneut wechseln.

Kompatibilität in der Praxis

OpenTofu spricht dieselbe HCL-Syntax, nutzt dasselbe State-Format und dieselbe Provider-Registry-Schnittstelle. Bestehende Module, Provider und Pipelines funktionieren weiter. Der Umstieg besteht im Wesentlichen aus einem anderen Binary:

# statt
terraform init && terraform plan

# nun
tofu init && tofu plan

In der CI-Pipeline reicht meist der Austausch des Setup-Schritts:

- uses: opentofu/setup-opentofu@v1
  with:
    tofu_version: 1.9.0

- run: tofu init
- run: tofu plan -out=tfplan

Ein sauberer Ablauf: State sichern, in einer nicht-produktiven Umgebung tofu plan laufen lassen und prüfen, dass der Plan leer bleibt. Ein leerer Plan ist der Nachweis, dass OpenTofu den bestehenden State identisch interpretiert. Erst danach Staging, dann Produktion.

Wo die Projekte auseinanderlaufen

Beide Werkzeuge entwickeln sich seit dem Fork eigenständig weiter. OpenTofu hat unter anderem clientseitige State-Verschlüsselung eingeführt — bei Terraform bleibt der State im Backend-Klartext, sofern das Backend nicht selbst verschlüsselt. Umgekehrt erscheinen neue HashiCorp-Funktionen nicht automatisch in OpenTofu.

Praktische Konsequenz: Prüfen Sie vor dem Wechsel, ob Ihr Code Sprachfeatures aus neueren Terraform-Versionen nutzt. Bei Setups, die aus der 1.5er-Ära stammen, ist das selten ein Thema.

Entscheidungshilfe

OpenTofu spricht für sich, wenn Sie Infrastruktur als Dienstleistung für Dritte betreiben, eine interne Plattform anbieten, Lizenz-Compliance formal nachweisen müssen oder Anbieterunabhängigkeit als Architekturprinzip führen.

Terraform bleibt sinnvoll, wenn Sie HCP Terraform oder Terraform Enterprise samt Support nutzen, auf Funktionen angewiesen sind, die es nur dort gibt, oder eine kommerzielle Vertragsbeziehung mit Supportzusagen brauchen.

Für viele Häuser ist die pragmatische Antwort: OpenTofu für neue Projekte, bestehende Umgebungen migrieren, wenn ohnehin ein Refactoring ansteht.

Wir bewerten Ihr bestehendes Setup und begleiten den Umstieg — inklusive Pipeline-Anpassung und State-Migration. Sprechen Sie uns an.