Open Source-Dschungel in der Ethereum-Blockchain

Von Lisa Käde

Auch im Rahmen des Hype-Trend-Themas Blockchain ergeben sich zahlreiche interessante Fragestellungen mit Bezug zu Open Source Lizenzen. Insbesondere die Lizenzkompatibilität im Dickicht der Software-Komponenten auf der Ethereum-Blockchain stellt die Entwickler vor besondere Herausforderungen.

Dieser Artikel gibt in einem ersten Teil einen kurzen Einblick in die Blockchain-Thematik, der nur dazu dienen soll, denjenigen Lesern den Zugang zu ermöglichen die sich bisher nicht mit Blockchain beschäftigt haben. Im zweiten Teil werden Open Source-rechtliche Fragestellungen beleuchtet.

I) Blockchain-Technologie

Warum? Man-In-The-Middle-Attacken schwächen das Vertrauen in zentrale Datenspeicher. Benutzer wollen wissen, was mit ihren Daten passiert. Banken sind externen Einflüssen aus Politik und Wirtschaft unterlegen. Daten, Dokumente etc. können jederzeit manipuliert werden, selbst wenn ein Original definiert ist, solange die Dokumente von einer einzelnen Person / Maschine kontrolliert werden.

Was ist eine Lösung? Blockchains ermöglichen direkte Kommunikation ohne zwischengeschaltete Übertragungsinstanz. Dies gewährleistet revisionssicheres transparentes und chronologisches Speichern von Daten, das nicht auf eine zentrale Instanz angewiesen ist, sondern quasi-demokratisch in einem Computernetzwerk eine datenbankähnliche Datensammlung bei allen Netzwerk-Teilnehmern synchronisiert. Beispiel: Die Bitcoin-Blockchain ermöglicht den Austausch digitaler Währung (Bitcoins) ohne Banken direkt zwischen den Handelspartnern.

Wie funktioniert‘s? Alle Knotenpunkte in einem Blockchain-Netzwerk erhalten eine Datensammlungskopie (Ledger), die ständig synchronisiert wird. Es gibt verschiedene Blockchain-Netzwerke. Eine Blockchain-Datensammlung besteht aus aneinander geketteten Datenblöcken („Block Chain“). Die Verkettung erfolgt indem jeder neue Block eine Prüfsumme des vorangegangenen Blocks enthält. Dadurch ist die Manipulation des jeweils vorangegangenen Blocks quasi unmöglich, da eine Veränderung des Blockinhalts die Prüfsumme verändern würde.

Das Hinzufügen neuer Daten kann also nur am Ende der Kette erfolgen. Wenn ein Nutzer neue Daten schreiben möchte, definiert er eine „Transaktion“ (Beispiel: „sende X Einheiten an Y“) und schickt diese in sein entsprechendes Blockchain-Netzwerk (das mag kompliziert klingen, das ist es für den Endanwender dank entsprechender Software aber eigentlich nicht). Diese Transaktion muss sodann in einen Block eingebunden werden, um Teil der Blockchain zu werden. Ein Datenblock kann mehrere Transaktionen enthalten. Datenblöcke werden von sog. „Minern“ errechnet.

Miner sind vereinfacht gesagt Knotenpunkte (Computer) im Netzwerk, die, um den neuen Block anhängen zu dürfen, eine komplexe, rechenintensive Aufgabe lösen müssen (Ethereum / Bitcoin - „Proof of Work“, Stand 10/2018 – in Zukunft sind auch andere Mechanismen geplant). Die Miner holen sich aus einem Pool bisher unbearbeiteter Transaktionen ein Bündel Transaktionen und fügen diese in einen neuen Block ein, nachdem sie überprüft haben, ob die Transaktionen zulässig sind (z.B. ob der jeweilige Sender genug Einheiten besitzt um die Transaktion durchzuführen). Der Miner, der zuerst einen neuen Block errechnet hat, „gewinnt“. Dessen Block wird im Netzwerk bekannt gemacht und synchronisiert.

Die Anzahl neuer Blöcke kann durch die variable Komplexität der Rechenaufgabe gesteuert werden. Miner erhalten für ihre Arbeit eine Gegenleistung in Form einer Blockchain-Netzwerk-spezifischen Währung (z.B. Bitcoin oder Ether). Mining wird von Software durchgeführt, Benutzer haben aber die Möglichkeit, den Mining-Prozess des eigenen Computers anzustoßen.

II) Was für Fragestellungen ergeben sich daraus in Bezug auf Open Source?

Bestimmte Blockchain-Systeme (z.B. Ethereum) ermöglichen es den Netzwerkteilnehmern, nicht nur Transaktionen in die Blockchain zu schreiben, sondern auch Programme ablaufen zu lassen (häufig „Smart Contracts“ genannt). Diese Programme können zum Beispiel Zahlungen entgegennehmen und aufteilen, oder auf bestimmten Input reagieren, oder besondere Rechenoperationen zur Verfügung stellen. In der Grundidee von Nick Szabo (ca. 1993) sollen die Programme Verträge digital abbilden und unterstützen. Da diese Programme zu einem großen Teil abhängig sind von der zugrundeliegenden Infrastruktur und deren Bibliotheken, stellt sich schnell die Frage nach der zulässigen Lizenzierung der beteiligten Software.

Aber nicht nur die Smart Contracts werfen Fragen auf, sondern auch die Entwicklung auf tieferen Ebenen der Blockchain (nachfolgende Erläuterungen beziehen sich auf die Ethereum-Blockchain): Es werden sowohl Client-Anwendungen in verschiedenen Programmiersprachen entwickelt (go-ethereum/geth, cpp-ethereum (aleth), pyethereum, Ethereum(J), ethereumjs-lib, ruby-ethereum etc.) als auch Javascript-Compiler für die Smart-Contract-Sprache Solidity (solc-js) und Entwicklungsumgebungen, um nur einige wenige zu nennen. Dank Open Source und weiter Verfügbarkeit der Quellcodes auf GitHub haben Softwareentwickler in der Regel keine Probleme, auf die für die eigene Lösung benötigten Softwareteile zuzugreifen.

Die Infrastruktur der Ethereum-Blockchain wird unterschieden in den „Core“, die „Applications“ und die „Middleware“. Für alle drei Ebenen gilt grundsätzlich (https://github.com/ethereum/wiki/wiki/Licensing): Ethereum wird entlang der Definition der Free Software Foundation als Open Source und Free Software (FLOSS) entwickelt, dabei sind unterschiedliche Lizenzen im Einsatz, um die jeweiligen Bedürfnisse der Anwender und Entwickler zu berücksichtigen. In Bezug auf die Lizenzierung formulierten die Ethereum-Entwickler ursprünglich folgende Ziele:

  1. Die „Applications“ (u.a. der Solidity Compiler) sollen unter der GNU GPL stehen. Begründet wird das damit, dass es in der Regel nicht erforderlich ist, diese Softwareteile in eine proprietäre Software zu integrieren.
  2. Die „Middleware“ (z.B. web3.js und das Kommandozeilenprogramm eth) sollen unter eine Affero Lizenz gestellt werden, "wobei voraussichtlich eine LGPL-Variante gewählt wird" (Anm.: unklar ist, welche Lizenz hier genau gewählt werden soll, die LGPL ist eine GNU-Lizenz und keine Affero-Lizenz wie es die AGPLv1 und die AGPLv3 sind). Dies soll gewährleisten, dass der technologischen Entwicklung keine Grenzen gesetzt werden, indem Verlinkungen zu jeder Art von Software hergestellt werden dürfen. Trotzdem soll ein Anreiz gesetzt werden, dass die entstehenden Back-End-Integrationen zurück in die Community gelangen, um auch Interoperabilität mit Legacy-Systemen zu ermöglichen.
  3. Der „Core“ soll unter der liberalsten verfügbaren Lizenz stehen, damit er in jeder kommerziellen Umgebung, sei es Open oder Closed Source, einsetzbar ist. Die Entscheider haben dazu die MIT-Lizenz, die MPL und die LGPL in die engere Wahl genommen. Sollte die Wahl auf die LGPL fallen, soll sichergestellt werden, dass der Code (durch eine Anpassung der Lizenzbestimmung) trotzdem statisch mit Closed Source Software verbunden werden kann.

Das war zumindest der Plan. Die Realität ist jedoch vielmehr ein Lizenzdschungel, den zu durchdringen es einiger Ausdauer und Geduld bedarf. Die Komplexität liegt einerseits in der Vielzahl der Plattformen für unterschiedliche Programmiersprachen (vgl. o.g. „Clients“) und andererseits in den verschiedenen Ebenen der Blockchain-Infrastruktur, für die die Lizenzierung nur teilweise entlang der ursprünglichen Philosophie erfolgt ist. Ein „Überblick“:

Ethereum-Blockchain-Architektur Quelle: eigene Darstellung

* SOLC ist integriert / wird heruntergeladen / wird genutzt        
** verwendet Solidity Binaries aus solc-bin

Schon beim Betrachten der Core-Bibliotheken bzw. Clients fällt eine sehr heterogene Lizenzierung ins Auge. Insbesondere der C++-Client „Aleth“ wurde unter die GPL v.3 gestellt, und nicht, wie ursprünglich beabsichtigt, unter eine „liberale“ Lizenz. Bereits 2016 wurde dieses Problem erkannt (https://github.com/ethereum/aleth/issues/3218) und ein Relizenzierungsversuch in Richtung Apache 2.0 unternommen, der bis heute allerdings keinen Erfolg hatte. Grund für das Scheitern war wohl – neben dem Fehlen eines Contributor Licensing Agreements - insbesondere, dass einer der ursprünglichen Contributors sich „aus Loyalität zu seinen Shareholdern“ dem Relizenzierungsvorhaben nicht anschloss (anschließen konnte?).  Bis heute herrscht also ein buntes Lizenzchaos in der Ethereum-Blockchain.

Die Frage der Lizenzkompatibilität stellt sich, sobald zwei unter verschiedenen Lizenzen stehende Programmteile zu einem Programm verbunden werden. Grundsätzlich gilt dabei: wenn der fremde Programmteil unter der GPL v3 steht, muss auch der eigene Programmteil unter die GPL v3 gestellt werden. Wenn der fremde Teil unter der LGPL steht, kommt es in der Regel auf die Art und Weise an, wie die Programmteile miteinander verbunden werden. Wann Programmteile als „miteinander verbunden“ gelten, ist nicht immer eindeutig, soll aber an dieser Stelle nicht erneut diskutiert werden.

Im Folgenden werden zwei Aspekte der (Ethereum-) Blockchain in Bezug auf die Lizenzierung genauer unter die Lupe genommen:

1. Smart Contracts:

Smart-Contract-Programmcode, der in der Regel in der dafür entwickelten Programmiersprache Solidity verfasst wird, wird in kompilierter Form in Blocks auf der Blockchain gespeichert. Da diese Blocks nur eine sehr begrenzte Kapazität haben (und um Redundanzen zu vermeiden) sind auch in der Welt der Smart Contracts bereits Bibliotheken im Einsatz – und zwar in Form von ausgelagerten Bibliotheken (Libraries), deren Funktionen bei Bedarf eingebunden und verwendet werden können.

Es gibt unterschiedliche Einbindungsvarianten: Entweder die Library wird schlicht referenziert (das hat zur Folge, dass im Rahmen der Kompilierung die Adresse der Library identifiziert und in den Code des referenzierenden Contracts eingebunden wird – wohl zu vergleichen mit „Dynamic Linking“) oder aber eine Funktion der Library wird aufgerufen, die mit dem Schlüsselwort „internal“ gekennzeichnet wurde. Das hat zur Folge, dass bei der Kompilierung (und nicht erst zur Run-Time) der Funktionsquellcode aus der Bibliothek in den referenzierenden Contract geladen und mitkompiliert wird (https://solidity.readthedocs.io/en/v0.4.23/contracts.html#libraries) – aus der Dokumentation: „code of internal library functions and all functions called from therein will at compile time be pulled into the calling contract, and a regular JUMP call will be used instead of a DELEGATECALL“. Der Code der Bibliothek wird also Teil des referenzierenden Contracts (auch verstanden als „Static Linking“). (vgl. auch die Diskussion dazu hier: https://github.com/ethereum/solidity/issues/3985)  [Man könnte erwägen, auch in der zuerst genannten Methode ein „static linking“ zu sehen: Schließlich kann die Adresse des referenzierten Smart Contracts technisch – aufgrund des permanenten unveränderlichen Designs der Blockchain – nicht mehr verändert werden, die Bibliothek ist also faktisch nicht austauschbar.]

Das alles wird lizenzrechtlich vor allem relevant, wenn der Quellcode der Library unter einer GPL- oder LGPL-Lizenz steht. Besonders spannend dabei: Letztendlich ist es nicht eine Entscheidung des Entwicklers des referenzierenden Contracts, ob eine statische oder dynamische Verlinkung erfolgt, sondern vielmehr des Entwicklers der Bibliothek, ob eine Funktion als „internal“ deklariert wird oder nicht.

Bei Verwendung einer unter der LGPL lizenzierten Bibliothek muss der Entwickler des referenzierenden Codes also besonderes Augenmerk auf den tatsächlichen Quellcode der Bibliothek legen, wenn er sein Programm nicht auch unter LGPL lizenzieren möchte.

 

2. Javascript

Ein Blick auf die „Applications“ in obiger Tabelle lässt erkennen, dass für die verschiedenen Programmiersprachen jeweils Compiler für die Smart-Contract-Programmiersprache Solidity entwickelt wurden. Der „Urahn“ dieser Compiler ist SOLC, der in der ursprünglichen C++-Variante Teil des Solidity-Pakets ist und unter der GPL v3 steht.

Um eine Anbindung an Smart Contracts bzw. die Blockchain zum Beispiel auch in Javascript-basierten Webanwendungen zu ermöglichen, wurde ein Javascript-Compiler für Solidity entwickelt (solc-js). Dieser greift auf die Solidity-Binaries (solc-bin) zurück. Solc-bin wurde mithilfe der Emscripten-Anwendung erstellt (diese kann unter anderem über Umwege C++-Code in Javascript umwandeln). Solc-bin steht – wie auch Solidity – unter der GPL v3. Solc-js ruft die jeweils aktuelle Version der Solidity-Binaries aus dem solc-bin-Repositorium ab und macht sie für Webanwendungen verfügbar.

Die Binary-Datei ist nicht Teil des solc-js Repositoriums, sondern wird bei Ausführung des Scripts als soljson.js in das Skript-Verzeichnis kopiert, um die Funktionen im weiteren Verlauf des Programms verwenden zu können. Die Einbindung in solc-js erfolgt – unter Verwendung von Node.js serverseitig – mittels der Funktion „require()“. Diese lädt soljson.js als Modul und macht die Inhalte für das aufrufende Modul verfügbar.

Da die Binaries austauschbar sind (was durch die Wahl der jeweils aktuellsten Version deutlich wird und auch dadurch, dass der Benutzer durch entsprechende Befehle die Version auch manuell festlegen kann) könnte hier ein „Dynamic Linking“ gesehen werden. Und dennoch stehen die Binaries unter GPL v3, was auch bei „Dynamic Linking“ dazu führt, dass das kombinierte Werk (also solc-js) unter die GPLv3 fallen müsste. Solc-js steht jedoch unter der MIT-Lizenz.

Dieses Problem wurde von Entwicklern bereits 2016 erkannt (https://gitter.im/ethereum/solidity/archives/2016/09/10), jedoch scheiterten auch hier bisher die Relizenzierungsversuche (erwogen wurde unter anderem, für SOLC oder SOLC-BIN zumindest eine LGPL-Lizenz einzusetzen). Hinzu kommt, dass in Javascript nicht immer – wie etwa bei C++ oder Java – klare Grenzen zwischen Quell- und Maschinencode gezogen werden können, auch eine Unterscheidung von Compile- und Run-Time zur Einordnung statischer oder dynamischer Verlinkung gelingt nicht sehr einfach.

 

FAZIT.

Die beteiligten Entwickler mögen gute Absichten gehabt haben, Ethereum in allen Facetten durch Verwendung von Open Source-Lizenzen der Allgemeinheit verfügbar zu machen. Dennoch ist es ratsam, in Kontakt zumindest mit Ethereum ein sauberes Lizenzmanagement zu betreiben. Insbesondere wenn eine Anbindung von Ethereum an proprietäre Projekte geplant ist, ist besonderes Augenmerk auf die zugrundeliegenden Lizenzen zu legen. Dieser Artikel kann insofern keine Lösung bieten, sondern nur auf bestehende Missstände aufmerksam machen.