8.1 HAPTIK – gelebte Interdisziplinarität
Der Beitrag ist das Ergebnis der Arbeiten und zugleich Erfahrungsbericht aus dem Verbundforschungsprojekt HAPTIK des Technologieprogramms Smarte Datenwirtschaft, des Bundesministeriums für Wirtschaft und Klimaschutz (BMWK) an der Universität Oldenburg. Gemeinsam mit den Verbundpartnern OFFIS e. V. und DB Schenker wurde hier an der vollständig rechtssicheren Umsetzung elektronischer Konnossemente geforscht und gearbeitet. Bei dem Konnossement handelt es sich um ein Warenwertpapier der internationalen Seefracht. Dessen Besonderheit liegt darin, dass es nicht nur Beweisurkunde über den Transport ist, sondern zugleich das Eigentum an der im Konnossement beschriebenen Ware repräsentiert. Diese, auch als Traditionsfunktion bezeichnete Eigenschaft, macht das Konnossement so bedeutsam für die Handelsfinanzierung. Der physische Besitz an der Urkunde ermöglicht somit zugleich die Eigentumsübertragung an der sich noch auf See befindenden Ware.
Den Projektmitarbeitenden ist es gelungen, prototypisch zu zeigen, dass es möglich ist, unter den Voraussetzungen des geltenden Rechts eine vollständig funktionsäquivalente elektronische Aufzeichnung dieses Konnossements mittels einer Blockchain zu erzeugen und zu handeln. Dabei wurden alle Anforderungen der digitalen Öffnungsklausel für elektronische Konnossemente in § 516 Abs. 2 HGB umgesetzt. Allerdings mussten dabei erhebliche Veränderungen an der eingesetzten Blockchain-Implementierung vorgenommen werden. Die hohen Anforderungen des Rechts führten zu einem regelrechten Bruch mit dem Dogma „Blockchain“ als vollständig dezentral und autonom agierendes Netzwerk. Im Zuge der Arbeiten wurde eine eigene Methodik, das sogenannte „Compliant Programming“ entwickelt, das es ermöglicht, rechtliche Anforderungen schon von Anfang an zu berücksichtigen. Im Folgenden wird auch hierauf näher eingegangen.
Anzeige
8.2 Herkömmliche Softwareentwicklungsmethodik
In herkömmlich organisierten Softwareentwicklungsprojekten wurde bis vor einiger Zeit noch immer das sogenannte „Wasserfallmodell“ praktiziert. Dieses Modell bzw. dessen Beschreibung geht wohl auf die Publikation von Winston W. Royce zurück (1970, S. 1–9). Darin beschreibt er den sequenziellen Durchlauf von fünf verschiedenen Phasen: Analyse, Design, Implementierung, Testen und Wartung. Erst nach Abschluss einer Phase kann in die nächste gewechselt werden. Ebenso ist erst nach Abschluss ein Rückschritt in die vorhergehende Phase möglich. Juristische Anforderungen kommen hier zunächst nicht vor. Allenfalls im Stadium „Design“ könnten auch juristische Fragen untergebracht werden.
In der Praxis ist es jedoch meist so, dass erst nach dem Abschluss aller Entwicklungsarbeiten die Rechtsabteilungen miteinbezogen und um rechtliche Einschätzung gebeten werden. Leider passiert dann häufig Folgendes: Nach der juristischen Überprüfung fällt auf, dass die Anforderungen des Rechts nur zum Teil, im schlimmsten Fall überhaupt nicht berücksichtigt wurden. Schon aus Gründen der Produkthaftung – ja, auch Software unterliegt dem Produkthaftungsgesetz (ProdHaftG) – sollte eine solche Software nicht auf den Markt gebracht werden. Daher müssen die Entwicklungsarbeiten fortgesetzt werden, dieses Mal jedoch unter Berücksichtigung der rechtlichen Anforderungen. Nach Abschluss der erneuten Entwicklung wird diese Anwendung erneut einer juristischen Prüfung unterzogen. Im besten Fall bleibt es bei dieser Iteration. Im schlechtesten Fall muss erneut angesetzt werden. Dies verzögert den Projektabschluss enorm. Zusätzlich entstehen (Mehr-)Kosten für die zusätzlich aufgewendeten Entwicklungsstunden. Nicht zu unterschätzen ist auch der soziale Aspekt zwischen den Disziplinen. In dieser Konstellation nehmen die Entwickelnden ihre Kolleginnen und Kollegen aus den Rechtsabteilungen zu Recht als Bremsende der Entwicklung und Fortschrittsverhindernde wahr. Der Interdisziplinarität und dem Projektfortschritt ist damit ein Bärendienst erwiesen!
8.3 Compliant Programming
Im Gegensatz dazu ermöglicht der im Rahmen des Projekts HAPTIK entwickelte Ansatz des „Compliant Programmings“ die Einbeziehung der juristischen Anforderungen von Beginn an und stärkt somit nicht nur die Produktqualität, sondern auch das Miteinander der Bereiche.
Das Compliant Programming baut auf den Grundsätzen der agilen Projektmethodik Scrum auf. Der Scrum-Prozess wurde erstmals von Schwaber und Sutherland (2017) beschrieben. Stark verkürzt wird bei Scrum der Entwicklungsprozess in kurze Sprints aufgeteilt. Innerhalb dieser Sprints werden Teile des zuvor definierten, aber nicht statischen Anforderungskataloges, dem Product Backlog, herausgegriffen und von dem Entwicklungsteam implementiert. Das Product Backlog selbst wird vom sogenannten Product Owner eigenverantwortlich geführt. Zudem steht der Product Owner im engen Austausch mit dem Entwicklungsteam, um die fachlichen Anforderungen für eine mögliche Umsetzung zu verfeinern. Der Scrum-Master ist dafür zuständig, dass die Regeln des Scrum-Prozesses von allen Beteiligten eingehalten werden. Er sorgt insbesondere dafür, dass die erforderlichen Meetings ihren vorgesehenen Ablauf beibehalten. So dient das Sprint Planning als Planungsmeeting für den bevorstehenden Sprint. Im Daily Scrum informieren sich die Mitglieder gegenseitig über den aktuellen Entwicklungsfortschritt. Im Sprint Review werden die Entwicklungsergebnisse vorgestellt und diskutiert. Im Rahmen der Sprint-Retrospektive wird die Zusammenarbeit der Mitglieder untereinander besprochen und Verbesserungsvorschläge für die weitere Zusammenarbeit ausgearbeitet. Der gesamte Scrum-Prozess legt dabei besonderen Werk auf die gelungene Kommunikation zwischen allen Beteiligten.
Anzeige
Damit ist Scrum prädestiniert für die Einbindung weiterer Disziplinen, insbesondere der Jurisprudenz. Um die oben beschriebenen Probleme der Wasserfallmethode zu vermeiden, sollte die juristische Expertise schon in das Product Backlog einfließen. Juristische Anforderungen sollten dieselbe Wertigkeit erhalten wie funktionale Anforderungen des Anwendungsfalls. Dabei sollte es jedoch nicht bleiben. Gerade juristische Anforderungen sind oftmals zu komplex, um sie in wenigen Worten juristischen Laien verständlich zu machen. Bei der bloßen Benennung im Product Backlog liefe man Gefahr, dass das Entwicklungsteam die Anforderungen nicht oder nur teilweise korrekt umsetzt. Jedes Scrum-Team sollte mit mindestens einer Person mit juristischer Expertise versehen sein, die als permanente Ansprechperson für das gesamte Team und die Auftraggeberin oder den Auftraggeber dient, wenn es um Rechtliches geht.
Im Rahmen des Projekts HAPTIK hat sich dabei die Position des Product Owners als Schlüsselstelle für die Juristinnen und Juristen bewährt (Precht und Saive 2019, S. 591). Als sogenannter Legal Product Owner kann der juristische Sachverstand dauerhaft Einfluss auf die Produktentwicklung nehmen, das Product Backlog füllen und für die Einhaltung des regulatorischen Rahmens sorgen. Auf diese Weise entsteht mit Abschluss des letzten Sprints eine fertige Software, die nicht nur allen Anforderungen des Anwendungsfalls, sondern auch den juristischen Anforderungen genügt.
8.4 Compliant Programming in der Praxis
Im Rahmen von HAPTIK wurde die oben beschriebene Vorgehensweise erstmalig umgesetzt und die Rolle des Legal Product Owners aktiv eingesetzt. Bevor dieser jedoch mit der Befüllung des Product Backlogs beginnen konnte, war zunächst eine umfassende juristische Analyse des Anwendungsfalls „Elektronisches Konnossement“ erforderlich. Compliant Programming ist insofern kein Ersatz zu den Methoden des rechtswissenschaftlichen Arbeitens, insbesondere des Gutachtenstils und der Canones der Auslegung, sondern ein Vehikel zur praktischen Umsetzung der Ergebnisse des rechtswissenschaftlichen Gutachtens.
8.4.1 Domänenspezifische Anforderungen
Ausgangspunkt jeder juristischen Betrachtung sind die originären und unmittelbaren Anforderungen, die sich aus der Domäne selbst ergeben. Für das Forschungsprojekt HAPTIK bedeutete dies, zunächst den Rechtsrahmen papierbasierter und elektronischer Konnossemente zu untersuchen. Entscheidend hierfür ist der bereits anfangs angesprochene § 516 Abs. 2 Handelsgesetzbuch (HGB). Dieser regelt in knappen Sätzen den Umgang mit elektronischen Konnossementen im deutschen Recht. Dabei handelt es sich um wortgleiche Formulierungen zu den weiteren „digitalen Öffnungsklauseln“ im HGB. Konkret heißt es dort: „Dem Konnossement gleichgestellt ist eine elektronische Aufzeichnung, die dieselben Funktionen erfüllt wie das elektronische Konnossement, sofern sichergestellt ist, dass die Authentizität und Integrität der elektronischen Aufzeichnung gewahrt bleiben (elektronisches Konnossement).“
Die Norm ist insoweit instruktiv, als dass sie schon vom Wortlaut ausgehend genau das vorschreibt, was im Kern bei jedem Digitalisierungsprojekt geschehen muss. Zunächst muss eine (juristische) Beschreibung der zu digitalisierenden Funktionen erfolgen. Erst wenn bekannt ist, welche Funktionen das analoge Vorbild erfüllt, können diese ins Digitale überführt werden. Das Konnossement erfüllt als Warenwertpapier der Seefracht gleich mehrere Funktionen: Aufgrund seiner Beweisfunktion gem. §§ 514, 517 HGB besteht die gesetzliche Vermutung, dass die Ware die beschriebene Qualität aufweist; aufgrund der Legitimationsfunktion aus § 519 HGB berechtigt es nur die benannten Empfangenden zur Geltendmachung der inkorporierten Rechte und durch die Sperrfunktion gem. 519 HGB ist eine Geltendmachung dieser Ansprüche nur gegen Vorlage des Konnossements möglich. Die wohl herausforderndste Funktion des Konnossements ist seine Wirkung als Traditionspapier gem. § 524 HGB. Bei einem Traditionspapier handelt es sich um ein Wertpapier, dessen Übergabe die zur Eigentumsübertragung grundsätzlich erforderliche Übergabe der Ware ersetzt. All diese Funktionen müssen durch die elektronische Aufzeichnung des Konnossements erfüllt werden. Ansonsten fehlt es an der Äquivalenz der Funktionen. Kurzum werden die Voraussetzungen von § 516 Abs. 2 HGB auch als schlichte „Funktionsäquivalenz“ bezeichnet.
Darüber hinaus gibt die Norm zugleich ein gewisses Maß an IT-Sicherheit vor. Es muss sichergestellt werden, dass stets die Authentizität und Integrität der elektronischen Aufzeichnung gewahrt bleiben. Damit wird zumindest der Einsatz fortgeschrittener elektronischer Signaturen i. S. d. Art. 3 Nr. 12 Verordnung (EU) Nr. 910/2014 über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt und zur Aufhebung der Richtlinie 1999/93/EG (eIDAS-VO) vorausgesetzt.
8.4.2 Sonstige Anforderungen des Rechts
Neben den rechtlichen Besonderheiten des Anwendungsfalls gelten jedoch auch die sonstigen Anforderungen des Rechts fort. Hier ist eine umfassende und abschließende Analyse aller berührten Rechtsgebiete erforderlich. Nur so kann konkret festgestellt werden, welche Anforderungen an die zu entwickelnde Software gestellt werden.
Am Beispiel des Konnossements bedeutet dies, dass eben nicht bei der Funktionsäquivalenz als solches stehengeblieben werden kann. Das oben schon angesprochene IT-Sicherheitsniveau muss mit Leben gefüllt werden. Überdies ist bei der IT-gestützten Verarbeitung von personenbezogenen Daten stets ein Blick auf das Datenschutzrecht erforderlich. (s. Abschn. 9.3.2, s. auch Abschn. 13.3). Des Weiteren können Aspekte des Telemedien- und Telekommunikationsrechts berührt werden. Nicht zuletzt können auch originär strafrechtliche Aspekte eine Rolle spielen. Überdies muss das regulatorische Umfeld im Auge behalten werden. Gerade bei einem Warenwertpapier, das eine entscheidende Rolle in der Außenhandelsfinanzierung spielt, wie es bei dem Konnossement der Fall ist, müssen ggf. auch Anforderungen der Geldwäscheprävention und anderer Gebiete Rechnung getragen werden.
8.5 Compliant Programming in der Blockchain
Nachdem die Anforderungen der Domäne sowie der damit zusammenhängenden Rechtsgebiete untersucht wurden, müssen diese Erkenntnisse auf die Blockchain-Technologie und ihre Besonderheiten angepasst werden. Ein Bruch mit dem Dogma der Blockchain als vollständig dezentrales Netzwerk ohne zentrale Instanz oder Überwachung ist dabei quasi unumgänglich (Saive 2019, S. 53). Im Folgenden werden die wesentlichen Ergebnisse des Forschungsprojekts HAPTIK kurz vorgestellt. Für die Details wird auf die jeweiligen Veröffentlichungen verwiesen.
8.5.1 Zivilrecht
Da es sich bei dem Konnossement um ein Warenwertpapier des Handelsrechts und damit um einen Gegenstand des Zivilrechts handelt, bildet der Ausgangspunkt dieser Betrachtung zunächst die zivilrechtlichen Herausforderungen der Blockchain. Dies ist jedoch keineswegs zwingend erforderlich. Nicht jeder Anwendungsfall ist zivilrechtlicher Natur. Hier ist unbedingt eine Entscheidung im Einzelfall erforderlich.
Für die Blockchain eröffnen sich gleich mehrere Problemfelder. Zunächst stellt sich die Frage nach dem wirksamen Vertragsschluss auf der Blockchain. Dafür muss jedoch zuerst die Frage beantwortet werden, ob schon der Vertragsschluss selbst über die Blockchain erfolgen soll oder die Blockchain nur zur Dokumentation einer bereits zuvor erfolgten Einigung der Vertragsparteien dienen soll (s. Abschn. 11.2.1). Ebenso muss unterschieden werden, ob der volle Vertragsinhalt bzw. Inhalt der Willenserklärungen auf der Blockchain abgebildet werden („on chain“) oder nur ein Hash dieser Informationen auf der Blockchain abgelegt werden soll („off chain“). Nur wenn bereits der Vertragsschluss mittels blockchainbasierter Willenserklärung erfolgen soll, kommt es auf die folgenden Ausführungen an.
Der Vertragsschluss setzt zwei aufeinander gerichteten Willenserklärungen über die Begebung eines Konnossements (Angebot und Annahme) voraus (Eckert 2021, Rn. 2). Das Angebot bzw. der Antrag i. S. d. § 145 Bürgerliches Gesetzbuch (BGB) ist eine empfangsbedürftige Willenserklärung, die auf den Vertragsschluss abzielt (Eckert 2021, Rn. 2). Diese kann nach herrschender Meinung auch elektronisch abgegeben werden (BGH 2002; Singer 2017, Rn. 57). Der erklärte Antrag entfaltet seine Bindungswirkung gem. § 130 BGB mit Zugang beim Empfänger. Eine Willenserklärung gilt dann als abgegeben, wenn nach außen hin mit Wissen und rechtlichem Wollen des Erklärenden dergestalt für andere wahrnehmbar gemacht wird, dass an der Endgültigkeit der Äußerung kein vernünftiger Zweifel mehr bestehen kann (Wendtland 2021, Rn. 5), der Absender also alles dafür getan hat, dass die Willenserklärung wirksam werden kann (Einsele 2021, Rn. 13 f.). Auf der Blockchain entspricht die Abgabe einer Willenserklärung einer Transaktion. Diese Transaktion wird erst dann ausgeführt, wenn der Abladende oder Befrachtende seine Erklärung mit seinem Private Key signiert. Dies gilt für jede Form der blockchainbasierten Abgabe von Willenserklärungen (Heckelmann 2018, S. 505). Erst mit Absendung dieser Transaktion können die Nodes die Transaktion verifizieren, validieren und der Inhalt der Transaktion schlussendlich von den Empfangenden und dem gesamten Netzwerk angenommen werden.
Damit die Willenserklärung wirksam werden kann, muss sie den Empfangenden auch zugehen. Für den Zugang muss sie so in dessen Machtbereich gelangt sein, dass damit zu rechnen ist, dass er von ihr Kenntnis nehmen kann (BGH 1977; Einsele 2021, Rn. 13 f.). Daraus folgt, dass eine blockchainbasierte Willenserklärung mit dem Empfang der Transaktionsinformationen bei den Adressaten zugegangen ist (BMVI 2019, S. 114). Dies gilt unabhängig von der Konzeption des Netzwerks, da die Möglichkeit der Kenntnisnahme der Transaktionsinformationen nicht in anderer Form auf der Blockchain dargestellt werden kann.
Das Wissen um diese Zeitpunkte ist bei der Implementierung von enormer Bedeutung. Es muss sichergestellt werden, dass die Transaktion den vollständigen Inhalt der Willenserklärung enthält und von der empfangenden Node entsprechend verarbeitet werden kann. Zudem ist dies wichtig für die Erfüllung ggf. bestehender Informationspflichten, die zum Beispiel aus dem Fernabsatzrecht resultieren können. Bedient sich zum Beispiel eine Unternehmerin oder ein Unternehmer i. S. d. § 13 BGB der Blockchain, um gem. § 312i BGB einen Vertrag im elektronischen Geschäftsverkehr einzugehen, so müssen den Kundinnen und Kunden die Informationen aus § 312i Abs. 1 S. 1 BGB bereits bei Vertragsschluss bereitgestellt werden. Zudem muss über die einzelnen technischen Schritte, die zum Vertragsschluss führen, gem. Art. 246c Einführungsgesetz zum BGB (EGBGB) dezidiert informiert werden. Dies ist ohne Kenntnis der Funktionsweise einer Blockchain nicht möglich.
8.5.2 Telemedienrecht
Blockchainbasierte Anwendungen sind grundsätzlich als Telemedium i. S. d. § 1 Abs. 1 Telemediengesetz (TMG) (Saive 2018a, S. 188) einzuordnen. Die hinter einer Node einer Blockchain stehenden natürlichen oder juristischen Personen nehmen dabei eine Mehrfachrolle aus Anbietenden und Nutzenden der jeweiligen Blockchain wahr. Aufgrund der Tatsache, dass die Nodes ein vollständiges Abbild der Netzwerkinhalte speichern und dieses Abbild innerhalb des verteilten Netzwerks anbieten, handelt es sich bei ihnen um Diensteanbieterinnen und Diensteanbietern i. S. d. § 2 Nr. 1 TMG. Dies hat zur Folge, dass die Haftungsprivilegierungen der §§ 7 ff. TMG zur Anwendung gelangen. Dementsprechend muss hinsichtlich der Privilegierung sorgsam geprüft werden, ob es sich bei den gespeicherten Daten um eigene oder fremde Informationen der Nodes handelt. Diese Prüfung muss im Voraus der Errichtung des Netzwerks erfolgen, da eigene oder fremde Informationen, von deren Rechtswidrigkeit die Anbietenden gem. § 10 Abs. 2 TMG Kenntnis bekommen haben, ggf. Gegenstand eines Löschungsanspruchs sein können. Aufgrund der weitestgehend bestehenden Irreversibilität der Blockchain sollte eine dahingehende Risikoanalyse durchgeführt werden, bevor solche Informationen in Klarform in ein blockchainbasiertes Netzwerk abgelegt werden.
8.5.3 Datenschutzrecht
Selbiges gilt auch aus der Perspektive des Datenschutzrechts. Dies ist sogar gesetzlich normiert. Art. 25 EU-Datenschutzgrundverordnung (DSGVO) schreibt Datenschutz durch Technikgestaltung vor. Daher ist nicht nur eine Risikoanalyse vor dem Hintergrund der allgemeinen Haftungsrisiken vonnöten, sondern auch eine genaue Bestimmung, ob und welche personenbezogenen Daten in die Blockchain abgelegt werden sollen.
Dabei muss unbedingt das weite Verständnis der DSGVO von personenbezogenen Daten berücksichtigt werden. Schon die Beziehbarkeit eines Datums auf eine Person ist hierfür ausreichend. Dementsprechend werden nach derzeit geltendem Verständnis die Public Keys von natürlichen Personen entsprechend der Rechtsprechung zu IP-Adressen als personenbezogenes Datum eingeordnet (Janicki und Saive 2019, S. 252). Somit verarbeitet jedes Blockchain-Netzwerk personenbezogene Daten, sobald natürliche Personen eigene Public Keys zugeteilt bekommen, mit denen sie Transaktionen innerhalb des Netzwerks absenden und empfangen können (s. Abschn. 10.3.2).
Zudem müssen die Spezifika des Anwendungsfalls berücksichtigt werden. Wenn dieser bereits aus sich heraus die Verarbeitung personenbezogener Daten vorsieht – wie im Falle von HAPTIK zum Beispiel die persönlichen Angaben von Absendenden und Empfangenden der Ware sowie der unterzeichnenden Person (Janicki und Saive 2019, S. 203) – muss auch hier Vorsicht walten gelassen werden. Die DSGVO gibt dem Individuum in den Art. 17 und 18 DSGVO verschiedene Rechte an die Hand, auf bestehende Datenverarbeitungsprozesse Einfluss zu nehmen, diese sogar ganz zu untersagen. Dabei steht vor allem das Recht auf Löschung aus Art. 17 DSGVO in offensichtlichem Widerspruch mit dem Dogma der Irreversibilität einer Blockchain. Hier bestehen nun zwei Lösungsansätze: Entweder es wird vollständig auf die Verarbeitung personenbezogener Daten verzichtet („off chain“) oder eine Möglichkeit der Löschung, z. B. durch „chameleon hashes“ implementiert (Saive 2018a, b, S. 766).
Allerdings ist nicht zwangsläufig Dringlichkeit geboten. In manchen Fällen stehen regulatorische, insbesondere die bilanz- und abgabenrechtliche Aufbewahrungspflichten aus § 257 HGB bzw. § 147 Abgabenordnung (AO) einer unmittelbaren Veränderung oder gar Löschung entgegen (Janicki und Saive 2019, S. 207). Auch hier ist wiederum eine saubere juristische Prüfung vor der Implementierung erforderlich, ob und wie lange die Informationen der Blockchain tatsächlich aufbewahrt werden müssen.
Auf der anderen Seite kann die Blockchain bzw. ein darin implementierter „smart contract“ auch gerade dazu genutzt werden, Datenschutz wirksam umzusetzen. So ist es z. B. möglich, über die Blockchain sog. Auftragsverarbeitungsverträge i. S. d. Art. 28 DSGVO automatisch einzugehen (Janicki und Precht 2020, S. 626 ff.).
8.5.4 Kartellrecht
Eine solche vorgreifende Pflicht zur Einhaltung rechtlicher Rahmenbedingungen findet sich jedoch nicht nur im Datenschutzrecht. Wie Louven zu Recht vorschlägt, sollte der „by design“-Ansatz aus Art. 25 DSGVO auch auf andere Rechtsgebiete, insbesondere auf das Kartellrecht übertragen werden (Louven 2018, S. 488). Dies folgt bereits aus dem kartellrechtlichen Selbstständigkeitspostulat und der Selbstveranlagung bei der Einhaltung der kartellrechtlichen Vorschriften (Louven 2018, S. 488).
Bei der Blockchain-Technologie bestehen gleich mehrere Anknüpfungspunkte für möglich Kartellrechtsverstöße. Zum einen könnte schon der Informationsaustausch über die Blockchain dem Prinzip des Geheimniswettbewerbs (Louven 2019, S. 703) widersprechen (Louven und Saive 2018, S. 349). Diese verbietet gerade einen zu großen Informationsaustausch zwischen Wettbewerberinnen und Wettbewerbern, um ein gesundes, weil innovationsförderndes Misstrauen (daher der Begriff „antitrust“) beizubehalten. Dies müssen nicht immer offenkundige Sachverhalte wie beispielsweise der Austausch über Preise sein. Jede Information kann grundsätzlich von kartellrechtlicher Relevanz sein.
Um das zu verdeutlichen, ein konkretes Beispiel aus der Domäne von HAPTIK: Würde über die Blockchain bekannt, dass die marktbeherrschende Spedition A für die Erstellung des Konnossements stets einen Tag benötigt, so würde der Anreiz für alle weiteren Speditionen entfallen, diesen Prozess zu beschleunigen, wenn sie selbst bereits weniger als einen Tag dafür benötigen. Der Wettbewerb wäre an dieser Stelle gelähmt.
Des Weiteren bietet der Konsensmechanismus der Blockchains selbst Anlass zur kartellrechtlichen Untersuchung (Louven und Saive 2018, S. 351). Es muss streng darauf geachtet werden, dass durch den Konsensalgorithmus selbst keine verbotene Koordinierung bzw. Benachteiligung oder Bevorzugung bestimmter Transaktionen oder Nodes erfolgt. Dies ist anhand einer strengen Prüfung des Einzelfalls festzustellen.
Überdies könnte in permitted-Architekturen auch der zentralen Instanz kartellrechtliche Bedeutung zuwachsen, wenn diese es zum Beispiel bestimmten Unternehmen nicht ermöglicht, an der Blockchain mitzuwirken, obwohl dies kartell- bzw. wettbewerbsrechtlich geboten wäre (Louven und Saive 2018, S. 351).
8.5.5 Produkthaftungsrecht
Nach mittlerweile wohl herrschender Auffassung in der Rechtswissenschaft unterfällt Software grundsätzlich dem Produktbegriff aus § 2 ProdHaftG (Rebin 2021, Rn. 54; Taeger 1996, S. 270). Dementsprechend trifft die Herstellerinnen und Hersteller von Software die Haftung aus § 1 Abs. 1 ProdHaftG. Diese Haftung ist insbesondere gem. § 1 Abs. 2 ProdHaftG dann ausgeschlossen, wenn sie das Produkt nicht in den Verkehr gebracht haben oder nach den Umständen davon auszugehen ist, dass das Produkt den Fehler, der den Schaden verursacht hat, noch nicht hatte, als es in den Verkehr gebracht wurde, oder das Produkt in dem Zeitpunkt, in dem es in den Verkehr gebracht wurde, zwingenden Rechtsvorschriften oder dem Stand der Wissenschaft und Technik entsprach.
Bei einer so neuen Technologie wie der Blockchain ist hier insbesondere die Frage nach dem Stand der Wissenschaft und Technik von großer Bedeutung. Wie vergangene Fälle eindrucksvoll gezeigt haben, bestehen noch einige unbekannte Vulnerabilitäten, die bei der Implementierung berücksichtigt werden müssen (Tagesschau 2021).
Das Produkthaftungsrecht zwingt also dazu, mehr als „nur“ eine Überprüfung der betroffenen Rechtsgebiete vorzunehmen. Darüber hinaus muss bei der Implementierung der aktuelle Stand von Wissenschaft und Technik festgestellt und dann entsprechend umgesetzt werden.
8.5.6 Weitere Rechtsgebiete
An dieser Stelle darf keinesfalls stehengeblieben werden. Es ist denkbar und äußerst wahrscheinlich, dass der konkrete Anwendungsfall weitaus mehr oder völlig andere Rechtsgebiete berührt. Daher muss von vornherein eine saubere und abschließende Analyse des Anwendungsfalls erfolgen, damit in der Folge auch eine vollständige Analyse aller rechtlichen Voraussetzungen erfolgen kann. Nur dann ist dem Entwicklungsteam möglich, das Compliant Programming überhaupt in die Tat umsetzen zu können.
Zusätzlich muss eine laufende Überprüfung stattfinden, ob die juristischen Anforderungen noch dem aktuellen Stand von Rechtsprechung und Gesetz entsprechen. Das Recht unterliegt ständigem Wandel. Dies setzt insofern eine gewisse Agilität voraus, damit ad hoc auf neue Entwicklungen reagiert werden kann.
8.6 Fazit
Der Beitrag konnte zeigen, dass gerade bei der Verwendung der Blockchain rechtliche Aspekte berührt werden, die auf den ersten Blick nur wenig mit dem eigentlichen Anwendungsfall der Technologie zu tun haben. Dies bedeutet allerdings nicht, dass Blockchain-Projekte aufgrund des bestehenden rechtlichen Rahmens von vornherein zum Scheitern verurteilt sind. Ganz im Gegenteil entstehen durch die konsequente interdisziplinäre Zusammenarbeit von Rechtswissenschaft und Informatik gänzlich neue Ideen, wie Rechtssicherheit durch Technikgestaltung erzeugt wird. Ein Legal Product Owner mit juristischer Expertise der dem herkömmlichen Product Owner gegenübersteht ist ein zielführender Ansatz um rechtliche und funktionale Anforderungen schon während der Entwicklung von Software-Projekten in Einklang zu bringen.
Grundvoraussetzung hierfür ist allerdings eine gewisse Offenheit seitens der beiden Disziplinen für die Eigenarten der jeweils anderen. Juristinnen und Juristen müssen lernen, juristische Anforderungen in Form von User Stories und anderen Einträgen in Product Backlogs zu formulieren. Umgekehrt müssen die Entwicklerinnen und Entwickler lernen, die eigene technische Umgebung zu beschreiben. Gefordert wird im Kern eine gegenseitige Übersetzungsarbeit. Gelingt dies, steht auch dem Projekterfolg nichts mehr im Wege.
Danksagung
Der Autor bedankt sich für die Förderung des Projektes HAPTIK (Förderkennzeichen: 01MT 19001D) durch das Bundesministerium für Wirtschaft und Klimaschutz im Rahmen des Förderprogramms Smarte Datenwirtschaft.
Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.