Von Open-Source- zu Source-Available-Lizenzen, Teil 2 Quellcode-Krimi – HashiCorp vs. OpenTofu

Anbieter zum Thema

Hyland Software Germany GmbH

Yorizon GmbH & Co. KG

Rechtliche Querelen rund um Lizenzen lösen wohl nur bei Juristen Begeisterungsstürme aus. Bei Opentofu und Terraform aber liegt der Fall etwas anders: Es geht um relevante Produkte, überschaubaren Code und ganz praktische Fragen für den Einsatz der Infrastructure-as-Code-Tools.

Ausgangspunkt einer aktuellen Open-Source-Lizenz-Misere ist Terraform, ein Infrastructure-as-Code-Werkzeug, mit dem sich zum Beispiel virtuelle Rechenzentren konstruieren lassen. Was die Software leistet, soll, ist in der Debatte aber völlig nebensächlich. Wichtiger war und ist die Entscheidung von HashiCorp, Terraform ab April 2024 mit einer neuen Lizenz auszustatten.

Bis dahin stand die Software unter der Mozilla Public License 2.0 (MPL-2.0), einer permissiven, von der Open Source Initiative (OSI) bestätigten Open-Source-Lizenz. Doch wie das bei kommerziellen Open-Source-Projekten nicht selten der Fall ist, sah sich HashiCorp wohl genötigt, gegen direkte Konkurrenz vorzugehen und hat darum auf die Business Source License (BSL) umgestellt. Redis ist mit der Server Side Public License (SSPL) einen ähnlichen Weg gegangen.

In Kürze: Die SSPL ist im Wesentlichen eine minimal abgewandelte GNU Affero GPL. Die AGPL ist nicht permissiv, sondern hängt am Copyleft-Prinzip (hier mehr zur allgemeinen Unterscheidung freier Lizenzen). Als Quasi-SaaS-Variante der regulären GPL greift die AGPL bereits, wenn eine lizenzierte Software über das Netz verfügbar gemacht wird – nicht erst bei der traditionellen Distribution.

Die SSPL weitet dieses Recht nun auf alle Produkte/Services aus, die bei der Leistungserbringung eingesetzt werden, sofern es sich um die Kernfunktionalität der Software selbst handelt. Schriebe man also beispielsweise für eine SSPL-Datenbank ein eigenes Frontend, müssten alle dabei zum Einsatz kommenden Tools ebenfalls unter die SSPL fallen – Frontend, Server, Bibliotheken etc.

Praktisch heißt das: Die freie Nutzung von Redis ist weiterhin gestattet, macht man allerdings den kommerziellen Redis-Services direkte Konkurrenz, wird es problematisch. Später folgt eine weitere Referenz auf diesen kleinen SSPL-Ausflug, kehren wir aber zunächst zur Problemstellung zurück.

Einem entsprechenden Zweck dient die BSL. Unter der BSL wird immer noch der Quellcode geliefert, es dürfen Derivate hergestellt und Produkte distribuiert werden – allerdings keine „competitive offerings“ zu HashiCorps bezahlten Varianten. Solche Entscheidungen führen in Open-Source-Projekten immer wieder zum gleichen Ergebnis: Es wird geforkt – und OpenTofu wurde geboren.

OpenTofu unter der MPL-2.0

Dies ist ein ganz normaler Vorgang: Terraform wechselt auf eine Nicht-Open-Source-Lizenz, also wird auf Github ein Fork erstellt und schon ist der letzte Open-Source-Status der Software die Basis für ein neues Produkt; dass HashiCorp das nicht gerne gesehen hat, dürfte verständlich sein – Handhabe dagegen gibt es aber freilich nicht.

Anschließend kam aber eine neue Funktion in die neue Terraform-Version, eine ähnliche oder identische (diese Frage ist des Pudels Kern!) Funktion in OpenTofu und folglich der in den USA recht beliebte Cease-and-Desist-Brief (Unterlassungsaufforderung). Die Anschuldigung: OpenTofu habe den BSL-lizenzierten Quellcode der neuen Funktion geklaut und in OpenTofu unter der MPL-2.0 zur Verfügung gestellt.

Erfreulicherweise kann man sich all die Materialien selbst anschauen, da OpenTofu die Unterlassungsaufforderung, die eigene Antwort sowie eine Code-Analyse veröffentlicht hat. Und hier wird der Fall einigermaßen greifbar.

Zwei Aspekte werden immer wieder angesprochen, in der Berichterstattung und von HashiCorp selbst. Zum einen diverse konkret betroffene Funktionen im Code und zum anderen die Copyright-Hinweise in den Dateien. Bezüglich der Copyright-Hinweise geht es laut Hashicorp um Dateien mit folgendem Hinweis:

Laut OpenTofu hingegen um diese Variante:

Nach OpenTofus Darstellung wurde daraus dann diese Version für die OpenTofu-Dateien, um den Original-Autoren ebenfalls Tribut zu zollen:

Schaut man in die von OpenTofu als Grundlage aufgeführte Version 1.5.5, finden sich freilich die MPL-Referenzen. Diesbezüglich dürfte es lediglich ein wenig Fleißarbeit im Detail benötigen, um die wirklich relevanten Versionen und Daten für eine weitere juristische Auseinandersetzung festzulegen.

Auf der anderen Seite geht es aber natürlich vor allem um Code. Die Entscheidung, inwiefern sich Funktionen urheberrechtlich wirklich voneinander abgrenzen, welche Code-Versatzteile schlicht der Programmiersprache geschuldete Standards sind, wo überhaupt eine relevante Schöpfungshöhe erreicht wird – all das mögen Experten in einer Verhandlung argumentieren.

Spannend ist aber, sich hier mal Beispiele anzuschauen, um zu verstehen worum es bei Copyright-Problemen mit Code denn in der Praxis überhaupt geht. OpenTofu geht in seinem 49-seitigen Dokument auf etliche Funktionen ein, die ersten stark zusammengekürzten Beispiele finden sich auf Seite 8 – hier ein Auszug:

Grundsätzlich ist der Vorwurf, OpenTofu haben die neue Funktion im „removed“-Block (Mitte) von der „removed“-Funktion der BUSL-Terraform-Variante (unten) abgeleitet. OpenTofu wiederum sagt, die Funktion sei von der alten MPL-Terraform-Variante „moved“ abgeleitet.

Hier dürfte es also jede Menge Argumentationen geben. In diesem ersten – auf eine Zeile gekürzten – Beispiel dürften aber auch Laien erkennen, dass die Ähnlichkeiten von Removed/MPL zu Moved/MPL deutlich größer sind als zu Removed/BUSL.

Auswirkungen

Noch mehr Spannung liefert die Berichterstattung über den Konflikt. Im Open-Source-Lager ist die Aufregung natürlich groß, der Vergleich zu Redis liegt nahe, SCO-vs-Linux wird hervorgekramt. Aber auch die Gegenseite hat sich schnell gemeldet.

Interessant ist vor diesem Hintergrund ein Kommentar von Matt Asay auf InfoWorld.com, in dem der Autor OpenTofu ziemlich heftige Vorwürfe macht. Mittlerweile ist dem Artikel ein Update-Hinweis vorangestellt, der Bezug nehmend auf OpenTofus C&D-Antwort erklärt, OpenTofu sei vermutlich doch nicht der Teufel.

Matt Asay? Ja, richtig, das ist ein Mitarbeiter von MongoDB – dem Erfinder der oben im Redis-Abschnitt erwähnten SSPL sowie der von HashiCorp adaptierten BSL. Hier kommt leider die Hybris durch: Firmen, die von Open-Source-Lizenzen auf „Source-Available-Lizenzen“ wechseln, möchten für sich selbst weiterhin den Nimbus einer Open-Source-Firma beanspruchen, sich aber gleichzeitig nicht an die dort geltenden Regeln halten. Die Gründe mögen nachvollziehbar sein, die Auswirkungen für die meisten Nutzer gering.

Ob sich das Risiko, durch einen Fork ersetzt zu werden, wirklich lohnt, wird die Zeit zeigen. Nun, vielleicht auch nicht: Mittlerweile hat IBM HashiCorp übernommen. Einst war IBM in einer ähnlichen Situation wie OpenTofu heute, als SCO ihnen Urheberrechtsverletzungen vorwarf – der Ausgang ist bekannt.

Ob IBM sich nun den Spott zuziehen möchte, seinerseits mit OpenTofu zu streiten? Die Community hofft eher auf eine Rückkehr zu einem ungeforkten Open-Source-Terraform beim traditionell Open-Source-freundlicheren Unternehmen IBM. Eines ist sicher: Open-Source-Lizenzen waren lange nicht mehr so spannend und relevant.

(ID:50081302)