Die Tücken der Lizenzierung

Die Lizenzbedingungen im Rahmen eines Software-Stacks beziehungsweise Ökosystems von Blockchain-basierten Lösungen zählen zu den Themen, mit denen sich Entwickler von Anfang an bewusst auseinandersetzen sollten. Denn bei derart verzahnten Stacks wie Blockchain-Software ist das nachträgliche Ändern einer Lizenz nicht bloss mühsam, sondern im Grunde unmöglich. Dies liegt in der grossen Zahl der Beteiligten begründet, die einen Beitrag geleistet haben, sich gegenseitig nicht kennen und ihre Zustimmung stillschweigend verweigern könnten.

Lizenzkonflikte sind in der Blockchain-Szene also vorprogrammiert und extrem problematisch. So trugen sich beispielsweise die Entscheider bei Hyperledger eine Zeit lang mit dem Gedanken, Projekte zu hosten, die sich in der Rolle eines Clients an die Ethereum-Kette anbinden oder auf der Ethereum-Plattform aufbauen würden. So könnte sich Hyperledger auf das Ethereum-Protokoll stützen und einen De-facto-Standard für Blockchains küren.

Die Integration angeregt hatte Ethereum-Erfinder Vitalik Buterin. Die Hyperledger-Gemeinde zeigte sich der Idee gegenüber entsprechend aufgeschlossen. Um die Zusammen­arbeit zu festigen, sollte Ethereum C++ (cpp-ethereum) in Hyperledger einfliessen. Dieses Vorhaben liess sich lizenzkonform aber nicht realisieren. Die Nutzungsbedingungen der beiden Projekte waren nämlich aufgrund der Verwendung unterschiedlicher Open-Source-Lizenzen inkompatibel miteinander. Ethereum C++ wurde unter der GPLv3 lizenziert, während Hyperledger Apache 2.0 verwendet. Die Integration von Ethereum C++ in Hyperledger hätte eine Neu-Lizenzierung des Ethereum-C++-Clients – mit Zustimmung jedes einzelnen Entwicklers – auf Apache 2.0 erforderlich gemacht. Die Zusammenarbeit ist an den vielfältigen Komplexitäten dieses Vorhabens letztendlich gescheitert. Für beachtliche Teile des Ethereum-Ökosystems sind die Lizenzbedingungen immer noch nicht eindeutig spezifiziert, sie neigen jedoch zu einer restriktiven Auslegung; da darf man sich über das Ergebnis nicht wundern. Die Schlussfolgerung lautet also: Drum prüfe, wer fremden Code in Lizenz nutzt – bei Blockchain-Lösungen umso genauer.

Hyperledger hostet derzeit unter anderem Fabric (das Flaggschiff-Framework für Blockchain-Lösungen), Sawtooth Lake (eine innovative Blockchain mit modularen Transak­tionsfamilien) und Iroha (eine quelloffene Blockchain-Plattform für vertrauenswürdige, schnelle und sichere Anwendungen mit byzantinischer Fehlertoleranz), von Ethereum gibt es hier praktisch keine Spur. Hinzu kommt noch ein weiterer, Blockchain-spezifischer Aspekt von Software-Lizenzen: das Aufkommen von hybriden Lizenzen wie JLP (Jelurida Public License), einer Coinleft-Lizenz. Basierend auf der GNU GPL fügt sie ihrem Copyleft-Unterbau eine zusätzliche Anforderung hinzu: Für die Verwendung der Nxt-Software für den eigenen Code müssen Entwickler 10 Prozent der Coins, die sie erzeugen, per Airdrop an die Nxt-Entwicklergemeinde übertragen.

Die Wahl des Blockchain-Frameworks hat weitreichende Konsequenzen. Sie beeinflusst die Leistungsfähigkeit der darauf aufbauenden Lösungen, bestimmt die zulässigen Methoden der Konsensbildung, die Herausforderungen der Inter­operabilität und den gebotenen Grad an Cybersicherheit.

Zu bedenken ist etwa, dass sich nach der Entscheidung für ein kommerzielles Framework die Entwicklung der Lizenzkosten niemals wirklich vorhersagen lässt. Ein proprietäres Framework mit einer kommerziellen Lizenz kann deshalb leicht das Aus für das Blockchain-Projekt bedeuten. Und selbst Grossunternehmen machen um kommerzielle Blockchain-Frameworks oft einen grossen Bogen, weil sich ein kostenpflichtiges Lizenzmodell in vielen Fällen negativ auf die Grösse und das Wachstum einer Entwicklergemeinde auswirkt.

Eine Herausforderung beim Umgang mit der Blockchain ist für interessierte Unternehmen nicht zuletzt die übergrosse Auswahl an Frameworks. Die nachstehende PDF-Datei stellt daher die wichtigsten Blockchains und ihre Eigenschaften vor.