OpenTofu oder Terraform? HashiCorp hat versucht, den Fork zu stoppen - zweimal

Ganz ehrlich: Bei den meisten Lizenz-Forks reicht die Geschichte “Konzern ändert Lizenz, Community forkt” als Erklärung. Bei OpenTofu nicht. Da kommt noch was dazu.

Versuch eins: der Registry-Riegel

August 2023, HashiCorp stellt Terraform von MPL auf Business Source License um. Die Reaktion: OpenTofu, ein Fork der letzten offenen Version, unter dem Dach der Linux Foundation.

Einen Monat später, im September 2023, änderte HashiCorp still und leise die Nutzungsbedingungen der Terraform-Registry. Neue Formulierung: Provider und Module dürfen nur noch “zur Nutzung mit HashiCorp Terraform” heruntergeladen werden. Für OpenTofu-Nutzer hieß das: kein Zugriff mehr auf die zentrale Provider-Quelle des gesamten Ökosystems.

OpenTofu blieb nichts anderes übrig, als sich eine eigene Registry zu bauen - parallel zur eigenen Alpha-Version, innerhalb weniger Wochen. Kein Rückzieher, sondern Tempo.

Versuch zwei: der Copyright-Vorwurf

April 2024, nächster Anlauf: HashiCorp schickte OpenTofu ein Cease-and-Desist-Schreiben. Vorwurf: Code widerrechtlich übernommen, falsch umgekennzeichnet. OpenTofu wies das zurück - der beanstandete Code stammte nachweislich aus der letzten legal offenen MPL-Version von Terraform, nicht aus der lizenzierten BUSL-Variante.

Was das für mich bedeutet

Ein Projekt, das zweimal aktiv ausgebremst wurde - Registry-Sperre, Copyright-Drohung - und trotzdem weitergewachsen ist, ist kein Zufallsprodukt. Das ist ein Team, das sich nicht wegdrängen lässt. Und inzwischen liefert OpenTofu obendrauf noch technisch mehr - eine ganze Reihe an Funktionen, die es im offenen Terraform-Binary bis heute nicht gibt:

• State-Verschlüsselung (seit 1.7): State- und Plan-Dateien werden verschlüsselt abgelegt, mit Unterstützung für AWS KMS, GCP KMS, Azure Key Vault und OpenBao als Key-Provider - im offenen Terraform-Binary gibt es das nicht, nur HCP Terraform Cloud verschlüsselt automatisch, und die Möglichkeit zum eigenen Schlüssel (“Hold Your Own Key”) ist dort sogar auf den Premium-Tarif beschränkt.
• Provider for_each (seit 1.9): Provider-Konfigurationen lassen sich iterieren statt sie für jede Region oder Zone einzeln auszuschreiben - gerade bei Multi-Region-Setups ein spürbarer Unterschied. Bei Terraform ist das laut HashiCorp selbst technisch bedingt nicht vorgesehen.
• OCI-Registry-Unterstützung (seit 1.10): Module und Provider lassen sich über ganz normale Container-Registries wie ECR, GHCR oder Docker Hub verteilen - dieselbe Infrastruktur, die ihr für eure Container-Images sowieso schon betreibt, auch für Air-Gapped-Umgebungen relevant. Terraform hat dafür bis heute keine Entsprechung - der zugehörige Feature-Request bei HashiCorp ist seit Juli 2022 offen, ohne Zeitplan oder Zusage.

Das ist keine Kompromiss-Entscheidung mehr zwischen “moralisch sauber, aber technisch schwächer”. OpenTofu liefert spürbar mehr - und hat sich das Recht dazu gegen echten Widerstand erarbeitet.

Meine klare Ansage

Für einen Neueinstieg in Infrastructure as Code für Kubernetes-Cluster: OpenTofu, ohne Wenn und Aber. Die Konfigurationssyntax ist praktisch identisch, die Provider funktionieren, der Umstieg ist kein Projekt.

Läuft bei euch bereits Terraform produktiv und stabil? Dann ist ein Wechsel eine Kosten-Nutzen-Frage, kein Muss - dieselbe Regel wie bei jedem eingespielten Tool.

Fazit

OpenTofu musste sich seinen Platz zweimal gegen aktiven Widerstand erkämpfen. Wer danach noch auf die Konzern-Variante setzt, tut das aus Gewohnheit, nicht aus einem echten technischen oder strategischen Grund.

Mein Kubernetes-Training mit Proxmox und OpenTofu zeigt dir Infrastructure as Code direkt am Live-Cluster - von der ersten .tf-Datei bis zum fertig provisionierten kubeadm-Cluster.