Dezentrale Anwendungen in der Sharing Economy: Marktzugang, Verbraucherschutz, Haftung [1 ed.] 9783737016063, 9783847116066


124 37 3MB

German Pages [191] Year 2023

Report DMCA / Copyright

DOWNLOAD PDF FILE

Recommend Papers

Dezentrale Anwendungen in der Sharing Economy: Marktzugang, Verbraucherschutz, Haftung [1 ed.]
 9783737016063, 9783847116066

  • 0 0 0
  • Like this paper and download? You can publish your own PDF file online for free in a few minutes! Sign Up
File loading please wait...
Citation preview

Kai Georg Hindahl

Dezentrale Anwendungen in der Sharing Economy Marktzugang, Verbraucherschutz, Haftung

V&R unipress Universitätsverlag Osnabrück

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über https://dnb.de abrufbar. Veröffentlichungen des Universitätsverlags Osnabrück erscheinen bei V&R unipress. © 2023 Brill | V&R unipress, Robert-Bosch-Breite 10, D-37079 Göttingen, ein Imprint der Brill-Gruppe (Koninklijke Brill NV, Leiden, Niederlande; Brill USA Inc., Boston MA, USA; Brill Asia Pte Ltd, Singapore; Brill Deutschland GmbH, Paderborn, Deutschland; Brill Österreich GmbH, Wien, Österreich) Koninklijke Brill NV umfasst die Imprints Brill, Brill Nijhoff, Brill Hotei, Brill Schöningh, Brill Fink, Brill mentis, Vandenhoeck & Ruprecht, Böhlau, V&R unipress und Wageningen Academic. Alle Rechte vorbehalten. Das Werk und seine Teile sind urheberrechtlich geschützt. Jede Verwertung in anderen als den gesetzlich zugelassenen Fällen bedarf der vorherigen schriftlichen Einwilligung des Verlages. Vandenhoeck & Ruprecht Verlage | www.vandenhoeck-ruprecht-verlage.com ISBN 978-3-7370-1606-3

Inhalt

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I. Eingrenzung des Untersuchungsgegenstandes . . . . . . II. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . III. Die Sharing Economy im Überblick . . . . . . . . . . . IV. Technische Grundlagen von Dezentralen Anwendungen V. Dezentrale Anwendungen in der Sharing Economy . . . VI. Gang der Untersuchung . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

9 10 11 11 13 14 15

Teil 1: Regulierung plattformbasierter Modelle . . . § 1 Marktzugangsregulierung . . . . . . . . . . . I. Personenbeförderung . . . . . . . . . . . II. Kurzzeitvermietung . . . . . . . . . . . . 1. Beschränkungen nach GewO . . . . . 2. Zweckentfremdungsgesetze der Länder III. Zwischenergebnis . . . . . . . . . . . . . § 2 Verbraucherschutz . . . . . . . . . . . . . . . I. Informationspflichten . . . . . . . . . . . II. Designpflichten . . . . . . . . . . . . . . § 3 Haftung der Plattformen . . . . . . . . . . . I. Verletzung von Schutzpflichten . . . . . II. Haftung bei maßgeblichem Einfluss . . . § 4 Ergebnis zu Teil 1 . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

17 17 18 22 23 24 25 25 26 29 31 31 32 36

Teil 2: Dezentrale Anwendungen der Sharing Economy . . . . . . . . § 5 Veränderung bestehender und Entstehung neuer Rechtsfragen I. Marktzugangsregulierung . . . . . . . . . . . . . . . . . . . II. Verbraucherschutz . . . . . . . . . . . . . . . . . . . . . . III. Haftung . . . . . . . . . . . . . . . . . . . . . . . . . . . . § 6 Marktzugang . . . . . . . . . . . . . . . . . . . . . . . . . . . . I. Sektorspezifische Schranken . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

37 37 38 40 41 42 43

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

6

Inhalt

1. Schranken für Dienste der Informationsgesellschaft . . . . 2. Personenbeförderung . . . . . . . . . . . . . . . . . . . . a. Genehmigungsbedürftigkeit . . . . . . . . . . . . . . . aa. Entwickler als Unternehmer i. S. d. PBefG . . . . . . . bb. Erweiternde Auslegung . . . . . . . . . . . . . . . . . cc. Analoge Anwendung des § 2 I PBefG . . . . . . . . . . (1) Planwidrige Regelungslücke . . . . . . . . . . . . . . . (2) Vergleichbare Interessenlage . . . . . . . . . . . . . . b. Sonstige Vorschriften des PBefG . . . . . . . . . . . . aa. Atypischer Verkehr . . . . . . . . . . . . . . . . . . . bb. Umgehungsverbot, § 6 PBefG . . . . . . . . . . . . . . cc. Zwischenergebnis . . . . . . . . . . . . . . . . . . . . 3. Kurzzeitvermietung . . . . . . . . . . . . . . . . . . . . . a. Normadressat des § 5 VI ZwVbG Berlin . . . . . . . . b. Normadressat des § 5 II Nr. 2 und 5 ZwVbG Berlin . . c. Sektorübergreifende Gefahrenabwehr . . . . . . . . . 4. Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . . . II. Kapitalmarktrechtliche Schranken . . . . . . . . . . . . . . . 1. Finanzierung von dezentralen Anwendungen . . . . . . . 2. Kapitalmarktrechtliche Aufsicht . . . . . . . . . . . . . . . a. Investment-und Currency-Token . . . . . . . . . . . . aa. Currency-Token . . . . . . . . . . . . . . . . . . . . . bb. Investment-Token . . . . . . . . . . . . . . . . . . . . b. Utility-Token . . . . . . . . . . . . . . . . . . . . . . . aa. Vergleichbarkeit zu bisherigen Wertpapieren . . . . . bb. Kategorisierung von Utility-Token . . . . . . . . . . . cc. Wirtschaftliche Gefährdungslage von Käufern . . . . . c. Kapitalmarkttypische Gefährdung . . . . . . . . . . . d. Einheitliche Kategorisierung von Token . . . . . . . . e. Prospektpflicht für Utility-Token . . . . . . . . . . . . f. Internationale Angebote . . . . . . . . . . . . . . . . . 3. Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . . . § 7 Verbraucherschutz . . . . . . . . . . . . . . . . . . . . . . . . . . I. Informationspflichten . . . . . . . . . . . . . . . . . . . . . . 1. Anwendungsentwickler als Verpflichteter . . . . . . . . . a. Verpflichtungen bei Veröffentlichung der Blockchain b. Verpflichtungen bei neuen Funktionen . . . . . . . . 2. Nodes als Verpflichtete . . . . . . . . . . . . . . . . . . . . II. Designpflichten . . . . . . . . . . . . . . . . . . . . . . . . . 1. Anwendungsentwickler . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43 44 44 44 48 48 49 50 54 54 55 57 57 58 58 62 65 65 66 67 68 68 69 71 71 73 75 77 80 81 83 85 85 86 86 86 89 93 93 93

Inhalt

2. Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a. Nodes als Host-Provider . . . . . . . . . . . . . . . . . . b. Miner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Verantwortlicher i. S. d. Gesetzes über digitale Dienste . . . III. Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . . . . . § 8 Haftung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I. Haftung des Entwicklers . . . . . . . . . . . . . . . . . . . . . 1. Vertragliche Haftung . . . . . . . . . . . . . . . . . . . . . . a. Vertragliche Beziehungen bei Überlassung der DApp . . aa. Lizenzvertrag . . . . . . . . . . . . . . . . . . . . . . . . bb. Vertragspartner bei Verwendung eines App-Stores . . . 1) Empfängerhorizont des Nutzers . . . . . . . . . . . . . 2) Rechtsbindungswille des Entwicklers . . . . . . . . . . . 3) Erklärung des App-Store-Betreibers . . . . . . . . . . . 4) Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . cc. Fälle fehlender Transparenz . . . . . . . . . . . . . . . . dd. Vertragspartner ohne Verwendung eines App-Stores . . 1) Entwickler als Vertragspartner . . . . . . . . . . . . . . 2) Dritter als Vertragspartner . . . . . . . . . . . . . . . . ee. Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . b. Pflichtverletzungen . . . . . . . . . . . . . . . . . . . . . c. Haftungsmaßstab . . . . . . . . . . . . . . . . . . . . . aa. Allgemeiner Haftungsmaßstab . . . . . . . . . . . . . . bb. Übertragung gesetzlicher Haftungsprivilegien . . . . . . cc. Haftungsmaßstab bei Schutzpflichtverletzungen . . . . d. Schaden . . . . . . . . . . . . . . . . . . . . . . . . . . . e. Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . 2. Produkt-und Produzentenhaftung für fehlerhafte Software . a. Produzentenhaftung . . . . . . . . . . . . . . . . . . . . aa. Betroffene Rechtsgüter . . . . . . . . . . . . . . . . . . . bb. Verletzungshandlung und Verkehrssicherungspflichten . 1) Konstruktionsfehler . . . . . . . . . . . . . . . . . . . . 2) Fabrikation-und Instruktionsfehler . . . . . . . . . . . . 3) Produktbeobachtungspflicht . . . . . . . . . . . . . . . cc. Vertretenmüssen und Beweislastumkehr . . . . . . . . . dd. Zwischenergebnis . . . . . . . . . . . . . . . . . . . . . b. Produkthaftung . . . . . . . . . . . . . . . . . . . . . . 3. Haftung bei maßgeblichem Einfluss . . . . . . . . . . . . . . II. Haftung der Node-Betreiber . . . . . . . . . . . . . . . . . . . 1. Haftung als Gesellschaft . . . . . . . . . . . . . . . . . . . .

7 97 99 100 102 102 104 104 105 105 105 106 106 109 110 111 111 112 112 112 113 114 115 115 117 118 120 120 120 121 121 125 126 130 131 135 136 136 140 143 143

8

Inhalt

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

144 145 147 147 148 149 149 150 153 155

Teil 3: Handlungsoptionen für eine Anpassung des Regulierungsrahmens . . . . . . . . . . . . . . . . . § 9 Spannungsfeld Regulierung und Innovation . § 10 Marktzugangsbeschränkungen . . . . . . . . § 11 Verbraucherschutz . . . . . . . . . . . . . . . § 12 Haftung . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

157 158 159 163 167

Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

171

Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

175

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179

a. Gemeinsamer Zweck b. Gesellschaftsvertrag 2. Vertragliche Haftung . . a. Nodes . . . . . . . . b. Miner . . . . . . . . 3. Deliktische Haftung . . a. Miner . . . . . . . . b. Nodes . . . . . . . . 4. Rechtsdurchsetzung . . III. Zwischenergebnis . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Einleitung »The Law of the Horse is doomed to be shallow and to miss unifying principles« Frank H. Easterbrook1

Wann immer sich eine neue Technologie verbreitet und früher oder später die Aufmerksamkeit von Rechtswissenschaftlern erlangt, wird über das von Easterbrook sogenannte »Law of the Horse« diskutiert. Dabei geht es letztendlich immer um die Frage, ob die neue Technologie eines neuen Rechtsrahmens bedarf oder nicht vielmehr die bestehenden Gesetze ausreichend sind, um auch die veränderten Sachverhalte zu erfassen. Das gilt insbesondere in Deutschland mit Blick auf das BGB, welches zwar immer wieder Änderungen unterlag, aber in seinem Kern bereits den Aufstieg des Automobils und des Internets miterlebt hat. Und selbst das PBefG ist in seinen wesentlichen Teilen seit 1934 gleich geblieben. Der Ruf der Rechtswissenschaftler nach einer neuen Regulierung wirkt dabei teilweise zu voreilig und ohne sichere Erkenntnisse über die Technologie und die tatsächlichen Anforderungen an eine neue Regulierung. Mit dem Aufstieg der Blockchain-Technologie seit 2008 steht möglicherweise der nächste große technologische Fortschritt bevor und damit auch eine neue Herausforderung für unser Rechtssystem.2 Erneut stellt sich die Frage, ob ein neuer Rechtsrahmen geschaffen werden soll oder das bisherige Recht nach wie vor geeignet ist, um mit der technologischen Evolution umgehen zu können. Im Rahmen dieser Arbeit wird der Frage nachgegangen, in welchem Umfang das geltende Recht geeignet ist, die neuen Herausforderungen zu bewältigen und in welchem Umfang es anpassungsbedürftig ist.

1 Frank H. Easterbrook, University of Chicago Legal Forum 1996, 207. 2 Die Erfindung der Blockchain wird dem Pseudonym Satoshi Nakamoto zugerechnet, der 2008 das Whitepaper »Bitcoin: A Peer-to-Peer Electronic Cash System« schrieb und damit die erste Kryptowährung auf blockchainbasis schuf.

10

I.

Einleitung

Eingrenzung des Untersuchungsgegenstandes

Es sollen nicht sämtliche rechtliche Rahmenbedingungen der BlockchainTechnologie diskutiert werden. Vor allem im Bereich von Bitcoin und sonstigen Kryptowährungen finden sich bereits hinreichend Arbeiten, die sich mit den allgemeinen Fragen der Technologie beschäftigen.3 Stattdessen soll ein konkretes Geschäftsmodell untersucht werden: die Verwendung von dezentralen Anwendungen in der Sharing Economy. Statt auf die Technologie insgesamt einzugehen, wird ein wirtschaftliches Geschäftsmodell aus unterschiedlichen Blickwinkeln betrachtet werden. Indem die Blockchain-Technologie verspricht den zentralen Intermediär zu ersetzen, bieten sich für diesen Ansatz alle Systeme an, in denen ein zentraler Intermediär für den funktionsfähigen Markt entscheidend ist. Die Sharing Economy bietet Fragen für eine Bandbreite von Rechtsgebieten und ist mittlerweile ein etabliertes Geschäftsmodell, dessen Rechtsfragen bereits ausführlich diskutiert werden.4 Auf dieser Diskussion soll aufgebaut und betrachtet werden, wie sich die Rechtsprobleme allein dadurch verändern, dass das Geschäftsmodell nicht mehr auf dem Internet basiert, sondern auf einer dezentralen Anwendung. Der Fokus liegt dabei auf den beiden bekanntesten Geschäftsfeldern der Sharing Economy: der Personenbeförderung und der Kurzzeitvermietung. Repräsentativ für diese Geschäftsfelder stehen die Modelle von Uber und Airbnb. Es sollen auch nicht alle denkbaren Rechtsprobleme untersucht werden, sondern die, die einen Querschnitt aus öffentlichem und Zivilrecht darstellen. Zugleich sollen die ausgewählten Rechtsgebiete auch eine repräsentative Auswahl von Fragestellungen umfassen, um die daraus gewonnenen Ergebnisse auch auf Rechtsfragen jenseits der Sharing Economy übertragen zu können. Die dezentralen Anwendungen in der Sharing Economy werden bezüglich Marktzugangsbeschränkungen, Grundsätzen von Verbraucherverträgen und der vertraglichen und deliktischen Haftung untersucht. Insbesondere Steuerrecht und Datenschutzrecht wurden von der Untersuchung ausgeklammert. Sie stellen jeweils für sich spezielle Regelungsregime dar, bei denen nicht in vergleichbarer Weise verallgemeinerungsfähige Erkenntnisse zu erwarten sind und auch nicht im Vordergrund der Diskussion zur Sharing Economy stehen. Im Übrigen wird auf sonstige Rechtsgebiete nur dann eingegangen, wenn es für die Argumentation in den behandelten Bereichen erforderlich ist.

3 Für viele weitere: Hofert, Regulierung der Blockchain; Scherer, Blockchain im Wertpapierbereich; Paal/Fries, Smart Contracts. 4 Bspw.: Zott, EuCML 2020, 252; EuGH Urt. v. 22. 9. 2020-C-724/18 und C-727/18; Busch u.w., Sharing Economy in Deutschland; im größeren Kontext der Plattformwirtschaft: Busch u.w., EuCML 2020, 61ff.; Schulte-Nölke, Plattformverträge und Vertrauensschutz, 167.

Die Sharing Economy im Überblick

11

Ebenfalls nicht behandelt werden Fragen des internationalen Privatrechts. Das Geschäftsmodell wird auf Grundlage des deutschen Rechts untersucht. Soweit es für die Argumentation und die Auslegung des deutschen Rechts ausschlaggebend ist, wird zudem Vorgaben des Unionsrechts eingegangen.

II.

Zielsetzung

Die Untersuchung von dezentralen Anwendungen in der Sharing Economy hat sowohl konkrete als auch abstrakte Ziele. Zunächst soll der geltende Rechtsrahmen für dieses Geschäftsmodell untersucht werden und dabei sowohl für Anbieter von dezentralen Anwendungen als auch den Regulatoren Erkenntnisse bringen, welche Anforderungen nach derzeitigem Recht erfüllt werden müssen. Die Untersuchung soll dazu beitragen, dass neue Entwickler einerseits gezielt auf die rechtlichen Rahmenbedingungen bei der Entwicklung der Anwendung eingehen können, andererseits aber auch einen Überblick über mögliche Haftungsrisiken bekommen. Langfristig soll die Rechtssicherheit zur Förderung von dezentralen Anwendungen in der Sharing Economy und darüber hinaus auf sonstigen Verbrauchermärkten dienen. Die Kehrseite zur Rechtssicherheit der Entwickler ist die Schaffung einer Basis für Regulatoren, die sich bei Markteintritt solcher Anwendungen mit einer neuen und, für die Mehrheit der Bevölkerung, komplizierten Technologie konfrontiert sehen. Für Belange der öffentlichen Regulierung soll diese Arbeit zeigen, in welchem Rahmen Anwendungen unter Marktzugangsbeschränkungen fallen können und welche Probleme sich bei der Subsumtion dieser Geschäftsmodelle unter bisherige Schranken stellt. Auf abstrakter Ebene zeigt die Untersuchung des konkreten Geschäftsmodells die Probleme der bisherigen Gesetzgebung beim Umgang mit dezentralen Systemen und einer Vielzahl von, weitestgehend anonymen, Beteiligten. Durch die Subsumtion von dezentralen Anwendungen in der Sharing Economy unter geltendes Recht kann festgestellt werden, ob Lücken bei der Anwendung von Rechtsnormen auf dezentrale Systeme entstehen und darüber diskutiert werden, ob und in welchem Umfang diese geschlossen werden können oder müssen.

III.

Die Sharing Economy im Überblick

Die einst erhoffte Dezentralisierung von Wirtschaftsmacht durch das Internet kann heutzutage als unerreicht angesehen werden. Stattdessen haben sich Plattformen gebildet, die mittlerweile zu den wertvollsten Unternehmen der Welt

12

Einleitung

zählen.5 Die Möglichkeit der Vermittlung von Leistungen hat nicht nur zur Zentralisierung von Märkten, sondern auch zur Schaffung neuer Märkte geführt. Zu den neuen Märkten zählen auch die Angebote der Sharing Economy. Die Europäische Kommission fasst hierunter Geschäftsmodelle, bei denen Ta¨ tigkeiten durch kollaborative Plattformen ermo¨ glicht werden, die einen offenen Markt fu¨ r die voru¨ bergehende Nutzung von Waren oder Dienstleistungen schaffen, welche ha¨ ufig von Privatpersonen angeboten werden.6 Im Rahmen dieser Arbeit werden unter Plattformen der Sharing Economy nur solche gefasst, die auf eine Kommerzialisierung des Privatbereichs ausgerichtet sind.7 In diesem Rahmen können zwar auch Unternehmer als Anbieter auftreten, dies ist aber nicht der primäre Zweck der Plattform. Trotz der recht jungen Vergangenheit der Sharing Economy wurde der Umsatz von Plattformen der Sharing Economy allein in Deutschland im Jahr 2017 auf rund 23 Mrd. € geschätzt.8 Die Plattformen ermöglichen es Einzelpersonen Güter oder Dienstleistungen mit anderen zu teilen, die ansonsten ungenutzte Ressourcen darstellen würden.9 Ihre Tätigkeit beschränkt sich in der Regel auf die Vermittlung der Leistungen zwischen Anbietern und Nutzern. Sie selbst haben vergleichsweise geringe Ressourcen in Form von physischen Gütern und aufgrund der rein digitalen Vermittlung geringe Grenzkosten. In diesem neuen Markt haben sich vor allem zwei Unternehmen in ihrem jeweiligen Sektor hervorgetan: Uber bei der Personenbeförderung und Airbnb bei der Kurzzeitvermietung. Sie stellen mit einer Marktkapitalisierung von 75 Mrd. €10 und und 66 Mrd. €11 die jeweils größten Plattformen in ihrem Marktsegment dar. Beide Unternehmen sahen sich in den letzten Jahren wiederholt Rechtsstreitigkeiten auf nationaler und europäischer Ebene ausgesetzt.12 In beiden Fällen ging es darum, ob Uber und Airbnb den Marktzugangsbeschränkungen der vermittelten Dienstleistungen unterliegen, d. h. insbesondere der Genehmigungsbedürftigkeit von Personenbeförderung und Maklerdienstleistungen.

5 Z. B. Amazon auf Platz 1 und Alibaba Platz 6 im Jahr 2020: Brandz, Ranking der Top-50 Unternehmen weltweit nach ihrem Markenwert im Jahr 2020 (in Milliarden US-Dollar) nach Statista: von https://tinyurl.com/4nc5r73u. 6 Mitteilung der EU-Kommission zur europäischen Agenda für die Sharing Economy, COM (2016) 356 final, v. 02. 06. 2016, S. 3. 7 Vgl. Sharing Economy im Wirtschaftsraum Deutschland, Studie des Instituts der deutschen Wirtschaft. 8 Beutin, Share Economy 2017 – The New Business Model, S. 19. 9 Koopman/Mitchell/Thierer, JBEL, 529, 531. 10 Https://www.boerse-online.de/aktie/uber-us90353t1007.html abgerufen am 18. 1. 2021. 11 Https://www.boerse-online.de/aktie/airbnb-us0090661010.html abgerufen am 18. 1. 2021. 12 Zu Uber: BGH, Beschl. v. 18. 5. 2017-I ZR 3/16 (KG), GRUR 2017, 743; EuGH Urt. v. 20. 12. 2017-C 434/15; zu Airbnb: EuGH Urt. v. 19. 12. 2019-C-390/18; Urt. v. 22. 9. 2020-C-724/18 und C-727/18.

Technische Grundlagen von Dezentralen Anwendungen

13

Während das Geschäftsmodell von Uber »UberPop«, in Deutschland untersagt wurde13 und sich nun auf die Vermittlung von Taxis, UberTaxi, und Mietwagen, UberX, beschränkt, darf Airbnb weiterhin die Vermittlung von Kurzzeitvermietungen erbringen.14

IV.

Technische Grundlagen von Dezentralen Anwendungen

Die bisherigen Geschäftsmodelle der Sharing Economy nutzen eine zentrale Organisation. Auch wenn diese Beschreibung im allgemeinen Sprachgebrauch selten verwendet wird, ist es die Organisationsform der uns bisher bekannten Webseiten. Zentralität bezeichnet dabei nicht die Art der Datenspeicherung, sondern die Verfügungsmacht über diese Daten. Bei zentralen Anwendungen, hat eine Entität die Verfügungsmacht. Im Rahmen von Webseiten sind es die Inhaber oder für unsere Fälle konkret die jeweiligen Unternehmen. Uber, Airbnb und sonstige Unternehmen haben volle Kontrolle über die Inhalte und Informationen, die auf ihren Webseiten und in den mobilen Anwendungen (Apps) zur Verfügung stehen. Sie entscheiden, wer ihre Apps nutzen kann, welche Informationen gespeichert werden und wie mit diesen Informationen umgegangen wird. Es steht in ihrer Macht, Nutzer von der Anwendung auszuschließen oder Webseiten oder Apps vollständig einzustellen. Der Gegensatz sind dezentrale Anwendungen. Sie nutzen die BlockchainTechnologie, um eine dezentral verteilte Anwendung zu schaffen. Die vom Bitcoin-Protokoll bekannte Technologie ist zwar die Grundlage und gemeinsamer Nenner vieler unterschiedlicher Anwendungen.15 Nicht alle dieser Anwendungen müssen zwingend vollständig dezentral sein. Wie bei Regierungsformen sind von autoritär bis zur direkten Demokratie viele Entscheidungsformen möglich. Gegenstand dieser Arbeit sind dabei nur vollständig dezentrale Anwendungen. Jedes Mitglied der dezentralen Anwendung ist dabei gleichberechtigt und mitentscheidend. Wie zwischen den einzelnen Mitgliedern der dezentralen Anwendung (Nodes) abgestimmt wird, bestimmt der Konsensmechanismus.16 Im Gegensatz zu zentralen Anwendungen, muss die Mehrheit sich für eine Änderung in der dezentralen Anwendungen entscheiden, um diese umzusetzen. Die Entscheidung der Mitglieder kann dabei automatisiert, wie beim Hinzufügen 13 BGH, Urt. v. 13. 12. 2018-I ZR 3/16; LG Frankfurt a.M., Urt. v. 18. 03. 2015-3-08 O 136/14. 14 Einführend zu den Unterschieden in den Rechtssachen Uber und Airbnb: Busch, EuCML 2018, 172ff. 15 Grundlegend zur Blockchain-Technologie: Böhme/Pesch, Technische Grundlagen und datenschutzrechtliche Fragen der Blockchain-Technologie, Datenschutz und Datensicherheit 2017, 8; Schrey/Talhofer, NJW, 2017, 1431. 16 Überblick über mögliche Konsensmechanismen: Baliga. Consensus Models.

14

Einleitung

eines neuen Blocks, auf Basis des gewählten Konsensmechanismus oder manuell erfolgen, wie bei der Änderung des Protokolls. Indem alle Mitglieder gleichberechtigt sind, verringert sich der Einfluss des Einzelnen mit zunehmender Teilnehmerzahl. Während der Entwickler vor Veröffentlichung einziges Mitglied und bei Änderungen allein entscheiden kann, letztlich identisch zur zentralen Organisation, schwindet sein Einfluss nach der Veröffentlichung mit zunehmender Teilnehmerzahl. Um Transaktionen zwischen den Nutzern zu ermöglichen, weisen dezentrale Anwendungen eigene »Währungen« auf, sog. Token. Sie funktionieren identisch zu bisher bekannten Kryptowährungen, sind jedoch ausschließlich zur Nutzung innerhalb einer Anwendung vorgesehen. Jedem Nutzer wird eine öffentliche Adresse zugewiesen, der wiederum seine Token zugewiesen sind.17 Eine Transaktion erfolgt, indem der Inhaber eines Tokens mit seinem privaten Schlüssel, ähnlich einem PIN, den Transfer zu einer anderen öffentlichen Adresse autorisiert und der Transfer in der Blockchain gespeichert wird.

V.

Dezentrale Anwendungen in der Sharing Economy

Die dezentrale Struktur der Anwendungen ermöglicht den Ersatz von Intermediären. Während sich für den Nutzer nur wenig verändert und der Unterschied für ihn kaum sichtbar ist, bieten dezentrale Anwendungen einige Vorteile zu bisherigen Plattformen der Sharing Economy. Insbesondere gibt es keinen zentralen Intermediär mehr, der eine Vermittlungsgebühr für sein Leistungen verlangt. Der Wegfall teils erheblicher Transaktionsgebühren kann ein entscheidender Vorteil dezentraler Anwendungen sein.18 Dennoch haben sich am Markt bisher keine vergleichbaren Anwendungen zu Uber und Airbnb durchgesetzt. Neben vorübergehenden Erscheinungen wie ArcadeCity19, Personenbeförderung, und Beenest20, Kurzzeitvermietung, gibt es aber auch konstante dezentrale Anwendungen, die sich nach wie vor in der Entwicklung befinden und sich in Richtung Marktreife entwickeln wie z. B. Lazooz21. Mangels am Markt etablierter Anwendungen muss man nach wie vor von einem theoretischen Ge-

17 Vgl. für Bitcoins: Kaulartz, CR 2016, 474. 18 Airbnb laut eigenen Angaben durchschnittlich 17 %: https://www.airbnb.de/help/article/18 57/was-sind-die-airbnbservicegebühren abgerufen am 11. 1. 2021; bei Uber wohl um die 25 %: https://www.uber.com/de-CH/blog/zurich/mehrwertsteuer-servicegebuhr/ abgerufen am 11. 1. 2021. 19 Https://arcade.city. 20 Https://coinformant.com/beetoken-merges-with-coinformant/ abgerufen am 11. 1. 2021. 21 Http://lazooz.org abgerufen am 11. 1. 2021.

Gang der Untersuchung

15

schäftsmodell sprechen. Dezentrale Anwendungen werden hingegen zunehmend in der Literatur diskutiert.22 Ob sich dezentrale Anwendungen gegenüber bisherigen Plattformen durchsetzen können, hängt nicht nur von den Anwendungen selbst, sondern vor allem auch von dem Vertrauen ab, das Nutzer der Blockchain-Technologie selbst entgegenbringen. Vor dem Hintergrund der Schlagzeilen zu Bitcoin und deren spekulativen Charakter bleibt die weitere Entwicklung in diesem Bereich abzuwarten.

VI.

Gang der Untersuchung

Die Arbeit ist in vier Abschnitte unterteilt. Ausgangspunkt ist die Ermittlung und Darstellung bisheriger Rechtsfragen zur Sharing Economy, bei denen zu erwarten ist, dass sich Probleme gerade durch die Umstellung der Technologie ergeben können. Diese Rechtsfragen werden zu Beginn der Arbeit kurz dargestellt und ein Überblick über die dazu geführten Diskussionen gegeben. Sie werden dabei jeweils in die Kategorien Marktzugangsregulierung, Verbraucherschutz und Haftung eingeordnet. Nachdem eine Bandbreite von Rechtsfragen ermittelt wurde, wird untersucht, wie sich diese Rechtsfragen durch die Verwendung von dezentralen Anwendungen aufgrund der neuen Technologie verändern. Die dadurch gewonnen Fragestellungen werden im Anschluss unter geltendem Recht diskutiert und beantwortet. Durch die Subsumtion und dem Vergleich zur bisherigen Diskussion zur Sharing Economy wird sich zeigen, ob nach geltendem Recht Regelungslücken bei dezentralen Anwendungen entstehen, die von denen der Sharing Economy abweichen. Für die hierbei identifizierten Lücken werden in einem letzten Teil Ansätze vorgestellt, um sie zu schließen. Dabei wird diskutiert, wie sich Aufwand und Mehrwert für eine individuelle Regulierung dezentraler Systeme gegenüberstehen.

22 Modell für eine dezentrale Anwendungen zur Personenbeförderung: Bossauer u.w., Dezentralisierung der Sharing Economy, https://tinyurl.com/34js4e79; für sonstige Transaktionsplattformen: Li u.w., LBRY: A Blockchain-Based Decentralized Digital Content Marketplace, https://ieeexplore.ieee.org/document/9126007; Klems u.w., Trustless Intermediation in Blockchain-Based Decentralized Service Marketplaces, ICSOC 2017, 731ff.

Teil 1: Regulierung plattformbasierter Modelle

Um einen Vergleichspunkt für die dezentralen Anwendungen zu schaffen, muss der derzeitige Stand zur Sharing Economy betrachtet werden. Die Diskussion zu Uber, Airbnb und Co. ermöglicht es, die grundlegenden Problemstellungen der Sharing Economy zu ermitteln. Es liegt die Annahme zugrunde, dass diese Probleme sich auch bei einem Wechsel der Technologie weiterhin stellen werden. Soweit bereits Vorschläge zum Umgang mit Plattformen der Sharing Economy gemacht wurden, kann untersucht werden, ob sie sich auf dezentrale Anwendungen übertragen lassen oder aber, ob der Wechsel der Technologie auch rechtliche Auswirkungen mit sich bringt.

§1

Marktzugangsregulierung

Der erhebliche Einfluss und das Wachstum der Sharing Economy resultiert zumindest in Teilen aus den gewählten Marktsegmenten. Prominenteste Beispiele sind der Mobilitäts- und der Wohnraumsektor. In beiden haben sich »milliardenschwere« Unternehmen der Sharing Economy gebildet. Diese Sektoren zeichnen sich aber gleichzeitig durch eine erhebliche Marktzugangsregulierung aus. So sind im Mobilitätssektor die Vorschriften des Personenbeförderungsgesetzes (PBefG) und im Wohnraumsektor neben dem öffentlichen Baurecht die Zweckentfremdungsgesetze der Länder zu beachten. Den Unternehmen der Sharing Economy, die in diesen Segmenten den größten Erfolg haben, wird vorgeworfen, sie würden diese Marktzugangsvoraussetzungen ignorieren und unerlaubt in den Wettbewerb zu den traditionellen Unternehmen treten.23 Dabei unterscheiden sich beide Marktsegmente vor allem im Anknüpfungspunkt für die Regulierung. 23 OLG Frankfurt a.M., Urt. v. 09. 06. 2016–6 U 73 / 15, GRUR-RR 2017, S. 17; OVG BerlinBrandenburg, Beschl. v. 10. 04. 2015-OVG 1 S 96.14, BeckRS 2015, 44779; OVG Hamburg, Beschl. v. 24. 9. 2014-3 Bs 175/14, NVwZ 2014, 1528.

18 I.

Regulierung plattformbasierter Modelle

Personenbeförderung

Bei der Personenbeförderung lassen sich zwei Ansatzpunkte für eine marktzugangsbeschränkende Regulierung finden. Zum einen kann sich aus dem Personenbeförderungsgesetz eine konkrete Erlaubnispflicht für die angebotenen Leistungen ergeben, zum anderen kann der Beförderungsdienstleister unter die allgemeinen Regelungen des Polizei-und Ordnungsrechts fallen, wenn es um die Abwehr einer Gefahr geht. Unternehmungen, die in den Anwendungsbereich des PBefG fallen, sind gem. § 2 I PBefG genehmigungspflichtig. Dies betrifft gem. § 2 I Nr. 2, 3 PBefG vor allem auch den Gelegenheitsverkehr mit Kraftfahrzeugen. Dieser umfasst gem.§ 46 I PBefG alle Beförderungen von Personen mit Kraftfahrzeugen, die kein Linienverkehr nach §§ 42, 42 PBefG sind. Als Gelegenheitsverkehr sind wiederum nur Taxis, Ausflugsfahrten und Mietwagen zugelassen, § 46 II PBefG. Linienverkehr erfordert demgegenüber eine zwischen Ausgangs-und Endpunkten eingerichtete regelmäßige Verkehrsverbindung. Da dies bei der Beförderung von Fahrgästen mit beliebigen Ausgangs-und Endpunkten nicht erfüllt ist, handelt es sich bei den durch Uber vermittelten, entgeltlichen Fahrten um Gelegenheitsverkehr i. S. d. § 46 PBefG, der gem. § 2 I Nr. 4 PBefG grundsätzlich genehmigungspflichtig ist. Adressat der Genehmigungspflicht ist gem. § 2 I PBefG der Unternehmer, der als Vertragspartner der Fahrgäste auftritt.24 Für die Plattformen der Sharing Economy, insbesondere Uber, ist dabei von zentraler Bedeutung, ob sie Unternehmer im Sinne des PBefG sind. Das Anbieten einer oder mehrerer Apps zur Fahrdienstvermittlung ist zwar nicht als Dienstleistung i. S. d. PBefG zu erachten, allerdings kann Uber auch Dienstleister der Fahrt selbst sein, wenn es Vertragspartner des Fahrgastes wird oder als solcher Auftritt.25 Geht man von Ubers Selbstverständnis aus, sieht es sich laut seinen AGB und Angaben seiner Website als Vermittler von Dienstleistungen und gerade nicht als Anbieter der Dienstleistung selbst.26 Die Selbstbezeichnung als Unternehmer oder Vermittler durch das Unternehmen kann aber nicht Maßstab für die rechtliche Einordnung sein.27 Vielmehr muss auf objektive Kriterien zurückgegriffen werden. Objektive Kriterien wurden sowohl auf europäischer als auch auf nationaler Ebene zur Beurteilung von Dienstleistungsvermittlern in der Sharing

24 Bauer, PBefG, § 2 Rn. 3; Heinze, in Heinze/Fehling/Fiedler PBefG, § 2 Rn. 8; Heinze, PBefG § 2 Rn. 2. 25 BGH, Beschl. v. 18. 5. 2017-I ZR 3/16 (KG), GRUR 2017, 743; EuGH Urt. v. 20. 12. 2017-C 434/ 15. 26 Https://www.uber.com/de/legal/terms/de/, abgerufen 06. 04. 2018, 11:25. 27 OVG Berlin-Brandenburg, Urt. v. 10. 04. 2015-OVG 1 S 96.14, BeckRS 44779.

Marktzugangsregulierung

19

Economy entwickelt.28 Dabei wird vor allem auf den Einfluss des Unternehmens auf den Anbieter der Dienstleistung abgestellt. Maßgebliche Kriterien können die Festsetzung des Preises durch die Plattform, Festsetzung sonstiger wesentlicher Vertragsbestandteile und das Eigentum an wesentlichen Gütern sein.29 Für die Modelle UberBlack und UberPop wurde zur Begründung der Unternehmereigenschaft vor allem auf die Preisfestsetzung und das einheitliche Auftreten der Fahrer unter dem Mantel von Uber abgestellt.30 Neben der unmittelbaren Festsetzung des Preises kann ergänzend auch auf die Zahlungsabwicklung abgestellt werden. Alle Zahlungen erfolgen über Uber. Die Quittungen werden im Namen von Uber ausgestellt. Sonstige Zahlungen des Gastes, insbesondere Trinkgelder an den Fahrer, sind untersagt.31 Bei diesen beiden Modellen gilt Uber nicht nur als Anbieter einer Vermittlerdienstleistung, sondern als Unternehmer für die Personenbeförderung i. S. d. § 2 I PBefG.32 Demgegenüber werden Aufträge bei UberTaxi an reguläre Taxis vermittelt, die die Tarifordnungen der jeweiligen Städte einhalten. Da UberTaxi ausschließlich eine Fahrt vermittelt, kann Uber in diesem Fall nicht als Unternehmer der Personenbeförderung angesehen werden. Mit den beiden Modellen UberBlack und UberPop fällt Uber hingegen selbst unter die Genehmigungspflicht des § 2 I PBefG, sodass zu klären bleibt, ob diese Tätigkeiten genehmigungsfähig sind; sei es als Taxiverkehr oder auch als Mietwagenverkehr. Mit den Modellen UberBlack und UberPop lagen die Genehmigungsvoraussetzungen nach der Rechtsprechung nicht vor. Als Taxisverkehr sind die Dienstleistungen allein schon wegen fehlender Kennzeichnung der Wagen als auch wegen fehlender Fahrtenzähler nicht genehmigungsfähig.33 Hinsichtlich der Genehmigungsfähigkeit als Mietwagen stellt sich das Problem, dass solche Aufträge gem. § 49 IV S. 2 PBefG nur am Betriebssitz des Unternehmers angenommen werden dürfen. Bei einer automatischen Weiterleitung an den Fahrer über die App ist ein vorheriger Eingang am Sitz des Unternehmens zweifelhaft. 28 Mitteilung der Kommission, Europa¨ische Agenda fu¨ r die kollaborative Wirtschaft, COM (2016) 356 final, v. 02. 06. 2016, S. 7; BGH, Beschl. v. 18. 5. 2017-I ZR 3/16 (KG), GRUR 2017, 743; EuGH Urt. v. 20. 12. 2017-C 434/15; OLG Frankfurt a.M., Urt. v. 09. 06. 2016-6 U 73 / 15, Rn. 38, GRUR-RR 2017, 17,19. 29 COM(2016) 356 final, S. 7. 30 BGH, Beschl. v. 18. 5. 2017-I ZR 3/16 (KG), GRUR 2017, 743; EuGH Urt. v. 20. 12. 2017-C 434/ 15; OLG Frankfurt a.M., Urt. v. 09. 06. 2016-6 U 73/15, Rn. 38, GRUR-RR 2017, S. 19; Kramer/ Hinrichsen, GewArch 2015, 145, 148. 31 OVG Hamburg Beschl. v. 24. 9. 2014-3 Bs 175/14, juris, Rn. 9; Wimmer/Weiß, MMR 2015, 80, 81f. 32 BGH, Beschl. v. 18. 5. 2017-I ZR 3/16 (KG), GRUR 2017, 743; EuGH Urt. v. 20. 12. 2017-C 434/ 15. 33 VG Berlin, Beschl. v. 26. 09. 2014-VG 11 L 353.14, juris, Rn. 51; ; Wimmert/Weiß: MMR, 2015 80, 83.

20

Regulierung plattformbasierter Modelle

Zwar geht die Anfrage zunächst auf den Servern am Sitz des Unternehmens ein, allerdings werden diese ohne individuelle Verarbeitung automatisch an den entsprechenden Fahrer weitergeleitet. Ausweislich des Sinns und Zwecks der Norm kann eine automatische Weiterleitung aber nicht genügen.34 Die Regulierung des Mietwagenverkehrs muss immer im Wettbewerb zum Taxiverkehr gesehen werden.35 Um die Funktionsfähigkeit des Taxiverkehrs zu gewährleisten, darf der Mietwagenverkehr nicht in einem Maße den Wettbewerb dominieren, dass er Taxis verdrängt.36 Soweit bereits eine automatische Weiterleitung für den Eingang beim Betriebssitz und damit für die Annahme eines Mietwagenverkehrs genügen würde, ginge ein wesentlicher Vorteil der Taxis verloren. Da die automatische Weiterleitung eine derart schnelle Verarbeitung ermöglicht, macht es für den Gast keinen wesentlichen Unterschied mehr, ob er über die App einen Mietwagen »bestellt«, der sich im unmittelbaren Umkreis befindet, oder ob er in ein wartendes Taxi einsteigt. Dem Mietwagenverkehr würde die Beförderung von »Laufkundschaft« ermöglicht. Für den Mietwagenverkehr wird deshalb eine separate fernmündliche Mitteilung des Auftrages gefordert, der über das automatische Weiterleiten mittels eines Servers hinausgeht.37 Demgemäß sind die Angebote Ubers in der von den Gerichten kontrollierten Gestaltungsformen UberPop und UberBlack genehmigungspflichtig, aber nicht genehmigungsfähig. Uber ist somit nach dem PBefG mit diesen konkreten Angeboten am Marktzugang gehindert. Dieses Regulierungssystem knüpft an die Inanspruchnahme des Plattformbetreibers an. Anstatt den einzelnen Fahrer zu sanktionieren, wird auf den Marktintermediär zurückgegriffen. Indem den Intermediären der Marktzugang versperrt wird, werden auch gleichzeitig alle auf dieser Plattform tätigen Fahrer an einem Tätigwerden am Markt gehindert. Aus Sicht der regulierenden Stelle ist es ein deutlicher Effizienzgewinn im Rahmen der Gefahrenabwehr. Hier wird der Marktintermediär zu einem scheinbaren regulatorischen Intermediär. Ein echter regulatorischer Intermediär agiert als Vermittler zwischen einem Legislativorgan und einem Adressaten, indem er im Rahmen der Bedeutung, des Einflusses und der Auswirkungen einer Norm auf den Adressaten einwirkt.38 Der Einfluss Ubers auf die Fahrer ergibt sich hingegen nicht aus einer rechtlichen Stellung, sondern aus dem faktischen Einfluss auf die Infrastruktur des Marktes. Es wird daher auf 34 OVG Berlin-Brandenburg, Urt. v. 10. 04. 2015-OVG 1 S 96.14, BeckRS 44779, Rn. 46; Kramer/ Hinrichsen, GewArch 2015, 145, 148. 35 Heinze, PBefG, § 49 Rn. 6. 36 Rogers, 82 Chicago Law Review Online, 85, 91. 37 Kramer/Hinrichsen, GewArch 2015, 145, 148. 38 Havinga/Verbruggen, Understanding Complex Governance Relationships, The ANNALS of the American Academy of Political and Social Science 2017, 58, 60.

Marktzugangsregulierung

21

Uber eingewirkt, um gesetzwidriges Verhalten der eigentlichen Fahrer zu unterbinden. Allerdings wird Uber dabei nicht als Intermediär in Anspruch genommen, sondern unmittelbar als Adressat. Das PBefG erlaubt nämlich nur die Inanspruchnahme des Unternehmers, nicht aber eines vorgeschalteten Intermediärs. Um dennoch das regulatorische Ziel zu erreichen, muss Uber als Adressat (Unternehmer) klassifiziert werden, da ansonsten keine Befugnisnorm vorliegt. Uber funktioniert zwar faktisch als Intermediär, wird aber rechtlich nicht entsprechend klassifiziert. Die zwanghafte Subsumtion unter den Begriff des Unternehmers anstelle der einfachen Subsumtion unter die Rolle eines Intermediärs, zeigt die Notwendigkeit eines Modells des Intermediärs für eine effektive Regulierung. Beim derzeitigen Geschäftsmodell Ubers mag seine Klassifizierung als Unternehmer noch zu dem gewünschten Ergebnis führen, kann aber bei einer zukünftigen Anpassung der Geschäftsmodelle zu erheblichen Schwierigkeiten führen, soweit sich der Einfluss nicht mehr aus den aufgestellten Kriterien ergibt. Die derzeitige Lösung der Subsumtion unter den Unternehmensbegriff erscheint wie eine kurzfristige Problemlösung, die dauerhaft keinen Bestand haben kann. Würden Uber oder eine entsprechende Plattform ein Unternehmensmodell entwickeln, in dem sie nicht mehr als Unternehmer i. S. d. PBefG angesehen werden könnten, wäre eine Regulierung nach dem PBefG nicht mehr möglich. Stattdessen könnte nur noch den einzelnen Fahrern gem. §§ 2 I Nr. 4, 46ff. PBefG das Anbieten der Leistung untersagt werden. Diese Form der Gefahrenabwehr ist aber kaum erfolgsversprechend, solange sich die Fahrer auf eine bereitstehende Infrastruktur verlassen können, die unter »geringen« Kosten die Vermittlung von Fahrer und Fahrgast ermöglicht. Obwohl Uber in diesem Beispiel nicht Adressat des PBefG sein kann, ermöglicht erst die bereitgestellte Infrastruktur den flächendeckenden Rechtsbruch durch Beförderer ohne Genehmigung. Es stellt sich daher die Frage, ob jenseits des PBefG eine Inanspruchnahme der Plattform im Interesse effektiver Gefahrenabwehr möglich ist. Den Behörden bliebe dann entweder nur die immer größere Ausweitung des Unternehmerbegriffs oder aber die Aufgabe einer effektiven Regulierung. In Betracht kommt die Inanspruchnahme der Plattform als Zweckveranlasser, da die Plattformen bei diesen alternativen Modellen nicht unmittelbarer Anbieter der Fahrleistung sind und somit nicht den Anforderungen der unmittelbaren Verursachung im Rahmen der Verhaltensstörung genügen.39 Auch wenn die Figur des Zweckveranlassers immer wieder in Frage gestellt wird, ist sie

39 Wobst/Ackermann, JA 2013, 916, 917; Graulich in Hdb. des Polizeirechts; Rn. 195f.; Schenke, Polizei-und Ordnungsrecht, Rn. 242.

22

Regulierung plattformbasierter Modelle

letztlich in Literatur und Rechtsprechung weitgehend anerkannt.40 Aber auch die kritischen Stimmen lassen die Möglichkeit zu, den Zweckveranlasser als sog. Nichtstörer zu betrachten, wenn die Gefahr auf Dauer nur durch Beseitigung der Ursache abgewehrt werden kann.41 Wer die Infrastruktur in der Form bereitstellt, dass auch rechtswidrige Leistungen angeboten werden können, muss damit rechnen, dass ein Dritter die Plattform nutzt, um solche Leistungen anzubieten. In diesen Fällen kann der Plattform-Betreiber unter den Nichtstörer fallen und somit im Rahmen des Polizei- und Ordnungsrechts in Anspruch genommen werden. Der Gesetzgeber hat sich mit dem Gesetz zur Modernisierung des Personenbeförderungsgesetzes42 für die Ausdehnung des PBefG entschieden. Unter anderem erfasst gem. § 1 Abs. 1a PBefG der Beförderungsbegriff nun auch die organisatorische und vertragliche Verantwortlichkeit für die Beförderung, sodass auch der Unternehmerbegriff sich auf diese Tätigkeit erstreckt. Neu eingefügt wurde ebenfalls der Begriff des Vermittlers von Beförderungsleistungen gem. § 1 Abs. 3 PBefG, der als Auffangtatbestand zu Abs. 1a solche Plattformanbieter erfassen soll, die keine organisatorische und vertragliche Verantwortung für die Beförderung tragen. Die reine Vermittlung unterliegt keiner Genehmigung. Den Vermittler treffen lediglich Auskunftspflichten gem. §§ 3a PBefG ff. Die Abgrenzung zwischen Vermittler und Unternehmer hat aber weiterhin nach gleichen Grundsätzen zu erfolgen. Eine Inanspruchnahme des Vermittlers auf Grundlage des Zweckveranlassers ist durch die neue Einbeziehung der Vermittler ebenfalls nicht ausgeschlossen. Zwar trifft das PBefG nunmehr ausdrückliche Regelungen für den Vermittler. Die Neuregelungen überlagern aber nicht die Inanspruchnahme nach den Polizei- und Ordnungsgesetzen der Länder.

II.

Kurzzeitvermietung

Bei Plattformen im Bereich der kurzeitigen Wohnraumvermietung sind neben dem allgemeinen Polizei-und Ordnungsrecht vor allem die Spezialgesetze der Länder zur Zweckentfremdung und die Gewerbeordnung (GewO) einschlägig. Die Bundesländer haben seit 1971 auf Grundlage des Mietrechtsverbesserungsgesetzes die Möglichkeit, Gesetze gegen die Zweckentfremdung zu erlassen. 40 Zur fehlenden gesetzlichen Grundlage: Wobst/Ackermann, JA 2013, 916, 917; Beaucamp/ Seifert, JA 2007, 577, 579; zur generellen Akzeptanz: VGH Mannheim, Beschl. v. 29. 05. 1995-1 S 442/95, Ullrich in BeckOK Polizei-und Ordnungsrecht Niedersachsen, § 6 NPOG, Rn. 19; Wehr, Bundespolizeigesetz, § 17, Rn. 4. 41 Wobst/Ackermann, JA 2013, 916, 917. 42 Gesetz zur Modernisierung des Personenbeförderungsgesetzes vom 16. 04. 2021, BGBl. 2021 Teil I Nr. 19, S. 822ff.

Marktzugangsregulierung

23

Mittlerweile haben davon fast alle Länder Gebrauch gemacht. Beispielhaft seien das Hamburgische Wohnraumschutzgesetz (HambWoSchG), das Berliner Zweckentfremdungsverbotsgesetz (ZwVbG) und die Münchener Satzung zum Verbot der Zweckentfremdung von Wohnraum (ZeS) genannt. Beispielhaft sei geprüft, ob auch in diesem Marktsegment Plattform-Betreiber am Marktzugang gehindert oder aber wenigstens zur Gefahrenabwehr in Anspruch genommen werden können. 1.

Beschränkungen nach GewO

Nach der Gewerbeordnung besteht grundsätzlich die Pflicht zur Anmeldung eines stehenden Gewerbes gem. § 1 I, 14 I GewO. Es handelt sich lediglich um eine Anzeigepflicht, ohne dass es zum Tätigwerden einer weiteren Erlaubnis der zuständigen Behörde bedarf. Die bloße Anzeigepflicht wirkt nicht marktzugangsbeschränkend. Es könnte aber eine Erlaubnispflicht nach § 34 c GewO bestehen, wenn es sich bei dem Modell von Airbnb um die Vermittlung von Wohnraumverträgen handelt. Geht man vom grundsätzlichen Verständnis des Bundesverfassungsgerichts aus, handelt es sich bei Wohnraum um den existenziellen Lebensmittelpunktes eines Menschen,43 was impliziert, dass sich der Lebensmittelpunkt einer Person dort befindet.44 Von Airbnb wurden sowohl Objekte inseriert, die dauerhaft über Airbnb vermietet werden, als auch solche, die zeitweise vom Anbieter selbst bewohnt werden. Unabhängig davon werden im Rahmen der Gewerbeordnung auch die sog. Mitwohnzentralen erfasst.45 Mitwohnzentralen sind Modelle, bei denen ein Mieter oder Eigentümer seine Wohnung bei einer vorrübergehenden Abwesenheit für diesen Zeitraum vermietet.46 Dieser Form der Mitwohnzentrale entspricht auch ein Teil des Angebotes von Airbnb, sodass auch das Modell von Airbnb auf Verträge über Wohnraum i. S. d. GewO gerichtet ist. Der Begriff der Vermittlung wird ebenfalls sehr weit verstanden, sodass hierunter auch das bloße in Verbindung bringen der Vertragsparteien zu verstehen ist.47 Somit unterfällt Airbnb zumindest der Erlaubnispflicht gem. § 34 c I Nr. 1 GewO.

43 BVerfG Beschl. v. 26. 05. 1993-1 BvR 208/93; NJW 1993, 2035; Schmidt in BeckOGK BGB, § 549 Rn. 9. 44 Wiederhold in BeckOK BGB, § 549 Rn. 8. 45 Marcks in Landmann/Rohmer GewO, § 34 c Rn. 17; Ennuschat in Tettinger/Wank/Ennuschat GewO, § 34 c Rn. 9. 46 Marcks in Landmann/Rohmer GewO, § 34 c Rn. 17. 47 Vgl. Marcks, Makler- und Bauträgerverordnung, § 34 c Rn. 8; Windoffer, LKV 2016, 337, 338.

24 2.

Regulierung plattformbasierter Modelle

Zweckentfremdungsgesetze der Länder

Zusätzlich könnte auch Genehmigungspflicht nach den Zweckentfremdungsgesetzen hinzutreten. Der Genehmigung bedarf beispielsweise gem. § 9 II HambWoSchG der Verfügungs- oder Nutzungsberechtigte.48 Da Airbnb aber weder nutzungs- noch verfügungsberechtigt bzgl. des Wohnobjektes ist, unterliegt die Plattform selbst nicht der Genehmigungspflicht des Zweckentfremdungsgesetzes. Wenn die Plattform nicht selbst unter ein Zweckentfremdungsgesetz fällt, kommt eine mittelbare Anknüpfung im Rahmen der gewerberechtlichen Erlaubnis in Betracht. Demnach könnte die Erlaubnis untersagt werden, wenn hinreichend konkret von einem Verstoß gegen die Zweckentfremdungsgesetze, vermittelt über die Plattform, ausgegangen werden kann. Die Erlaubnis kann allerdings nur aus Gründen des § 34 II GewO abgelehnt werden. Dessen Aufzählung ist abschließend.49 Denkbar wäre beim bewussten Anbieten von zweckentfremdeten Wohnungen ein Verstoß gegen die gewerbliche Zuverlässigkeit gem. § 34 II Nr. 1 GewO. Aus den Regelbeispielen des § 34 II Nr. 1 GewO kann aber entnommen werden, dass der Plattformbetreiber selbst eine ihm obliegende Pflicht verletzen müsste.50 Dies ist bei Verstößen gegen ein Zweckentfremdungsgesetz nicht der Fall, da der Plattformbetreiber nicht Regelungssubjekt des Gesetzes ist. Insoweit bestehen zwar auch für Plattformen bei kurzfristiger Wohnraumvermietung Marktzugangsbestimmungen, die aber den Marktzugang der Plattformen nicht wesentlich beschränken, da gerade die Zweckentfremdungsgesetze mangels Adressateneigenschaft keine Anwendung finden. Auch hier ist die Lösung über die Inanspruchnahme eines regulatorischen Intermediärs wünschenswert, aber aufgrund der rechtlichen Rahmenbedingungen nicht möglich. Im Unterschied zur Personenbeförderung kann das Ziel nicht durch Ausdehnung des Adressatenkreises korrigiert werden. Die Zweckentfremdungsgesetze stellen jeweils auf den Verfügungsberechtigten ab. Dieser Rechtsbegriff lässt sich nicht gleichermaßen ausdehnen, wie der Unternehmerbegriff des PBefG. Bereits hier stößt die bisherige Regulierungstechnik an ihre Grenzen. Wenn zum einen keine Befugnisnorm für die Inanspruchnahme eines Intermediärs vorliegt, andererseits die bestehenden Regelungen eine Ausdehnung des Adressatenkreises nicht ermöglichen, ist eine Inanspruchnahme des Marktintermediärs nicht möglich. Da sich aber die grundsätzlichen Probleme der Regulierung von Marktintermediären nicht wesentlich unterscheiden, wird deutlich, dass die Rechtsprechung zu Uber eine einzelfallbezogene Lösung dar48 Vgl. auch in Berlin und München, § 1 I ZwVbG und § 4 I ZeS. 49 Will in BeckOK GewO, § 34 c Rn. 59; Marcks in Landmann/Rohmer GewO, § 34 c Rn. 77. 50 Will in BeckOK GewO, § 34 c Rn. 68.

Verbraucherschutz

25

stellt, die sich kaum auf andere Bereiche übertragen lässt. Um die Rolle des Marktintermediärs unter Berücksichtigung widerstreitender Interessen ausgewogen zu behandeln, d. h. sowohl das Interesse der Behörden an einer Regulierung, als auch das Interesse der Plattformen an der Ausübung der Unternehmenstätigkeit zu berücksichtigen, sind die derzeitigen rechtlichen Rahmenbedingungen unzureichend ausgestaltet. Wie bei den Plattformen zur Personenbeförderung stellt sich im Anschluss an den Marktzugang auch die Frage nach der Inanspruchnahme aus den Grundsätzen des Zweckveranlassers. Diese Fragestellung ändert sich grundsätzlich nicht mit der Art der vermittelten Dienste. Entscheidend ist vielmehr, dass der Plattformbetreiber eine Infrastruktur zur Verfügung stellt, die die Umgehung spezialgesetzlicher Verbote ermöglicht. Hierzu dürfte letztlich auch das Zweckentfremdungsgesetz zählen.

III.

Zwischenergebnis

Bei Plattformmodellen wie Uber und Airbnb stellt sich nach der bisherigen Diskussion die Frage, in welchem Umfang und mit welchen rechtlichen Regelungen Plattformbetreiber durch Vorschriften am Marktzugang behindert werden können. Ein struktureller Unterschied entsteht dabei dort, wo der Plattformbetreiber nicht nur als Vermittler, sondern selbst als Anbieter der vermittelten Leistung betrachtet werden kann. In solchen Fällen kann der Marktzugang nicht nur aufgrund von Regelungen versagt werden, die gezielt an den Plattformbetreiber gerichtet sind, sondern auch solcher, die die vermittelten Dienstleistungen betreffen. Es ist also jeweils zu prüfen, ob der Plattformbetreiber auch als Anbieter der Dienstleistung angesehen werden kann und welchen Marktzugangsbeschränkungen die Plattform im Einzelfall unterliegt. Eine nachträgliche Inanspruchnahme als Zweckveranlasser ist hingegen aufgrund der zugrundliegenden Infrastruktur unabhängig vom Plattformmodell denkbar. Eine gezielte Beantwortung dieser Fragen kann aber letztlich unter dem Gesichtspunkt der Erarbeitung relevanter Rechtsfragen zur Blockchain in der Sharing Economy offenbleiben.

§2

Verbraucherschutz

Nutzt ein Kunde einen Plattformdienst, ist er etlichen Rechtsunsicherheiten ausgesetzt. Im Vordergrund dürfte die Frage nach dem Vertragspartner stehen. Ist diese Frage bereits für jeden Nutzer aufgrund des davon abhängigen Vertrauens relevant, ist sie für Verbraucher essentiell. Nur bei ausreichender In-

26

Regulierung plattformbasierter Modelle

formation über den Vertragspartner kann der Verbraucher beurteilen, ob ihm die Verbraucherschutzrechte gegen Unternehmer zustehen.

I.

Informationspflichten

Gemäß § 312a BGB ist der Unternehmer bei einem entgeltlichen Verbrauchervertrag dazu verpflichtet, dem Verbraucher die Informationen des § 246 EGBGB zur Verfügung zu stellen. Zur Bestimmung der Unternehmereigenschaft muss festgestellt werden, wer auf Anbieterseite überhaupt Vertragspartner wird. Dabei ist auf den objektiven Empfängerhorizont gem. §§ 133, 157 BGB abzustellen. Für den objektiven Empfängerhorizont ist die Darstellung des Inserats maßgeblich. Ohne weitere Angaben würde man grundsätzlich von einem Vertragsschluss mit dem Plattformbetreiber ausgehen, wenn dieser ein Angebot ohne weitere Angaben zum Vertragspartner anzeigt. Diese Annahme kann aber schon durch bloßes Nennen eines anderen Vertragspartners beseitigt werden. Das gilt auch, wenn es sich bei der Bezeichnung des Vertragspartners nicht um einen Klarnamen handelt. Zwar sind auch andere Umstände vorstellbar, die bei einer Gesamtbetrachtung den Plattformbetreiber als Vertragspartner erscheinen lassen. Bei einem Mindestmaß an Transparenz wird jedoch der Anbieter der Leistung als Vertragspartner anzusehen sein. Während der Plattformbetreiber eindeutig als Unternehmer einzuordnen ist, fällt die Bewertung bei sonstigen Anbietern schwerer. Auf Plattformen treten die Parteien nur noch selten mit vollen Namen und noch seltener mit einer Klassifizierung als Unternehmer oder Verbraucher auf. Durch die Infrastruktur der Plattformen wird es aber jedem, sowohl Unternehmern als auch Verbrauchern, ermöglicht, ohne weitere Hindernisse die Plattformen als Anbieter zu nutzen. Die damit einhergehende steigende Zahl von Verbrauchern als Anbieter auf diesen Plattformen erschwert es den Nutzern, die Unternehmereigenschaft des Anbieters zu erkennen. Man kann bei einem Vertragsschluss über eine Plattform nicht mehr grundsätzlich davon ausgehen, dass der Vertragspartner ein Unternehmer ist. Durch den steigenden Anteil von Verbrauchern auf Anbieterseite entwickelte sich die Sharing Economy als C2CSonderform der Plattformwirtschaft. Diese Entwicklung erschwert zwar die sachliche Beurteilung, hat aber an sich noch keine Auswirkung auf rechtlicher Ebene. Soweit ein Unternehmer auf einer Plattform tätig ist, ist er gem. §§ 246, 246a EGBGB verpflichtet, dem Verbraucher ausreichend vorvertragliche Informationen zur Verfügung zu stellen. Nach der Neufassung des § 312l BGB i. V. m. § 246d EGBGB muss der Online Marktplatz

Verbraucherschutz

27

auch darüber informieren muss, ob es sich nach der Selbstauskunft des Anbieters bei ihm um einen Verbraucher oder einen Unternehmer handelt.51 Die eigentlichen Probleme erwachsen aus der Übertragung des Plattformmodells auf die Sharing Economy. Hier werden vermeintliche »Verbraucher« derart regelmäßig als Anbieter tätig, dass eine klare Abgrenzung von Unternehmer und Verbraucher schwierig wird. Auch wenn es diverse unterschiedliche Definitionen für die Unternehmereigenschaft gibt52, stimmen sie insoweit überein, dass eine planmäßige und dauerhafte Tätigkeit verlangt wird.53 Dies setzt wiederum einen planmäßigen Mindestaufwand und eine regelmäßige Ausübung voraus.54 Für beide Voraussetzungen lassen sich nur schwer abstrakte Vorgaben bestimmen. Im Rahmen des Anbietens von Wohnraum kann die Vermietung in Zeiten eigener Abwesenheit noch als Verwaltung des eigenen Vermögensangesehen werden.55 Ab welcher Häufigkeit eine unternehmerische Tätigkeit vorliegt, lässt sich darüber hinaus nur am Einzelfall bestimmen.56 Zumindest sind sich eine Vielzahl dieser Anbieter nicht ihrer möglichen Unternehmereigenschaft i. S. d. § 14 BGB bewusst und kommen daher unwissentlich auch nicht ihren Informationspflichten nach. Es muss also sichergestellt werden, dass alle Anbieter, die rechtlich Unternehmer i. S. d. § 14 BGB sind, ihren Informationspflichten gegenüber Verbrauchern nachkommen. Aus aufsichtsrechtlicher Perspektive wäre auch hier die Zentralisierung von Pflichten wünschenswert. Anstelle einer Vielzahl von Anbietern müsste lediglich ein Adressat bei Verstößen in Anspruch genommen werden. Der Plattformbetreiber würde als regulatorischer Intermediär eingesetzt werden. Als systemimmanenter Akteur ermöglicht er eine effektive und kostengünstigere Regulierung.57 Die höhere Effizienz resultiert vor allem aus einem Wissensvorsprung

51 Gesetz zur Änderung des Bürgerlichen Gesetzbuchs und des Einführungsgesetzes zum Bürgerlichen Gesetzbuch in der Umsetzung der EU-Richtlinie zur besseren Durchsetzung und Modernisierung der Verbraucherschutzvorschriften der Union und zur Aufhebung der Verordnung zur Übertragung der Zuständigkeit für die Durchführung der Verordnung (EG) Nr. 2006/2004 auf das Bundministerium der Justiz und für Verbraucherschutz vom 10. 98. 2021. 52 BGH, Urt. v. 18. 10. 2017-VIII ZR 32/16, NJW 2018, 150; OLG Celle, Urt. v. 22. 9. 2010-3 U 75/10, juris; Schmittmann, VuR 2006, 223, 224. 53 Ellenberg in Palandt, § 14 Rn. 2; Micklitz in MüKo BGB, § 14 Rn. 20; Wolf in Wolf/Lindacher/ Pfeiffer AGB-Recht, § 310 I Rn. 9. 54 Ellenberg in Palandt, § 14 Rn. 2; Micklitz in MüKo BGB, § 14 Rn. 20; Wolf in Wolf/Lindacher/ Pfeiffer AGB-Recht, § 310 I Rn. 9. 55 Ludwigs, NVwZ, 2017, 1646, 1650. 56 Mögliche Inidizien für Wohnraumvermietung: Ingold, DÖV 2016, 595, 600; allgemein Föhlisch in Hdb. Multimediarecht, 13.4, Rn. 18. 57 Havinga/Verbruggen, Understanding Complex Governance Relationships, The ANNALS of the American Academy of Political and Social Science 2017, 58, 60.

28

Regulierung plattformbasierter Modelle

und einem engeren Kontakt zum Adressaten.58 Im Gegensatz zum Gesetzgeber hat der Plattformbetreiber die Möglichkeit, eine Vielzahl von Daten von Anbietern und Nutzern der Plattformen zu erlangen und diese Daten in Hinblick auf regulatorische Relevanz zu analysieren. So kann Airbnb bspw. kontrollieren, ob ein Anbieter gegen die Zweckentfremdungsgesetze verstößt, indem er seine Wohnung häufiger als die zulässige Höchstzahl an Tagen vermietet. Oder Uber kann aufgrund der Häufigkeit und des generierten Umsatzes ermitteln, ob ein Anbieter nicht tatsächlich als Unternehmer anstatt als Privater handelt. Damit gehen zwar auch einige Gefahren einher, z. B. dass der regulatorische Intermediär die Vorschriften im Sinne eigener ökonomischer Interessen auslegt und somit die Umsetzung einer Norm hinter dem gesetzlichen Ziel zurückbleibt. In erster Linie erlaubt aber erst dieses Modell eine sinnvolle Regulierung der Sharing Economy. Ohne solche Intermediäre ist eine Umsetzung des geltenden Rechts bei der Vielzahl an Anbietern auf jeder einzelnen Plattform kaum noch möglich. Die §§ 312ff. BGB ermöglichen eine derartige Inanspruchnahme bislang jedoch nicht. Sie richten sich ausschließlich an den Vertragspartner einer Leistung. Sofern der Plattformbetreiber nicht nach §§ 133, 157 BGB Vertragspartner ist, treffen ihn keine unmittelbaren Informationspflichten bezüglich der auf der Plattform angebotenen Leistungen von Drittanbietern. Um den Plattformbetreiber dennoch zu verpflichten, dem Verbraucher die notwendigen Informationen bereitzustellen, wurde mit der Omnibus-Richline59 Art. 6a in der Verbraucherrechterichtline60 hinzugefügt. Danach ist der Betreiber eines OnlineMarktplatzes dazu verpflichtet, den Verbraucher über die Unternehmereigenschaft des Vertragspartners aufzuklären. Derartige Informationspflichten sind auch in der geplanten Verordnung des europäischen Parlaments und des Rates u¨ ber einen Binnenmarkt fu¨ r digitale Dienste (Gesetz u¨ ber digitale Dienste) und ¨ nderung der Richtlinie 2000/31/EG nicht vorgesehen. Zwar muss der anzur A bietende Unternehmer vor der Nutzung der Plattform Informationen an den Plattformbetreiber weiterleiten und der Plattformbetreiber muss es dem Unternehmer ermöglichen seinen Informationspflichten gegenüber dem Verbraucher nachzukommen. Dem Plattformbetreiber werden aber keine eigenen Informationspflichten auferlegt.

58 Abbott/Levi-Faur/Snidal: The RIT-Model, 14, 18. ¨ nderung der Richtlinie 93/13/EWG des Rates und der Richt59 Richtlinie 2019/2161/EU zur A linien 98/6/EG, 2005/29/EG und 2011/83/EU des Europa¨ ischen Parlaments und des Rates zur besseren Durchsetzung und Modernisierung der Verbraucherschutzvorschriften der Union. 60 Richtlinie 2011/83/EU u¨ ber die Rechte der Verbraucher, zur Aba¨nderung der Richtlinie 93/13/ EWG des Rates und der Richtlinie 1999/44/EG des Europa¨ischen Parlaments und des Rates sowie zur Aufhebung der Richtlinie 85/577/EWG des Rates und der Richtlinie 97/7/EG des Europa¨ ischen Parlaments und des Rates.

Verbraucherschutz

29

Die Informationspflichten gem. § 312l BGB i. V. m. § 246d EGBGB erlegen dem Plattformbetreiber zwar eigene Informationspflichten auf. Es handelt sich dabei aber um ergänzende Informationen zur Förderung von Transparenz und nicht um die Übertragung der bisherigen Informationspflichten des Vertragspartners auf den Plattformbetreiber.

II.

Designpflichten

Darüber hinaus finden sich Lösungsansätze in dem Versuch, das umfassende verbraucherrechtliche Pflichtenprogramm, wonach jeder Anbieter selbst für die Informationen verantwortlich ist, auf den Plattformbetreiber zu übertragen.61 Ziel ist es, ihm Informationspflichten62 oder Organisationspflichten63 zuzuweisen, um die Transparenz für den Verbraucher zu fördern. Teilweise wird dieser Versuch bereits nach geltendem Recht unternommen, indem unter Auslegung der Verbraucherrechterichtlinie der Plattformbetreiber bereits als Vertreter des Anbieters angesehen wird und er somit die vorvertraglichen Informationspflichten in Bezug auf das konkrete Produkt zusammen mit dem Anbieter erfüllen muss.64 Aus Erwägungsgrund 14 der Richtlinie ergibt sich aber, dass das nationale Vertragsrecht in Bezug auf Abschluss und Gültigkeit nicht verändert werden soll. Nach deutschem Recht kann der Plattformbetreiber nicht als Vertreter des Anbieters angesehen werden, da er nicht an der Abgabe der Willenserklärung für den Vertragsschluss beteiligt ist und auch nur im eigenen Namen handelt.65 Überzeugender ist es, eine Informations- oder Organisationspflicht des Plattformbetreibers aus dem Lauterkeitsrecht abzuleiten. Gem. Art. 6 I lit. f, 7 I, II, 4 I der Richtlinie gegen unlautere Geschäftspraktiken66 soll der Plattformbetreiber verpflichtet sein, auf seiner Plattform kenntlich zu machen, ob jemand als 61 Vorschlag der EU-Kommission für eine Richtline zur besseren Durchsetzung und Modernisierung der EU-Verbraucherschutzvorschriften, COM (2018) 185 final (New Deal for Consumers); Busch, Europäische Modellregeln für Online-Vermittlungsplattformen, 150, 157; Busch/Schulte-Nölke/Domagalska/Zoll, EuCML 2016, 3f.; Mozina, EuCML 2016, 25. 62 COM (2018) 185 final, S. 4, 22 a.E.; Busch u.w., EuCML 2016, 3, 6; Mozina, EuCML 2016, 25, 26. 63 Busch, Europäische Modellregeln für Online-Vermittlungsplattformen, 150, 157. 64 Mozina, EuCML 2016, 25, 26f. 65 Ausnahmen hierzu z. B. die Plattform Foodora, allerdings sind hier keine Verbraucher als Anbieter aktiv, sodass es nicht zu diesen Problemen kommt, vgl. AGB Foodora, https:// www.foodora.de/contents/terms-and-conditions.htm abgerufen am 18. 1. 2021. 66 Richtlinie 2005/29/EG des europäischen Parlamentes und des Rates u¨ ber unlautere Gescha¨ ftspraktiken im binnenmarktinternen Gescha¨ ftsverkehr zwischen Unternehmen und ¨ nderung der Richtlinie 84/450/EWG des Rates, der Richtlinien 97/7/ Verbrauchern und zur A EG, 98/27/EG und 2002/65/EG des Europa¨ ischen Parlaments und des Rates sowie der Verordnung (EG) Nr. 2006/2004 des Europa¨ ischen Parlaments und des Rates.

30

Regulierung plattformbasierter Modelle

Verbraucher oder Unternehmer auftritt.67 Der Plattformbetreiber muss somit zumindest auf seiner Plattform die Möglichkeit der Kennzeichnung einräumen. Diese Vorgabe schafft ein Mindestmaß an Transparenz, behebt aber nicht die Probleme, die sich aus der Selbstkennzeichnung im Rahmen der Sharing Economy ergeben. Andererseits ist der Plattformbetreiber selbst Unternehmer und Anbieter einer Dienstleistung, für die er Informationspflichten hat. Durch Bestimmung des Umfangs dieser Informationspflichten könnten dem Plattformbetreiber auch Informationspflichten in Bezug auf über die Plattform geschlossene Verträge zugewiesen werden. Nach § 246 EGBGB muss aber nur über die Eigenschaften der angebotenen Dienstleistung des Unternehmers informiert werden. Das Angebot des Plattformbetreibers, das Zur-Verfügung-Stellen der Plattform, ist von den auf der Plattform angebotenen Leistungen strikt zu trennen. Für die angebotenen Leistungen ist der Plattformbetreiber gerade nicht Unternehmer, sondern Dritter, den keine weitergehenden Informationspflichten treffen. Im Hinblick auf die Relevanz dieser Fragen für den Schutz des Verbrauchers in der Sharing Economy könnten auch ältere Ansätze wieder aufgegriffen werden. Bereits seit einiger Zeit gibt es Stimmen, die eine grundlegende Umstrukturierung des Verbraucherrechts befürworten. Es soll für Informations- und Schutzpflichten weniger auf die Verbrauchereigenschaft als auf die Eigenschaft als Kunde abgestellt werden.68 Diese Ansätze scheinen sich in ihren konkreten Ausgestaltungen bislang nur auf die Seite des Bestellers zu beziehen, das heißt der Kreis der schutzbedürftigen Marktteilnehmer wird nur einseitig erweitert. Würde man es auch auf die Seite des Anbieters übertragen, brächte dieser Ansatz einen weiteren Vorteil für Plattformmodelle der Sharing Economy mit sich. Es müssten weniger Ressourcen in die Feststellung der Eigenschaften der Vertragspartei investiert werden, die Pflichten eines jeden Anbieters wären eindeutig und transparent und die zu zentralisierenden Pflichten in der Rolle des Plattformbetreibers könnten auf eine Organisationspflicht zur Ermöglichung der Bereitstellung der Information reduziert werden. Dabei sind jedoch die Rechtsfolgen der Verbraucherrechte nicht zu vernachlässigen. Es muss bedacht werden, dass in diesem Fall auch gegenüber Verbrauchern als Verkäufer das Widerrufsrecht ausgeübt werden kann. Für eine adäquate Anwendung muss also geklärt werden, ob die Verbraucherrechte gegebenenfalls generell bei digitalen Verträgen Anwendung finden sollten oder ob ein entsprechender Ausgleich geschaffen werden kann. In dieser Überlegung könnte es letztlich leichter sein, 67 Common position of national authorities within the CPC Network concerning the commercial practices and the terms of service of Airbnb Ireland, https://tinyurl.com/3kcawkc5 abgerufen am 18. 1. 2021. 68 Engel/ Stark, ZEuP 2015, 32, 46; Schulte-Nölke, EuVR 2013, 1; ders. The Brave New World of EU Consumer Law, EuCML 2015, 135, 138.

Haftung der Plattformen

31

starre Grenzen für die Unternehmereigenschaft aufzustellen, um eine sicherere Selbstklassifizierung zu gewährleisten.

§3

Haftung der Plattformen

Bei den Plattformmodellen der Sharing Economy handelt es sich um vertragliche Dreiecksverhältnisse zwischen dem Nutzer, dem Anbieter und dem Plattformbetreiber. Wie sich in diesem Verhältnis die Haftung gestalten sollte, wird rege diskutiert. Hierbei ist vor allem die Rolle des Plattformbetreibers interessant. Einerseits versucht sich der Plattformbetreiber von einer vertraglichen Haftung überwiegend auszunehmen, indem er in den AGB festlegt, dass er nicht Vertragspartei wird, andererseits überschreitet sein Einfluss in weiten Teilen die Rolle eines klassischen Vermittlers.

I.

Verletzung von Schutzpflichten

Die Haftung für die Verletzung von Schutzpflichten ist zunächst dogmatisch unproblematisch. Sobald eine vertragliche Beziehung zwischen Anbieter und Plattformbetreiber oder Nutzer und Plattformbetreiber besteht oder sich eine solche anbahnt, bestehen die vertraglichen Schutzpflichten des § 241 II BGB, die zwar nicht im Einzelnen beschrieben sind, aber durch Auslegung des Schuldverhältnisses gem. §§ 133, 157 BGB ermittelt werden können. Solange also ein Vertrag zwischen den einzelnen Parteien besteht, wird eine Haftung für die Verletzung von Schutzpflichten gem. §§ 280 I, 241 II BGB begründet. Anhaltspunkte für die Ausgestaltung von Schutzpflichten im Verhältnis von Betreiber und Nutzer kann das Maklerrecht liefern.69 Die Verletzung einer Schutzpflicht ist zumindest dann anzunehmen, wenn dem Plattformbetreiber Informationen bekannt sind, dass eine Gefahr für die Rechtsgüter des Nutzers besteht und dieser hierüber nicht informiert wird.70 Der Ersatzanspruch des Nutzers ist auf den Ersatz des Vertrauenschadens gerichtet, nicht aber auf das positive Interesse.71 Darüber sollen die Schutzpflichten gerade keine Erkundungs- und Nachfor-

69 Zur Klassifizierung des Plattformbertreibers als Makler: Vilgertshofer, Online Plattformen und vertragliche Haftung, S. 95f.; Dreyer/Haskamp, ZVertriebsR 2017, 359, 361; zur Übertragung der Grundlagen Busch, Effektiver Verbraucherschutz im Online-Handel, https://tin yurl.com/2nxenjx8, S. 25ff. 70 BGH, Urt. v. 12. 7. 2018, I ZR 152/17, NJW 2019, 1223 Rn. 12. 71 OLG München Urt. v. 19. 11. 2014 – 20 U 2215/14, NJW-RR 2015, 692 Rn. 44; OLG Koblenz Urt. v. 16. 11. 2012 – 10 U 199/12 NJW-RR 2013, 828.

32

Regulierung plattformbasierter Modelle

schungspflicht des Plattformbetreibers begründen.72 Damit umfasst die Informationspflicht nur noch den stark eingegrenzten Anwendungsfall, dass der Plattformbetreiber sichere Kenntnis von einer Gefahr für den Nutzer hat, oder ausreichend Informationen über eine solche Gefahr vorhanden sind, dass der Plattformbetreiber sich nicht mehr nur auf die Angaben des Anbieters berufen kann.73 Es bleibt die Frage, ob eine Haftung des Plattformbetreibers für Verletzungen der primären Leistungspflichten des Anbieters oder eine sonstige Haftung für Schäden besteht, die nicht aus der Verletzung von Schutzpflicht resultieren.

II.

Haftung bei maßgeblichem Einfluss

Eine Haftung des Plattformbetreibers für die primäre Leistungspflicht der angebotenen Dienstleistung kommt zunächst dann in Betracht, wenn er selbst Vertragspartner im Rahmen des Dienstleistungsvertrages wird. Wird der Plattformbetreiber nicht selbst Vertragspartner und damit Anbieter der angebotenen Leistungen, stellt sich weiterhin die Frage, ob dennoch eine Haftung des Plattformbetreibers für die Leistungspflicht des Anbieters in Betracht kommt. Dies kann sich vor allem aus Gesichtspunkten des Vertrauensschutzes ergeben.74 Bei der verwaltungsrechtlichen Inanspruchnahme wurde für das PBefG darauf abgestellt, wer Vertragspartner wird bzw. wer zumindest als solcher auftritt. Insoweit kann auch bei der vertraglichen Haftung nicht auf eine andere Beurteilung abgestellt werden. Dort, wo der Plattformbetreiber mangels Transparenz als Anbieter einer Leistung auftritt, dürfte er bereits nach den §§ 133 157 BGB als Vertragspartner angesehen werden. In diesem Umfang würde er auch für die Nichtleistung nach den vertraglichen Grundlagen haften.75 Bei fehlender Transparenz wird der Plattformbetreiber zum Vertragspartner werden und für die Primärleistung unmittelbar haften. Verwaltungsrechtlich wird die Stellung des Plattformbetreibers als Vertragspartner nicht nur bei fehlender Transparenz, sondern auch bei maßgeblichem Einfluss des Plattformbetreibers auf den Anbieter bejaht.

72 Busch, Effektiver Verbraucherschutz im Online-Handel, https://tinyurl.com/2nxenjx8, S. 27; BGH, Urt. v. 12. 7. 2018, I ZR 152/17, NJW 2019, 1223 Rn. 22; OLG Du¨ sseldorf, Urt. v. 28. 07. 2017, I-7 U 118/16, juris. 73 BGH, Urt. v. 18. 1. 2007, III ZR 146/06, NJW-RR 2007, 711, 712 Rn. 13. 74 Busch/Dannemann/Schulte-Nölke, MMR 2016, 787, 789; Busch u.w., EuCML 2020, 61, 65ff.; Maultzsch in Blaurock/Schmidt-Kessel/Erler, Verantwortlichkeit der Plattformbetreiber, 223. 75 Maultzsch, in Blaurock/Schmidt-Kessel/Erler, Verantwortlichkeit der Plattformbetreiber, 223, 235f.

Haftung der Plattformen

33

Fraglich ist, ob diese Kriterien des öffentlichen Rechts auch zur Bestimmung des zivilrechtlichen Vertragspartners übertragen werden können. Das PBefG nimmt Bezug auf die vertraglichen Regelungen.76 Allerdings wird dort zwischen dem tatsächlichen, zivilrechtlichen Vertragspartner und dem faktischen Vertragspartner, der die rechtliche und tatsächliche Herrschaftsmacht innehat, differenziert.77 Bei der Bestimmung der rechtlichen und tatsächlichen Herrschaftsmacht ist das PBefG nicht an die Transparenzvorschriften, §§ 133, 157 BGB, gebunden, sondern kann auch eigene Anforderungen an die Transparenz stellen, indem sie auf den wirtschaftlichen Einfluss des Plattformbetreibers abstellt.78 Da für den Bereich der öffentlich-rechtlichen Regulierung unter den genannten Merkmalen ein scheinbarer Vertragspartner angenommen werden kann, könnte die Frage nach dem tatsächlichen Vertragspartner rein zivilrechtlich beantwortet werden, ohne dass es zu Widersprüchen mit dem öffentlichen Recht kommt. Wendet man hingegen diese Kriterien unverändert auf das Zivilrecht an, um den tatsächlichen Vertragspartner zu bestimmen, kommt es gerade nicht mehr allein auf die vertraglichen Beziehungen an, sondern es wird primär auf eine wirtschaftliche Betrachtung zurückgegriffen. Dieser Ansatz wird auf dogmatischer Ebene angegriffen. Es sei dem Zivilrecht fremd, dass eine private oder juristische Person allein aufgrund wirtschaftlichen Einflusses für die Verpflichtungen einer anderen Person hafte.79 Die Umgehung der Relativität der Schuldverhältnisse würde wesentliche Merkmale des Unternehmensrechts aufheben.80 Insbesondere die Haftungsbeschränkung und -verteilung scheinen nicht oder nur noch sehr eingeschränkt möglich zu sein. Konzernstrukturen würden die Funktion der Haftungsallokation nicht mehr sinnvoll erfüllen, da die Konzernmutter den wirtschaftlichen Einfluss auf die Tochterfirmen ausübt. Dem könnte allerdings entgegengehalten werden, dass die Plattformwirtschaft die typische Differenzierung zwischen »firm« und »market« durch fort-

76 Bauer, PBefG, § 2 Rn. 3; Heinze in Heinze/Fehling/Fiedler PBefG, § 2 Rn. 8. 77 Heinze in Heinze/Fehling/Fiedler PBefG, § 2 Rn. 9. 78 COM (2016) 356 final, v. 02. 06. 2016, S. 7; BGH, Beschl. v. 18. 5. 2017-I ZR 3/16 (KG), GRUR 2017, 743; EuGH Urt. v. 20. 12. 2017-C 434/15; OLG Frankfurt a.M., Urt. v. 09. 06. 2016-6 U 73 / 15, Rn. 38, GRUR-RR 2017, S. 19. 79 Maultzsch, in Blaurock/Schmidt-Kessel/Erler, Verantwortlichkeit der Plattformbetreiber, 223, 235. 80 Maultzsch, in Blaurock/Schmidt-Kessel/Erler, Verantwortlichkeit der Plattformbetreiber, 223, 240ff.

34

Regulierung plattformbasierter Modelle

schreitende technologische Möglichkeiten aufhebt und insoweit eine wirtschaftliche Betrachtungsweise zur Frage der Haftung erforderlich ist.81 In den neuen Märkten fallen der wirtschaftliche Nutzen und die wirtschaftlichen Risiken zunehmend auseinander. Bei Vermittlungsleistungen nehmen die Plattformen gleich Einfluss auf die Vertragsparteien und bestimmen teilweise sogar die elementaren vertraglichen Bestandteile wie z. B. den Preis.82 Ohne eine Haftung für die Primärleistungspflicht operiert die Plattform ohne wesentliche Risiken, während sie die Partei mit dem höchsten Umsatz und größten Einfluss ist, wohingegen der Anbieter der Leistung in der Regel von der Plattform abhängig ist und die Haftungsrisiken mit den Einnahmen nur eingeschränkt decken kann. Es scheint berechtigt, dass der Marktteilnehmer mit dem größten Nutzen und Einfluss auch ein überdurchschnittliches Haftungsrisiko zu tragen hat. So sollte der Plattformbetreiber zwar nicht als Vertragspartner angesehen, aber dennoch seine Haftung für Nichterfüllung in Betracht gezogen werden.83 Im US-amerikanischen Recht wurde bereits eine Haftung von Verkaufsplattformen angenommen, wenn der ausländische Verkäufer mangels Erreichbarkeit nicht in Anspruch genommen werden konnte.84 Hierbei wurde vor allem auf den Einfluss abgestellt, den Amazon sowohl auf den Verkäufer als auch auf den Käufer ausübt und somit wesentlicher Bestandteil der Lieferkette wird.85 Auch im deutschen Recht könnte sich eine solche Haftung aus der Vertrauens- oder Produkthaftung ergeben. Dies könnte sowohl in der Form einer Schadensersatzhaftung als auch in Form eines Anspruches auf die Primärleistung ausgestaltet werden.86 Als Grundlage kommen zum einen die Vertrauenstatbestände des BGB, zum andern die Haftung nach dem Produkthaftungsgesetz in Betracht. Im BGB könnte für eine Haftung von Dritten vor allem auf § 311 III BGB abgestellt werden. Er bietet einen Anknüpfungspunkt für eine Haftung eines Dritten vor allem dann, wenn er besonderes Vertrauen für sich in Anspruch nimmt und auf den Vertrag einwirkt gem. § 311 III S. 2 BGB. Hierzu wurden zwei grundlegende Fallgruppen erarbeitet. Zunächst soll die Haftung gem. § 311 III 81 Busch, Europäische Modellregeln für Online-Vermittlungsplattformen, 150, 159; grundlegend zur Terminologie: Coase, 4 (16) Economica, S. 386ff. 82 https://tinyurl.com/2p92ecs3 abgerufen am 18. 1. 2021. 83 Vgl. Busch, Europäische Modellregeln für Online-Vermittlungsplattformen, 150, 159. 84 Oberdorf v amazon.com Inc., 930 F.3d 136, 151 (3d Cir. 2019), CRi 2019, 120; Bolger v Amazon LLC, (to be published), https://tinyurl.com/4hnh6r8t, abgerufen am 18. 1. 2021. 85 Oberdorf v amazon.com Inc., 930 F.3d 136, 151 (3d Cir. 2019), CRi 2019, 120, S. 13ff.; Bolger v Amazon LLC (to be published), https://tinyurl.com/4hnh6r8t abgerufen am 18. 1. 2021, S. 17ff. 86 Zugunsten eines Schadensersatzanspruches: Maultzsch, in Blaurock/Schmidt-Kessel/Erler, Verantwortlichkeit der Plattformbetreiber, 223, 236.

Haftung der Plattformen

35

BGB in Betracht kommen, wenn der Dritte im eigenen unmittelbaren, wirtschaftlichen Interesse tätig wird.87 An das wirtschaftliche Interesse werden aber besonders hohe Anforderungen gestellt, sodass bloße Gewinne und Provisionen nicht erfasst sein sollen.88 Die zweite Fallgruppe erfasst Fälle, in denen der Dritte ein besonders Vertrauen in die Vertragsdurchführung schafft.89 Es muss sich letztlich um das Gegenstück einer echten Garantie im vorvertraglichen Bereich handeln.90 Grundsätzlich lassen sich beide Fallgruppen im Rahmen der Plattformhaftung diskutieren. Einerseits erinnert das Erfordernis des eigenen persönlichen Interesses an die Maßstäbe der wirtschaftlichen Einflussnahme im Rahmen des PBefG. Andererseits könnte der Plattformbetreiber durch Ranking-und Bewertungsmechanismen ein erhebliches Maß an Vertrauen in Anspruch nehmen, welches maßgeblich für den Vertragsschluss ist.91 Beide Fallgruppen bieten im Rahmen der Sharing Economy aber keinen erkennbaren Mehrwert. Die Haftung gem. § 311 III BGB ist auf die Verletzung von Schutzpflichten beschränkt. Die Plattformen der Sharing Economy setzen aufgrund der Möglichkeit von Transaktionen über die Plattform aber ohnehin eine Anmeldung auf der Plattform für die Nutzung voraus, sodass ein Plattformnutzungsvertrag zustande kommt. Ansichten, dass ein solcher lediglich die Pflicht zur Vertragsabwicklung erfasst92, kann nicht zugestimmt werden. Das Pflichtprogramm umfasst auch die Schutzpflicht gem. § 241 II BGB, sodass umfassend auf die Rechtsgüter der anderen Partei Rücksicht genommen werden muss. Auch wenn nicht schon die bloße Nutzung einer Website einen Vertragsschluss darstellt, so muss dieses Verhalten zumindest als Vertragsanbahnung i. S. d. § 311 II Nr. 2 BGB angesehen werden. Es besteht in diesem Bereich kein struktureller Unterschied zu dem Kunden, der sich zwar in den Verkaufsräumen des Händlers aufhält, bei dem eine konkrete Transaktion aber noch nicht ersichtlich ist. Der Plattformbetreiber haftet bereits unmittelbar als (künftiger) Vertragspartner gem. §§ 280 I, 241 II (311 II Nr. 2) BGB für Schutzpflichtverletzungen. Zwar müssen hier die Pflichten mittels Auslegung bestimmt werden. Dass dies zu

87 Emmerich in MüKo BGB, § 311 Rn. 190; Kersting, Die Dritthaftung für Informationen im Bürgerlichen Recht, S. 317 ff.; Grüneberg in Palandt, § 311 Rn. 61f. 88 BGH, Urt. v. 06. 06. 1994-II ZR 292/91, NJW 1994, 2220ff.; Urt. v. 27. 03. 1995 -II ZR 136/94, NJW 1995, 1544ff.; Urt. v. 5. 10. 2001-V ZR 275/00, NJW 2002, 208, 212. 89 BGH, Urt. v. 4. 7. 1954-II ZR 278/53, NJW 1954, 1524ff.; Urt. v. 5. 4. 1971-VII ZR 163/69, NJW 1971, 1309ff.; Urt. v. 29. 01. 1997-VIII ZR 356/95, NJW 1997, 1233ff. 90 Emmerich in MüKo BGB, § 311 Rn. 193 m.w.N. 91 Busch, Effektiver Verbraucherschutz im Online-Handel, https://tinyurl.com/2nxenjx8, S. 33; Hauck/Blaut, NJW 2018, 1425, 1429. 92 Hauck/Blaut, NJW 2018, 1425, 1427.

36

Regulierung plattformbasierter Modelle

anderen Ergebnissen als eine Anwendung des § 311 III BGB führen soll, ist aber nicht überzeugend. Für sonstige Pflichtverletzungen jenseits des § 241 II BGB genügt ein Schuldverhältnis gem. § 311 II, III BGB nicht. Die Ausdehnung der Haftung des § 311 III auf Ansprüche jenseits des §§ 280 I, 241 II BGB wird jedoch bei dem Sonderfall der Agenturgeschäfte bei Gebrauchtwagenhändlern diskutiert. Hier bietet § 476 I S. 2 BGB mit dem Verbot des Umgehungsgeschäfts allerdings einen konkreten Anknüpfungspunkt für die weitergehende Haftung.93 Es handelt sich bei den Vertragsschlüssen der Sharing Economy jedoch nicht um Kaufverträge, sondern es werden Nutzungen und Dienstleistungen vermittelt, sodass auch die Vorschriften des § 476 BGB nicht weiterhelfen. Über die Limitierung der Haftung kann auch nicht das ProdHaftG hinweghelfen. Bei Plattformen der Sharing Economy werden gerade keine Produkte veräußert. Es handelt sich vielmehr um Plattformen zur Vermittlung von Werk-, Dienst-, Miet- und Leihverträgen. Mangels einer veräußerten beweglichen Sache besteht keine Grundlage für die Anwendung gem. § 1 I, § 2 ProdHaftG.

§4

Ergebnis zu Teil 1

Aus dieser Darstellung lassen sich vor allem zwei Rückschlüsse ziehen. Zum einen scheint die öffentliche Regulierung gerade im Bereich der Personenbeförderung nicht mehr an die voranschreitende Entwicklung angepasst zu sein. Auch die Änderungen im PBefG mit Einführung der Figur des Beförderungsvermittlers zeigt lediglich, dass zwar die bisherige Rechtsprechung umfassend kodifiziert wird, kommende Herausforderungen aber nicht weiter beachtet werden. Zwar können dadurch die derzeitigen Geschäftsmodelle unter unter das PBefG subsumiert werden. Dies gelingt aber nur unter Rückgriff auf neue Kriterien, die sich lediglich auf den derzeitigen Stand von Plattformmodellen beziehen, aber künftig leicht umgangen werden können. Zum anderen besteht bereits beim derzeitigen Plattformmodell der Sharing Economy das Problem, dass die vermeintliche Dezentralisierung der Angebote ein Anknüpfen an den zentralen Intermediär erheblich erschwert. Ein Anknüpfen an den Intermediär ist aber aus Gründen der Solvenz und Risikobeherrschung für den Haftungsfall vorzugswürdig.

93 Vgl. Emmerich in MüKo BGB, § 311 Rn. 195f.

Teil 2: Dezentrale Anwendungen der Sharing Economy

Technologiebedingte Veränderungen der rechtlichen Einordnung lassen sich feststellen, indem dezentrale Anwendungen im Rahmen der im ersten Teil aufgeworfenen Fragen untersucht werden. Dazu wird das Geschäftsmodell einer dezentralen Anwendung unter die bisher diskutierten Normen subsumiert. Soweit sich im Rahmen dieser Subsumtion neue Rechtsfragen stellen, wird auch auf diese eingegangen. Mittels der dadurch gefundenen Ergebnisse lässt sich ein Vergleich zwischen Plattformen und dezentralen Anwendungen der Sharing Economy ziehen.

§5

Veränderung bestehender und Entstehung neuer Rechtsfragen

Die Antworten auf die bisherigen Fragen zur plattformbasierten Sharing Economy sind der Versuch, an eine zentrale Partei anzuknüpfen, während die eigentliche Leistung von Dritten erbracht wird. Gerechtfertigt wird dies mit der Effektivität einer Inanspruchnahme des Intermediärs. Während im Bereich des Marktzugangs die Effektivität der Durchsetzung bestehender Regulierung im Vordergrund steht, kommt es im Bereich effektiver Haftungssysteme auf einen solventen Schuldner an. Hierzu werden Maßstäbe herangezogen, die es ermöglichen, bei einem ausreichenden Einfluss des Plattformbetreibers diesen aufgrund seiner wirtschaftlichen Stärke zusätzlich in Anspruch zu nehmen. Stellt man sich nun ein System vor, das genauso wie die Plattformmodelle einer Vielzahl von Personen die Interaktion miteinander erlaubt, gleichzeitig aber keine zentralen Intermediäre mehr hat, werden die Probleme offensichtlich. Wird kein geeigneter Ersatz für den Intermediär gefunden, stehen die öffentliche Marktregulierung, die Durchsetzung von Informationspflichten und die Haftung vor einem kaum zu bewältigenden Regelungsproblem.

38 I.

Dezentrale Anwendungen der Sharing Economy

Marktzugangsregulierung

Eine Blockchain ist nach ihrer Veröffentlichung autonom und vor der Einflussnahme eines Einzelnen geschützt Dieses Stadium setzt den Marktzugang aber bereits voraus. Entscheidender Zeitpunkt für die Regulierung des Marktzugangs ist der Übergang zwischen der Entwicklung und dem Zur-VerfügungStellen an Dritte. Dies entspricht der Veröffentlichung der dezentralen Anwendung, die nichts anderes als das Anbieten einer Software ist94, die es einem mit dem Code kompatiblen Gerät ermöglicht, Aufgaben auszuführen. Die Nutzung der Software setzt voraus, dass sie heruntergeladen wird. Ob dabei das gesamte Programm oder nur ein Teil geladen werden muss, ist zunächst für die Frage der Verbreitung nicht erheblich.95 Das Veröffentlichen einer Blockchain geschieht in der Regel über das unentgeltliche Anbieten eines Downloads im Internet. Derjenige, der diesen Download bereitstellt, könnte dann als Verantwortlicher für die Blockchain angesehen werden. Im Rahmen dieser Funktion könnte er zur Einhaltung der marktzugangsbeschränkenden Regelungen verpflichtet sein. Dabei sind einerseits die derzeitigen Marktzugangsbeschränkungen von Plattformen zu beachten, gleichzeitig tritt andererseits eine weitere rechtliche Ebene hinzu. Während bei Plattformen die Nutzung bereits durch bloßes Anmelden mit einem Nutzerprofil möglich ist, wird die Nutzung von dezentralen Anwendungen ermöglicht, indem ihr Entwickler bei der Veröffentlichung der Anwendung sog. Token veräußert, die es Nutzern ermöglichen, Dienstleistungen in Anspruch zu nehmen. Hier stellt sich die Frage nach der rechtlichen Einordnung dieser Token. Dabei sind diverse Klassifizierungen möglich, von Zahlungsmitteln bis hin zu Wertpapieren, die dann jeweils eigenen Marktzugangsbeschränkungen unterliegen.96 Bisherige marktzugangsbeschränkende Regulierungen stehen im Konflikt mit dem grds. Aufbau einer dezentralen Anwendung. Nach den geltenden Vorschriften wird derjenige in Anspruch genommen, der eine bestimmte Leistung anbietet, beispielsweise in der Personenbeförderung derjenige, der als Beförderungsunternehmen auftritt. Es wird nicht auf das Anbieten digitaler Inhalte 94 Software sind die zum Betrieb einer Datenverarbeitungsanlage benötigten Programme, https://www.duden.de/rechtschreibung/Software abgerufen am 18. 1. 2021. 95 Zunächst ist eine Differenzierung zwischen »Full Node« und »Leightweight Node« nicht erforderlich, da zu Beginn der Blockchain in jedem Fall ein Full Node erforderlich ist. Ohne Full Node kann die Blockchain nicht funktionieren. 96 Positionspapier des deutschen Blockchain Bundesverbandes, https://tinyurl.com/tjr2rykh, S. 11; Girasa, Regulation of Crypotcurrencies and Blockchain Technologies, https://doi.org /10.1007/978–3–319–78509–7, S. 71ff.; BaFin Hinweisschreiben zu: Aufsichtsrechtliche Einordnung von sog. Initial Coin Offerings, WA 11-QB 4100-2017/0010, S. 2ff.

Veränderung bestehender und Entstehung neuer Rechtsfragen

39

abgestellt, sondern auf die tatsächlich erbrachte Dienstleistung. Mit Veröffentlichung der dezentralen Anwendung verliert der Anbieter aber seinen Einfluss auf diese. Im Gegensatz zu einem Plattformbetreiber, der als zentrale Figur jederzeit die Kontrolle über das System hat, ist der Anbieter einer Blockchain nur gleichwertiges Mitglied aller Node-Betreiber.97 Je mehr Node-Betreiber es gibt, desto geringer wird der Einfluss des Anbieters. Dies führt zu der Frage, inwieweit der Anbieter trotz seines Einflussverlustes auch nach Veröffentlichung der Blockchain noch als ihr Verantwortlicher angesehen werden kann und inwieweit bereits das Anbieten der Blockchain unter marktzugangsbeschränkende Regelungen fallen kann. Soweit der Anbieter selbst nicht Adressat entsprechender Regelungen ist, muss nach alternativen Ansatzpunkten für eine Pflicht zur Umsetzung der marktzugangsbeschränkenden Regelungen gesucht werden. Dies kann sowohl ein Anknüpfen an eine Handlung, nämlich das Veröffentlichen der Blockchain, als auch an andere Personen als den Anbieter sein, beispielsweise alle Betreiber der Full-Nodes.98 Wird dabei festgestellt, dass der Anbieter bereits beim Anbieten bestimmte Regelungen umsetzen muss, stellen sich Fragen nach den Folgen eines Verstoßes. Im Gegensatz zur Plattform kann der Anbieter die Blockchain weder einseitig einstellen, noch eigenmächtig den Code derart verändern, dass die Anforderungen der Regelungen erfüllt werden. Werden keine angemessenen Alternativen mit einem vergleichbaren Wirkungsgrad zur Inanspruchnahme des Plattformbetreibers gefunden, müssten die Anbieter einer Leistung mittels der Blockchain in Anspruch genommen werden. Dies würde bedeuten, dass jeder einzelne Anbieter einer Dienstleistung identifiziert, verpflichtet und die Durchsetzung der Maßnahme überwacht wird. Bei einer weltweiten Nutzerzahl Ubers von 75 Millionen Menschen99 würde bereits ein Bruchteil dieser Zahl zur faktischen Unmöglichkeit der Durchsetzung geltenden Rechts in Deutschland führen, und dies schon bei einer einzigen Blockchain. Es käme faktisch zu einem nicht regulierten Wirtschaftsbereich, der erhebliche Gefahren für die Nutzer birgt.

97 Selbst dies ist nicht zwingend erforderlich. Der Anwendungsentwickler muss nicht zwingend ein Full-Node betreiben. Allerdings dürfte dies zur Beobachtung der Entwicklung der Blockchain regelmäßig der Fall sein. 98 Full-Nodes sind die klassische Form der Nodes, die die gesamte Blockchain herunterladen und dadurch vollwertiges Mitglied der Blockchain werden. Light-Nodes sind hingegen von untergeordneten Bedeutung, da sie zwar einen Teil der Blockchain speichern, aber keinen Einfluss nehmen können. 99 Https://www.uber.com/newsroom/company-info/ abgerufen am 18. 1. 2021.

40 II.

Dezentrale Anwendungen der Sharing Economy

Verbraucherschutz

Die Ziele des Verbraucherschutzes sind bei der Blockchain die gleichen wie bei Plattformmodellen. Auch hier ist der Verbraucher an den wesentlichen Vertragsinformationen interessiert. Teilweise könnten sie mittels der Blockchain sogar vereinfacht werden, wenn eine Technologie die Vermittlungsleistung übernimmt. Wenn man den Versuch der Zentralisierung der Aufklärungspflichten bei Plattformen weiterverfolgt, ergibt sich innerhalb der Blockchain das Problem, dass es keine zentrale Partei mehr gibt, die diese Pflichten erfüllen kann. Es muss entweder eine andere Partei gesucht werden, die diese Pflichten erfüllen könnte oder es muss erneut auf die Anbieter zurückgegriffen werden, was aber nicht ausreichend effektiv ist. Wie auch bei Plattformen entstehen zwei unterschiedliche Szenarien. Einerseits kann der Anbieter gewillt sein, alle geforderten Informationen zu geben, die Blockchain ermöglicht dies aber in der technischen Umsetzung nicht oder aber die Blockchain bietet die technischen Voraussetzungen, der Anbieter liefert aber nicht die relevanten Informationen. Auch wenn im zweiten Szenario der Anbieter der Leistung in jedem Fall in Anspruch genommen werden könnte, sind zur effektiven Rechtsdurchsetzung Möglichkeiten auf der Ebene der Blockchain und deren technologischen Umsetzung zu suchen. Durch die stetig wachsenden technischen Möglichkeiten könnte im Endergebnis eine Durchsetzung der Pflichten effektiver sein als bisher. Die Idee von Regulierung durch Design könnte stärker denn je zum Tragen kommen.100 In den Blick der technischen Umsetzung sollten daher solche Mittel stehen, bei denen der Anbieter keine andere Wahl mehr hat als die rechtlichen Vorgaben einzuhalten. Wie der Plattformbetreiber nicht nur als Marktintermediär sondern auch als regulatorischer Intermediär101 behandelt wird, ist im Rahmen der dezentralen Anwendung nach ähnlichen Intermediären zu suchen. Da es aber nicht nur eine zentrale Partei gibt, existieren, wenn überhaupt, nur eine Vielzahl von Intermediären. Wenn solche in der Blockchain existieren, verlagert sich eine Vielzahl der Fragen. Es wäre weniger ein Problem, ob die Pflichten bei Plattformmodellen gleichermaßen auch in der dezentralen Anwendung bestehen, als vielmehr den Pflichtenadressaten zu bestimmen. Im Rahmen einer neuen Technologie entstehen für die Nutzer, und insbesondere für den Verbraucher, auch neue Gefahren aufgrund der Unerfahrenheit im Umgang mit dieser Technologie. Insoweit gilt es zu untersuchen, in welchem 100 U. a. Spindler in Verbraucherrecht 2.0, Regulierung durch Technik, S. 333ff. 101 Busch, Self-Regulation and Regulatory Intermediation in the Platform Economy, S. 115ff.

Veränderung bestehender und Entstehung neuer Rechtsfragen

41

Umfang der Verbraucher rechtlich oder tatsächlich vor dezentralen Anwendungen geschützt werden muss.

III.

Haftung

Einerseits ist eine weitgehende Haftung aus der Sicht des Verbraucher-und Anbieterschutzes wünschenswert, andererseits gilt es, die Besonderheiten der Technologie und die Umsetzungsmöglichkeit neuer Geschäftsmodelle zu berücksichtigen. Soweit dieser Konflikt nicht schon nach geltendem Recht zu lösen ist, muss untersucht werden, in welchem Umfang sich das Recht weiterentwickeln muss, um die jeweiligen Interessen zu schützen oder einen angemessenen Ausgleich zu schaffen. Schon bei Plattformbetreibern ist umstritten, in welchem Umfang diese gegenüber dem Anbieter und Nutzer haften.102 Die gleiche Frage stellt sich auch für eine Blockchain mit dem Problem, dass auf den ersten Blick ausschließlich eine Technologie tätig wird. Auf einer ersten Ebene muss untersucht werden, wer und in welchem Umfang für – gewollte oder ungewollte – Fehler der Technologie haftet. Während der Plattformbetreiber als Verantwortlicher zweifelsfrei ermittelt werden kann, gilt bei der dezentralen Anwendung zu berücksichtigen, dass unterschiedliche Parteien zu unterschiedlichen Zeitpunkten Einfluss auf die Anwendung nehmen können. Schäden können nicht nur durch Fehler, d. h. vom Programmierer unerwünschtes oder unbekanntes Verhalten, sondern auch durch gewolltes Verhalten der Technologie entstehen. Auf den ersten Blick scheinen diese Fragen in der Lösung identisch zu sein. Dies kann im Rahmen der Blockchain aber nicht so pauschal beantwortet werden. Die derzeit diskutierte Frage, inwieweit der Plattformbetreiber für Leistungsstörungen der Vertragsabwicklung haftet, erhält im Rahmen der Blockchain eine grundsätzliche Bedeutung. Ihr liegt die Frage zu Grunde, ob eine Technologie Vertrauen aufbauen kann und wer für dieses Vertrauen verantwortlich ist. Was passiert, wenn eine Vielzahl von Personen rechtlich relevante Handlungen vornehmen, die geeignet sind, andere Personen zu schädigen? Durch den starken Einfluss der Technologie und den geringeren Einfluss menschlichen Verhaltens auf die dezentrale Anwendung ist es zweifelhaft, ob das geltende

102 Statt vieler Busch/Dannemann/Schulte-Nölke, MMR 2016, 787; Busch u.w., EuCML 2020, 61ff.; Maultzsch in Blaurock/Schmidt-Kessel/Erler, Verantwortlichkeit der Plattformbetreiber, 223ff.

42

Dezentrale Anwendungen der Sharing Economy

Recht in der bisherigen Auslegung noch ausreichend Antworten liefern kann, die den neuen Geschäftsmodellen Rechnung tragen. Nach geltendem Recht könnten Lösungen im BGB und Produkthaftungsrecht unter Hinzuziehung unterschiedlicher Rechtsinstitute gesucht werden, von Produkthaftung über deliktische bis zur gesellschaftsrechtlichen Haftung, die vielleicht nicht einzeln aber möglicherweise im Zusammenspiel ein geeignetes Haftungssystem für dezentrale Anwendungen liefern könnten.

§6

Marktzugang

Im Bereich der marktbezogenen Regulierung ergibt sich eine Besonderheit von dezentralen Anwendungen nicht nur aus der Dezentralisierung des Systems, sondern vor allem bei Marktzugangsbeschränkungen aus der Rolle des Entwicklers der Blockchain. Während der Betreiber einer Plattform tatsächlich selbstständig die Vermittlungsdienstleistung und sonstige Dienste auf der Plattform eigenständig anbietet, ist der Entwickler einer Blockchain an der Dienstleistung oder auch nur deren Vermittlung letztlich nicht beteiligt. Er beschränkt seine Tätigkeit auf die Entwicklung und Veröffentlichung der Blockchain. Die einzig rechtlich relevante Tätigkeit, an die letztendlich angeknüpft werden kann, ist die Verbreitung einer Software, die geeignet ist, die Funktionen eines Plattformbetreibers zu ersetzen. Nur wenn sich hieraus Pflichten ergeben, kann der Entwickler einer Blockchain Marktzugangsschranken unterliegen. Während der rechtliche Anknüpfungspunkt schwierig erscheint, dürfte wohl das gewünschte Ergebnis offensichtlich sein. Die Gründe für Marktzugangsbeschränkungen für Plattformbetreiber bleiben die gleichen, wenn die Funktionen durch eine Technologie ersetzt werden. Es wäre ein logischer Schluss, wenn somit auch die Technologie einer Marktzugangsbeschränkung unterliegt. Einzig möglicher Zeitpunkt für die Beschränkung des Marktzuganges ist die Veröffentlichung der Software. Daraus ergibt sich folgendes Bild: Einerseits kann man den Entwickler einer dezentralen Anwendung nicht mit einem Plattformbetreiber gleichsetzen, da sein Tätigkeitsfeld, zumindest auf den ersten Blick, deutlich hinter dem des Plattformbetreibers zurückbleibt; andererseits beeinträchtigt seine Tätigkeit die geschützten Interessen der Marktteilnehmer gleichermaßen. Vom Schutzzweck ausgehend wäre es insoweit widersprüchlich, wenn eine Regulierung nur aufgrund der Anwendung einer neuen Technologie unterbleibt. Zwar könnte man dem Betreiber einer Plattform die Entwicklung und Verbreitung einer Technologie zur »autonom funktionierenden Plattform« gleich-

Marktzugang

43

setzen103, da es letztlich nur zu einer Vorverlagerung der Handlungen kommt, dies stößt aber im Rahmen der Anwendung von öffentlich-rechtlichen Normen an seine Grenzen.

I.

Sektorspezifische Schranken

Da der Anwendungsentwickler zunächst vor allem digitale Inhalte anbietet, stellt sich die Frage, ob er im Rahmen dieser Tätigkeit einer Genehmigungspflicht, also einer marktzugangsbeschränkenden Maßnahme unterliegt. Aufgrund der Vielzahl möglicher dezentraler Anwendungen werden solche Maßnahmen zunächst an den Beispielen Personenbeförderung und Kurzzeitvermietung als den beiden populärsten Sharing Economy Modellen untersucht. 1.

Schranken für Dienste der Informationsgesellschaft

Soweit es sich bei den untersuchten Anwendungen um Dienstleistungen der Informationsgesellschaft im Sinne des Art. 2 a) der Richtlinie 2000/31/EG (ECommerce RL)104 handelt, gilt der Grundsatz der Zulassungsfreiheit gem. Art. 4 E-Commerce RL. Nach der Rechtsprechung des EuGH gilt die Zulassungsfreiheit gem. Art. 4 E-Commerce RL aber nur insoweit uneingeschränkt, wie der Vermittlungsdienst nicht integraler Bestandsteil einer anderen Dienstleistung und im Rahmen der Gesamtdienstleistung in der Bedeutung untergeordnet ist.105 Für Anwendungsentwickler im Bereich der Personenbeförderung bedeutet das, dass eine Zulassungsschranke mit der E-Commerce RL vereinbar ist, soweit der Entwickler als Erbringer der Beförderung, d. h. Unternehmer gem. § 3 PBefG, anzusehen ist. Gleichermaßen gilt für den Bereich der Kurzzeitvermietung, dass Schranken insoweit zulässig sind, wie der Entwickler auch Anbieter der Unterkunft ist.

103 Das Problem der Autonomisierung von Technologien zeigt sich auch im Bereich des autonomen Fahrens; mögliche Lösungen könnten sich also auch aus der Debatte um die Zulassung selbstfahrender Autos ergeben. 104 Richtlinie 2000/31/EG des Europäischen Parlaments und des Rates vom 8. Juni 2000 über bestimmte rechtliche Aspekte der Dienste der Informationsgesellschaft, insbesondere des elektronischen Geschäftsverkehrs, im Binnenmarkt (»Richtlinie über den elektronischen Geschäftsverkehr«). 105 Für den Fall Uber: EuGH Urt. v. 20. 12. 2017-C-434/15.

44 2.

Dezentrale Anwendungen der Sharing Economy

Personenbeförderung

Es gibt bereits eine Vielzahl von dezentralen Anwendungen, die im Bereich der Personenbeförderung entwickelt wurden.106 Dabei können sich die Konzepte stark unterscheiden. Während einige nur das System von Uber in die Blockchain übertragen, wollen andere ein eigenes Ökosystem für sämtliche fahrzeugbezogene Transaktionen schaffen, vom Kauf bis zu jeder Wartung und jeder entgeltlichen Personenbeförderung. Da Letzteres nur ein »Mehr« zu solchen Anwendungen darstellt, die sich ausschließlich auf die Personenbeförderung beziehen, genügt die Konzentration auf Ersteres. Soweit hier Ergebnisse gefunden werden, können diese auf sonstige weitergehende Anwendungen übertragen werden. Die Marktzugangsbeschränkung im Personenbeförderungsrecht liegt in der Genehmigungspflicht des § 2 PBefG. Aus dem Grundsatz des Gesetzesvorbehaltes ergibt sich die Unterteilung in die Genehmigungsbedürftigkeit und die Genehmigungsfähigkeit. Soweit eine Handlung nicht unter die Genehmigungspflicht fällt, ist diese dementsprechend nicht grundsätzlich unzulässig, sondern nur dann, wenn dies gesetzlich angeordnet ist. a. Genehmigungsbedürftigkeit Gem. § 2 I PBefG muss derjenige im Besitz einer Genehmigung sein, der i. S. d. § 2 I Nr. 4 i. V. m. § 46 PBefG mit Kraftfahrzeugen im Gelegenheitsverkehr Personen befördert. Der Normadressat der Genehmigungspflicht ist, anders als der Wortlaut dies vermuten ließe, nicht der tatsächlich Befördernde, sondern derjenige, der die rechtliche Herrschaft über das Fahrzeug ausübt.107 Hierunter fällt vor allem derjenige, der im Rahmen einer vertraglichen Beförderungspflicht handelt.108 Damit der Anwendungsentwickler genehmigungsbedürftig ist, müsste er also Vertragspartner der späteren Beförderungsleistung sein. aa. Entwickler als Unternehmer i. S. d. PBefG Dass der Anwendungsentwickler nicht Vertragspartner der Beförderungsleistung wird, lässt sich nach vertragsrechtlichen Grundlagen feststellen. Voraussetzungen für einen Vertragsschluss sind übereinstimmende Willenserklärungen. Und soweit sie vorliegen, muss Einigkeit über die essentialia negotii bestehen.109 Eine Willenserklärung setzt als Mindestmaß einen Rechtsbindungswillen 106 Beispiele sind LaZooz, ArcadeCity, MVL und diverse weitere in der Entwicklung z. B. durch Kuaidi Dache. 107 Heinze, PBefG, § 2 S. 2; Grätz in Fielitz/Grätz PBefG, § 2 Rn. 5; BVerwG, Urt. v. 27. 03. 1992-7C 26/91, juris; VGH Bayern Urt. v. 25. 11. 1982, Urt. v. 25. 11. 1982-11 B 80 A.992, juris. 108 Heinze in Heinze/Fiehling/Fädler PBefG, § 3 Rn. 9. 109 Busche in MüKo BGB, § 145 Rn. 7ff.

Marktzugang

45

voraus.110 Aus Sicht eines verständigen Dritten muss mit der Handlung eine rechtliche Bindung gewollt sein, §§ 133, 157 BGB analog. Zwar können Willenserklärungen auch konkludent erfolgen, aber auch dies stößt bei der Zurverfügungstellung einer Software an ihre Grenzen. Dem Anwendungsentwickler sind weder die zukünftigen Vertragspartner für Personenbeförderung oder ihre Anzahl bekannt, noch möchte er sich überhaupt zu einer Beförderung verpflichten. Dies ergibt sich allein schon daraus, dass er in aller Regel faktisch zur Personenbeförderung nicht in der Lage sein wird. Die Voraussetzungen zur Entwicklung einer Software sind gänzlich andere als die für den Betrieb eines Personenbeförderungsunternehmens. Insoweit müsste der Entwickler auch nach der Veröffentlichung einen Einfluss auf die Anbieter von Leistungen haben, damit entsprechend der Uber-Rechtsprechung von der Unternehmereigenschaft ausgegangen werden könnte. Der Entwickler bietet zwar digitale Inhalte an – und in diesem Rahmen ist es durchaus denkbar, dass ein Vertrag zwischen dem Entwickler und dem Nutzer über den Download der Software entsteht – hieraus aber eine Willenserklärung für einen Vertragsschluss sämtlicher folgender Transaktionen zwischen den Nutzern untereinander abzuleiten, entspricht weder dem Willen des Anwendungsentwicklers noch dem Verständnis eines verständigen Dritten. Allein aus der Bereitstellung der Software kann sich kein ausreichender Rechtsbindungswille ergeben. Auch haben die Nutzenden ein Interesse daran, mit einem »Gegenüber« den Vertrag zu schließen, der im Gegensatz zum Entwickler zur Erfüllung der Primärpflicht im Stande ist. Dem steht nicht entgegen, dass die Beförderung nicht höchstpersönlich erfolgen muss.111 Eine Zurechnung würde voraussetzen, dass sich der Anwendungsentwickler Angestellter oder sonstiger beauftragter Personen bedient. Auch ein solches rechtliches Verhältnis lässt sich zwischen dem Entwickler und den Nutzern der Blockchain nicht herstellen. Für die Willenserklärungen der Nutzenden mag letztlich zwar noch die Solvenz im Haftungsfall eine Rolle spielen. Hieraus aber einen erkennbaren Rechtsbindungswillen des Entwicklers bei Veröffentlichung der Blockchain abzuleiten, überdehnt die Möglichkeiten der Auslegung nach §§ 133, 157 BGB. Der Entwickler wird also zumindest aus zivilrechtlicher Sicht nicht Vertragspartner der späteren Beförderungsleistungen. Es bleibt im Endeffekt dabei, dass der Anwendungsentwickler als einzige Leistung die Bereitstellung einer Technologie leisten möchte und leistet. Im Fall Uber hat die nationale und europäische Rechtsprechung auch über die zivilrechtlichen Maßstäbe hinaus Kriterien entwickelt, durch die ein sonstiger

110 Busche in MüKo BGB, § 145 Rn. 7ff. 111 Heinze, PBefG § 2 Rn. 2.

46

Dezentrale Anwendungen der Sharing Economy

Dienstleister als Anbieter der Personenbeförderung angesehen werden kann;112 nämlich dann, wenn er die Preisgestaltung, die Abwicklung des Zahlungsverkehrs und die Beförderungsbedingungen für die Fahraufträge maßgeblich bestimmt.113 Diese Rechtsprechung könnte auch auf den Anwendungsentwickler übertragen werden, sodass er zwar nicht im zivilrechtlichen Sinne Vertragspartner wird, sich aber im Rahmen des PBefG als solcher behandeln lassen müsste. Im Unterschied zu den bisherigen Plattformmodellen ist aber der Anwendungsentwickler im Zeitpunkt der tatsächlichen Transaktion nicht mehr Mittelsmann, da er zu diesem Zeitpunkt den Einfluss auf die Blockchain bereits verloren hat. Allerdings kann er durch die Programmierung des Codes im Zeitpunkt der Entwicklung all diese Merkmale in die Blockchain integrieren. Er kann beliebige Voraussetzungen in der Blockchain hinterlegen, damit eine Transaktion als gültig angesehen wird. Insoweit kann er zunächst im erheblichen Ausmaß die Bedingungen der einzelnen Transaktionen bestimmen. Dies kann von automatischen Preisalgorithmen bis zu einer Identitätsfeststellung vor Fahrtbeginn alle denkbaren Formen annehmen. Er wickelt zwar nicht die Zahlungsvorgänge selbst ab, allerdings schafft er mit der Blockchain die Technologie für eine automatische Zahlungsabwicklung und in den überwiegenden Fällen in Gestalt der Token auch ein eigenes Zahlungsmittel. Insoweit hält der Vergleich mit bisherigen Beförderungsplattformen stand. Indem er die Blockchain entwirft, kann der Anwendungsentwickler im gleichen Maße Einfluss auf die Transaktionen nehmen wie ein Plattformanbieter. Anwendungsentwickler und Plattformbetreiber unterscheiden sich aber in der Dauerhaftigkeit und Umfang ihres Einflusses. Im Gegensatz zu einem Plattformbetreiber gibt ein Anwendungsentwickler keine AGB für die einzelnen Transaktionen vor. Der Plattformbetreiber hingegen übt mit den AGB zur Nutzung seiner Plattform dauerhaft seinen Einfluss auf die Transaktionen aller Nutzenden aus. Auch wenn diese unter den Wirksamkeitsvoraussetzungen der §§ 305ff. BGB stehen, kann hiermit der Einfluss des Plattformbetreibers auf einzelne Transaktionen rechtlich abgesichert werden. Die tatsächliche Macht des Plattformbetreibers auf die Plattform und die Transaktionen wird somit durch die rechtliche Absicherung mittels der AGB ergänzt. Im Gegensatz dazu übernimmt der Entwickler keine zentrale Rolle in der Blockchain nach deren Veröffentlichung. Er hat kein Interesse daran, durch AGB 112 BGH, Beschl. v. 18. 5. 2017-I ZR 3/16 (KG), GRUR 2017, 743; EuGH Urt. v. 20. 12. 2017-C 434/ 15. 113 BGH, Beschl. v. 18. 5. 2017-I ZR 3/16 (KG), GRUR 2017, 743; EuGH Urt. v. 20. 12. 2017-C 434/ 15.

Marktzugang

47

Vorgaben zu machen, die er letztlich nicht durchsetzen kann. Er kann aufgrund der Open-Source-Natur der Blockchain niemandem den Zutritt zur Blockchain verweigern und er kann auch Teilnehmer nicht aus der Blockchain entfernen.114 Statt auf AGB zurückzugreifen, kann er aber Vorgaben durch das Design der Blockchain machen. Durch die automatisierten Vorgänge kann dieser Einfluss sogar den eines Plattformbetreibers übersteigen. Indem sämtliche Voraussetzungen im Code der Blockchain hinterlegt sind und die Abwicklung automatisiert wird, besteht für den Anbieter und den Nutzer auch im tatsächlichen Sinne keine Möglichkeit, von den Vorgaben des Anwendungsentwicklers abzuweichen. Der Anwendungsentwickler kann also letztlich im gleichen Maße wie ein Plattformbetreiber einen Einfluss auf die Transaktionen ausüben, gleichzeitig kann er aber auch auf die Ausübung dieses Einflusses verzichten. Insoweit erscheint es sinnvoll, die Kriterien aus den bisherigen Entscheidungen zu Beförderungsdienstleistern zu übernehmen, sodass der Anwendungsentwickler bei einer vergleichbaren Einflussnahme ebenfalls als Unternehmer i. S. d. § 2 PBefG behandelt werden könnte und die gleichen Voraussetzungen erfüllen müsste. Der einzige Unterschied, der verbleibt, ist letztlich, dass der Plattformbetreiber seine Kontrolle während der Transaktion ausübt, der Anwendungsentwickler aber bereits im Vorfeld, ohne Kenntnis von einer konkreten Transaktion zu haben. Der Einfluss des Anwendungsentwicklers kann nach Veröffentlichung der Blockchain von den Nodes auch jederzeit verändert werden. Gerade dieser Unterschied kann aber dazu führen, dass der Anwendungsentwickler nicht mehr unter die Genehmigungspflicht des § 2 I PBefG fällt. Auch wenn die entsprechende Anwendung der bisherigen Kriterien zur Bestimmung des Unternehmers möglich ist, ist der tatsächliche Einfluss des Blockchain-Betreibers nicht rechtlich abgesichert. Es besteht für ihn keine Möglichkeit, seinen Einfluss zu garantieren und die Nodes sind nicht verpflichtet sich an die Vorgaben des Entwicklers zu halten. Gerade die rechtliche Absicherung ist aber der Ausgangspunkt der Uber-Rechtsprechung. Auch wenn sie sich nicht unmittelbar übertragen lässt, könnte der Anwendungsentwickler von der Genehmigungspflicht des § 2 PBefG erfasst sein, wenn er in sonstiger Weise die Voraussetzungen erfüllt oder§ 2 PBefG analog anzuwenden ist.

114 Dies bezieht sich auf public permissionless blockchains, die aber die Grundlage für jede massentaugliche dezentrale Anwendung sind; permissionless blockchains werden aufgrundlage von open-source-software umgesetzt, d. h. jeder kann den erforderlichen client frei herunterladen, vgl. Münzer, BaFin Journal 2014, 26.

48

Dezentrale Anwendungen der Sharing Economy

bb. Erweiternde Auslegung Bei dem Versuch, den Anwendungsentwickler unter § 2 PBefG zu subsumieren, muss man sich letztlich die Frage stellen, ob es sich hierbei noch um eine Auslegung der Norm handelt oder aber bereits eine Analogie erforderlich ist. Abhängig von der Antwort, müssen unterschiedliche Grenzen berücksichtigt werden. Vom Wortlaut ausgehend muss festgestellt werden, was unter jemandem zu verstehen ist, der Personen befördert i. S. d. § 2 I PBefG. Wie bereits gezeigt, fällt hierunter derjenige, der die Leistung in eigener Verantwortung erbringt und gegenüber dem Beförderten als Vertragspartner auftritt.115 Der Anwendungsentwickler hat, im Unterschied zum Plattformbetreiber, zum Zeitpunkt der Beförderungsleistungen keine rechtliche Beziehung zum Nutzer der Leistung. Vertragliche Verbindungen können zwar zum Zeitpunkt der Überlassung der dezentralen Anwendung bestehen. Diese beziehen sich aber auf die Nutzung der Anwendung selbst, nicht auf die hierüber geschlossenen Verträge mit Dritten. Der Anwendungsentwickler ist weder Vertragspartner, noch tritt er mangels rechtlicher Einflussnahme als solcher gegenüber dem Beförderten auf. Sein Einfluss beschränkt sich auf den Moment der Veröffentlichung, indem er den Code der dezentralen Anwendung bestimmt. Auch wenn man mit dem Wortlaut auf den tatsächlich Befördernden abstellt, ist der Entwickler nicht erfasst. Auf die Beförderung als solche hat er auch mittels der Blockchain keinen Einfluss. Er mag zwar die Umstände des Vertragsschlusses beeinflussen und mittels der Blockchain tatsächlichen Einfluss auf die Zahlungsabwicklung haben, die Beförderung ist hiervon aber losgelöst. Da nur der natürliche Wortsinn als klare Grenze zwischen Auslegung und Analogie dienen kann, kann bereits hier auf die Analogie übergegangen werden.116 cc. Analoge Anwendung des § 2 I PBefG Eine Analogie setzt grundsätzlich eine planwidrige Regelungslücke und eine vergleichbare Interessenlage voraus.117 Bei der planwidrigen Regelungslücke handelt es sich um eine planwidrige Unvollständigkeit des Gesetzes.118 Voraussetzung ist zum einen ein subjektiver gesetzgeberischer Wille oder ein objektiver

115 Heinze, PBefG, § 2 Rn. 2; Grätz in Fielitz/Grätz PBefG, § 2 Rn. 5; BVerwG, Urt. v. 27. 03. 1992– 7C 26/91; VGH Bayern Urt. v. 25. 11. 1982, Urt. v. 25. 11. 1982-11 B 80 A.992. 116 Hemke, Methodik der Analogiebildung im öffentlichen Recht, S. 64; Luther, Jura 2013, 449, 450ff. 117 BGHZ 105, 140, 143; 149, 165, 174; 170, 187, 14; Puppe: Kleine Schule des juristischen Denkens, S. 115ff. 118 Canaris, Die Feststellung von Lücken im Gesetz, S. 39; Bydlinski: Juristische Methodenlehre und Rechtsbegriff, S. 472ff.

Marktzugang

49

Zweck des Gesetzes zur Regelung entsprechender Fälle, zum anderen darf der Fall nicht schon unter eine bestehende Norm zu subsumieren sein.119 (1) Planwidrige Regelungslücke § 2 I PBefG ist die einzige eine Genehmigungspflicht im PBefG begründende Norm und erfasst, wie gezeigt, den Anwendungsentwickler nicht unmittelbar. Der subjektive Wille des Gesetzgebers zum Sinn und Zweck der Genehmigungspflicht aus § 2 PBefG lässt sich nur schwer nachvollziehen. Im Wesentlichen besteht die Norm unverändert seit 1934 (i. d. F. des PBefG von 1934).120 Zum damaligen Sinn der Genehmigungspflicht äußert sich der Gesetzgeber nicht. Es lassen sich lediglich allgemeine Ausführungen zum Sinn und Zweck des Gesetzes von 1934 finden. Danach sollten alle Beförderungen von Personen mit Ausnahme des Schienenverkehrs einheitlich im »ganzen Reich« geregelt werden. Diese Fassung wurde 1952 ohne weitere Begründung im Wesentlichen übernommen.121 Rückschlüsse über Ziel und Zweck des Gesetzes lassen sich daher nur aus den Regelungen des Gesetzes selbst entnehmen, vor allem aus § 13 PBefG. Aus den Gründen, die zu einer Versagung der Genehmigung führen, lässt sich im Umkehrschluss auf Sinn und Zweck der Genehmigung schließen. § 13 II PBefG findet nur auf den Linienverkehr Anwendung, der bei der unregelmäßigen Beförderung zwischen unterschiedlichen Zielen gerade nicht betroffen ist. Eine Beschränkung der Genehmigung unterliegt nur § 13 I PBefG und den darin geregelten subjektiven Voraussetzungen. Aus den Voraussetzungen der Zuverlässigkeit und der fachlichen Eignung aus § 13 I PBefG, lässt sich der Schutz der Sicherheit des öffentlichen Personenbeförderungsverkehrs ableiten. Die Allgemeinheit soll vor leistungsunfähigen, unzuverlässigen oder fachlich ungeeigneten Personen geschützt werden.122 Dieser Schutz ist aber nicht nur erforderlich, wenn es sich um einen Unternehmer handelt, sondern auch dann, wenn andere Personen in vergleichbarer Weise Einfluss auf den Verkehr nehmen können. Aus Sinn und Zweck des Gesetzes zur Genehmigungspflicht bestimmter Leistungen der Personenbeförderung kann gefolgert werden, dass § 2 PBefG keine abschließende Regelung ist. Der objektive Wille des Gesetzgebers legt vielmehr nahe, dass § 2 PBefG auf vergleichbare Fälle erstreckt werden soll. Der Anwendungsentwickler ist auch nicht bewusst aus dem Regelungsbereich des PBefG ausgeschlossen worden. Blockchains sind Erscheinungsformen technischen Fortschritts, den der Gesetzgeber nicht voraussehen konnte. 119 120 121 122

Canaris, Die Feststellung von Lücken im Gesetz, S. 39. Damals: § 2 Gesetz zur Beförderung von Personen zu Lande, RGBl. I S. 1217. BGBl. I 1952 S. 21. Grätz in Fielitz/Grätz PBefG, § 13 Rn. 4.

50

Dezentrale Anwendungen der Sharing Economy

Insgesamt kann somit von einer planwidrigen Regelungslücke ausgegangen werden. (2) Vergleichbare Interessenlage Nachdem die Historie keine Rückschlüsse für die Anwendung auf Anwendungsentwickler ermöglicht, bleiben zum Vergleich der Interessenlage nur die Systematik des Gesetzes und Telos der Norm.123 Eine Analogie scheint nach dem Normzweck zumindest dann geboten, wenn der Anwendungsentwickler, wie ein bisheriger Unternehmer, den öffentlichen Personennahverkehr beeinflusst. Da dann auch die gleichen Risiken bestehen, scheint es sinnvoll auch die gleichen Zugangsvoraussetzungen zu fordern. Bis zum Erscheinen von Uber war der Einfluss des Einzelnen auf das Gesamtsystem der Personenbeförderung gering. Der verbreitete Einsatz von Subunternehmern begründete bislang keine Vormachtstellung eines Einzelnen.124 Dies änderte sich mit Uber und vergleichbaren Plattformen. Schon vorher gab es Taxi-Apps, aber es erschien in der Person des App-Anbieters kein neuer Unternehmer. Die App war ausschließlich auf die Vermittlung beschränkt. Erst Uber nahm auf die tatsächlich befördernden Personen einen solchen Einfluss, dass Uber selbst als Beförderungsdienstleister eingestuft wurde. Der Einfluss auf die Personenbeförderung ergab sich dabei zum einen aus dem Einfluss auf jeden einzelnen Beförderer, der Uber nutzte, zum anderen auch insgesamt durch die flächendeckende Verbreitung von Uber in vielen deutschen Städten und die dadurch wachsende Marktmacht. An diese Stelle tritt nun der Anwendungsentwickler. Auch er kann erheblichen Einfluss auf den einzelnen Fahrer wie auch auf das gesamte System der Personenbeförderung nehmen. Auch beim Anwendungsentwickler besteht bei Unzuverlässigkeit und fehlender fachlicher Kenntnis die Gefahr, dass eine Blockchain veröffentlicht wird, die erhebliche Nachteile für die Sicherheit der Allgemeinheit mit sich bringt. Nachteile können von fehlerhaften Preismechanismen über die Zulassung ungeeigneter Fahrer bis zur bewussten Umgehung sonstiger Beschränkungen der Personenbeförderung gehen. Auch wenn Grundlage der Analogie nicht der Vergleich zu einem anderen konkreten Sachverhalt ist, scheint ein Vergleich mit Uber hilfreich, um ein Gespür für ein sinnvolles Ergebnis zu bekommen. Je ähnlicher die beiden konkreten Sachverhalte sind, desto sinnvoller wäre die Anwendung der gleichen Regelungen auf der abstrakten Normebene.

123 BGH, Beschl. v. 18. 5. 2017-I ZR 3/16 (KG), GRUR 2017, 743; EuGH Urt. v. 20. 12. 2017-C 434/ 15. 124 2016 gab es fast 22.500 Taxiunternehmen in Deutschland. Bei rund 2.000 Städten zeigt sich keine vorherrschende Stellung eines einzelnen Unternehmens.; Statistisches Bundesamt nach statista: https://tinyurl.com/2ehzdzuf abgerufen am 18. 1. 2021.

Marktzugang

51

In der bisherigen Rechtsprechung wird überwiegend betont, dass Uber die Herrschaft über die Zahlungsabwicklung hat und dadurch einen erheblichen Einfluss auf den einzelnen Fahrer ausübt.125 Ähnlich ist die Zahlungsabwicklung in einer dezentralen Anwendung. Schließlich ist der Anwendungsentwickler für die Ausgestaltung der Zahlungsabwicklung verantwortlich. Allerdings ist es ihm in öffentlichen, zugangsfreien Blockchains nicht möglich, Transaktionen zu beeinflussen. Unabhängig davon, welcher Konsensmechanismus der Blockchain zu Grunde gelegt wird, wird nicht der Anwendungsentwickler zentrale Verifizierungsstelle sein, da dies den Eigenschaften der Blockchain widerspräche. Kerngedanke der Blockchain-Technologie ist gerade die Dezentralisierung, das heißt die Unabhängigkeit von einer zentralen Partei. Auch wenn es eine Vielzahl von Konsensmechanismen bei öffentlichen Blockchains gibt, haben diese alle gemein, dass keine Partei alleine Verifizierungsstelle ist.126 Daher schafft der Anwendungsentwickler zwar die Infrastruktur für die Bezahlung, auf die einzelne Transaktion kann er aber im Gegensatz zu Uber keinen Einfluss nehmen. Insbesondere ist der Fahrer für den Erhalt des Entgeltes nicht auf eine Transaktion des Anwendungsentwicklers angewiesen. Diese Rolle wird stattdessen von den Nodes erfüllt. Dabei wird aber nach den Regeln der Konsensmechanismen durch Zufall bestimmt, welches Node die Transaktion überprüft und bestätigt. Die übrigen sind hingegen nur für die Implementierung des fertigen Blockes in die Blockchain verantwortlich. Letztlich sind somit die Nodes für die Zahlungsabwicklung verantwortlich und nicht der Entwickler. Indem die Gültigkeit der Transaktion nur erreicht werden kann, wenn eine Mehrzahl der Nodes die Transaktion speichert, sind alle Nodes gemeinschaftlich für die Transaktion verantwortlich, wobei jedes Node selbst nur für einen Bruchteil der Verifizierung verantwortlich ist. Selbst wenn man die Rechtsprechung auf einen Anwendungsentwickler übertrüge, wäre man nicht in der Lage ihn mit den gleichen Voraussetzungen unter den Unternehmerbegriff zu subsumieren. So sehr das Telos der Norm für die Vergleichbarkeit der Sachverhalte und somit für die Analogie zu § 2 PBefG spricht, darf die Systematik der sonstigen Normen des PBefG nicht außer Acht gelassen werden. Gegen eine Genehmigungspflicht spräche, wenn die Genehmigungsvoraussetzungen nicht sinnvoll anwendbar sind und die Rechtsfolgen der Genehmigung wirkungslos wären. Aus § 13 I PBefG lassen sich die Voraussetzungen entnehmen, in welchen Fällen eine Genehmigung versagt werden dürfte. Während §13 I Nr. 1–2 PBefG noch sinnvoll auf den Anwendungsentwickler übertragen werden können, scheint dies bei § 13 125 EuGH Urt. v. 20. 12. 2017-C-434/15, juris; LG Frankfurt a.M. Urt. v. 19. 12. 2019-3-08 O 44/19, juris. 126 Einen Überblick bietet: https://tinyurl.com/37vmy3d6 abgerufen am 03. 09. 2018.

52

Dezentrale Anwendungen der Sharing Economy

I Nr. 3–4 PBefG fraglich. Gem. § 13 I Nr. 3 PBefG ist die Genehmigung zu versagen, wenn der Unternehmer fachlich ungeeignet ist. Die fachliche Eignung des Blockhain-Entwicklers fördert aber nur in seltenen Fällen den Schutz des Beförderten. Auf die tatsächliche Beförderung hat der Entwickler keinen Einfluss, sodass sich die fachliche Eignung nur in der Programmierung der Blockchain widerspiegeln kann. Nur wenn eine Programmierung der Anwendung bereits Auswirkungen auf die tatsächliche Beförderung hat, kann ein Nutzen aus der fachlichen Eignung des Entwicklers resultieren. Gem. § 3 PBZugV i. V. m. Anhang 1 der Richtlinie über Zugangsvoraussetzungen von Personenkraftverkehrsunternehmern127 müssen für die fachliche Eignung Kenntnisse über die kaufma¨ nnische und finanzielle Verwaltung des Betriebes, über technische Normen und den technischen Betrieb der Fahrzeuge nachgewiesen werden. Entsprechende Kenntnis oder Nichtkenntnis beim Entwickler wirkten sich nicht auf die Programmierung der Blockchain aus. Kenntnisse erhöhen auch nicht den Schutz der Beförderten. Vielmehr müssen die Kenntnisse bei demjenigen vorliegen, der Einfluss auf die Beförderung selbst hat. Auch § 13 I Nr. 4 PBefG läuft beim Anwendungsentwickler ins Leere. Danach ist eine Genehmigung zu versagen, wenn der Antragssteller seinen Betriebssitz oder seine Niederlassung im Sinne des Handelsrechts nicht im Inland hat. Dies dürfte letztlich sämtliche Anwendungsentwickler von einer Genehmigung ausschließen oder zur sinnlosen Gründung von Unternehmen in Deutschland führen, um die Voraussetzung des § 13 I Nr. 4 PBefG zu erfüllen. Da der Anwendungsentwickler ab der Veröffentlichung der Anwendung keinen weiteren Einfluss mehr auf die Blockchain hat, entfällt auch sein bis dorthin bestehender Unternehmenszweck in gleichem Maße wie der Nutzen der Beförderten an der fachlichen Eignung des Entwicklers. Zur Durchführung welcher Leistungen sollte ein Anwendungsentwickler noch ein Unternehmen aufrechterhalten? Der Grund für § 13 I Nr. 4 PBefG liegt vor allem in der Ermöglichung einer effektiven Aufsicht.128 Eine Aufsicht ist aber nicht mehr erforderlich, wenn der Unternehmer keinen Einfluss mehr auf die Personenbeförderung hat. Sämtliche Kontrollen und Bescheide gegen den Anwendungsentwickler wären nutzlos. Zwar könnte er für Verstöße bei analoger Anwendung des § 2 PBefG als Verantwortlicher in Anspruch genommen werden, mangels Einfluss auf die Blockchain würde hierdurch aber nicht die Sicherheit der Beförderung selbst 127 Richtlinie 96/26/EG vom 29. 4. 1996 u¨ ber den Zugang zum Beruf des Gu¨ ter- und Personenkraftverkehrsunternehmers im innerstaat lichen und grenzu¨ berschreitenden Verkehr sowie u¨ ber die gegenseitige Anerkennung der Diplome, Pru¨ fungszeugnisse und sonstigen Befa¨higungsnachweise fu¨ r die Befo¨ rderung von Gu¨ tern und die Befo¨ rderung von Personen im Straßenverkehr und u¨ ber Maßnahmen zur Fo¨ rderung der tatsa¨ chlichen Inanspruchnahme der Niederlassungsfreiheit der betreffenden Verkehrsunternehmer. 128 Grätz in Fielitz/Grätz PBefG, § 13 Rn. 25.

Marktzugang

53

gefördert werden. Der Schutzzweck des § 13 I PBefG würde trotz Inanspruchnahme nicht erreicht werden. Es bedarf somit keiner Aufsicht des Anwendungsentwicklers nach Veröffentlichung der Blockchain. Dass hierdurch der § 13 I Nr. 4 PBefG überflüssig wird, ließe sich zwar ebenfalls lösen, z. B. im Rahmen einer teleologischen Reduktion, letztlich führt aber eine Genehmigungspflicht nicht zu einer sinnvollen Rechtsfolge. Gem. § 25 I Nr. 1 PBefG ist die Aufsichtsbehörde bei Wegfall einer der subjektiven Voraussetzungen aus § 13 I Nr. 1–3 PBefG zum Widerruf der Genehmigung verpflichtet. Stellt man sich vor, dass ein Anwendungsentwickler die erforderliche Genehmigung erhält, eine dezentrale Anwendung veröffentlicht und direkt im Anschluss offenbart, dass er in keinem Fall zuverlässig ist, bleibt die Frage, was der Widerruf der Genehmigung bewirken würde. Der Entwickler wäre zwar nicht mehr zur Personenbeförderung berechtigt, er hat aber ohnehin seine Unternehmerstellung bereits mit der Veröffentlichung der Blockchain verloren. Gleichermaßen hätte der Entzug der Genehmigung keine relevanten Folgen. Der Anwendungsentwickler wäre nicht in der Lage, die dezentrale Anwendung eigenmächtig zu entfernen.129 Damit würde trotz Entzugs der Genehmigung der Schutzzweck nicht erreicht werden. Da letztlich die Gefährdung unmittelbar nur von der dezentralen Anwendung ausgehen kann, ist sinnvoller Regulierungsgegenstand auch nur diese Anwendung. Es kann insoweit dahinstehen, welche fachliche Eignung der Entwickler hat, solange die Anwendung (und damit sein Einfluss) dem Schutzzweck des § 13 PBefG gerecht wird. Wie oben gezeigt, begründet sich die Vergleichbarkeit zu bisherigen Unternehmern aus seinem rein tatsächlichen Einfluss durch Codierung der dezentralen Anwendung. Dieser Einfluss erlischt aber automatisch mit der Veröffentlichung, da er auf die Node-Betreiber als Gesamtheit übergeht. Es gibt ab diesem Zeitpunkt keinen Grund mehr für eine Genehmigung oder sonstige Aufsicht des Entwicklers. Die Vorgaben der Regulierung können durch den Entwickler nicht mehr umgesetzt werden. Um endgültig die Analogie zu begründen oder abzulehnen, muss man sich fragen, ob die Genehmigung irgendeinen Sinn erfüllen würde. Vor Veröffentlichung der Blockchain sind die Handlungen des Anwendungsentwicklers nicht genehmigungsbedürftig, nach der Veröffentlichung hat die Genehmigung keinen sinnvollen Anwendungsbereich. So sind die Schranken vor der Veröffentlichung der Blockchain zwar sinnvoll, aber nicht mit der Natur der Genehmigung als Dauer-VA im PBefG vereinbar. Auch wenn sich der Wunsch und das Bedürfnis für eine Regulierung bei Uber und vergleichbaren Systemen und dezentralen Anwendungen nicht wesentlich 129 Kennzeichen der Dezentralität ist der Fortbestand der Blockchain unabhängig vom Einzelnen.

54

Dezentrale Anwendungen der Sharing Economy

unterscheiden, führen die Eigenschaften der Technologie und die Systematik der sonstigen gesetzlichen Regelungen zur Genehmigung im PBefG zu einem nicht analogiefähigen Sachverhalt. Anstatt an den Unternehmer anzuknüpfen, müsste bei einer dezentralen Anwendung an diese angeknüpft werden. Es käme also nicht zu einer personenbezogenen, sondern sachbezogenen Zulassung. Der Anwendungsentwickler bedarf also nicht analog § 2 I PBefG einer Genehmigung. b. Sonstige Vorschriften des PBefG Das PBefG enthält einige Vorschriften, die gerade auf untypische Geschäftsmodelle zugeschnitten sind. Dies sind zum einen § 2 VI und VII PBefG und zum anderen das Umgehungsverbot des § 6 PBefG. Nur wenn der Anwendungsentwickler nicht unter diese Vorschriften zu subsumieren ist, kann von einer generellen erlaubnisfreien Tätigkeit i. S. d. PBefG bei der Veröffentlichung einer dezentralen Anwendung gesprochen werden. aa. Atypischer Verkehr Bei der dezentralen Anwendung könnte es sich um einen atypischen Verkehr handeln, der unter keinen der genannten Typen des PBefG passt. Die Konsequenz wäre, dass zum einen gem. § 2 VI PBefG nach den Regelungen genehmigt werden muss, deren Typ die Verkehrsart am ähnlichsten ist, zum anderen könnten gem. § 2 VII PBefG Ausnahmen von Vorschriften des PBefG gemacht werden.130 Soweit es sich bei der Veröffentlichung der dezentralen Anwendung um eine atypische Verkehrsart handelt, ist diese nur genehmigungsfähig, wenn kein öffentliches Verkehrsinteresse dem entgegensteht.131 Entscheidend dürfte hierfür der Begriff des Verkehrs sein. Wenn dieser nur die tatsächliche Beförderung von Personen und Gütern erfasst, wäre die telekommunikationstechnische Infrastruktur für einen solchen Verkehr nicht erfasst. Geht man von einem weiten Wortverständnis aus, kann Verkehr als die Gesamtheit aller technischen, organisatorischen, informatorischen und ökonomischen Maßnahmen, um Personen, Güter und Nachrichten zu befördern, verstanden werden.132 Dies scheint aber nicht dem Begriffsverständnis des PBefG zu entsprechen. Auch wenn es keine abstrakte Definition von Verkehr im PBefG gibt, werden zahlreiche besondere Verkehrsarten definiert.133 Diese haben allesamt gemeinsam, dass nur auf die tatsächliche Beförderung von Personen abgestellt wird. Daher dürfte dies auch einem allgemeinen Verkehrsbegriff des 130 131 132 133

Heinze in Heinze/Fehling/Fiedler PBefG, § 2 Rn. 54. Grätz in Fielitz/Grätz PBefG, § 2 Rn. 26. Grätz in Fielitz/Grätz PBefG, § 2 Rn. 26. https://tinyurl.com/mrh364c7 abgerufen am 18. 01. 2022. § 8 PBefG: öffentlicher Personennahverkehr; § 42 PBefG: Linienverkehr; § 46 PBefG: Gelegenheitsverkehr; § 47 PBefG: Verkehr mit Taxis.

Marktzugang

55

PBefG zugrunde gelegt werden. Der weite Verkehrsbegriff findet im PBefG keine Grundlage. Eine Ausdehnung auf die telekommunikationstechnische Infrastruktur dürfte den Regelungsgehalt des PBefG daher überspannen. Letztlich könnte keine trennscharfe Unterscheidung zwischen einer App, einer DApp und dem Internet selbst gemacht werden, da sie allesamt eine telekommunikationstechnische Infrastruktur anbieten. Auch die bisherige Rechtsprechung zeigt, dass nicht von einem weiten Wortverständnis ausgegangen wird. Ansonsten wären einerseits sämtliche TaxiApps genehmigungspflichtig, andererseits hätte Uber nicht die tatsächliche Beförderung zugerechnet werden müssen, um es unter einen Verkehrsunternehmer zu subsumieren. Die telekommunikationstechnische Infrastruktur ist nach dem derzeitigen Verständnis des PBefG kein eigenständiger Verkehr, sodass auch der Anwendungsentwickler nicht gem. § 2 VI und VII PBefG genehmigungspflichtig ist. bb. Umgehungsverbot, § 6 PBefG Auch wenn die bisherige Subsumtion unter die Vorschriften des PBefG gescheitert ist, würden die Vorschriften dennoch zur Anwendung kommen, wenn es sich bei der Gestaltung des Geschäftskonzeptes eines Anwendungsentwicklers um eine Umgehung der bisher genannten Vorschriften gem. § 6 PBefG handelt. Im Tatbestand wird zwischen Scheintatbeständen und rechtsgeschäftlichen und firmenrechtlichen Gestaltungen unterschieden. Der Scheintatbestand lässt sich in Anlehnung zu § 117 BGB als Gestaltung definieren, bei der das Erklärte nicht dem Gewollten entspricht.134 Dies ist bei der Schaffung einer dezentralen Anwendung nicht der Fall. Der Anwendungsentwickler gibt zu keinem Zeitpunkt Erklärungen ab, mit denen er das tatsächlich Gewollte verschleiert. Mit Ausnahme der Bereitstellung der dezentralen Anwendung gibt er auch keine weiteren Erklärungen ab. Ein Scheintatbestand scheidet mithin aus. Problematischer könnten die rechtsgeschäftlichen und gesellschaftsrechtlichen Gestaltungen sein. Es ist dabei ein Ausgleich zwischen neuen innovativen Geschäftsmodellen und unlauteren Gestaltungen, die kein berechtigtes Interesse verfolgen, sondern zur Umgehung der Vorschriften dienen, zu schaffen.135 Der Anwendungsbereich des § 6 PBefG geht dabei sehr weit, da er bereits eine abstrakte Eignung zur Umgehung genügen lässt.136 Letztlich dürfte entscheidend sein, dass eine Rechtsfolge nicht umgangen werden darf, wenn das Gesetz nach seinem klaren Inhalt auf diese Gestaltung Anwendung finden soll.137 134 135 136 137

Grätz in Fielitz/Grätz PBefG, § 6 Rn. 5, Mansel in Jauernig BGB, § 117 Rn. 2. Heinze, PBefG, § 6 Rn. 1. Grätz in Fielitz/Grätz, PBefG § 6 Rn. 2. Heinze, PBefG, § 6 Rn. 2.

56

Dezentrale Anwendungen der Sharing Economy

Betrachtet man die Gestaltung zunächst ohne Blockchain, sondern mittels einer Plattform, geht es lediglich um die Vermittlung von Leistungen, nicht um die Erbringung der Leistung selbst. Es handelt sich somit um eine Leistung, die nicht vom PBefG erfasst ist. Auf diese Gestaltung würde also auch nicht das Umgehungsverbot Anwendung finden, da es keinen Sachverhalt gibt, der vom PBefG geregelt werden soll. Dies bestätigt die Uber-Rechtsprechung, wonach es erforderlich ist, Uber als Unternehmer der Beförderungsleistung selbst zu betrachten, um das PBefG auf Uber anzuwenden.138 Dementsprechend kann es aber auch keine Umgehung sein, wenn an die Stelle der Plattform eine Technologie tritt. Allerdings besteht auch ein erheblicher Unterschied zwischen der Blockchain Technologie und Plattformen. Bei Plattformen kann der Einfluss auf die Anbieter derart groß sein, dass sie (wie Uber) selbst zum Anbieter der Leistung i. S. d. PBefG werden. Aufgrund der Vorverlagerung der Einflussnahme auf den Zeitpunkt der Entwicklung der Anwendung und die fehlende rechtliche Absicherung dieses Einflusses ist dies beim Anwendungsentwickler nicht möglich. Es könnte somit aber als Umgehung angesehen werden, wenn eine Vermittlungsplattform, die als Anbieter der Fahrdienstleistung anzusehen ist, auf eine dezentrale Anwendung umgestellt wird, um so die Anwendbarkeit des PBefG zu verhindern. Bei dieser Frage kommt man erneut an die Grenzen des § 6 PBefG. Dieser soll ausdrücklich nur rechtsgeschäftliche und firmenrechtliche Umgehungen erfassen. Ob eine technologische Umgehung ebenfalls erfasst sein soll, erscheint zweifelhaft. Auf den ersten Blick würde dies dem Wortlaut der Norm widersprechen. Allerdings ergeben sich aus der technologischen Umgestaltung zumindest auch rechtsgeschäftliche Änderungen. Die Anbieter und Nutzer schließen keinen Vertrag mehr mit dem Plattformanbieter über die Nutzung der Plattform, sondern lediglich mit dem Anwendungsentwickler über das Herunterladen einer Software. Dies ist zugleich ein wesentlicher Grund, warum der Anwendungsentwickler nicht mehr als Anbieter der Dienstleistung angesehen werden kann. Soweit die Vorschrift nach ihrem Wortlaut anwendbar ist, kann auf den klassischen Auslegungskanon zurückgegriffen werden. Und hier kommt, wie bereits bei der Analogie, dem Sinn und Zweck der Vorschrift eine erhebliche Bedeutung zu. Wenn man die Folgen der Anwendbarkeit des § 6 PBefG betrachtet, stellt man fest, dass sie nicht zu sinnvollen Ergebnissen führt. § 6 PBefG führt zur Anwendbarkeit der umgangenen Vorschrift, in diesem Fall wäre es die Umgehung der Unternehmereigenschaft i. S. d.§ 2 I PBefG.139 Über die Anwendbarkeit von § 2 PBefG käme man zur Anwendung sämtlicher Vorschriften, die an die Un138 BGH, Beschl. v. 18. 5. 2017-I ZR 3/16 (KG), GRUR 2017, 743; EuGH Urt. v. 20. 12. 2017-C 434/ 15. 139 Grätz in Fielitz/Grätz PBefG, § 6 Rn. 3.

Marktzugang

57

ternehmereigenschaft anknüpfen. Wie bereits gezeigt ist dies für den Anwendungsentwickler gerade nicht sinnvoll. Es hat keinen weiteren Nutzen, dem Anwendungsentwickler die Pflichten eines Unternehmers i. S. d. PBefG aufzuerlegen. Es kann bei der Auslegung des § 6 PBefG nicht ein anderer Sinn und Zweck als bei § 2 I PBefG erkannt werden. Schließlich ist die Funktion des § 6 PBefG, die umgangenen Vorschriften zur Anwendung zu bringen und somit den Sinn und Zweck dieser Vorschriften zu erreichen. Wenn also § 2 I PBefG nach seinem Zweck keine Anwendung finden soll, so darf dieses Ergebnis im Rahmen des § 6 PBefG nicht anders ausfallen. Es handelt sich letztlich bei der Verwendung einer dezentralen Anwendung anstelle einer Plattform nicht um eine Umgehung des § 2 I PBefG, wobei bei der Begründung nicht allein auf den technologischen Fortschritt abgestellt wird. cc. Zwischenergebnis Mangels Umgehung der Vorschriften des PBefG i. S. d. § 6 PBefG, unterliegt der Anwendungsentwickler nicht den Regelungen des PBefG. Obwohl das PBefG auf den Anwendungsentwickler nicht anwendbar ist, heißt dies nicht, dass die über die Infrastruktur vermittelten und abgewickelten Fahrten rechtmäßig sind. Bei den Fahrern handelt es sich sehr wohl um Unternehmer i. S. d. § 2 I PBefG, soweit das Entgelt die Betriebskosten i. S. d. § 1 II Nr. 1 PBefG übersteigt. Dies schafft letztlich genau das Problem, das bei Uber vermieden werden sollte. Während der Infrastrukturanbieter nicht genehmigungsbedürftig ist, sind die Nutzer (auf Seiten der Fahrer) genehmigungsbedürftig. Solange keine effektive Möglichkeit zur Durchsetzung der Genehmigungspflicht auf Fahrerseite besteht, ermöglicht die dezentrale Anwendung in einem erheblichen Umfang rechtswidrige Tätigkeiten. Solange die Infrastruktur besteht und die Fahrer keine Inanspruchnahme befürchten müssen, besteht für sie kein Anreiz, ihre Tätigkeit aufzugeben. Auch wenn die Regulierung nicht über die Anwendbarkeit des PBefG führt, ist sie notwendig. 3.

Kurzzeitvermietung

Wie auch bei der Personenbeförderung kann man sich im Rahmen der Kurzzeitvermietung von Wohnraum die Frage stellen, ob regulatorische Anforderungen auch den Anwendungsentwickler im Rahmen einer Marktzugangsbeschränkung treffen. Im Gegensatz zur Personenbeförderung wurden bisherige Plattformen nicht als Anbieter der Wohnraumvermietung betrachtet, sondern lediglich als Vermittler. Die Vermittler werden wiederum teilweise als eigen-

58

Dezentrale Anwendungen der Sharing Economy

ständige Adressaten in den Wohnraumschutzgesetzen behandelt, z. B. gem. § 5 II Nr. 5 ZwVbG Berlin. Berlin bei der Herausgabepflicht gesammelter Daten.140 Unabhängig von den Kriterien für eine Annahme eines erheblichen Einflusses, scheitert eine unmittelbare Anwendung am Adressatenkreis der Zweckentfremdungsgesetze bezüglich der Genehmigungspflicht. Adressat der Genehmigungspflicht ist der Verfügungsberechtigte des Wohnraums, § 10 I HambWoSchG, § 3 I ZwVbG Berlin.141 Die Verfügungsberechtigung ist nach sachenrechtlichen Grundsätzen zu beurteilen. Sie steht ursprünglich dem Eigentümer aus § 903 BGB zu.142 Der Anwendungsentwickler ist als Person bereits nicht Adressat der Genehmigung. Insoweit kommt auch hier nur eine analoge Anwendung der Normen in Frage. a. Normadressat des § 5 VI ZwVbG Berlin Eine Analogie lässt sich allerdings mit der Systematik der Gesetze schnell abweisen. Die Genehmigungen, bzw. im Fall von Berlin auch die Anzeige gem. § 5 VI ZwVbG Berlin, sind an den jeweiligen Wohnraum gebunden, sodass jeder Wohnraum einer eigenen Genehmigung bedarf. Insoweit bezieht sich die Genehmigung im Gegensatz zur Personenbeförderung nicht auf den Anbieter, sondern auf den angebotenen Wohnraum. Der Vermittler wird nicht als regulatorischer Intermediär eingesetzt. Eine zusätzliche Inanspruchnahme des Anwendungsentwicklers neben dem Verfügungsberechtigten des Wohnraums bietet keinen Effizienzgewinn in der Regulierung. b. Normadressat des § 5 II Nr. 2 und 5 ZwVbG Berlin Auch wenn der Anwendungsentwickler nicht unmittelbar durch die Zweckentfremdungsgesetze betroffen ist und durch sie nicht am Marktzugang gehindert wird, könnte er als Diensteanbieter im Rahmen des Telemediengesetzes (TMG) gem. § 5 II Nr. 2 ZwVbG Berlin bei der Erhebung von Daten in Anspruch genommen werden. Obwohl es sich nicht um eine Marktzugangsschranke handelt und somit auch nicht gegen die Genehmigungsfreiheit gem. Art. 4 E-Commerce RL verstößt, würde es zeigen, dass das ZwVbG Berlin zumindest grundsätzlich geeignet ist, den Entwickler in Anspruch zu nehmen. Voraussetzung hierfür ist zum einen die Anwendbarkeit des § 5 II ZwVbG Berlin und die tatsächliche Fähigkeit des Anwendungsentwicklers zur Herausgabe der Daten. Auch wenn es sich hierbei nicht um eine Marktzugangsbeschränkung handelt, könnte dies ein

140 Für den Fall von Airbnb stellt das VG Berlin die Rechtmäßigkeit des Auskunftsverlangen ausdrücklich fest: VG Berlin, Urt. v. 23. 6. 2021-6 K 90/20. 141 In der Münchener Wohnraumzweckentfremdungssatzung sind Mieter und Verfügungsberechtigter Adressat, § 4 I ZeS. 142 Oeschler in MüKo BGB, § 929 Rn. 44ff.

Marktzugang

59

geeigneter Anknüpfungspunkt für eine Inanspruchnahme des Anwendungsentwicklers sein. Um den Anwendungsentwickler als Diensteanbieter i. S. d. § 2 Nr. 1 TMG zu klassifizieren, muss dieser eigene oder fremde Telemedien zur Nutzung bereithalten oder die Nutzung vermitteln. Die Blockchain selbst müsste somit ein Telemedium sein. Ein Telemedium ist ein elektronischer Kommunikations- oder Informationsdienst, der kein reiner Telekommunikationsdienst, kein telekommunikationsgestützter Dienst oder ein Rundfunkdienst ist.143 Ein Kommunikations- oder Informationsdienst liegt vor, wenn der Nutzen des Dienstes in der Information und Kommunikation auf elektronischem Wege besteht.144 Dieses Merkmal ist bei allen Blockchains aufgrund ihrer Technologie gegeben. Zwingende Voraussetzung für eine funktionierende Blockchain ist die elektronische Kommunikation zwischen den Nodes. Dabei darf sie jedoch kein reiner Telekommunikationsdienst i. S. d. § 3 Nr. 24 Telekommunikationsgesetzes sein, § 1 I TMG. Ein reiner Telekommunikationsdienst liegt nur vor, wenn der Dienst ganz oder überwiegend in der Übertragung von Signalen über Telekommunikationsnetze besteht gem. § 3 Nr. 25 TKG. Zwar ist Kernbestandteil der BlockchainTechnologie die Kommunikation der Nodes, sie geht aber auch hierüber hinaus. Zum einen besteht eine dezentrale Anwendung nicht nur aus der Blockchain selbst und dem dazugehörigen Backend der Anwendung, sondern auch aus Software für die eigentliche Anwendung inklusive einem Front-End-Interface zur Interaktion mit der Blockchain; zum anderen dienen die Nodes der Blockchain nicht nur zur Kommunikation, sondern auch zur Konsensbildung.145 In beiden Fällen wird die Schwelle der reinen Übertragung von Signalen überschritten. Da auch kein telekommunikationsgestützter Dienst mangels unmittelbarer Leistungserbringung146 und auch kein Rundfunkdienst vorliegt, handelt es sich bei der dezentralen Anwendung um ein Telemedium i. S. d. § 1 I TMG. Zu diesem Telemedium müsste der Anwendungsentwickler Zugang zur Nutzung verschaffen. Dies erfolgt in jedem Fall, wenn der Anwendungsentwickler die Anwendung zum Download bereitstellt und es so Dritten ermöglicht die dezentrale Anwendung zu nutzen. Insgesamt lässt sich festhalten, dass der Anwendungsentwickler zumindest bei der erstmaligen Veröffentlichung als Diensteanbieter i. S. d. § 2 Nr. 1 TMG auftritt. Somit unterliegt er grundsätzlich auch dem Anwendungsbereich des § 5 II Nr. 2 ZwVbG Berlin.

143 144 145 146

Martini in BeckOK Informations- und Medienrecht, TMG § 2 Rn. 6ff. Martini in BeckOK Informations- und Medienrecht, TMG § 2 Rn. 6. Saive, CR 2018, 186, 188. Martini in BeckOK Informations- und Medienrecht, TMG § 2 Rn. 7a.

60

Dezentrale Anwendungen der Sharing Economy

Es handelt sich hingegen nicht um einen Vermittler von Dienstleistungen gem. § 5 II Nr. 5 ZwVbG Berlin. Die Vermittlereigenschaft setzt wie auch bei der Personenbeförderung voraus, dass in irgendeiner Form Einfluss auf den Vermittlungsvorgang genommen werden kann. Ab der Veröffentlichung der Blockchain hat der Entwickler keinen Einfluss mehr auf die Vermittlung und kann somit bei der Buchung eines Objektes nicht als Vermittler i. S. d. § § 5 II Nr. 5 ZwVbG Berlin angesehen werden. Allerdings ist fraglich, ob er zur Herausgabe der relevanten Daten in der Lage ist. Dabei sind zwei Schritte zu differenzieren. Zum einen ist zu klären, ob überhaupt relevante Daten in der Blockchain gespeichert werden, zum anderen, ob der Entwickler Zugang zu diesen Daten hat. Der Einfachheit halber sei mit der zweiten Frage begonnen, nämlich wer Zugriff auf Daten der Blockchain hat. Die Blockchain basiert letztlich auf der Verteilung identischer Datensätze auf allen beteiligten Rechnern, den sog. Full-Nodes. Alle Full-Nodes haben den gleichen Datensatz und grundsätzlich auch Zugriff auf diesen. Allerdings muss es sich bei dem Anwendungsentwickler nicht um ein Full-Node handeln. Bei frei zugänglichen Blockchains kann sich jeder frei dazu entscheiden, ein Full-Node zu werden, indem er den gesamten Datensatz der Blockchain lädt. Der Anwendungsentwickler kann zwar auch ein Full-Node sein, muss es aber nicht. Soweit der Anwendungsentwickler selbst kein Full-Node ist, hat er grundsätzlich auch keinen Zugriff auf die in der Blockchain gespeicherten Datensätze. Gesonderte Daten hätte der Anwendungsentwickler letztlich nur, wenn er im Austausch zum Download Daten über die Nutzer erhält. Zum einen ist dies momentan keine gängige Praxis, zum anderen wären die hierdurch gesammelten Daten für Aufsichtsbehörden des ZwVbG Berlin nicht sinnvoll nutzbar, da zum Zeitpunkt des Downloads der Anwendung durch Nutzer nicht abschließend feststeht, ob die dezentrale Anwendung dem Anbieten oder Nutzen von Angeboten dienen soll. Zudem sind die konkret vermieteten Objekte zum Zeitpunkt des Downloads unbekannt. So könnte die Aufsichtsbehörde zwar sämtliche Teilnehmer der Blockchain identifizieren, dadurch aber nur Informationen gem. § 5 I Nr. 1 ZwVbG Berlin ermitteln und keine sonstigen der Nr. 2–4. Richtiger Adressat für einen Anspruch zur Herausgabe von Daten gem. § 5 II ZwVbG Berlin müsste also nicht der Anwendungsentwickler sein, sondern die Full-Nodes sein. Dies setzt erneut voraus, dass auch sie Diensteanbieter i. S. d. § 2 Nr. 1 TMG sind. Obwohl die Nodes Nutzer des Dienstes sind, können sie auch zeitgleich als Diensteanbieter fungieren.147 Deshalb kann auf die Argumentation zur Anbietereigenschaft des Anwendungsentwicklers weitestgehend Bezug genommen werden, wobei der eigene Dienst der Nodes in der konstanten Verifi147 Martini in BeckOK Informations- und Medienrecht, TMG § 2 Rn. 17; BT-Drucks, 14/6098, S. 16; Saive, CR 2018, 186, 188.

Marktzugang

61

zierung neuer Blöcke und Validierung der gesamten Blockchain liegt. Da die Nodes die gesamte Blockchain und somit den Datensatz speichern, sind sie auch in der Lage diese Daten gem. § 5 II ZwVbG Berlin herauszugeben. Dabei stellen sich jedoch noch einige weitere Hürden. Zum einen ist der Datensatz, den die Nodes haben, nicht vollständig übereinstimmend mit den in § 5 I ZwVbG Berlin genannten, zum anderen sind die Daten verschlüsselt und zuletzt könnte die Inanspruchnahme der Nodes unverhältnismäßig und unzweckmäßig sein, wenn der Behörde ein einfacherer Weg zur Datenerlangung zur Verfügung steht. Von denen in § 5 I ZwVbG Berlin genannten Daten wird zumindest die Nr. 1 (persönliche Daten über die Person) in Form des Public Keys auf der Blockchain gespeichert. Mit Hilfe dieses Public Keys können zwar Rückschlüsse auf die Person des Anbieters gezogen werden, allerdings erfordert dies einen erheblichen Mehraufwand, sog. Blockchain-Profiling,148 auf Seiten der Behörde.149 Darüber hinaus werden nicht nur Daten zum Anbieter, sondern zeitgleich auch Daten zum Nutzer erhoben. Dies ist jedoch nicht vom § 5 I, II ZwVbG Berlin gedeckt. Insoweit kann aber darauf verwiesen werden, dass die Daten ausreichend kodiert sind, sodass die Behörde trotz des Public Keys des Nutzers nicht automatisch weiß, wer sich hinter diesem Key verbirgt. Insoweit besteht nicht die Gefahr, dass unberechtigt Daten von der Behörde gesammelt werden. Dies ergibt sich vor allem auch aus der Nutzung der Blockchain durch die Nutzer der angebotenen Dienste. Jedem Nutzer muss bei öffentlichen Blockchains bewusst sein, dass der Public Key in der Blockchain gespeichert wird und dass jeder in der Lage ist, die Blockchain mitsamt den Daten in den verifizierten Blöcken herunterzuladen. Es könnte zwar noch vorgebracht werden, dass im Zweifel nur die Behörde die erforderlichen Mittel zur Nachverfolgung des Public Keys hat. Dies ändert aber nichts an der freiwilligen Veröffentlichung der Daten. Weil sich auch die Behörde die Blockchain herunterladen kann und automatisch Zugriff auf die relevanten Daten hat, ist eine Inanspruchnahme einzelner Nodes für die Behörde unverhältnismäßig aufwendig. Denn um einen solchen in Anspruch zu nehmen, müsste ein Node-Betreiber selbst erst einmal identifiziert werden. Im Vergleich zum selbstständigen Herunterladen der Blockchain durch die Behörde steht dies in keinem Verhältnis. Obwohl die zuständige Behörde über § 5 II ZwVbG die Nodes in Anspruch nehmen könnte, ist dies für die Behörde nicht notwendig und unverhältnismäßig aufwendig, um an die entsprechenden Daten zu kommen. 148 Béres u.w., Blockchain is Watching You: Profiling and Deanonymizing Ethereum Users, https://arxiv.org/abs/2005.14051. 149 Girasa, Regulation of Cryptocurrencies and Blockchain Technology, https://doi.org/10.100 7/978–3–319–78509–7, S. 72.

62

Dezentrale Anwendungen der Sharing Economy

Das Problem im Rahmen der Zweckentfremdungsgesetze liegt somit weniger in der Person, die in Anspruch genommen werden soll, sondern vielmehr in den zu erlangenden Informationen. Die Behörde kann sich jederzeit sämtliche Informationen verschaffen, die auf der Blockchain gespeichert sind. Solange für den Entwickler aber keine Designpflicht vorgeschrieben ist, welche Informationen zu den vermieteten Objekten auf der Blockchain abgespeichert werden müssen, haben die Informationen auf der Blockchain für die Behörde aber keinen praktischen Nutzen. Im Rahmen der Kurzzeitvermietung zeigt sich, dass die Teilnehmer der Blockchain durchaus nach bestehenden Vorschriften in Anspruch genommen werden können. Dies hat aber praktisch keine Relevanz, da die entsprechenden Daten jederzeit von der Behörde selbst heruntergeladen werden können. Es zeigt sich auch, dass der Anwendungsentwickler nicht unter die bisherigen Zweckentfremdungsgesetze fällt. Er bleibt also bis zu diesem Punkt weiterhin im Rahmen des Marktzugangs unreguliert. c. Sektorübergreifende Gefahrenabwehr Wenn keine spezialgesetzliche Vorschrift zur Inanspruchnahme des Anwendungsentwicklers besteht, bleibt nur eine Inanspruchnahme nach den allgemeinen Polizei- und Ordnungsvorschriften. Unabhängig von der konkreten Befugnisnorm hat eine Inanspruchnahme zumindest die Voraussetzung der Polizeipflichtigkeit gemeinsam. Letztlich richtet sich dies nach den Landesgesetzen, da die Bundespolizei mangels ausdrücklicher Befugnis nicht zuständig ist. Bei der Polizeipflichtigkeit muss zwischen verantwortlichen und nichtverantwortlichen Personen unterschieden werden. Anknüpfungspunkt ist jeweils der Ursprung der Gefahr. Der Begriff der Gefahr ist dabei zwar nicht in jedem Landesrecht definiert, umfasst aber eine Sachlage, bei der die hinreichende Wahrscheinlichkeit für einen Schaden der öffentlichen Sicherheit/ Ordnung besteht.150 Die öffentliche Sicherheit umfasst dabei die objektive Rechtsordnung151, somit also auch die öffentlich-rechtlichen Vorschriften des PBefG und der Zweckentfremdungsgesetze. Bei einem Verstoß gegen die Vorgaben oder einer hinreichenden Wahrscheinlichkeit, besteht also eine Gefahr für die öffentliche Sicherheit. Der Anwendungsentwickler ist, wie oben gezeigt, nicht Adressat dieser Gesetze und verstößt auch nicht gegen sie. Es ist vielmehr der einzelne Anbieter, der eine Gefahr durch einen Verstoß auslöst. Insoweit ist der Anwendungsentwickler kein Verhaltensverantwortlicher. Auch eine Verantwortlichkeit für Sachen wird nicht ausreichend sein, um den Anwendungsentwickler als Verantwortlichen heranzuziehen. Zum einen ist die Blockchain keine 150 Vgl. § 2 Nr. 3a BremPolG, § 2 Nr. 1a Nds. SOG. 151 Mehde in Hartmann/Mann/Mehde, Landesrecht Niedersachen, S. 89f.

Marktzugang

63

Sache, sondern eine auf diversen Servern gespeicherte Software, zum anderen ermöglicht und erleichtert sie zwar die Rechtsverletzung; diese geht aber nicht unmittelbar von ihr aus. Insoweit ist der Anwendungsentwickler als Nichtverantwortlicher anzusehen, der nur unter zusätzlichen Voraussetzungen in Anspruch genommen werden kann. Die Voraussetzungen sind dabei in den verschiedenen Landesgesetzen sehr ähnlich und verlangen überwiegend (1) eine gegenwärtige erhebliche Gefahr, (2) fehlende Möglichkeit der Inanspruchnahme des Verantwortlichen, (3) keine rechtzeitige Abwehr der Gefahr durch die Behörden selbst und (4) keine Gefährdung des Nichtverantwortlichen durch die Inanspruchnahme.152 Entscheidend sind dabei einerseits die Voraussetzungen der erheblichen Gefahr und die fehlende Möglichkeit einer rechtzeitigen Abwehr durch die Behörden. Für die erhebliche Gefahr ist die Wertigkeit des betroffenen Rechtsguts und damit die Schwere des eintretenden Schadens maßgeblich.153 Das betroffene Rechtsgut unterscheidet sich teilweise erheblich auf den jeweiligen Märkten, auf denen die dezentralen Anwendungen genutzt werden. Bei der Personenbeförderung wird die Sicherheit des öffentlichen Straßenverkehrs und die Gewährleistung des öffentlichen Nahverkehrs gefährdet, während bei der Kurzzeitvermietung die Wohnraumversorgung der Bevölkerung im Vordergrund steht. Beide sind essentielle Rechtsgüter für die Gesellschaft. Auch der Umfang der Gefährdung ist ausreichend, um eine erhebliche Gefahr zu begründen. Die mögliche Ausdehnung dezentraler Anwendungen kann Millionen von Nutzern und Anbietern betreffen. Gleichzeitig sind die Behörden derzeit nicht in der Lage, die Massen an Nutzern zu regulieren. Allerdings ist zwischen Personenbeförderung und Kurzzeitvermietung zu unterscheiden. Bei einer App, wie von Uber verwandt, wird nicht angezeigt, wer der Beförderer ist, bis tatsächlich eine Fahrt gebucht wurde. Aufgrund der starken Fluktuation von Anbietern bei der Personenbeförderung scheint die Behörde nur durch tatsächliches Testen der Beförderer überprüfen zu können, ob jemand gegen das PBefG verstößt. Bei der Kurzzeitvermietung kann hingegen bereits auf der Plattform eingesehen werden, welche Wohnung vermietet wird. Da die Lage eine erhebliche Grundlage für die Vermietung ist, könnte es der Behörde möglich sein, die Anzeigen mit den zur Vermietung registrierten Objekten abzugleichen und so feststellen, ob eine entsprechende Berechtigung zur Vermietung vorliegt. Allerdings stellen sich hier noch einige Probleme bei der Identifizierung des Anbieters, wobei dies wohl bei rechtstreuen Blockchains mit keiner vollständigen Anonymität nicht das wesentliche Problem sein dürfte. 152 § 7 I BremPolG, § 10 I HambSOG, § 7 POG Rh-Pf, § 10 I PAG Bay, § 10 I PAG Thü. 153 Mehde in Hartmann/Mann/Mehde Landesrecht Niedersachsen, S. 92.

64

Dezentrale Anwendungen der Sharing Economy

Unabhängig von der erheblichen Gefahr und der Möglichkeit einer rechtszeitigen Gefahrenabwehr bleiben zwei weitere Probleme bestehen. Zum einen muss die Maßnahme nach den verschiedenen Polizei-und Ordnungsrechten auch noch verhältnismäßig sein. Zum anderen sind die Rechtsfolgen für eine Inanspruchnahme eines Nichtverantwortlichen unter Umständen für die Behörden ungewollt, sodass dieses Mittel, obwohl anwendbar, letztlich nicht angewendet wird. Für das Totalverbot einer Blockchain bestehen Zweifel an der Verhältnismäßigkeit. Es kann einer dezentralen Anwendung nicht von vornherein unterstellt werden, dass sie ausschließlich für rechtswidrige Zwecke genutzt wird. Allerdings dürfte eine überwiegende Wahrscheinlichkeit dafürsprechen, dass ein Teil der Nutzer rechtswidrig handelt. Insoweit lässt sich aber kein Totalverbot ohne weitere Erfahrungen zum Umfang der rechtswidrigen Angebote rechtfertigen. Dies kann letztlich aber erst annähernd geschätzt werden, wenn die Blockchain bereits am Markt verbreitet ist. Dann ist es wiederum zu spät, um den Anwendungsentwickler in Anspruch zu nehmen, da er keine Möglichkeit zur Beeinflussung der Blockchain mehr hat, eine Inanspruchnahme also nicht erfolgsversprechend ist. Selbst wenn man annähme, dass ein nicht unerheblicher Teil der Nutzer rechtswidrig handeln würde und man eine präventive Inanspruchnahme des Anwendungsentwicklers für verhältnismäßig hält, kommt es zum Problem des Entschädigungsanspruches. Da ein Nichtverantwortlicher in Anspruch genommen wird, der ein Sonderopfer erbringt, steht ihm ein Entschädigungsanspruch zu.154 Da sich der Entschädigungsanspruch auf einen Wertausgleich für die erlittenen Einbußen richtet, kann er einen erheblichen Umfang einnehmen. Nicht ersatzfähig sind mittelbare Schäden, wie der entgangene Gewinn.155 Die bereits verteilten oder noch zurückbehaltenen Token würden wertlos werden, sodass durchaus von einem Eingriff in Kapitalanlagen eines Unternehmens gesprochen werden kann, bei denen ein Wertausgleich in Höhe des regelmäßigen Ertrages angesetzt wird.156 Der Ausgleichsanspruch besteht nicht, wenn der Blockchain- Entwickler über die Figur des Zweckveranlassers in Anspruch genommen wird und mit der h. M. als mittelbarer Verhaltensstörer kategorisiert wird.157 Zwar würde das eine Inanspruchnahme unter den vereinfachten Voraussetzungen des Verhaltensstörer 154 Mehde in Hartmann/Mann/Mehde Landesrecht Niedersachsen, S. 96; Götz/Geis, Allgemeines Polizei- und Ordnungsrecht, S. 233ff. 155 Mehde in Hartmann/Mann/Mehde Landesrecht Niedersachsen, S. 96; Götz/Geis, Allgemeines Polizei- und Ordnungsrecht, S. 233ff. 156 Götz/Geis, Allgemeines Polizei- und Ordnungsrecht, S. 233ff. 157 Für viele Schoch Jura 2009, 360, 366.

Marktzugang

65

ermöglichen und den Erstattungsanspruch entfallen lassen. Die Hürde der Verhältnismäßigkeit ließe sich aber auch hier nur schwer überwinden. Letztendlich dürfte eine Inanspruchnahme des Anwendungsentwicklers als Nichtstörer oder Zweckveranlassers nur in Betracht kommen, wenn weniger intensive Eingriffsmöglichkeiten als das Totalverbot entwickelt werden. Mangels hinreichender Prognose ist vor allem die Inanspruchnahme vor Veröffentlichung zweifelhaft. Da dies aber der einzig mögliche Zeitpunkt für eine Inanspruchnahme des Anwendungsentwicklers ist, erscheint auch unter diesem Gesichtspunkt eine Inanspruchnahme nach dem Polizei-und Ordnungsrecht als verfehlt. Somit ist festzuhalten, dass das Polizei-und Ordnungsrecht unter den entsprechenden Voraussetzungen eine Inanspruchnahme des Anwendungsentwicklers ermöglichen kann, diese aber keine ausreichende Berücksichtigung verschiedener Interessen ermöglicht. Benötigt wird eine ausdifferenzierte Regelung, die einerseits das Wachstum des Marktes fördert, andererseits die Gefahren für die Gesellschaft weitestgehend eindämmt. Ein präventives Totalverbot wird dem nicht gerecht. 4.

Zwischenergebnis

Insgesamt lassen sich die Marktzugangsbeschränkungen der einzelnen Sektoren nicht auf den Anwendungsentwickler übertragen. Der Markt soll vor unqualifizierten Anbietern oder besonderen Gefahren aus der Dienstleistung selbst geschützt werden. Nach der Systematik der Normen ist der Anwendungsentwickler kein geeigneter Anknüpfungspunkt für eine Marktzugangsbeschränkung. Da die bisherigen Marktzugangsbeschränkungen als personenbezogene Genehmigung ausgestaltet sind, werden die dezentralen Anwendungen vom bisherigem Rechtsrahmen nicht erfasst. Der technologische Unterschied zu bisherigen Plattformen mit der Abgabe der Verantwortlichkeit zum Zeitpunkt der Veröffentlichung stellt eine strukturelle Veränderung dar, für die die bisherigen Marktzugangsbeschränkungen nicht geeignet sind.

II.

Kapitalmarktrechtliche Schranken

Das Wirtschaftssystem einer dezentralen Anwendung basiert, anders als der bisher übliche Markt, nicht auf gesetzlichen Zahlungsmitteln, sondern auf Token. Dem Vertrieb der Token können dabei kapitalmarktrechtliche Schranken entgegenstehen. Anders als die zuvor untersuchten öffentlich-rechtlichen Normen des Gefahrenabwehrrechts schützen die Vorschriften des Kapitalmarktrechts die Funktionsfähigkeit des Marktes und die Anleger.

66

Dezentrale Anwendungen der Sharing Economy

Die Leistungen innerhalb der dezentralen Anwendungen werden im Austausch gegen diese Rechnungseinheiten erbracht.158 Im Rahmen dieser Arbeit wird zwischen Token und Kryptowährungen unterschieden. Zwar stellen beide Blockchain basierte Rechnungseinheiten dar, sie unterscheiden sich aber in ihrer grundsätzlichen Funktion. Kryptowährungen sind generell zum Ersatz der gesetzlichen Zahlungsmittel bestimmt und sind nicht auf eine Anwendung beschränkt, sondern sollen auch im alltäglichen Zahlungsverkehr nutzbar sein.159 Bekanntestes Beispiel für eine Kryptowährung ist Bitcoin. Ihr Ziel ist es, auch in der Offline-Welt, in Restaurants und Geschäften, eingesetzt zu werden und damit eine Alternative zu gesetzlichen Zahlungsmitteln zu schaffen. 1.

Finanzierung von dezentralen Anwendungen

Das Problem, das Anwendungsentwickler bei der Veröffentlichung der Blockchain haben, liegt in der Refinanzierung der Ausgaben und der Erwirtschaftung eines Gewinns. Plattformanbieter können Gewinne erwirtschaften, indem sie Gebühren für die Nutzung der Leistung erheben. Investoren können mit diesem zukünftigen Gewinn geworben werden. An sich kann zwar auch in einer dezentralen Anwendung eine Nutzungsgebühr einprogrammiert werden, der Anwendungsentwickler kann aber nicht gewährleisten, dass diese Softwarefunktion für einen längeren Zeitraum Bestand hat. Die Dezentralisierung der Anwendungen führt dazu, dass der Entwickler keinen beherrschenden Einfluss mehr auf Veränderungen des Softwarecodes hat. Mit einer Mehrheit der beteiligten Nodes kann nach Veröffentlichung der dezentralen Anwendungen die einprogrammierte Nutzungsgebühr gelöscht werden. Der Entwickler kann sich also nicht darauf verlassen, nach der Veröffentlichung der dezentralen Anwendung einen Gewinn zu erwirtschaften, zumindest nicht im Wege einer Nutzungsgebühr, wie es die bisherigen Plattformanbieter tun. Dies ist zwar gleichzeitig ein Vorteil der dezentralen Anwendungen, da ein überwiegender Teil der Transaktionskosten wegfällt. Es stellt den Anwendungsentwickler aber vor die Herausforderung, eine alternative Form der Gewinnerwirtschaftung zu finden. Diese erfolgt, indem er nicht die gesetzlichen Zahlungsmittel oder sonstige Kryptowährungen innerhalb seiner Blockchain zur Bezahlung zulässt, sondern eine eigene »Währung« innerhalb seiner Anwendung 158 Https://library.gito.de/open-access-pdf/B3_WI2020%20final%20Blockchain%20Sharing% 20Economy.pdf S. 8; abgerufen am 18. 1. 2021. 159 Weitnauer, BKR 2018, 231, 232; Rohr/Wright, Blockchain-Based Token Sales, https://hastings lawjournal.org/wp-content/uploads/70.2-Rohr-1.pdf, S. 22; Hacker/Thomale, Crypto-Securities Regulation, European Company and Financial Law Review 2018, 645, 652; Hahn/Wons; Initial Coin Offering, S. 10.

Marktzugang

67

schafft. Diese »Währung« sind Token. Bei der Programmierung der dezentralen Anwendung ist es dem Entwickler möglich, diese Token frei zu schaffen. Um als Zahlungsmittel geeignet zu sein, wird die Gesamtzahl von Token im Code der dezentralen Anwendung beschränkt. Einen Wert erlangt dieses »erfundene« Zahlungsmittel durch die Leistungen, die damit erlangt werden können. Wer die in der dezentralen Anwendung angebotenen Leistungen nutzen möchte, muss zunächst diese Token kaufen. Durch die begrenzte Anzahl der Token steigt der Wert im Verhältnis zur Nachfrage der angebotenen Leistungen.160 Durch den Verkauf der Token kann der Entwickler seine Kosten decken und Gewinn erzielen. Auf einem Primärmarkt werden die Token erstmals vom Entwickler an die möglichen Nutzer verkauft. Dieses Verfahren wird allgemein »Initial Coin Offering« (ICO) genannt.161 Sobald eine ausreichende Anzahl an Token verteilt wurde, entsteht ein Sekundärmarkt, wo die Token zwischen den jeweiligen Inhabern auf Plattformen, sog. Coin Exchanges, gehandelt werden. 2.

Kapitalmarktrechtliche Aufsicht

Da die Token der Finanzierung der Anwendungsentwickler dienen, stellt sich die Frage, ob sie dem regulierten Kapitalmarkt unterfallen, ob sie also Wertpapiere, Vermögensanlagen oder Anteile an Investmentvermögen darstellen. Aufgrund des besonderen Informationsgefälles zwischen Emittenten und Investoren, besteht auf diesem Markt die Prospektpflicht, durch die sich die Anleger ein zutreffendes Bild über den Emittenten und die angebotenen Wertpapiere machen können.162 Token können abhängig von ihrem Zweck in drei unterschiedliche Kategorien eingeordnet werden. Investment-Token bieten dem Inhaber Beteiligungsrechte an Unternehmungen oder Gewähren einen Anspruch auf künftige Zahlungen.163 Currency-Token hingegen dienen ausschließlich als Zahlungsmittel für Leistungen und sind dabei nicht an eine Anwendung gebunden.164 Während Currency- und Investment-Token oft nur einen Funktionstyp verkörpern, sind Utility-Token eine Kombination mehrerer Eigenschaften von Investment-und Currency-Token. Sie gewähren zwar keinen Anspruch gegen den Emittenten, ermöglichen es aber später, die innerhalb der dezentralen Anwendung angebo160 Klöhn/ Parhofer/Resas, ZBB 2018, 89, 93. 161 In Anlehnung an den kapitalmarktrechtlichen Begriff der IPOs (Initial Public Offering) für Wertpapiere; vgl. zur Organisation eines ICO: Behme/Zickgraf, ZfPW 2019, 66, 70f. 162 BGH Urt. v. 31. 5. 2011 − II ZR 141/09 NJW 2011, 2719, 2720; Buck-Heeb, Kapitalmarktrecht, S. 58f. 163 Spindler, WM 2018, 2109; Krüger/Lampert, BB 2018, 1154, 1155; Zickgraf, AG 2018, 293, 295. 164 Weitnauer, BKR 2018, 231, 232; Zickgraf, AG 2018, 293, 296.

68

Dezentrale Anwendungen der Sharing Economy

tenen Dienstleistungen zu nutzen.165 Für die rechtliche Einordnung ist es erforderlich, die »reinen« Tokenarten zu analysieren, um anschließend die hybriden Utility-Token bewerten zu können. a. Investment-und Currency-Token Beide Tokenarten lassen sich auf den ersten Blick eindeutig dem Kapitalmarktrecht oder dem Bankrecht zuordnen. Voraussetzung einer Prospektpflicht i. S. d. WpPG ist gem. § 3 I WpPG das Anbieten eines Wertpapieres im Inland. Wertpapiere werden in § 2 I WpPG legaldefiniert und umfassen insbesondere Aktien und vergleichbare Wertpapiere. Wie auch im WpHG ist Grundvoraussetzung für ein Wertpapier, dass es standardisiert, übertragbar und marktmäßig handelbar ist.166 Darüber hinaus darf es kein Zahlungsinstrument sein.167 aa. Currency-Token Bereits an dieser Stelle lassen sich die Currency-Token aus dem Wertpapierbegriff ausschließen. Gem. § 2 I WpHG handelt es sich bei Zahlungsinstrumenten nicht um Wertpapiere. Zahlungsinstrumente sind Bargeld, Schecks oder andere liquide Mittel, die üblicherweise als Zahlungsmittel verwendet werden.168 Hierzu hat bereits der EuGH entschieden, dass es sich bei Bitcoin, als Beispiel für Currency-Token, um ein vertraglich vereinbartes Zahlungsmittel handelt.169 Es verkörpert zwar nicht alle Funktionen bisheriger Zahlungsmittel, ist diesen aber letztlich ausreichend angenähert, um eine Ausnahme vom Kapitalmarktrecht zu rechtfertigen.170 Es ist weder ein inländisches oder ausländisches gesetzliches Zahlungsmittel, noch typisches E-Geld, welches einen Anspruch gegen den Emittenten gewährt. Dennoch wird es zur Zahlung von Leistungen verwendet171 und weist eine ausreichende Liquidität auf, die mit gesetzlichen Zahlungsmitteln vergleichbar ist.172 Für eine Gleichstellung mit Zahlungsmitteln sprechen die vergleichbaren Risiken, die Nutzer von Bitcoin treffen. Dies ist vor allem der Wechselkurs zu 165 Zickgraf, AG 2018, 293, 295; Hacker/Thomale, Crypto-Securities Regulation, European Company and Financial Law Review 2018, Fn.5; Rohr / Wright, Blockchain-Based Token Sales, https://hastingslawjournal.org/wp-content/uploads/70.2-Rohr-1.pdf, S. 18, 21. 166 Fuchs, WpHG, § 2 Rn. 10, 13; Roth in Kölner Kommentar zum WpHG, § 2 Rn. 15; Buck-Heeb, Kapitalmarktrecht, S. 26 mit weiteren Nachweisen. 167 Fuchs, WpHG, § 2 Rn. 10; Roth in Kölner Kommentar zum WpHG, § 2 Rn. 41. 168 Begr. RegE, BT-Drcks. 16/4028 S. 54. 169 EuGH, C-264/14, Rn. 42. 170 Spindler, WM 2018, 2109, 2114; Hacker/Thomale, Crypto-Securities Regulation, European Company and Financial Law Review 2018, 645, 679. 171 Bspw. für Bitcoin auf https://openbazaar.org/ abgerufen am 18. 1. 2021. 172 Bitcoin hat eine Marktkapitalisierung von 500 Mrd.€, https://tinyurl.com/48s49wca abgerufen am 18. 1. 2021.

Marktzugang

69

Fiat-Währungen.173 Diesen Schwankungen unterliegen aber auch die sonstigen Fiat-Währungen. So sind Schwankungen zwischen US Dollar und Euro von 10 % im Verlauf eines Jahres nicht unüblich.174 Eine andere Sichtweise vertrat unlängst hingegen das Kammergericht. Danach sollen Kryptowährungen, entgegen der Auffassung der BaFin175, zumindest keine Rechnungseinheiten i. S. d. § 1 XI Nr. 7 KWG darstellen.176 Der Gesetzgeber folgte bei der Umsetzung der AMLD5 Richtlinie177 hingegen der BaFin und führte den Begriff des Kryptowertes als eigenständiges Finanzinstrument i. S. d. KWG gemäß § 1 XI Nr. 10 KWG ein. Dieser stimmt, wenn auch wortgleich, nicht mit dem Begriff des Finanzinstrumentes des § 2 IV WpHG überein, sondern ist eigenständig zu bestimmen.178 An der Einordnung als Zahlungsinstrument könnte durch die Einfügung des Begriffes der Kryptowerte als Finanzinstrument Zweifel bestehen. Bereits in § 2 XI Nr. 3 KWG werden Zahlungsinstrumente ausdrücklich im Rahmen von Schuldtiteln von den Finanzinstrumenten ausgenommen. Dies könnte dafür sprechen, dass zwischen Finanzistrumenten und Zahlungsinstrumenten ein Exklusivitätsverhältnis vorliegt. Durch die Einordnung des Kryptowertes als Finanzinstrument wäre eine Einordnung als Zahlungsinstrument zwingend ausgeschlossen. Allerdings könnte auch hier darauf abgestellt werden, dass der Begriff des Zahlungsinstrumentes im Rahmen des WpHG eigenständig auszulegen ist und nicht mit dem des KWG übereinstimmt. In diesem Fall könnte den Ausführungen des EuGH gefolgt werden, sodass bei einer eigenständigen Auslegung des WpGH kein Wertpapier vorläge. Zum Zwecke der weiteren Argumentation soll zunächst von einer Einordnung der Currency-Token als Zahlungsinstrumente ausgegangen werden. bb. Investment-Token Da Investment-Token eindeutig nicht als Zahlungsmittel verwendet werden, müssen diese die sonstigen Voraussetzungen von Wertpapieren erfüllen. Investment-Token müssen, wie auch die sonstigen Wertpapiere, keine emittentenübergreifende Standardisierung aufweisen, sondern lediglich unterein-

173 Hacker/Thomale, Crypto-Securities Regulation, European Company and Financial Law Review 2018, 645, 679. 174 Werte der EZB nach Statista: https://tinyurl.com/22jnj847 abgerufen am 18. 1. 2021. 175 BaFin, Hinweise zu Finanzinstrumenten nach § 1 Abs. 11 Sätze 1 bis 5 KWG: https://tin yurl.com/32dc6v75 abgerufen am 18. 1. 2021. 176 KG Berlin, Urt. v. 25. 09. 2018-161 Ss 28/18, juris. 177 Richtlinie (EU) 2018/843 des europäischen Parlaments und des Rates vom 30. Mai 2018 zur ¨ nderung der Richtlinie (EU) 2015/849 zur Verhinderung der Nutzung des Finanzsystems A ¨ nderung der zum Zwecke der Geldwa¨ sche und der Terrorismusfinanzierung und zur A Richtlinien 2009/138/EG und 2013/36/EU. 178 Behrens/Schadtle, WM 2019, 2099, 2103; Zöllner, BKR 2020, 117, 121f.

70

Dezentrale Anwendungen der Sharing Economy

ander übereinstimmen.179 Die Token dürfen nicht auf die Bedürfnisse einzelner Kunden oder Anleger zugeschnitten sein.180 Allein aufgrund der für das Initial Coin Offering geschaffenen Stückzahl identischer Token kann von einer Standardisierung ausgegangen werden.181 Selbst emittentenübergreifend weisen Token eine immer höhere Standardisierung aus. So gilt für eine Veröffentlichung von Token auf der Ethereum Blockchain der ERC20 Token Standard, der die Mindestvoraussetzungen für ein Token beschreibt.182 Hierbei werden vor allem die Einheiten, die Übertragbarkeit und die Authentifizierung der Transaktion vereinheitlicht.183 Auch an der Übertragbarkeit lässt sich bei Investment-Token nicht zweifeln.184 Soweit eine Übertragbarkeit im Blockchain-Protokoll vorgesehen ist, wie es bei eigentlich allen Token der Fall ist, kann durch Nennung des Public Key des Empfängers und der Autorisierung durch den Private Key des Übertragenden ein Token beliebig zwischen Accounts der Blockchain übertragen werden.185 Zuletzt müssen die Token auch an Märkten handelbar sein. Ein starkes Indiz dafür ist der tatsächliche Handel mit Token.186 Teilweise wird verlangt, dass Wertpapiere einen gutgläubigen Erwerb zulassen müssen oder aber ein vergleichbarer gesetzlicher Schutz für den Erwerb besteht.187 Letzteres ist für Token nicht abschließend geklärt, was aber auch nicht zwingend notwendig erscheint. Die Blockchain stellt die gesamte Transaktionshistorie aller Token öffentlich dar. Dies verhindert zumindest die Verfügung von Nichtberechtigten. Zwar ist die Verfügung von Geschäftsunfähigen und beschränkt Geschäftsfähigen möglich, sodass der endgültige Erwerb nicht zwingend ist. Es findet aber eine ausreichende Annäherung an den gutgläubigen Erwerb durch die absolute Transparenz der Blockchain statt, sodass ein ausreichender Schutz des Erwerbers ge-

179 Fuchs, WpHG, § 2 Rn. 14. 180 Fuchs, WpHG, § 2 Rn. 14. 181 In der Regel werden mindestens einige Millionen Token in einem ICO verteilt, vgl. https://co inmarketcap.com abgerufen am 18. 1. 2021. 182 18 der 20 größten Token erfüllen den ERC20 Token Standard, vgl. https://coinmarketcap. com abgerufen am 18. 1. 2021. 183 Https://eips.ethereum.org/EIPS/eip-20, abgerufen am 18. 1. 2021. 184 Es ist allerdings durchaus denkbar, dass die Übertragbarkeit durch das Blockchain-Protokoll ausgeschlossen wird und somit keine Einstufung als Wertpapier möglich ist. 185 Der Public Key entspricht somit der Kontonummer und Bankleitzahl im elektronischen Zahlungsverkehr. Der Private Key kann mit dem Passwort fürs Online-Banking oder der herkömmlichen PIN gleichgesetzt werden. Sie bilden in der Regel zufällige 24-stellige Ziffern und Zahlen Kombination. 186 Hacker/Thomale, Crypto-Securities Regulation, European Company and Financial Law Review 2018, 645, 665ff. 187 Fuchs, WpHG, § 2 Rn. 19.

Marktzugang

71

währleistet ist.188 Insoweit können »Investment« Token grundsätzlich als Wertpapiere angesehen werden.189 b. Utility-Token Nach diesen grundlegenden Kriterien des Wertpapierbegriffes wären allerdings auch fast alle anderen Token Wertpapiere, unabhängig von ihrer Funktion. Soweit Utility-Token keine Zahlungsinstrumente sind, werden sie gehandelt, sind standardisiert gestaltet und innerhalb der Blockchain übertragbar. Ausnahmen lassen sich nur sehr vereinzelt finden, wenn die Übertragbarkeit von vornherein ausgeschlossen ist. Diese Arten sind aber eindeutig und offensichtlich von sonstigen Token abzugrenzen. Es stellt sich daher die Frage, ob weitere Kriterien hinzukommen müssen, um im Falle von Token zutreffend zwischen Wertpapieren und sonstigen Token zu differenzieren. aa. Vergleichbarkeit zu bisherigen Wertpapieren Teilweise wird darauf verwiesen, dass es allein auf die genannten abstrakten Merkmale ankommt.190 Danach ist es auch unerheblich, ob eine der genannten Fallgruppen in § 2 I Nr. 1–3 WpHG vorliegt. Diese sollen lediglich der Vereinfachung der Subsumtion dienen, indem sie ein starkes Indiz für das Vorliegen eines Wertpapieres liefern.191 Diese Ansicht kann sich zumindest auf den Wortlaut stützen, nach dem die genannten Merkmale Voraussetzungen eines Wertpapieres und die Beispiele nicht abschließend sind. Allerdings kommt sie gerade bei Token an Ihre Grenzen. Allein aufgrund der Struktur der Token und der leichten Übertragbarkeit innerhalb der Blockchain könnten die bisherigen Kriterien nicht mehr geeignet sein, um den Anwendungsbereich des WpHG zu bestimmen. Die Einordnung des Token sollte nicht losgelöst vom Inhalt des Token bestimmt werden. Insoweit sind ausreichend Token denkbar, die keinen näheren Bezug zum Kapitalmarktrecht haben und lediglich bisherige Güter in der realen Welt digital abbilden.192 Für eine Konkretisierung wird auf die Regelbeispiele des § 2 I Nr. 1–3 WpHG zurückgegriffen. Zwar sind diese nicht abschließend, dennoch soll für ein Wertpapier die Vergleichbarkeit zu den genannten Beispielen Voraussetzungen

188 Hacker/Thomale, Crypto-Securities Regulation, European Company and Financial Law Review 2018, 645, 666. 189 Hacker/Thomale, Crypto-Securities Regulation, European Company and Financial Law Review 2018, 645, 662ff.; Roth in KK WpHG, § 2 Rn. 43f. 190 Roth in KK WpHG, § 2 Rn. 15. 191 Roth in KK WpHG, § 2 Rn. 15; Fuchs, WpHG § 2 Rn. 19. 192 Beispiel: Einkaufsgutscheine ab einer bestimmen Einkaufssumme; Treuepunkte o. ä.

72

Dezentrale Anwendungen der Sharing Economy

sein.193 Dabei wird davon ausgegangen, dass wenn ein Token mit einem der Regelbeispiele vergleichbar ist, auch vergleichbare Risiken mit dem Token einhergehen, d. h. die Risiken durch das WpPG und WpHG reguliert werden müssen. Allerdings stößt auch die Vergleichbarkeit schnell an ihre Grenzen. Wenn man die Liste der Regelbeispiele durchgeht, dürfte zumindest kein Utility-Token in eine der Kategorien passen. Im Gegensatz zu Aktien oder Anteilen an Kapitalgesellschaften, § 2 Nr. 1 WpHG werden durch Utility-Token keine Anteile an einem Unternehmen übertragen. Insbesondere wird der Token-Erwerber auch nicht faktisch wie ein Aktionär gestellt. Ihm stehen keinerlei Beteiligungs- oder Gewinnrechte an der zugrundeliegenden Gesellschaft des ICOs zu. Auch nur in Ausnahmefällen führt der Erwerb des Token zu einer »Beteiligung« an der dezentralen Anwendung. Eine »Beteiligung« wird eingeräumt, wenn durch die Token ein Stimmrecht innerhalb der Anwendung implementiert ist194 oder das Mining der Blocks durch das Proof-of-Stake-Verfahren durchgeführt wird.195 Auch wenn in diesen Fällen keine rechtliche Beteiligung an einem Unternehmen vorliegt196, ist ein ausreichender faktischer Einfluss gegeben, bei dem man durchaus eine Vergleichbarkeit annehmen könnte. Hierbei stellt sich nur das die Frage, ob eine Blockchain mit einem Unternehmen vergleichbar ist. Strukturelle Unterschiede bestehen vor allem in der Umsatzerwirtschaftung und der Einbringung von Kapital in das Unternehmen durch Kauf von Anteilen. Insgesamt ist eine (wenn auch nur faktische) Beteiligung der Ausnahmefall für Token und ist insbesondere bei Utility Token unüblich, sodass in der Regel keine Vergleichbarkeit zu § 2 I Nr. 1 WpHG angenommen werden kann. Eine Vergleichbarkeit zu § 2 Nr. 3a und b WpHG setzen eine am Markt handelbare Forderung voraus.197 Dabei kommt es nicht auf ein finanzielles Leistungsversprechen an, sondern es genügt jegliche Form einer künftigen Leistung an.198 Insoweit ist zweifelhaft, ob Token-Halter irgendeinen Anspruch gegen Entwickler oder sonstige Blockchain-Beteiligten haben. Es kämen unterschiedliche Ansprüche bezogen auf die dezentrale Anwendung in Frage, z. B. Zugang, Nutzung oder Entwicklung und Instandhaltung der Anwendung. Es wäre also durchaus eine Vergleichbarkeit zu den Schuldtiteln denkbar. Aller193 Hacker/Thomale, Crypto-Securities Regulation, European Company and Financial Law Review 2018, 645, 670. 194 Wie z. B. bei der DAO (Decentralised Autonomous Organisation). 195 Hier wird der jeweilige Miner durch Auslosung unter allen Token bestimmt. Je mehr Token ein Miner hält, desto wahrscheinlicher ist die Auswahl. 196 Zum einen ist zweifelhaft, ob es sich bei der dezentralen Anwendung um eine Gesellschaft handelt (s. Haftung), zum anderen ist die Position eines Token-Halters in keiner Weise rechtlich abgesichert. 197 Vgl. Fuchs, WpHG § 2 Rn. 27. 198 Vgl. Fuchs, WpHG § 2 Rn. 27.

Marktzugang

73

dings kommt es letztlich für die Einordnung als Schuldtitel i.R.d. § 2 Nr. 3a WpHG erneut nur auf die Handelbarkeit am Markt an. Zuletzt verbleiben noch sog. Optionsscheine, die zum Erwerb von Wertpapieren i. S. d. § 2 I Nr. 3b WpHG berechtigen. Auch hier sind aufgrund der fast grenzlosen Möglichkeiten Token denkbar, die entsprechende Rechte digitalisieren. Diese sind aber nicht der Normalfall eines Utility-Token. Das Recht zum Erwerb von Wertpapieren dürfte nur in Ausnahmefällen mit der Verknüpfung einer dezentralen Anwendung einhergehen. Es ist kein generelles Kriterium zur Beurteilung von Utility-Token. Insgesamt bringt die Methode der Vergleichbarkeit mit den Regelbeispielen keinen wirklichen Fortschritt für die Kategorisierung von Token als Wertpapiere. Allerdings ist der Ansatz nicht gänzlich verfehlt, wenn weniger auf die Vergleichbarkeit mit den Regelbeispielen, sondern auf eine Vergleichbarkeit des Risikos und des Schutzzweckes abgestellt wird. Nach Sinn und Zweck der Norm muss festgestellt werden, ob ein Token in den Anwendungsbereich des WpPG und WpHG fällt, oder ob es keine kapitalmarktrechtliche Relevanz aufweist. Insoweit hat bereits die BaFin eine Stellungnahme veröffentlicht, nach der es auf eine Einzelfallabwägung des konkreten Token ankommt.199 Die Token sollen dabei technologieneutral beurteilt werden.200 Was genau es mit der technologieneutralen Bewertung auf sich hat, wird im Hinweisschreiben allerdings nicht deutlich. Trotz der individuellen Betrachtung von Token kommt die BaFin bei Utility-Token grundsätzlich zum Ergebnis, dass es sich bei ihnen nicht um Wertpapiere handelt.201 Wann immer Token Risiken mit sich bringen, die üblicherweise durch das Kapitalmarktrecht (insbesondere Prospektrecht) beherrscht werden, sollte das Kapitalmarktrecht Anwendung finden.202 Die Einzelfallabwägung hindert indes nicht, Utility-Token zu systematisieren. bb. Kategorisierung von Utility-Token Zur Kategorisierung der Utility-Token sind typische, bei ihnen auftretende Risiken zu identifizieren und mit dem kapitalmarktrechtlichen Schutz zu vergleichen. Utility-Token lassen sich zunächst einmal nach der zugrundeliegenden Anwendung differenzieren, für die sie geschaffen wurden. Da sich diese Untersuchung auf dezentrale Anwendungen im Rahmen der Sharing Economy beschränkt, sollen auch nur Token im Rahmen solcher Anwendungen beurteilt werden. 199 200 201 202

BaFin, Merkblatt ICOs, WA 51-Wp 7100-2019/0011 und IF 1-AZB 1505-2019/0003. BaFin, Merkblatt ICOs, WA 51-Wp 7100-2019/0011 und IF 1-AZB 1505-2019/0003, 4ff. BaFin, Merkblatt ICOs, WA 51-Wp 7100-2019/0011 und IF 1-AZB 1505-2019/0003, 5f. Zustimmend zu einem risikobasierten Ansatz: Spindler, WM 2018, 2109, 2113.

74

Dezentrale Anwendungen der Sharing Economy

Token im Rahmen von dezentralen Anwendungen in der Sharing Economy haben gemeinsam, dass die Token der Nutzung der angebotenen Leistungen dienen. Diese Leistung wird jedoch nicht von den Entwicklern der Anwendung erbracht, sondern von Dritten, die auf Anbieterseite die Anwendung nutzen. Je nach Konsensmechanismus erhalten die Anbieter der Leistung nicht nur ein Entgelt in Form von Token, sondern minen auch zeitgleich neue Blöcke der Blockchain und erhalten hierdurch neue Token, die nicht vom Entwickler veräußert wurden.203 Die Begrenzung der Token auf eine maximale Zahl schafft eine künstliche Knappheit der »Währung« für die dezentrale Anwendung, wodurch bei ausreichender Nutzung ein Wertzuwachs erzielt werden soll. Der Entwickler kann zwar zu diesem Zeitpunkt noch Inhaber von Token sein, ist dabei aber den anderen Nutzern gleichgestellt, d. h. er kann die Token auf dem Sekundärmärkt handeln oder als Entgelt für eine Leistung innerhalb der Anwendung nutzen. Den Token werden weder Stimmrechte noch sonstige Genussrechte in irgendeiner Form gewährt. Es wird auch nicht garantiert, dass eine Leistung zu einem bestimmten Gegenwert in Token erhältlich sein wird. Utility-Token haben in diesen Fällen immer mehr als nur eine Funktion. Sie setzten sich aus Elementen der Nutzung, Zahlung und Investition zusammen. Wie auch Currency-Token dienen sie dem Bezahlen von Leistungen innerhalb der dezentralen Anwendung. Im Gegensatz zu Currency-Token (Kryptowährungen) sollen sie aber auf eine Anwendung beschränkt sein. Die mit ihnen bezahlbaren Gegenleistungen sind durch die dezentrale Anwendung auf eine oder mehrere konkrete Leistungen beschränkt. Durch den Handel auf Sekundärmärkten und die natürliche Knappheit kann bei einer starken Nutzung, d. h. bei starker Nachfrage nach Token eine Wertsteigerung erwartet werden. Bei steigendem Wert können die Token mit Profit weiterverkauft werden. Insoweit werden die Käufer von ICOs als »Erstnutzer« der Token auch regelmäßig eine dahingehende Erwartungshaltung haben, dass der Wert des Token auf Dauer steigen wird.204 Hieraus ergibt sich die Möglichkeit, den Kauf von Token als Investition/ Geldanlage zu betrachten. Letztlich ist ihre natürliche oder auch bestimmungsgemäße Funktion die Nutzung der angebotenen Leistung selbst. 203 Das Minen hat zur Folge, dass neue Token geschaffen werden. Im Code der Blockchain wird die maximale Anzahl von Token festgelegt. Nach dem ICO ist das Minen die einzige Form zur Schaffung neuer Token. Wenn die maximale Anzahl an Token gemint wurde, können Miner als Entgelt für die Verifizierung neuer Blöcke nur noch von den Nutzern Token erhalten. Dadurch steigen die Transaktionskosten, indem der Nutzer dieses zusätzliche Entgelt entrichten muss. 204 Hacker/Thomale, Crypto-Securities Regulation, European Company and Financial Law Review 2018, 645, 681.

Marktzugang

75

Auch wenn die Token der unterschiedlichen zugrundeliegenden Anwendungen die gleichen Charakteristiken teilen, unterscheiden sie sich in einer zeitlichen Komponente von denjenigen, die bereits eine funktionsfähige Anwendung bieten und solchen, bei denen eine entsprechende Anwendung erst entwickelt wird. Bei bereits funktionsfähigen Anwendungen können die Token direkt nach dem Erwerb im Rahmen der ICO innerhalb der Anwendung genutzt werden, um die angebotenen Leistungen zu erwerben. Hier dürfte sich der Wert des Tokens ausschließlich am Wert der Nutzung orientieren. Soweit dies der Fall ist, würde kein systematischer Unterschied zu Gutscheinen bestehen und eine Regulierung über das Kapitalmarktrecht wäre nicht erforderlich. Wenn hingegen schon diese Token als Wertpapiere zu klassifizieren wären, müsste dies erst recht für Token gelten, denen nicht einmal eine funktionierende Anwendung zugrunde liegt. Andererseits können auch noch Token für zukünftige Anwendungen unter den Wertpapierbegriff fallen, obwohl Token bereits laufender Anwendungen von diesem ausgenommen sein können. cc. Wirtschaftliche Gefährdungslage von Käufern Das wirtschaftliche Risiko eines Tokenkaufs besteht vorwiegend im Wertverlust des Token. Da die Utility-Token von dezentralen Anwendungen in der Sharing Economy Eigenschaften von Investment-und Currency-Token aufweisen, teilen Sie auch die jeweiligen Risiken, die sich typischerweise hieraus ergeben. Empirisch lässt sich ermitteln, dass die am Sekundärmarkt gehandelten Token unter erheblichen Kursschwankungen leiden.205 Kursschwankungen können dabei unterschiedliche Gründe haben. Wie auch bei sonstigen Fiat-Währungen könnten sie auf allgemeine Veränderungen der Märkte zurückzuführen sein. So könnte man erwarten, dass sich die Kurse von Kryptowährungen und Token an der allgemeinen Konjunktur orientieren. Sie zeigen dabei aber deutlich stärkere Kursschwankungen als Fiat-Währungen wie der Euro oder Dollar in der gleichen Zeit.206 Es kann also nicht allein an der allgemeinen Konjunktur liegen, sondern es müssen weitere Gründe für die Schwankungen hinzutreten. Dabei lässt sich zunächst ein Phänomen unmittelbar nach einer ICO beobachten. In der Regel steigt der Kurs von Token nach ihrer Veröffentlichung in einer kurzen Zeitspanne erheblich an, um anschließend stark einzubrechen.207 205 Zetsche u.w., The ICO Gold Rush: It’s a Scam, It’s a Bubble, It’s a Super Challenge for Regulators, http://dx.doi.org/10.2139/ssrn.3072298, S. 15; Evans, Economic Aspects of Bitcoin and Other Decentralized Public-Ledger Currency Platforms, , https://core.ac.uk/down load/pdf/208684586.pdf, S. 8. 206 Evans, Economic Aspects of Bitcoin and Other Decentralized Public-Ledger Currency Platforms, https://core.ac.uk/download/pdf/208684586.pdf, S. 8. 207 Hargrave/Sahdev/Feldmeier, How Value is Created in Tokenized Assets, http://dx.doi.org /10.2139/ssrn.3146191, S. 6.

76

Dezentrale Anwendungen der Sharing Economy

Diese kurzfristigen Kursschwankungen sind auf die Anlegerstimmung vor der ICO zurückzuführen. Je stärker ein Token vor dem ICO beworben wird und je positiver die vorangehende Anlegerstimmung ist, desto stärker wird dieser erstmalige Preisanstieg nach der ICO ausfallen.208 Der anschließende Einbruch lässt sich nur mit dem Verkauf großer Mengen an Token durch Erstinvestoren begründen, die durch »Pump and Dump« einen Gewinn erzielen wollen. Langfristig kann erwartet werden, dass sich der Wert eines Token am Metcalfe’schen Gesetz orientiert.209 Dieser besagt, dass sich der Wert eines Systems exponentiell zur Anzahl der Nutzer verhält. Der langfristige Wert einer dezentralen Anwendung ergibt sich daher aus der Anzahl der Nutzer. Der Wert eines Token ergibt sich wiederum aus dem Gesamtwert der Applikation geteilt durch die Anzahl verfügbarer Token.210 Diese, auch als Netzwerkeffekt beschriebene Korrelation ist der Grund für langfristige Schwankungen. Aus der Erwartung der zukünftigen Entwicklung lässt sich ermitteln, ob ein Kauf von Token langfristig einen Profit verspricht. Im Ergebnis ist dies auch der Grund, warum Käufer einen Totalverlust ihrer Investitionssumme erleiden können. Wenn die zugrunde liegende Applikation nicht marktfähig ist oder aufgrund von Konkurrenz sich nicht am Markt behaupten kann, verliert das System die Nutzer und damit an Wert. Sobald keine ausreichende Nutzerzahl mehr vorhanden ist, werden die Utility-Token für diese Anwendung wertlos. Die Token haben somit keinen unmittelbaren Nutzungswert wie sonstige Rohstoffe, sondern sind in ihrem Wert immer von der zugrundeliegenden Anwendung und den darauf zu erwerbenden Leistungen abhängig. In diesem Bereich sind die Token äquivalent zu Gutscheinen. Auch deren Wert ergibt sich ausschließlich aus der damit einzutauschenden Leistung. Man könnte Token in diesem Rahmen auch als digitale Gutscheine bezeichnen. Einzige Veränderung durch die Digitalisierung und das System der Blockchain ist die Handelbarkeit. Diese wird deutlich vereinfacht, während ein Sekundärmarkt für Gutscheine kaum vorhanden, für Token aber essentieller Bestandteil ist.

208 Hargrave/Sahdev/Feldmeier, How Value is Created in Tokenized Assets, http://dx.doi.org /10.2139/ssrn.3146191, S. 6. 209 Peterson, Metcalfe’s Law as a Model for Bitcoin’s Value, http://dx.doi.org/10.2139/ssr n.3078248, S. 17. 210 Hargrave/Sahdev/Feldmeier, How Value is Created in Tokenized Assets, http://dx.doi.org /10.2139/ssrn.3146191, S. 4.

Marktzugang

77

c. Kapitalmarkttypische Gefährdung Wenn die Gefährdungslage der Käufer von Token den typischen Risken von Kapitalmärkten entspringen und gerade diese Gefahren durch das Kapitalmarktrecht bekämpft werden sollen, sollte es bei der grundsätzlichen Einordnung von Token als Wertpapiere bleiben. Der Schutzzweck des Kapitalmarktrechts ist grundsätzlich zweigeteilt in den Funktionsschutz der Märkte und den Anlegerschutz.211 Diese beiden Schutzzwecke stehen dabei in enger und untrennbarer Wechselwirkung, sodass durch den Schutz der Anleger auch ein Funktionsschutz der Märkte erzielt wird.212 Insbesondere der institutionelle Funktionsschutz wird durch das Vertrauen der Anleger gewährleistet, was durch deren Schutz gesteigert wird.213 Die kapitalmarktrechtlichen Regelungen lassen sich diesen Schutzzwecken zuordnen. So dient das WpPG nicht der Bekämpfung von Informationsasymmetrien als Selbstzweck, sondern der mit dem Anlegerschutz einhergehende Stärkung des Vertrauens der Anleger in den Markt. Ob eine Informationspflicht einem darüber hinausgehendem Interesse dient oder unmittelbar einer Entscheidung des informierten Verbrauchers dient, lässt sich am Inhalt der Informationspflicht nur schwer feststellen. Hier kommt die angesprochene Wechselwirkung am Kapitalmarkt zum tragen, sodass das Fördern einer auf Informationen beruhenden Entscheidung zwangsläufig zur Förderung des Vertrauens in den Markt führt. Alleine auf der Grundlage des WpPG lässt sich nicht feststellen, ob bei Token nun eine kapitalmarktrechtliche oder allgemein zivilrechtliche Informationspflicht erforderlich ist, da beide letztlich Informationsasymmetrien reduzieren wollen. Der Einordnung als Problem des Kapitalmarktrechts wird entgegengehalten, dass auf der angebotenen Leistung beruhende Risiken gerade Gegenstand der Verbraucherschutzrechte sind.214 Die im Verbraucherrecht verankerten Informationspflichten seien besser zum Abbau von Informationsassymetrien bezüglich der zugrundeliegenden Leistung geeignet.215 Das alleinige abstellen auf das Prospektrecht ist jedoch zu eindimensional und berücksichtigt nicht die gesamte Risikolage von Käufern und Inhaber von UtilityToken. Eine solche Betrachtung lässt außer Acht, dass gerade nicht nur die Prospektpflicht, sondern eine Vielzahl weiterer Verpflichtungen mit der Ein211 Hirte/Heinbach in KK WpHG, Einleitung Rn. 11; Assmann, ZBB 1989, 49, 61f.; Hommelhoff, ZHR 1989, 181, 192; Hopt, Der Kapitalanlegerschutz im Recht der Banken, 1975, S. 89ff. 212 Fuchs, WpHG, Einl. Rn. 13; Hopt, ZHR 1995, 135, 159; Kübler, AG 1977, 85, 87f. 213 Fuchs, WpHG, Einl. Rn. 16. 214 The Cardozo Blockchain Project, Not So Fast – Risks Related to the Use of a »SAFT« for Token Sales, https://tinyurl.com/38nynf 7u; Weitnauer, BKR 2018, 231, 233. 215 Hacker/Thomale, Crypto-Securities Regulation, European Company and Financial Law Review 2018, 645, 675f.; Zickgraf, AG 2018, 293, 304.

78

Dezentrale Anwendungen der Sharing Economy

ordnung als Wertpapier einhergehen. Diese umfassen vor allem Marktzugangsfolgeinformationspflichten (Ad-hoc Mitteilungen), sowie Marktmanipulationsund Insiderhandelsverbote.216 Um eine zutreffende Einordnung von Token vorzunehmen, muss daher zunächst geprüft werden, welche Risiken auf den Sekundärmärkten allgemein beim Handel mit Token auftreten. Wenn diese Risiken eine Zuordnung zum Kapitalmarktrecht erforderlich machen, sollte auch im Marktzugang eine einheitliche Zuordnung vorgenommen werden, sodass das Prospektrecht Anwendung finden sollte. Erst im Anschluss kann beurteilt werden, welche Informationen der Prospektpflicht sich auf Token übertragen lassen. Durch Analyse des Bitcoin- Kurses im Vergleich zur typischen Erwartungshaltung nach dem Metcalfe’schen Gesetz wurde festgestellt, dass mit an Sicherheit grenzender Wahrscheinlichkeit der Kurs im Zeitraum einiger Monate durch Preismanipulationen beeinflusst wurde.217 Solche Preismanipulationen sind geeignet, das Vertrauen der Anleger in den Markt zu beeinträchtigen. Marktmanipulationen sind seit 2016 in der MMVO (Marktmissbrauchsverordnung)218 geregelt. Diese untersagt die Marktmanipulation für alle Finanzinstrumente, die an einem multilateralen Handelssystem oder organisiertem Markt gehandelt werden gem. §§ 15, 2 I MMVO. Der Begriff des Finanzinstrumentes ist dabei Deckungsgleich mit dem WpHG, da Art. 3 I Nr. 1 MMVO auf die MiFID II verweist und das WpHG diese Terminologie in Deutschland identisch umgesetzt hat. Finanzinstrumente beschränken sich allerdings nicht auf Wertpapiere, sondern umfassen gem. § 2 IV WpHG auch sonstige handelbare Titel. Mit diesen sonstigen Finanzinstrumenten besteht aber keine besondere Vergleichbarkeit, sodass die MMVO auf Token nur Anwendung finden wird, wenn es sich bei den Token um Wertpapiere handelt. Das gleiche gilt auch für die Ad-hoc Publizität. Auch § 17 MMVO setzt keine Wertpapiere voraus, sondern verlangt nur einen Emittenten von Finanzinstrumenten. Die Ad-hoc Publizität bezieht sich dabei auf Insiderinformationen i. S. d. § 7 MMVO. Dabei handelt es sich vor allem um solche Informationen, die hinreichend präzise sind und die bei Veröffentlichung geeignet sind, das Finanzinstrument erheblich zu beeinflussen. Gerade solche Informationen sind auch für den Käufer von Token nach Erwerb entscheidend, damit dieser beurteilen kann, wie sich der Wert der Token entwickeln wird. 216 Zur Gefahr des Marktmissbrauchs und Insiderhandel: Börner, NZWiSt 2018, 48, 50ff. 217 Peterson, Metcalfe’s Law as a Model for Bitcoin’s Value, http://dx.doi.org/10.2139/ssrn.307 8248, S. 5. 218 Verordnung (EU) Nr. 596/2014 des Europäischen Parlaments und des Rates vom 16. April 2014 u¨ ber Marktmissbrauch (Marktmissbrauchsverordnung) und zur Aufhebung der Richtlinie 2003/6/EG des Europa¨ischen Parlaments und des Rates und der Richtlinien 2003/ 124/EG, 2003/125/EG und 2004/72/EG der Kommission.

Marktzugang

79

Bei allen Utility-Token, solche für die bereits eine funktionierende Anwendung veröffentlicht wurde und solche, bei der die Anwendung erst in der Zukunft erscheinen soll, lässt sich ein Bedürfnis für die Offenlegung solcher Informationen erkennen. Da die Wertprognose des Token unmittelbar von der zu erwartenden Nutzerzahl abhängt, gilt vor allem für Token mit zukünftigen Anwendungen, dass die Erwerber dieser Token erfahren müssen, wenn das Entwicklerteam Informationen erhält, die für die Prognose entscheidend sind. Exemplarisch sind vor allem Informationen, die sich auf das Entwicklungsstadium der Anwendung und erhebliche Abweichungen von den bisherigen Planungen beziehen. So muss der Erwerber erfahren, wenn die geplanten Leistungen innerhalb der Anwendung verändert werden sollen, da die Änderung die Zahl möglicher Nutzer beeinflusst und dadurch auch den Wert der Token. Auch Verzögerungen innerhalb der Entwicklung oder Probleme bei der Fertigstellung der Anwendung sind entscheidend für den Erwerber. Das Informationsbedürfnis besteht in etwas veränderter Form auch nach Veröffentlichung der Anwendung fort. Auch hier können Einzelne einen erheblichen Informationsvorsprung erlangen, der sich unmittelbar auf den Wert der Token auswirken könnte. Wenn der Entwickler nach Veröffentlichung der Blockchain seine Arbeit einstellt, kann sich dies negativ auf die zukünftige Entwicklung der Blockchain und damit auch die der Token auswirken. Auch wenn prinzipiell jeder nach Veröffentlichung der Blockchain an ihrer Verbesserung mitwirken kann und die Gesamtheit der Nodes oder Miner ein Update für die Blockchain vorschlagen kann, hat der Entwickler einen Wissensvorsprung. Eine Vielzahl der Blockchain-Nutzer wird darauf vertrauen, dass vorwiegend der bisherige Entwickler an einer Weiterentwicklung arbeitet. So wird z. B. schon in Whitepapers erklärt, dass der Entwickler auch weiterhin an einer Verbesserung arbeiten möchte, wenn er im Gegenzug gegen das Update eine Provision aus den Blockchain-Transaktionen erhält.219 Die Prognose für eine Blockchain wird sich verschlechtern, wenn der bisherige Entwickler kein Interesse an einer Weiterentwicklung mehr zeigt, sondern mit der Veröffentlichung jede weitere Arbeit einstellt. Andererseits kann ein Entwickler, der an einer Verbesserung der Anwendung arbeitet, wegen seiner beschränkten Einflussnahme nach Veröffentlichung nicht mehr sicher sein, dass seine Verbesserungsvorschläge von der Mehrheit der Nodes übernommen werden. Nur wenn sich ausreichend Unterstützer für die Änderungen finden lassen, können die Veränderungen in die Blockchain übernommen werden. Also selbst wenn der Entwickler ein Update programmiert hat,

219 Whitepaper ArcadeCity, S. 13.

80

Dezentrale Anwendungen der Sharing Economy

besteht keine hinreichende Sicherheit für eine Umsetzung, die diesen Vorgang als Insiderinformation kategorisieren würde.220 Wenn nicht die Umsetzung selbst eine Insiderhandelsinformation ist, könnte der Vorschlag eines solchen Updates an die Blockchain-Teilnehmer eine Insiderinformation darstellen. Sobald das Update allerdings vorgeschlagen wurde, ist es öffentlich bekannt, sodass gem. Art. 7 Ia MMVO keine Insiderinformation vorliegt. Letztlich kommt nur noch die Vorbereitung eines solchen Update-Vorschlags durch eine Person in Betracht.221 Bereits die Kenntnis über ein mögliches Update ist geeignet, sich auf den Wert der Token auszuwirken. Schon diese Information kann zu einer Kursveränderung führen, wenn sie der Öffentlichkeit bekannt wird. Sobald der Markt erfährt, dass ein Update vorgeschlagen wird, kann auf die Umsetzung spekuliert werden. So kann einerseits eine Wertsteigerung erwartet werden, wenn das Update die dezentrale Anwendung künftig verbessert, andererseits aber auch zu einem Wertverlust führen, wenn es zu einer Hard Fork der Blockchain kommt, bei der zumindest ein Teil der alten Blockchain das Update nicht umsetzt und sich so letztlich zwei separate dezentrale Anwendungen entwickeln, die miteinander in Konkurrenz stehen. Insgesamt gibt es also bei beiden Arten von dezentralen Anwendungen, solche die bereits veröffentlicht wurden und solche die erste in Zukunft veröffentlicht werden sollen, Insiderinformationen, die den Wert der Token beeinflussen können und durch den leichten Handel mit Token auch Möglichkeiten für Marktmanipulationen. d. Einheitliche Kategorisierung von Token Zumindest seit den 1930er Jahren hat sich die Ansicht durchgesetzt, dass Insiderhandel zu einem Funktionsproblem der Märkte führt und das Vertrauen in sie beeinträchtigt, wenn nicht entsprechende regulatorische Maßnahmen ergriffen werden.222 Wenn sich die Probleme einheitlich bei allen handelbaren Token stellen, sollten sie auch einheitlich als Wertpapiere behandelt und so dem Kapital-

220 Für zukünftige Ereignisse bedarf es einer ausreichenden Wahrscheinlichkeit, um von einer Insiderinformation ausgehen zu können: Buck-Heeb, S. 109. 221 Auch Absichten und Pläne einer Person können für eine Insiderinformation ausreichend sein: Buck-Heeb,S. 109f.; Assmann in Assmann/Schneider/Mülbert, Wertpapierhandelsrecht, Art.7 VO Nr. 596/2014 Rn. 20. 222 Vgl. zur Entwicklung des Insiderhandels: Behr, Insiderhandel und Optionspreisspannen, 13ff.; Mennicke in Fuchs, WpHG, Vor §§ 13–14 Rn. 4, 31; a. A. die sich auf den Nutzen von Insiderhandel zur effektiven Informationsverbreitung aussprechen: Neus, Ökonomische Agency-Theorie und Kapitalmarktgleichgewicht, 1989; Manne, Insidertrading and the Stock Market, S. 131.

Marktzugang

81

marktrecht zugeordnet werden.223 Das Verbraucherinformationsrecht ist zwar ebenfalls geeignet, Informationsasymmetrien abzubauen, wird aber der Regulierung des Sekundärmarktes nicht gerecht. Stattdessen ist hier das Kapitalmarktrecht erforderlich, um vor allem die Sekundärmärkte zu schützen und das Vertrauen zu stärken. Da auch das Kapitalmarktrecht Informationsasymmetrien mit der Prospektpflicht auf den Primärmärkten und der Ad-hoc Publizitätspflicht auf den Sekundärmärkten entgegenwirkt, ist eine Korrektur des Wertpapierbegriffes nicht erforderlich. Da sich die Gefahren aus der vereinfachten Handelbarkeit an Märkten ergibt, bedarf es keiner Korrektur der Kriterien Standardisierung, Übertragbarkeit und marktmäßige Handelbarkeit. Es bedarf jenseits dieser Merkmale für die Einordnung eines Token als Wertpapier nicht einer gesonderten Vergleichbarkeit zu den bisher genannten Wertpapieren in § 2 I WpHG und § 2 Nr. 1 WpPG. Da somit zumindest alle üblichen Utility-Token ein Wertpapier i. S. d. des Kapitalmarktrechts darstellen, findet auch die Prospektpflicht grundsätzlich Anwendung, wobei der Inhalt dieses Prospektes noch weitergehend untersucht werden muss.224 e. Prospektpflicht für Utility-Token Die allgemeine Prospektpflicht und deren Inhalt ergeben sich aus § 3 I, 5 WpPG. Grundsätzlich sind alle Emittenten von Wertpapieren vor ihrem öffentlichen Anbieten der Wertpapiere im Inland zur Erstellung eines Prospektes verpflichtet. § 3 II WpPG sieht zwar Ausnahmen von der Prospektpflicht vor, überwiegend beim Ausschluss für qualifizierte Anleger oder ab einem Mindestabnahmebetrag von 100.000 €. Massentaugliche Utility-Token werden diese Schwelle wohl nicht überschreiten. Der Inhalt des Prospektes richtet sich nach § 5 WpPG. Dabei lässt sich der Tatbestand vereinfacht gesprochen in § 5 I, II WpPG nach allgemeinen und in § 5 IIa, IIb WpPG nach konkreten Anforderungen unterteilen. Da Wertpapiere letztlich als Unternehmensanteile ausgestaltet sind, können nicht alle Anforderungen des § 5 WpPG auf einen Prospekt für Utility-Token übertragen werden. Den Anforderungen lassen sich aber eine Vielzahl von Grundgedanken entnehmen, die sich übertragen lassen. § 5 I 1, II 3 WpPG lassen sich zwei Aussagen entnehmen, die keinen konkreten Bezug zum Inhalt, sondern vielmehr zur Präsentation der Informationen haben. Danach müssen die Informationen »in leicht analysierbarer und verständlicher 223 Im Ergebnis zur gleichen Risikolage ohne nähere Argumentation: van Aubel in: Habersack/ Mülbert/Schlitt, Unternehmensfinanzierung am Kapitalmarkt, 20.65. 224 Grundsätzlich sollten nach dieser Argumentation sämtliche Token-Arten unter den Wertpapierbegriff subsumiert werden. Auch Kryptowährungen sind diesen Gefahren ausgesetzt, sodass viel für eine Kategorisierung als Wertpapier anstatt eines Zahlungsmittels spricht.

82

Dezentrale Anwendungen der Sharing Economy

Form« wiedergegeben werden, sodass sie »den Anlegern bei der Prüfung der Frage, ob sie in die betreffenden Wertpapiere investieren sollten, behilflich« sind. Diese Anforderungen lassen sich unproblematisch auch auf Token übertragen, da sie letztlich nur ein Mindestmaß an Relevanz und Verständlichkeit der Informationen verlangen. Schwieriger ist die Bewertung bei Informationen, die sich konkret auf das Unternehmen beziehen. So müssen nach § 5 I 1 WpPG wesentliche Informationen über den Emittenten enthalten sein, insbesondere über die Finanzlage, die Gewinne und Verluste, die Zukunftsaussichten des Emittenten und jedes Garantiegebers, sowie die mit diesem Wertpapier verbundenen Rechte. Letztlich lassen sich diese Informationen als solche klassifizieren, die den Inhalt des Wertpapieres maßgeblich beeinflussen. Dies lässt sich aber nicht ohne weiteres auf Utility-Token übertragen. Insbesondere Angaben zur wirtschaftlichen Lage des Emittenten haben bei Token keinen Einfluss auf das angebotene Produkt. Zwar lässt sich hieraus unter Umständen ein Rückschluss auf die Seriosität des Token ziehen; dies entspricht aber nicht der ursprünglichen Zweckrichtung dieser Angaben. Insoweit muss hier eine Einschränkung der Informationen erfolgen. Es müssen nur solche Informationen preisgegeben werden, die sich konkret auf die Erfolgsaussichten und die Zukunft des Utility-Token beziehen. Hierzu dürften vor allem die mit dem Token verbundenen Rechte zählen. Darüber hinaus sind für die Zukunftsaussichten des Token aber vor allem der Stand der Entwicklung, die geplante Veröffentlichung einer Anwendung sowie die Unterstützung der Anwendung durch den Entwickler nach der Veröffentlichung entscheidend. Dies lässt sich im weitesten Sinne noch unter das Kriterium der Zukunftsaussichten des Emittenten fassen. Eine darüber hinausgehende Veröffentlichungspflicht bezüglich der finanziellen Lage des Emittenten scheint aber vor allem aus dem Gesichtspunkt der unterschiedlichen Arten von Emittenten nicht gerechtfertigt. Entgegen dem bisherigen Wertpapierbegriff können Token auch von Individuen ausgegeben werden, die keiner Gesellschaftsform entsprechen, sondern natürliche Personen sind. Diesen eine umfassende Offenlegungspflicht aufzubürden, ist sowohl unverhältnismäßig als auch unnötig. Die finanzielle Situation des Emittenten wirkt sich auf die Bewertung von Token nur insoweit aus, wie sich hieraus die weitere Entwicklung bis zur Veröffentlichung der Anwendung ergibt. Insofern müssen zumindest Angaben über die Absicherung der künftigen Entwicklung der Anwendungen gegeben werden. Dies lässt sich aber unter Umständen auch aus den konkreten Vorgaben der § 5 IIa, IIb WpPG entnehmen. Aus § 5 IIa WpPG sind vor allem die Nummern 2 und 5 entscheidend. So müssen die wesentlichen Risiken des Wertpapieres und die Verwendung der Erlöse angegeben werden. Beide Voraussetzungen sind auch entscheidend für

Marktzugang

83

Token. Hierunter ließen sich vor allem Angaben zur künftigen Entwicklung der Anwendung und der Finanzierung der Anwendung subsumieren. Bei bereits fertigen Anwendungen bedarf es unter Umständen nicht einmal dieser Informationen. Für die Anwendungen ist letztlich nur entscheidend, welche Rechte mit dem Token gem. § 5 I 1 WpPG einhergehen. Auch wenn das WpPG von Mindestangaben spricht, so ist dies nicht allgemein gültig. Letztlich verweist das WpPG in § 5 II 4 auf die europäische Prospektverordnung.225 Für neue Wertpapiertypen, worunter die reinen Utility-Token fallen, ist in Art. 23 III der Verordnung eine Ausnahme von Informationspflichten vorgesehen. Danach bestimmt für solche Wertpapiertypen die zuständige Behörde im Einvernehmen mit dem Emittenten den Inhalt des Prospektes und setzt hiervon die EU-Kommission in Kenntnis. Die Zulassung von Utility-Token scheitert somit nicht schon an dem Mindestmaß an Informationen, sondern der Inhalt kann individuell bestimmt werden. Insoweit obliegt es der BaFin, entweder für jedes Utility-Token eigene Vorgaben zu machen oder eine gewisse Klassifizierung vorzunehmen, um für ähnliche Token einheitliche Informationspflichten zu bestimmen. Zumindest muss sich der Prospekt an die allgemeinen Grundsätze halten: Prospektwahrheit, Prospektklarheit und Prospektaktualität.226 f. Internationale Angebote Indem eine überwiegende Anzahl an ICOs online stattfinden, bleibt als letztes Problem der Anwendung des deutschen Prospektrechts der Inlandsbezug des öffentlichen Angebotes gem. § 3 I WpPG. Seit Verbreitung des Internets wird erörtert, unter welchen Voraussetzungen von einem inländischen Angebot ausgegangen werden kann.227 Entscheidend ist, ob Anleger in Deutschland von dem Angebot angesprochen werden.228 Indiz soll hierfür sein, ob das Angebot in deutscher Sprache verfasst wird oder deutsche Ansprechpartner genannt werden.229 Da ICOs grundsätzlich an ein internationales Publikum gerichtet sind, werden Sie fast ausschließlich in englischer Sprache verfasst. Die deutsche Sprache kann heutzutage kein notwendiges Kriterium in einem internationalen Markt sein. Auch ein Angebot in englischer Sprache kann an Anleger in ¨ nderung 225 Delegierte Verordnung (EU) Nr. 486/2012 der Kommission vom 30. 3. 2012 zur A der Verordnung (EG) Nr. 809/2004 in Bezug auf Aufmachung und Inhalt des Prospekts, des Basisprospekts, der Zusammenfassung und der endgu¨ ltigen Bedingungen und in Bezug auf die Angabepflichten. 226 Groß, Kapitalmarktrecht, Art. 6 Prospektverodnung Rn. 1ff. 227 Lenz/Ritz, Die Bekanntmachung des Bundesaufsichtsamtes für den Wertapierhandel, WM 2000, 904ff.; zur alten Fassung: Ritz/Zeising in Just WpPG, § 2 Rn. 171ff. 228 Ritz/Zeising in Just WpPG, § 2 Rn. 171. 229 Groß, Kapitalmarktrecht, Art. 3 Prospektverordnung Rn. 5.

84

Dezentrale Anwendungen der Sharing Economy

Deutschland gerichtet sein,230 wobei im Einzelfall Indizien erforderlich sind, um ein inländisches Angebot annehmen zu können.231 Hilfestellung bieten die Vorgaben der EU-Prospektverordnung232 und die Stellungnahme der BaFin233. Demnach liegt immer dann ein inländisches Angebot vor, wenn das Angebot allgemein zugänglich ist und der Adressatenkreis im Angebot nicht eingeschränkt wird.234 Für die Nichtanwendung deutschen Rechts sollen auch noch Maßnahmen erforderlich sein, die einen Erwerb von einem ausgeschlossenen Adressatenkreis, d. h. in diesem Fall ein Erwerb von Anlegern aus Deutschland, verhindern.235 Ein solcher Ausschluss lässt sich zumindest bislang in den angebotenen ICOs nicht beobachten. Dies mag sich hingegen ändern, sobald die BaFin auch für Utility-Token wiederholt Prospekte verlangt. Bisher werden entsprechende Hinweise vor allem für China und Russland veröffentlicht, nicht jedoch für Deutschland.236 Bei anonymen Verkäufen ist es bislang schwierig, Käufer aus einem bestimmten Land auch faktisch am Kauf zu hindern. Ausreichend soll jedoch sein, wenn vor dem Kauf die Adresse des Käufers anzugeben ist.237 Ob sich darüber hinaus auch technische Möglichkeiten entwickeln, die einen Verkauf geographisch beschränken, bleibt abzuwarten. Gerade solange der Kauf anonymisiert erfolgt, sollten grundsätzlich hohe Anforderungen an entsprechende Maßnahmen gestellt werden. Im anonymen Geschäftsverkehr auf eine ehrliche Selbstklassifizierung der Käufer zu vertrauen, scheint keine geeignete Maßnahme zu sein, um einen entsprechenden Verkauf in das entsprechende Land zu verhindern. Soweit andere Mitgliedstaaten eine ähnliche Auffassung zum Adressatenkreis eines Angebotes vertreten, muss mindestens in einem dieser Länder ein Prospekt gebilligt werden, der dann gem. Art. 25 der Prospektverordnung für die übrigen Mitgliedstaaten Geltung entfaltet.238 Da die Umsetzung des WpPG zu überwiegenden Teilen aber auf dieser Verordnung beruht, dürften nur geringe Abweichungen zur Prospektpflicht in Deutschland bestehen. Das deutsche WpPG wird vor allem nicht dadurch umgangen, dass sich bisher nicht alle europäischen 230 Ritz/Zeising in Just WpPG, § 2 Rn. 171. 231 VG Frankfurt/M. Urt. v. 05. 07. 2007-1 E 4355/06, juris. 232 Verordnung (EU) 2017/1129 des europäischen Parlaments und des Rates vom 14. Juni 2017 u¨ ber den Prospekt, der beim o¨ ffentlichen Angebot von Wertpapieren oder bei deren Zulassung zum Handel an einem geregelten Markt zu vero¨ ffentlichen ist und zur Aufhebung der Richtlinie 2003/71/ EG. 233 Https://tinyurl.com/2p9dpvzu, abgerufen am 18. 1. 2021. 234 Https://tinyurl.com/2p9dpvzu, abgerufen am 18. 1. 2021. 235 Ritz/Zeising in Just WpPG, § 2 Rn. 171. 236 Vgl. Whitepaper ArcadeCity. 237 Vgl. Ritz in Assmann/Lenz/Ritz, § 1 VerkProspG Rn. 73; Heidelbach in Schwark, § 4 VerkProspG Rn. 8ff. 238 Verordnung (EU) 2017/1129 v. 14. 06. 2017.

Verbraucherschutz

85

Aufsichtsbehörden zur Bewertung von Token geäußert haben oder noch zurückhaltend in der Anwendung von Prospektpflichten sind. Solange kein gebilligter Prospekt aus einem Mitgliedstaat vorliegt, findet das WpPG für ICOs im Internet weiterhin Anwendung. 3.

Zwischenergebnis

Auch Utility-Token fallen somit unter die kapitalmarktrechtliche Regulierung und können von der BaFin beaufsichtigt werden. Dabei gilt für den Emittenten einer Blockchain vor allem die Prospektpflicht, die vor Veröffentlichung der Token im Inland zu erfüllen ist. Der Prospekt ist vor dem Verkauf der Token von der BaFin gem. § 13 I WpPG zu genehmigen. Ohne Token lässt sich zumindest eine gewinnorientierte dezentrale Anwendung nicht umsetzen und somit werden Beschränkungen des Tokenvertriebes zu Marktzugangsbeschränkungen der Anwendung. Der Marktzugang wird aber nicht bereits dadurch verhindert, dass nicht alle Mindestangaben des WpPG und der europäischen Proskpektverordnung durch Utility-Token erfüllbar sind, sondern es müssen in der Praxis die wesentlichen Kriterien zur Evaluierung eines Utility-Token bestimmt und als Maßstab für den Inhalt des Prospektes genutzt werden. Die dadurch gewährleistete Mindestinformation für den Käufer wahrt den individuellen Anlegerschutz wie auch die Funktionalität des Marktes.

§7

Verbraucherschutz

Beim Vertragsschluss ändert sich durch die Verwendung einer dezentralen Anwendung auf den ersten Blick nichts. Vor allem muss dem Nutzer nicht einmal bewusst sein, dass er den Vertrag nicht über eine herkömmliche Plattform schließt. Lediglich der Intermediär wird durch eine Technologie ersetzt. Die Vertragsparteien bleiben hingegen unverändert. Somit müssen zumindest die verbraucherrechtlichen Informationspflichten der §§ 312ff. BGB; §§ 246, 246a EGBGB nach wie vor durch den Anbieter der Leistung erbracht werden, wenn es sich bei ihm um einen Unternehmer handelt. Es stellen sich die gleichen Fragen nach der Abgrenzung zwischen Unternehmern und Verbrauchern sowie der Umsetzung der Informationspflichten wie bei Plattformen. Zu ihnen wurde zwar festgestellt, dass der Plattformbetreiber nicht unmittelbar für die Informationspflichten des Vertragspartner verantwortlich ist, er innerhalb seiner Plattform aber für Transparenz der Vertragsparteien sorgen muss.

86

Dezentrale Anwendungen der Sharing Economy

Abhängig von der Art der angebotenen Leistungen, die der Entwickler der Anwendung zur Verfügung stellt, können auch weitere Informationspflichten hinzutreten.

I.

Informationspflichten

Soweit die Plattform durch die dezentrale Anwendung ersetzt wird, stellt sich die Frage nach der Anwendung der Pflichten des bisherigen Plattform-Betreibers. Dabei kommen sowohl Informationspflichten aus dem BGB als auch weitere Schutzvorschriften aus dem Lauterkeitsrecht in Betracht. Auf der zeitlichen Achse ist erneut zwischen der Entwicklung und dem späteren Betrieb der Blockchain zu differenzieren. 1.

Anwendungsentwickler als Verpflichteter

Wie bereits bei den Marktzugangsbeschränkungen ist der erste Ansatzpunkt der Entwickler der Blockchain. Dieser trifft zumindest die ersten wesentlichen Strukturentscheidungen über die Blockchain und das Interface für die spätere Nutzung. Gleichzeitig ist er auch der erste, der die dezentrale Anwendung als solche zum ersten Mal in Umlauf bringt. An beiden Stellen könnten Verbraucherschutzvorschriften zum Tragen kommen. a. Verpflichtungen bei Veröffentlichung der Blockchain Die zentralen Regeln über besondere Vertriebsformen und allg. Anforderugen für Verbraucherverträge des BGB, §§ 312ff., knüpfen an das Erfordernis eines entgeltlichen Vertrages gem. § 312 I BGB an. Ein Vertrag wird regelmäßig zwischen einem Verbraucher und einem Unternehmer geschlossen werden. Problematisch ist jedoch die Unentgeltlichkeit der Verbreitung der Anwendung. Insoweit ist zwischen der Anwendung selbst und einer späteren Nutzung zu differenzieren. Die Anwendung kann kostenfrei über die einschlägige Verbreitungsplattform heruntergeladen werden. In diesem Kontext wird der Nutzer nicht einmal Daten oder sonstiges angeben müssen, sodass es sich auch nicht unter diesem Aspekt um eine entgeltliche Leistung handeln kann.239 Allerdings verbreitet der Entwickler die Anwendung auch nicht ohne jeglichen monetären Anreiz. Für seine Arbeit wird er mittels des Vertriebs der Token entgolten. Ohne Token ist die Anwendung nicht nutzbar. Der Nutzer kann sich 239 Zur grds. weiten Auslegung der Entgeltlichkeit: BT-Drs. 17/13951, S. 59; Grüneberg in Palandt § 312 Rn. 3b; Wendehorst in MüKoBGB, § 312 Rn. 19; Brönneke/ Schmidt-Kessel, VuR 2014, 3.

Verbraucherschutz

87

zwar die Anwendung herunterladen, die darauf angebotenen Dienstleistungen setzen aber voraus, dass er zuvor die entsprechenden Token zur Anwendung erworben hat. Für die Nutzung ist also grundsätzlich ein entgeltliches Geschäft erforderlich. Ähnlich zu Bürgschaften könnte man erwägen, ob die Verbreitung der Anwendung und die Veräußerung der Token als Einheit betrachtet werden müssen.240 Bei Bürgschaften geht es zwar darum, eine Leistung zwischen Bürgen und Unternehmer zu begründen, letztlich führt dies aber im Kern zu einer Gesamtbetrachtung aus Erwägungen des Verbraucherschutzes.241 Zwar hat der BGH die Anwendbarkeit der § 312 BGB nach der Neufassung der Norm ab dem 13. Juni 2014 die Unanwendbarkeit auf Bürgschaften festgestellt.242 Die Änderung wird aber mit dem neuen Wortlaut der Leistungsrichtung begründet. Der Wortlaut des § 312 Abs.1 BGB wurde dahingehend geändert, dass nur noch entgeltliche Leistungen des Unternehmers erfasst sind und keine Leistungen eines Verbrauchers an einen Unternehmer. Der Grundgedanke der Gesamtbetrachtung wird von der geänderten Rechtsprechung aber nicht berührt. Auch im Falle des Anbietens einer Blockchain-Anwendung haben wir eine Leistung eines Unternehmers an einen Verbraucher. Es kann somit nach den Grundgedanken der ursprünglichen Rechtsprechung für die Entgeltlichkeit weiterhin auf eine Gesamtbetrachtung zurückgegriffen werden. Das Kernargument des EuGHs war bei Bürgschaften die rechtliche Akzessorietät der Bürgschaft zur Hauptschuld.243 Da die Nutzung der Anwendung ohne den Kauf entsprechender Token nicht möglich ist, kann man bei dezentralen Anwendungen zwar nicht von einer rechtlichen, wohl aber von einer tatsächlichen, technischen Akzessorietät sprechen. Bei derartigen Abhängigkeiten soll es, um die einfache Umgehung der Vorschriften zu verhindern, lediglich auf eine kausale oder konditionale Abhängigkeit (in Form einer Bedingung) ankommen.244 Eine Abhängigkeit ist dann zu bejahen, wenn es für den Nutzer keine andere Möglichkeit gibt, Token der Anwendung zu erlangen, als diese vom Entwickler zu erwerben. An dieser Stelle stößt das Modell an die Grenzen einer möglichen Zurechnung. Der Entwickler ist nicht der einzige Anbieter der Token. Er ist zwar im Rahmen des ICOs der erste Anbieter, der Kreis erweitert sich aber im Anschluss an die Veröffentlichung erheblich. Durch die Handelbarkeit und einer Vielzahl von multilateralen Handelsplattformen im Internet ist es für den letztendlichen 240 EuGH, Urteil vom 17. 3. 1998 -Rs. C-45–96, NJW 1998, 1295f.; Reinicke/Tiedtke, Schutz des Bürgen, ZIP 1998, 893ff. 241 Busch in BeckOGK BGB, § 312 Rn. 19. 242 BGH, Urteil vom 22. 09. 2020 -XI ZR 219/19, NJW 2020, 3649ff. 243 EuGH, Urt. v. 17. 3. 1998 -Rs. C-45/96, NJW 1998, 1295f. 244 Wendehorst in MükoBGB, § 312 Rn. 36; Koch in Erman BGB, § 312 Rn. 6.

88

Dezentrale Anwendungen der Sharing Economy

Nutzer äußerst unwahrscheinlich, unmittelbar vom Entwickler die Token zu erwerben, soweit er nicht am ICO teilnimmt. Zumindest für Transaktionen nach dem ICO kann nicht von einem ausreichenden Zusammenhang ausgegangen werden. Es kann zwar in Einzelfällen auch eine entgeltliche Leistung an Dritte ausreichend sein,245 dies gilt aber nur soweit, wie der Unternehmer aus dieser Zahlung auch seine Vergütung erlangt.246 Beim Handel mit Token auf dem Sekundärmarkt erfolgt keine Weiterleitung eines Anteils an den Entwickler. Seine Leistung wird ausschließlich über den Verkauf der Token während des ICO kompensiert. Auch wenn der Entwickler beim ICO Token verkauft, weist die Käufergruppe keinen ausreichenden Bezug zu den späteren Nutzern auf, um für die dezentrale Anwendung selbst einen entgeltlichen Vertrag anzunehmen. Bei den Erstkäufern handelt es sich regelmäßig um Investoren, die die Token nicht zur späteren Nutzung sondern zur Kapitalanlage und Weiterveräußerung erwerben. Neben dem Bezug stünden der Zurechnung auch noch zwei faktische Hindernisse entgegen. Zum einen kann die Anwendung, sobald einmal im Umlauf, von jeder beliebigen Person weitergeleitet werden. Der Entwickler ist also selbst nicht einmal der ausschließliche Vertreiber der Anwendung. Er ist weder konstanter Anbieter der Leistung noch der Token. In diesem Zusammenhang ist nicht ersichtlich, warum sich die Informationspflichten danach unterscheiden sollten, von welcher Internetseite der Download erfolgt. Darüber hinaus ist der Kauf von Token auch nicht die einzige Möglichkeit ihrer Beschaffung. Durch diverse Modelle der Konsensbildung können auch, je nach Modell, die Token durch Mining erzeugt werden, also eine originäre Neuschöpfung statt eines Erwerbs von einem Dritten. Die Token können also auch vollkommen unabhängig von einem Erwerb erlangt werden. Insoweit erbringt der Nutzer der Blockchain selbst eine Leistung, das Mining.247 Auf diese umgekehrten Leistungsbeziehungen bei Fernabsatzverträgen könnten die § 312ff. BGB ebenfalls anwendbar sein. Ausdrücklich dagegen spricht sich die Gesetzesbegründung aus, da die in der Richtlinie genannten Vertragsarten jeweils eine Leistung des Unternehmers voraussetzen würden.248 Dem wird jedoch entgegengehalten, dass die Richtlinie eine derart enge Formulierung nicht aufweist. Stattdessen sollen alle Verträge zwischen einem Unternehmer und einem Ver245 Koch in Erman BGB, § 312 Rn. 6. 246 BGH, Beschl. v. 07. 01. 2003-X ARZ 362/02, JZ 2003, 1120. 247 Dies kann das typische zur Verfügung stellen von Rechenleistung entsprechend der BitcoinBlockchain sein, oder auch innovative Modelle wie das Fahren einer bestimmten Kilometerzahl mit dem Auto, wie bei LaZooz. 248 BT-Drs. 17/12637, 45. Sich anschließend: BGH, Urt. v. 10. 12. 2014 – VIII ZR 90/14, NJW 2015, 1009, 1011; Urt. v. 22. 9. 2020-XI ZR 219/19, NJW 2020, 3649, 3650; Hilbig-Lugani, ZJS 2013, 441, 444.

Verbraucherschutz

89

braucher erfasst werden.249 Zumindest die Übertragung der Informationspflichten nach § 246 EGBGB über die wesentlichen Bestandteile der Leistung scheint nicht sinnvoll.250 Letztlich liegt beim Mining jedoch nicht einmal ein Vertragsschluss zwischen Miner und Entwickler vor, sondern lediglich die Erfüllung einer Auslobung des Nutzers. Da Token also auch auf diesem Wege erlangt werden können, womit letztlich nicht zwingend ein entgeltlicher Vertrag zur Nutzung der Anwendung erforderlich ist, kann auch nicht von einer gesicherten Kausalität zwischen Download der Anwendung und entgeltlichem Kauf von Token ausgegangen werden, die eine Gesamtbetrachtung rechtfertigen würde. Solange sich die Handlung des Entwicklers ausschließlich auf die Veröffentlichung der Anwendung beschränkt, liegt kein entgeltlicher Verbrauchervertrag vor; die § 312ff. BGB finden für die Veröffentlichung keine Anwendung. b. Verpflichtungen bei neuen Funktionen Verbraucherrechtlich relevante Konstruktionen ergeben sich allerdings nicht nur bei der erstmaligen Verbreitung der dezentralen Anwendung durch den Entwickler, sondern können auch nachträglich entstehen. Dies gilt vor allem für Funktionen, die durch einen Konsens der Nodes nachträglich in die Blockchain implementiert werden. Obwohl der Entwickler251 nach Veröffentlichung der Anwendung keinen Einfluss mehr auf sie und die Blockchain hat, gibt es einige Modelle, bei denen der Entwickler für Folgeentwicklungen innerhalb der Anwendung vergütet werden soll.252 Für entsprechende Fortentwicklungen der Anwendung werden Provisionen für jede Transaktion unter Verwendung der neuen Funktionen an den jeweiligen Entwickler weitergeleitet. Obwohl auch diese neuen Funktionen jederzeit kopiert und so die Provision des Entwicklers umgangen werden könnte, kann der Entwickler Vertrauen in den Fortbestand der Provision haben. Sobald die Provision von den BlockchainMitgliedern entfernt würde, bestünden für den Entwickler keinerlei Anreize mehr für eine weitergehende Entwicklung der Blockchain. Insoweit ist die Provision auch im Interesse der Blockchain-Mitglieder, die auf diese Weise eine Weiterentwicklung der Blockchain fördern.

249 Busch in BeckOGK BGB, § 312 Rn. 13; Maume, NJW 2016, 1041, 1043. 250 Für diesen Fall zustimmend: Busch in BeckOGK BGB, § 312 Rn. 14. 251 Der Entwickler muss/ wird aber regelmäßig mit dem ursprünglichen Entwickler der Blockchain identisch sein, da dieser die größte Expertise und einen Wissensvorsprung ggü. konkurrierenden Entwicklern hat. 252 Vgl. Whitepaper ArcadeCity.

90

Dezentrale Anwendungen der Sharing Economy

Bei diesen Funktionen erfolgt dann eine Vergütung der Leistungen unmittelbar vom Nutzer an den Entwickler der Funktion. Es handelt sich somit um eine entgeltliche Leistung von einem Unternehmer an einen Verbraucher i. S. d. § 312 BGB. Auch hier scheint die Unternehmereigenschaft des Entwicklers zunächst unproblematisch zu sein, da die Funktion auf unbestimmte Dauer in die dezentrale Anwendung integriert wird und im Falle der Nutzung regelmäßige Einkünfte an den Entwickler fließen.253 Lediglich das Merkmal eines organisatorischen Mindestaufwandes könnte zweifelhaft sein. Sofern dieser zur Begründung einer planvollen Tätigkeit verlangt wird, soll eine professionelle Arbeitsweise und Organisation die Unternehmereigenschaft indizieren.254 Es werden jedoch keine weiteren Aussagen bezüglich der Anforderungen an diesen Mindestaufwand getroffen. Unzweifelhaft erfordert die Entwicklung einer weiteren Funktion für eine dezentrale Anwendung regelmäßig einen erheblichen Aufwand und Organisation, insbesondere auch zur Finanzierung. Allerdings ist dieser Aufwand dem Vertragsschluss mit dem Verbraucher zeitlich vorgelagert. Sobald die Funktion in die Anwendung übernommen wurde, beschränkt sich das Interesse des Entwicklers auf die Verteilung der Einnahmen. Die reine Nutz-/ Gewinnziehung aus einem Recht oder einer Anlage ist jedoch keine planmäßige Tätigkeit, da es hierbei am organisatorischen Mindestaufwand fehlt.255 Für den Zeitpunkt nach der Implementierung der Funktion lässt sich dies auch auf den Entwickler einer neuen Funktion in der dezentralen Anwendung übertragen. Solange nur die reine Gewinnziehung betrachtet wird, ist kein organisatorischer Mindestaufwand erforderlich. Allerdings wird es dem Zweck des § 14 BGB zur Bestimmung schutzbedürftiger Personengruppen nicht gerecht, allein auf das Ergebnis einer Tätigkeit zu schauen. Um die Erfahrung und die Schutzbedürftigkeit einer Person zu ermitteln, kann nicht ausschließlich auf das Ergebnis geschaut werden.256 Entscheidender sind die Maßnahmen, die bis zur Gewinnziehung getroffen werden müssen. Soweit diese Vorbereitungshandlungen planmäßig, d. h. einen organisatorischen Mindestaufwand voraussetzend, erfolgen, muss dies bei der Bewertung berücksichtigt werden. Es ist eine Gesamtbetrachtung des Handelns vorzunehmen.257 Das hierbei erworbene Wissen führt

253 Vgl. an die Anforderungen der Dauer: Faber, ZEuP 1998, 854, 869ff.; Alexander in BeckOGK BGB, § 14 Rn. 133. 254 Martinek/Heine in juris-PK BGB, § 14 Rn. 13ff.; Bamberger in Bamberger/Roth, § 14 Rn. 14; Micklitz in MüKoBGB, § 14 Rn. 20. 255 Für den Gewinn aus einer Photovoltaikanlage: OLG Hamm, Urt. v. 11. 11. 2015-I-12 U 34/15, NZBau, 2016, 363, 364; Alexander in BeckOGK BGB, § 14 Rn. 131.1. 256 Zum Schutzzweck des § 14 BGB: Alexander in BeckOGK BGB, § 14 Rn. 10. 257 BGH, Urt. v. 18. 10. 2017-VIII ZR 32/16, NJW, 2018, 150, Rn. 31; BGH, Urt. v. 13. 3. 2013-VIII ZR 186/12, NJW, 2013, 2107.

Verbraucherschutz

91

in allen daran anschließenden, auf das gleiche Geschäft gerichteten Handlungen dazu, dass der Entwickler der Funktion nicht schutzbedürftig ist. Dies lässt sich letztlich auch den Überlegungen zu Handlungen der Unternehmensgründung entnehmen. Hier entfällt der Verbraucherschutz, mit Ausnahme für Kreditgeschäfte gem. § 512 BGB, schon bei den Handlungen der Unternehmensgründung.258 Wenn die Schutzbedürftigkeit schon dort entfällt, wo nur die Absicht zur künftigen unternehmerischen Tätigkeit gegeben ist, muss dies erst recht gelten, wenn in der Vergangenheit bereits eine planmäßige selbstständige Tätigkeit vorlag und lediglich die zukünftige Gewinnerzielung keinen weiteren Aufwand mehr erfordert. Soweit also die ursprüngliche Veröffentlichung inkl. der Entwicklung einen organisatorischen Mindestaufwand voraussetzt, liegt auch zu einem späteren Zeitpunkt eine unternehmerische Tätigkeit bezogen auf dasselbe Produkt vor. Dies gilt bis zu dem Zeitpunkt, zu dem die Funktion eingestellt wird oder die Einnahmen auf sonstige Art und Weise zum Erliegen kommen. Ob die Arbeiten im Vorfeld einer Veröffentlichung von Funktionen für die Blockchain einen organisatorischen Mindestaufwand voraussetzen, richtet sich nach einer objektiven Betrachtungsweise.259 Dabei können sowohl der Zweck der Handlung, als auch der zu erwartende Aufwand berücksichtigt werden. Der Zweck ist bei allen entgeltlichen Funktionen auf die dauerhafte Erzielung von Einnahmen ausgerichtet und insoweit eindeutig einem unternehmerischen Handeln zuzuordnen. Auch der Aufwand zur Entwicklung einer solchen Funktion wird regelmäßig eine Vielzahl von Personen und Zeitaufwand erfordern, sodass auch hierbei in der Organisation von Arbeitsabläufen und Beschaffung von notwendigen Ressourcen von einem organisatorischen Mindestaufwand ausgegangen werden kann, solange nicht anderweitige Indizien vorliegen. Solche Indizien könnten im Bereich der Informatik und anonymen Blockchain-Welt darin gesehen werden, dass die Funktionen lediglich unter einem einzelnen Pseudonym oder durch einen einzelnen Entwickler veröffentlicht werden.260 Von einem organisatorischen Mindestaufwand kann ausgegangen werden, wenn der Entwickler an weiteren Funktionen arbeitet und diese veröffentlicht. Wenn die Einnahmen aus einer früheren Funktion in die Entwicklung weiterer Funktionen mit vergleichbarem Aufwand fließen, kann kaum die Unterneh-

258 EuGH, Urteil vom 03. 07. 1997 -C-269/95, WM 1997, 1549; BGH, Beschl. v. 24. 2. 2011 − 5 StR 514/09, NJW, 2011, 1236, Rn. 4; Urt. v. 15. 11. 2007 -III ZR 295/06, NJW 2008, 435, Rn. 6. 259 OLG Düsseldorf, Urt. v. 6. 6. 2012 -I-3 U 63/11, NZV 2012, 432; BGH, Urt. v. 13. 3. 2013-VIII ZR 186/12, NJW 2013, 2107. 260 Vgl. zum Indiz gegen Unternehmereigenschaft bei Pseudonymen auf Plattformen: Alexander in BeckOGK BGB, § 14 Rn. 192; OLG Koblenz Beschl. v. 30. 7. 2008-5 U 397/08, MMR 2009, 199.

92

Dezentrale Anwendungen der Sharing Economy

mereigenschaft für alle folgenden abgelehnt werden, da hieraus ein regelmäßiger Aufwand erwächst. Somit liegt in den Fällen der Nutzung einer entgeltlichen Funktion in der Blockchain ein Verbrauchervertrag i. S. d. §§ 310 III, 312 BGB vor. Da die Blockchain als Fernkommunikationsmittel fungiert, sind grds. die Informationspflichten gem. § 312d BGB, § 246a EGBGB zu erfüllen. Sie werden vor allem auch nicht durch § 312 II BGB ausgeschlossen. Selbst wenn eine Anwendung unter einen der Bereiche des § 312 II BGB fällt, ist die Leistung des Entwicklers lediglich die Bereitstellung digitaler Dienste, die auf die Förderung der zugrunde liegenden Leistung gerichtet sind. Sie fallen also selbst nicht in die Bereichsausnahmen, sondern sind allgemeine Dienstleistungen des Unternehmers im Rahmen des § 312 I BGB. Wie auch bei sonstigen Dienstleistungen erlischt das Widerrufsrecht gem. § 356 IV BGB mit vollständiger Erbringung der Dienstleistung. Bei den Funktionen dürfte es sich regelmäßig um sehr kurzfristig zu erfüllende Dienstleistungen handeln, sodass in aller Regel, bei entsprechendem Hinweis des Unternehmers gem. § 356 IV 1 BGB, das Widerrufsrecht ausgeschlossen sein dürfte. Da aber die Widerrufsmöglichkeit zumindest im Ansatz gewährleistet werden muss, muss der Unternehmer sicherstellen, dass eine Kommunikation zwischen ihm und dem Verbraucher möglich ist. Diese Pflicht des Unternehmers führt somit letztlich zu einer Designpflicht für die Anwendungen in der Form, dass sowohl alle erforderlichen Informationen übermittelt werden als auch der Verbraucher eine Kontaktmöglichkeit zum Entwickler/ Unternehmer erlangt. Letztlich muss der Entwickler einer Funktion sicherstellen, dass die Anforderungen des Verbraucherrechts ungeachtet der Technologie erfüllt werden können. Bei entgeltlichen Dienstleistungen ist der Entwickler Unternehmer i. S. d. § 312ff. BGB. Der Entwickler unterscheidet sich in seiner Funktion hierbei grundlegend vom Plattformanbieter. Er tritt im Rahmen von entgeltlichen Dienstleistungen innerhalb der dezentralen Anwendung nicht als Vermittler von Leistungen, sondern als Anbieter einer entgeltlichen Leistung gegenüber dem Verbraucher auf. Wir haben es also nicht mit der üblichen Dreiecksbeziehung von Plattformen als Intermediär, sondern einem klassischen Zwei-PersonenVerhältnis zu tun. Tritt der Entwickler hingegen nicht in diesem Rahmen als eigenständiger Anbieter auf, sondern dient die dezentrale Anwendung nur der Vermittlung von Leistungen Dritter, finden die §§ 312ff. BGB nicht unmittelbar auf den Entwickler Anwendung. Allerdings ist der Entwickler durch das Design der Anwendung maßgeblich dafür verantwortlich, ob es dem Dritten möglich ist, über

Verbraucherschutz

93

die dezentrale Anwendung seinen Informationspflichten nach § 312ff. BGB gerecht zu werden. 2.

Nodes als Verpflichtete

Indem das Verbraucherrecht der § 312ff. BGB an den Vertragspartner, also den Unternehmer anknüpft, scheint für eine Verantwortlichkeit der BlockchainMitglieder auf den ersten Blick kein Raum zu sein.261 Dies gilt, wie auch für den Entwickler, zumindest in der Hinsicht der vertraglichen Informationen gem. § 312ff. BGB, Art. 246ff. EGBGB. Die Mitglieder der Blockchain sind zunächst lediglich die Dienstleister der Infrastruktur und haben keinen unmittelbaren Kontakt zu den angebotenen Leistungen. Insoweit lassen sich keine verbraucherrechtlichen Verpflichtungen aus dem BGB bestimmen.

II.

Designpflichten

Wie schon bei den Plattformen der Sharing Economy sind derzeit weder der Entwickler noch die Blockchain-Mitglieder gem. § 312ff. BGB zur Bereitstellung von Informationen verpflichtet. Dennoch hängt die Erfüllung der Informationspflichten des Anbieters von der Gestaltung der dezentralen Anwendung ab. Nur wenn ihm hier die Möglichkeit zur Selbstkennzeichnung gegeben wird, kann er seine Informationspflichten gegenüber dem Verbraucher erfüllen. 1.

Anwendungsentwickler

Die Designpflichten können sich unabhängig von der Anwendbarkeit der §§ 312ff. BGB auf den Entwickler aus dem UWG ergeben. Da die § 312ff. BGB nur unmittelbar das Zwei-Personen-Verhältnis regeln, bleibt das UWG der einzige Anknüpfungspunkt für eine Verantwortlichkeit von Vermittlern wie dem Plattformbetreiber. Zwar regelt § 3 UWG nur das Verbot unlauterer Geschäftspraktiken. Soweit unlautere Praktiken aber im Vorenthalten wesentlicher Informationen bestehen, begründet es im Umkehrschluss eine entsprechende Informationspflicht, falls die Anwendung weiterhin rechtmäßig betrieben werden soll.262 Grundvoraussetzung ist das Vorliegen einer geschäftlichen Handlung i. S. d. § 2 I Nr. 1 UWG. Eine solche liegt in jedem Verhalten, das mit der Förderung des 261 Mit der Änderung des § 312 l BGB stellt sich die Frage, wer Betreiber gem. § 312l Abs. 4 BGB n. F. des Online-Marktplatzes ist, wenn dieser blockchainbasiert umgesetzt wird. Aufgrund der Kontrollrechte dürfte mit Veröffentlichung die Nodes »Betreiber« i.d.S. sein. 262 Vgl. Frank in Harte-Bavendamm/Henning-Bodewig UWG, § 3 III Nr. 23 Rn. 448.

94

Dezentrale Anwendungen der Sharing Economy

Absatzes von Waren und Dienstleistungen zusammenhängt.263 Es ist dabei unbeachtlich, ob sich die Handlung auf die Förderung des eigenen Unternehmens oder eines Dritten bezieht.264 Betroffen sind alle Informationen, die unmittelbar für den Vertragsschluss erforderlich sind. Auch der Unternehmensbezug ist trotz eines eigenständigen Begriffsverständnisses des UWG zu bejahen.265 Auch hier genügt jede auf Dauer angelegte, selbständige wirtschaftliche Betätigung, die darauf gerichtet ist, Waren oder Dienstleistungen gegen ein Entgelt zu vertreiben.266 Damit sind die betreffenden Anbieter erfasst, die in der Sharing Economy Leistungen über das übliche Maß eines Verbrauchers hinaus anbieten. Ob die fehlende Kennzeichnung als Unternehmer eine unlautere geschäftliche Handlung ist, ist an den §§ 3 ff UWG zu messen, wobei für die Informationspflicht letztlich vor allem § 3 III Anhang Nr. 23 und § 5a II in Betracht kommen. Die in § 3 III Anhang genannten Per-se-Verbote gehen dabei als lex specialis dem § 5a UWG vor.267 Demnach ist das Erwecken des Eindruckes, der Unternehmer würde nicht als solcher handeln, unlauter gem. § 3 III Anhang Nr. 23.268 Bei den Plattformen der Sharing Economy geht der Kunde grundsätzlich davon aus, dass die Anbieter der Leistungen Verbraucher sind. Darin unterscheiden sich Plattformen von herkömmlichen Geschäftsmodellen, bei denen die Leistungen unterschiedlicher Unternehmer bereitgestellt werden. Selbst wenn auf einer Plattform sowohl Verbraucher als auch Unternehmer tätig sind, geht der Kunde von einem Verbraucher als Anbieter aus, wenn keine gesonderte Kennzeichnung erfolgt. Für die unlautere Handlung ist es im Rahmen der Nr. 23 irrelevant, ob der Verbraucher hierdurch zum Vertragsschluss veranlasst wurde oder ob eine besondere Erheblichkeitsschwelle vorliegt.269 Wenn nicht schon unmittelbar aus Nr. 23, so ergibt sich die Unlauterkeit zumindest aus § 5a I, da der Verbraucher zum Vertragsschluss veranlasst wird ohne, dass der Unternehmer als solcher kenntlich gemacht wird. Ob nun bereits der Plattform-Betreiber unmittelbar unlauter handelt, wenn er eine entsprechende Kennzeichnung des Unternehmers nicht ermöglicht oder nur Gehilfe zu einer unlauteren Handlung des Unternehmers ist, kann für die Rechtsfolge des Unterlassungs- und Beseitigungsanspruches des § 8 I UWG 263 Bähr in MüKo LautR, § 2 UWG Rn. 25. 264 BGH, Urt. v. 6. 2. 2014-I ZR 2/11, juris; Keller in Harte-Bavendamm/Henning-Bodewig UWG, § 2 Rn. 12; Köhler in Köhler/Bornkamm/Feddersen UWG, § 2 Rn. 2.19. 265 Götting in Götting/Nordemann UWG, § 2 Rn. 49; Bähr in MüKo LautR, § 2 UWG Rn. 307. 266 BGH, Urt. v. 19. 06. 1981 -I ZR 100/79, juris; Erdmann/Pommerening in Loschelder/Danckwerts, Hdb. Wettbewerbsrecht, § 31 Rn. 32; Bähr in MüKo LautR, § 2 UWG Rn. 41. 267 Obergfell in Fezer/Büscher/Obergfell UWG, Anhang zu § 3 III Nr. 23. 268 BT-Drucks 16/10 145, S. 34; Sosnitza in Ohly/Sosnitza UWG, Anhang (zu § 3 III), Rn. 67; Obergfell in Fezer/Büscher/Obergfell UWG, Anhang zu § 3 III Nr. 23 Rn. 22; Frank in HarteBavendamm/Henning-Bodewig UWG, Anhang zu § 3 III Nr. 23 Rn. 452. 269 Wirtz in Götting/Nordemann UWG, § 3 Rn. 135.

Verbraucherschutz

95

keinen Unterschied machen.270 Da jedes Hilfeleisten i. S. d. § 27 StGB genügt271, ist hiervon auch das Verhindern einer Selbstkennzeichnung erfasst. Erforderlich ist lediglich ein entsprechender Vorsatz bei den Plattform-Betreibern.272 Strafrechtlich ist zumindest bedingter Vorsatz vorauszusetzen.273 Bei Handelsplattformen müsse der Vorsatz auf den konkreten Rechtsbruch bezogen sein,274 die Kenntnis möglicher Rechtsverstöße ohne konkrete Nachforschungsmaßnahmen hingegen noch nicht für einen bedingten Vorsatz genügen.275 Etwas anderes gilt jedoch dann, wenn die Plattform nach ihrer Art auf den Rechtsbruch ausgerichtet ist.276 Bei den üblichen Plattformen der Sharing Economy überwiegen C2C Verträge. Eine Nutzung durch Unternehmer ist jedoch nicht ausgeschlossen. Wenn eine Kennzeichnung als Unternehmer auf der Plattform nicht möglich ist, ist dem Plattform-Betreiber auch bewusst, dass es bei jedem Unternehmer zu einem Rechtsverstoß kommt. Soweit die Nutzung der Plattform durch Unternehmer vom Betreiber gewünscht und bewusst akzeptiert wird, genügt es für den Vorsatz, dass bereits von vornherein mit Rechtsverstößen zu rechnen ist.277 Damit besteht der Gehilfenvorsatz im Grundsatz bei allen Plattformen der Sharing Economy, die sich auch für Unternehmer öffnen, aber keine entsprechende Kennzeichnung ermöglichen. Für Plattformen der Sharing Economy besteht somit gem. § 3 I UWG eine Designpflicht, die Selbstkennzeichnung von Unternehmern unter den genannten Voraussetzungen zu ermöglichen. So sieht es auch die EU-Kommission im Falle von Airbnb, wobei sie sich hier nicht auf die Verbotsnormen ohne Wertungsmöglichkeit bezieht, sondern auf Art. 6, 7 der UGP Richtlinie.278 Auf Handelsplätzen, auf denen sowohl Unter270 Vgl. Fritzsche in MüKo LautR, § 8 UWG Rn. 245. 271 BGH, Urteil vom 3. 7. 2008-I ZR 145/05, GRUR 810, 812; Weithergehend zu den strafrechtlichen Voraussetzungen der Beihilfe: Joecks in MüKo StGB, § 27 Rn. 5ff. 272 Nach überwiegender Auffassung ist eine vorsätzliche Haupttat nicht erforderlich. Es genügt das vorliegen des obj. Tatbestandes, hier die fehlende Information über die Unternehmereigenschaft; vgl. OLG Brandenburg Urt. v. 13. 06. 2006, GRUR-RR 2007, 18, 19; Goldmann in Harte-Bavendamm/Henning-Bodewig UWG, § 8 Rn. 441ff. 273 BGH Urt. v. 19. 04. 2007-I ZR 35/04, GRUR 2007, 708; Urt. v. 11. 03. 2004-I ZR 304/01, GRUR 2004, 860; Fritzsche in MüKo LautR, § 8 UWG, Rn. 245. 274 Fritzsche in MüKo LautR, § 8 UWG Rn. 245. 275 Fritzsche in MüKo LautR, § 8 UWG Rn. 245. 276 OLG Köln Urt. v. 26. 06. 2008-6 U 111/08, GRUR-RR 2009, 4, 5f.; Fritzsche in MüKo LautR, § 8 UWG Rn. 245. 277 Vgl. OLG Köln Urt. v. 26. 06. 2008-6 U 111/08, GRUR-RR 2009, 4, 5f. 278 Richtlinie 2005/29/EG u¨ ber unlautere Gescha¨ ftspraktiken im binnenmarktinternen Ge¨ nderung der Richtlinie scha¨ftsverkehr zwischen Unternehmen und Verbrauchern und zur A 84/450/EWG des Rates, der Richtlinien 97/7/EG, 98/27/EG und 2002/65/EG des Europa¨ ischen Parlaments und des Rates sowie der Verordnung (EG) Nr. 2006/2004 des Europa¨ ischen Parlaments und des Rates.

96

Dezentrale Anwendungen der Sharing Economy

nehmer als auch Verbraucher Dienstleistungen anbieten, ist es für den Kunden eine erhebliche Information i. S. d. Art. 7 UGP-Richtlinie, welcher Personengruppe der Anbieter zuzurechnen ist.279 Auch wenn die Sharing Economy auf C2C Verhältnisse ausgerichtet ist, gibt es keine starren Grenzen, wodurch Verbraucher und Unternehmer getrennt werden. Soweit eine Anwendung beiden Personenkreisen zugänglich ist, soll nach der EU-Kommission eine entsprechende Kenntlichmachung zwingend sein. Dies würde zunächst den Verkäufer selbst betreffen, der über seine Identität aufklären muss. Bei den klassischen zentralen Plattformen führe dies aber auch zu einer Pflicht des Plattformbetreibers, das Design der Plattform insoweit anzupassen, dass eine Selbstkenntlichmachung möglich sei.280 Diese Pflicht könnte sich auf den Entwickler der dezentralen Anwendung übertragen lassen, soweit er in einem vergleichbaren Maßstab für das Design der Plattform verantwortlich ist. Dies lässt sich schon mit der ursprünglichen Entwicklung begründen. Wenn bereits zu dem Zeitpunkt absehbar ist, dass die Anwendung nicht nur von Verbrauchern genutzt wird, muss der Entwickler entsprechende Designpflichten übernehmen, sodass der spätere Anbieter von Leistungen in der Lage ist, die entsprechenden Informationen darzustellen. Hieran könnte sich etwas ändern, wenn jeder Anbieter selbst über das Design seiner angebotenen Leistung bestimmt. Dies ist dann der Fall, wenn jeder Anbieter seine eigene Website erstellt, sodass das Design des Frontend-Interfaces letztlich ausschließlich unter dem Einfluss des Anbieters steht und lediglich von den Nodes gespeichert wird. Anwendungen sollten nicht die ursprüngliche Designpflicht des Entwicklers ausschließen. Die hypothetische Möglichkeit, dass es einem Anbieter möglich ist, die Website selbst so anzupassen, dass eine Information möglich ist, setzt einen Kenntnisstand voraus, der nicht dem des durchschnittlichen Anbieters entspricht. Von diesem spezifische informationstechnische Kenntnisse abzuverlangen, geht zu weit. Der Ansatzpunkt muss weiterhin beim cheapest cost avoider liegen.281 Das ursprüngliche Layout stammt vom Entwickler der Anwendung. Dieser ist in der Lage Designelemente zur Kennzeichnung einzubauen. Den Anbietern wird eine ursprüngliche Version vorgegeben, die den Anforderungen des § 3, Anhang Nr. 23 UWG genügt. Die Nodes und Anbieter müssten von diesen Vorgaben bewusst abweichen, wenn keine Angaben über den Status als Ver279 Common position of national authorities within the CPC Network concerning the commercial practices and the terms of service of Airbnb Ireland, https://tinyurl.com/3kcawkc5 abgerufen am 18. 1. 2022, S. 2. 280 Common position of national authorities within the CPC Network concerning the commercial practices and the terms of service of Airbnb Ireland, https://tinyurl.com/3kcawkc5, abgerufen am 18. 1. 2022, S. 3. 281 Grundlegend Calabresi, The Cost of Accidents, S. 135ff.; Taupitz, AcP 1996, 114ff.

Verbraucherschutz

97

braucher oder Unternehmer gemacht werden sollen. Bei einem rechtmäßigen ursprünglichen Design sind die Verstöße der Ausnahmefall. Trotz der technischen Möglichkeit des Anbieters selbst eine Kennzeichnung zu gewährleisten, muss der Entwickler der Anwendung in der ursprünglichen Anwendung eine Kennzeichnung ermöglichen, um nicht gegen § 3, Anhang 3 III Nr. 23 UWG zu verstoßen. 2.

Nodes

Wie für den Entwickler können auch für sonstige Personen Designpflichten entstehen, wenn ansonsten ein Einhalten der verbraucherrechtlichen Vorgaben durch den Unternehmer selbst nicht möglich ist. Auch wenn den Entwickler eine ursprüngliche Designpflicht trifft, muss eine Verantwortlichkeit diskutiert werden, wenn dieser ursprünglichen Pflicht nicht nachgekommen wird oder sich die gesetzlichen Anforderungen nachträglich ändern. Die dezentrale Anwendung wird von den Blockchain-Mitgliedern aufrechterhalten. Die Full-Nodes ermöglichen die Nutzung, indem die Datensätze auf Anfrage vorgehalten und Transaktionen abgewickelt werden. Ohne diese FullNodes ist eine nutzbare Anwendung auf Grundlage einer Blockchain nicht denkbar. An jeder einzelnen Transaktion sind aber nur sehr wenige Full-Nodes beteiligt. Im Wesentlichen lässt sich der Kreis der beteiligten auf das Full-Node begrenzen, das die Daten übermittelt und ein weiteres, dass eine daran anschließende Transaktion abwickelt und bestätigt.282 Auch wenn nur zwei FullNodes beteiligt sind, werden diese, je nach Konsens-Modell, zufällig ermittelt. Keine dieser Parteien kann eigenständig oder in Kooperation mit der anderen ausreichend Einfluss auf die Transaktionen nehmen, um Rechtsverletzungen, ex ante oder ex post, zu verhindern. Die an die Nodes übermittelten Daten sind lediglich sog. Metadaten283, die an sich für den Menschen unverständlich sind. Aus den übermittelten Daten kann der Node-Betreiber keine hinreichenden Informationen ziehen, um auf einen Rechtsverstoß schließen zu können. Es ist ihm aber auch nicht möglich, präventiv Rechtsverstöße zu verhindern, da letztlich die Änderung oder Sperren von Daten nur durch die Mehrheit der Blockchain-Nodes erfolgen kann. Insoweit kann eine Designpflicht nicht auf die einzelnen Nodes bezogen werden. Soweit einzelne Nodes der Designpflicht nachkommen würden, wären auf den sonstigen Nodes immer noch die rechts282 Letzteres der sog. Miner. 283 Arlt in Multimedia Recht (47. EL) 7.7 Rn. 7: »Ziel von Metadaten ist es, Informationen über ein Werk in einer formalen und differenzierten Weise zu beschreiben, so dass diese automatisiert verarbeitet werden können.«; Es handelt sich also um Daten über Daten zur komprimierten Verarbeitung durch Rechner.

98

Dezentrale Anwendungen der Sharing Economy

widrigen Angebote gespeichert und eine Minderheit könnte sich nicht durchsetzen. Der Rechtsbruch würde also mit der Inanspruchnahme der einzelnen Nodes nicht verhindert werden. Wenn eine Pflicht den Blockchain-Mitgliedern auferlegt werden soll, muss diese an die Gesamtheit der Full-Nodes gerichtet sein und kann nicht für jede Transaktion der jeweils Beteiligte zur Verantwortung gezogen werden. Entsprechende Pflichten können also letztlich nur alle Blockchain-Mitglieder gleichermaßen treffen. Wenn der Entwickler seiner ursprünglichen Designpflicht nicht nachkommt, bleiben letztlich zwei mögliche Anknüpfungspunkte für die Unterbindung von Verstößen. Unmittelbar Beteiligter ist letztlich immer der Unternehmer, der einen entsprechenden Vertrag abschließt ohne die notwendigen Informationen gem. Art. 246ff. EGBGB zu übermitteln. Dieser ist gem. § 312 ff BGB der Verpflichtete der Informationspflichten. Unabhängig von weiteren Designpflichten treffen diesen die vertraglichen und lauterkeitsrechtlichen Folgen eines Verstoßes. Dies umfasst neben möglichen Schadensersatzansprüchen und einem denkbaren Anfechtungsgrund, vor allem auch Unterlassungsklagen gem. §§2, 8 UWG.284 Ein erforderliches Vertretenmüssen wird kaum widerlegt werden können, da der Unternehmer nicht durch den Verstoß weiterer Parteien (fehlende Möglichkeit zur Kenntlichmachung auf der Plattform) gegen das Lauterkeitsrecht entlastet wird. Letztlich ist es seine Pflicht, nur solche Verträge abzuschließen, die den gesetzlichen Vorgaben genügen. Darüber hinaus können auch die Blockchain-Mitglieder gegen das Lauterkeitsrecht verstoßen, wenn Sie, vergleichbar zum Plattformbetreiber, verantwortlich sind. Nach der Veröffentlichung der dezentralen Anwendung ermöglichen sie den Zugriff auf deren Inhalte und somit auch auf Angebote ohne ausreichende Information über die Unternehmereigenschaft oder sonstige Informationen der §§ 312ff. BGB. Für eine täterschaftliche Haftung nach dem UWG müssten sie zunächst selbst eine geschäftliche Handlung vornehmen oder an einer entsprechenden beteiligt sein.285 Soweit man auch hier auf § 3 III Anhang Nr. 23 UWG abstellt, kommt mangels Verbraucherkaufvertrag zwischen Nodes und Käufer nur eine Beihilfehandlung in Betracht. Da sich die Handlung des Verkäufers durch die Form der technischen Struktur der Plattform nicht verändert, liegt auch hier unproblematisch die widerrechtliche Haupttat in der fehlenden Information über die Unternehmereigenschaft. Da allein das Aufrechterhalten der Blockchain-Infrastruktur die Nutzung der Anwendung zum 284 Busch in BeckOGK BGB, § 312a Rn. 9f.; Wendehorst in MüKoBGB, § 312a Rn. 38; Koch in Erman BGB, § 312a Rn. 34. 285 Ohly in Ohly/Sosnitza UWG, § 8 Rn. 119.

Verbraucherschutz

99

Vertragsschluss ermöglicht, liegt zumindest ein Fördern der Haupttat vor. Entscheidendes Kriterium ist auch hier der Vorsatz der Nodes bezüglich des konkreten Rechtsverstoßes. Im Gegensatz zum Anwendungsentwickler sind die Nodes aber nicht für die ursprüngliche Gestaltung der Plattform verantwortlich, sodass ein generelles Ausbleiben der Kennzeichnungsmöglichkeit nicht per se zu Lasten der Nodes ausgelegt werden kann. Vielmehr muss der Vorsatz für den individuellen Verstoß eines Anbieters dargelegt werden. Hierfür kann erneut nach den Funktionen der Nodes unterschieden werden. Zunächst kann auf diejenigen abgestellt werden, die die Informationen speichern und für den Abruf bereithalten. Diese erfüllen die gleichen Funktionen wie bisherige Host-Provider im Internet mit dem Unterschied, dass für jede abgerufene Information nicht ein Provider existiert, sondern eine Vielzahl (nämlich die Zahl aller Full-Nodes). Es besteht daher auch kein Bedarf, die Verantwortlichkeit anders als für HostProvider zu bewerten. Sie setzt die Kenntnis des konkreten Angebotes vor Veröffentlichung voraus.286 Daran fehlt es bei einer »permissionless« Blockchain. Das Speichern neuer Informationen wird automatisch veranlasst und lediglich automatisch mit den logischen Voraussetzungen der Anwendung überprüft. Die Nodes führen darüber hinaus keine Einzelprüfung durch, durch welche sie Kenntnis erlangen könnten. Eine Überprüfung ist für das einzelne Node, wenn überhaupt, erst nach dem Speichern in der Blockchain möglich. Mangels Teilnahmevorsatz scheidet eine Haftung wegen eines Verstoßes gegen § 3 III Anhang Nr. 23 UWG aus. Sobald die Informationen durch die Nodes gespeichert und so Teil der dezentralen Anwendung geworden sind, kann eine Haftung, mangels ursprünglicher Kenntnis, nur noch dann vorliegen, wenn eine entsprechende Prüfpflicht für die Inhalte der dezentralen Anwendung besteht. a. Nodes als Host-Provider Damit können die Nodes im Rahmen ihrer Funktion als Host-Provider nur noch für eine eigene Verletzung von Verkehrssicherungspflichten haften.287 Rechtsgrundlage für eine lauterkeitsrechtliche Verantwortlichkeit im Rahmen von Verkehrssicherungspflichten gegenüber Verbrauchern ist § 3 II UWG.288 Selbst beim unentgeltlichen Betreiben eines Nodes ergibt sich die unternehmerische Tätigkeit aus der Förderung des Absatzes eines anderen Unternehmens.289 Allerdings verlangt § 3 II UWG die Verletzung einer unternehmerischen Sorg286 BGH, Urt. v. 11. 3. 2004 -I ZR 304/01, GRUR 2004, 860, 864. 287 BGH Urt. v. 25. 10. 2011 -VI ZR 93/10, GRUR 2012, 311 Rn. 22, 25ff.; Fritzsche in MüKo LautR, § 8 UWG Rn. 275. 288 Köhler/Feddersen in Köhler/Bornkamm/Feddersen UWG, § 8 Rn. 2.8f. 289 Vgl. für unentgeltliche Absatzförderung: Köhler/Feddersen in Köhler/Bornkamm/Feddersen UWG, § 8 UWG Rn. 2.7.

100

Dezentrale Anwendungen der Sharing Economy

faltspflicht, welche wiederum durch § 2 I Nr. 7 UWG einen Unternehmer voraussetzt. Im Gegensatz zu Haftung als Gehilfe der Plattformen und des Anwendungsentwicklers müssen die Nodes selbst Unternehmer i. S. d. UWG sein, damit überhaupt Sorgfaltspflichten gegenüber Verbrauchern bestehen. Der Normadressat muss selbstständig entgeltliche Leistungen erbringen.290 Dies ist bei Nodes, die der Speicherung der dezentralen Anwendung dienen, nicht der Fall. Sie erhalten für ihre Teilnahme an der Blockchain keine wirtschaftliche Gegenleistung. Im Gegensatz zu den Minern erhalten sie weder eine Vergütung aus Schaffung neuer originärer Token, noch werden sie im Rahmen der Transaktion zwischen Anbieter und Nutzer entlohnt. Die Nodes sind vielmehr in aller Regel einfach Nutzer, die sich die Anwendung heruntergeladen haben. Auch wenn es ggf. mehrere unterschiedliche Formen von Nodes geben kann, abhängig vom Datenumfang, ist die Eigenschaft des Nodes in irgendeiner Form die Voraussetzung zur Teilnahme an der dezentralen Anwendung. Die sich daraus ergebenden Vorteile, insbesondere die Nutzungsmöglichkeit und Mitbestimmungsrechte in der Blockchain, genügen nicht für die Entgeltlichkeit. Nutzungsmöglichkeit und Mitbestimmungsrecht im Gegenzug für das Bereithalten der Informationen sind keine Vermögenswerte.291 Die Nodes sind somit keine geeigneten Täter im Rahmen von Verkehrssicherungspflichten und können für einen Verstoß auch nicht in Anspruch genommen werden. Mangels eines absoluten Rechtsgutes im Rahmen der Verbraucherschutznormen, §§ 312ff. BGB, kommt auch keine Störerhaftung aus dem allgemeinen Zivilrecht gem. § 1004 BGB (analog) in Betracht.292 b. Miner Neben der Funktion als Host-Provider betätigen sich einige Nodes auch als Miner, indem sie die Transaktionen bestätigen. Hierbei erlangen sie weitergehende Informationen, indem ihnen als erste die Transaktionsdaten übermittelt werden, die für eine Verifizierung erforderlich sind. Dies beschränkt sich bisher aber auf die Wallet-Informationen des Anbieters und des Kunden, sowie das zu entrichtende Entgelt. Insoweit fällt ihnen neben der sonstigen Funktion als Node auch die Funktion der Zahlungsabwicklung zu. Hierfür werden sie von der dezentralen Anwendung oder von den beteiligten Parteien in Form von Token entlohnt. Im Gegensatz zu den sonstigen Nodes erhalten sie ein Entgelt für ihre Leistungen. Damit verschiebt sich auch die Bewertung der Unternehmereigenschaft. Diese kann nicht mehr bloß aufgrund der Unentgeltlichkeit abgelehnt 290 Bähr in MüKo LautR, § 2 UWG Rn. 319ff.; Erdmann/Pommerening in Loschelder/Danckwerts Hdb. Wettbewerbsrecht, § 35 Rn. 9ff. 291 Vgl. Alexander in BeckOGK BGB, § 14 Rn. 140. 292 Fritzsche in MüKo LautR, § 8 UWG Rn. 259.

Verbraucherschutz

101

werden. Im Gegensatz zu § 14 BGB wird die Unternehmereigenschaft des § 2 I Nr. 6 UWG anhand des Art. 2 UGP-Richtlinie richtlinienkonform ausgelegt und verlangt ausschließlich die auf Dauer angelegte entgeltliche Tätigkeit.293 Damit handeln auch die Miner als Unternehmer i. S. d. § 2 Nr. 6 UWG und unterliegen somit der unternehmerischen Sorgfalt des § 2 Nr. 7 UWG. Sie könnten eine unlautere Handlung gem. § 3 II UWG begehen. Für die Verantwortlichkeit aufgrund von Verkehrspflichten ist es erforderlich, dass von dem Verhalten des Unternehmers die ernsthafte Gefahr eines Verstoßes gegen das Lauterkeitsrecht durch Dritte ausgeht und der betroffene Personenkreis schutzbedürftig ist.294 Die ernsthafte Gefahr kann eine Erstbegehungs-oder Wiederholungsgefahr sein.295 Eine Gefahr wird schon dadurch begründet, dass eine Kennzeichnung durch Unternehmer in der dezentralen Anwendung nicht möglich ist. Solange Unternehmern der Zugang zur Anwendung gewährt wird, besteht eine Gefahr der Verletzung des Lauterkeitsrecht. Bei neutralen Plattformdienstleistern darf allerdings ein von der Rechtsordnung gebilligtes Geschäftsmodell nicht unverhältnismäßig erschwert werden.296 Als keine unverhältnismäßige Einschränkung wird beispielsweise die Designpflicht zur Ermöglichung der Impressumspflicht angesehen.297 Zwischen der Impressumspflicht und der Pflicht zur Kennzeichnung als Unternehmer besteht kein struktureller Unterschied. Auch die Umsetzung der beiden Verpflichtungen ist vergleichbar. Allerdings sind die Miner in diesen Punkten nicht mit den Internetplattformen gleichzustellen. Unabhängig von der schwere des Rechtsverstoßes durch Dritte setzt eine Verkehrspflicht die Möglichkeit der Gefahrenabwehr voraus.298 Hieran scheitert es beim Miner. Diesem ist es weder möglich, die Verletzungshandlung zu erkennen, da ihm hierfür nur unzureichende Informationen vorliegen, noch kann er eigenständig eine entsprechende Designpflicht umsetzen. Änderungen im Front-End der Anwendung sind auch in diesem Punkt nur durch eine Mehrheit der Nodes möglich. Dem Miner ist es weder alleine, noch gemeinsam mit allen anderen Minern (es sei denn sie bilden gleichzeitig die Mehrheit der Nodes) möglich, ein entsprechendes Design in der Anwendung durchzusetzen. Insoweit bliebe es den 293 EuGH, Urt. v. 3. 10. 2013-C-59/12, GRUR 13, 1159 Rn 31f–BKK Mobil Oil; BGH Urt. v. 30. 4. 2014-I ZR 170/10, GRUR 14, 1120 Rn 20–Betriebskrankenkasse II; Urt. v. 22. 1. 2014-I ZR 218/ 12, GRUR 14, 682 Rn 17–Nordjob-Messe. 294 Fritzsche in MüKo LautR, § 8 UWG Rn. 258ff.; Köhler/Feddersen in Köhler/Bornkamm/ Feddersen UWG, § 8 Rn. 2.8ff. 295 BGH, Urt. v. 12. 7. 2007 -I ZR 18/04, GRUR 2007, 890, 895. 296 BGH Urt. v. 30. 4. 2008 -I ZR 73/05, GRUR 2008, 702 Rn. 51 ff. – Internet-Versteigerung III; BGH Urt. v. 22. 7. 2010 -I ZR 139/08, GRUR 2011, 152 Rn. 38 – Kinderhochstühle im Internet I; BGH Urt. v. 12. 7. 2012 -I ZR 18/11, WRP 2013, 332 Rn. 28. 297 OLG Düsseldorf Urt. v. 18. 6. 2013-I-20 U 145/12, WRP 2013, 1221 Rn. 25. 298 Köhler/Feddersen in Köhler/Bornkamm/Feddersen UWG, § 8 Rn. 2.10; BGH Urt. v. 22. 7. 2010 -I ZR 139/08, GRUR 2011, 152, 154 – Kinderhochstühle im Internet I.

102

Dezentrale Anwendungen der Sharing Economy

Minern nur übrig, sämtliche Transaktionen ohne Angabe eines unternehmerischen oder privaten Bezugs abzulehnen und nicht durchzuführen. Bei einer dezentralen Anwendung, die eine entsprechende Kennzeichnung nicht möglich macht, würde dies die Ablehnung sämtlicher Transaktionen zur Folge haben. Dadurch würde sowohl die Tätigkeit der Miner vollständig eingeschränkt, als auch eine Nutzung der dezentralen Anwendung durch Private, obwohl sie keinen Verstoß gegen das Lauterkeitsrecht begehen. 3.

Verantwortlicher i. S. d. Gesetzes über digitale Dienste

Art. 22 des Gesetzes über digitale Dienste (DSA) sieht eine entsprechende Designpflicht in Abs. 7 vor. Verpflichteter ist danach die »Online-Plattform«. Dem Wortlaut nach könnte dies sowohl den Entwickler als auch die Node-Betreiber erfassen. Art. 2g) beschreibt die Online-Plattform lediglich als Hosting-Diensteanbieter, der im Auftrag des Nutzers Informationen speichert und öffentlich verbreitet. Einerseits sind die Nodes für die Speicherung verantwortlich, andererseits der Entwickler für die öffentliche Verbreitung. Die Nodes und der Entwickler teilen sich somit die definierenden Eigenschaften einer Online-Plattform nach dem Gesetz über digitale Dienste. Da zwischen Nodes und Entwickler mit der Veröffentlichung der Blockchain mit der Veröffentlichung eine klare zeitliche Trennung liegt, sollte die Online-Plattform nach der Systematik der jeweiligen Norm ausgelegt werden. Damit kann auch dem Wortlaut gerecht werden, der nur von »einer« Online-Plattform ausgeht. Zu jeder Zeit liegt nur eine OnlinePlattform vor. Der damit angesprochene Adressat unterscheidet sich aber abhängig vom Zeitpunkt der Inanspruchnahme. Für Art. 22 ist somit anhand der Systematik zu bestimmen, ob die Pflicht vor oder nach Veröffentlichung zu erfüllen ist und somit der Entwickler oder die Nodes als Online-Plattform gemeint sind. Laut Art. 22 Abs. 7 soll die OnlinePlattform die Online-Schnittstelle so konzipieren und organisieren, dass eine Selbstkennzeichnung möglich ist. Die Formulierung des Konzipierens und Organisierens stellt auf den Zeitpunkt der Entwickung der Online-Schnittstelle an. Bereits bei der Entwicklung ist die Schnittstelle nach den Vorgaben des DSA zu programmieren. In zeitlicher Hinsicht wird somit konkret der Entwickler als Online-Plattform i. S. d. Art. 22 Abs. 7 DSA angesprochen.

III.

Zwischenergebnis

Zwar lassen sich mit dem Lauterkeitsrecht auch bei dezentralen Anwendungen Vermittler in Anspruch nehmen, allerdings nur der Anwendungsentwickler. Seine Einflussnahme ist wiederum auf den Zeitpunkt der Veröffentlichung der

Verbraucherschutz

103

Blockchain begrenzt. Nach diesem Zeitpunkt kann nach geltendem Recht keiner der Beteiligten der Blockchain, mit Ausnahme des Anbieters, für Verstöße gegen das Verbraucherrecht in Anspruch genommen werden. Vor Veröffentlichung besteht keine Einsichtsmöglichkeit in die Anwendung, sodass sämtliche Maßnahmen und Ansprüche ausschließlich repressiver Natur sein können. Dies mag zwar beim Entwickler einen Anreiz schaffen, das Design an geltendes Recht anzupassen, löst aber weder die Probleme von Änderungen der Rechtslage und der dadurch notwendigen Anpassung des Designs noch die Verstöße nach Veröffentlichung der Blockchain. Insbesondere ist auch das UWG nicht geeignet, den Anwendungsentwickler zu einem rechtmäßigen Verhalten zu zwingen. Der Unterlassungsanspruch des § 8 UWG mag für künftige dezentrale Anwendungen relevant sein, setzt aber voraus, dass weitere Anwendungen vom gleichen Entwickler veröffentlicht werden. Der Beseitigungsanspruch läuft hier ins Leere, da keine Möglichkeit zur Rücknahme oder Anpassung der Blockchain durch den Entwickler besteht. Am vielversprechendsten scheint noch ein Anspruch auf Gewinnabschöpfung gem. § 10 UWG, der durch die Verbraucherverbände geltend gemacht werden kann.299 Allerdings besteht hier das Problem, den kausal erwirtschafteten Gewinn zu bestimmen. Der Gewinn des Anwendungsentwicklers wird durch das ICO erwirtschaftet. Zu diesem Zeitpunkt besteht aber in der Regel noch keine funktionierende DApp; sie befindet sich lediglich im Entwicklungsstadium. Die Gewinne durch Veräußerung von Token im ICO, die zeitlich vor der Verletzung von Verbraucherrechten liegen, können aber nicht kausal durch sie verursacht sein. Der Anspruch ist im Ergebnis nur dort zielführend, wo nachträglich rechtswidrige Funktionen in die dezentrale Anwendung integriert werden. Der Entwickler der Anwendung als solcher ist somit auch im Rahmen des § 10 UWG weitestgehend vor einer Inanspruchnahme sicher. Soweit der DSA eingeführt wird, zeigt sich eine neue Möglichkeit, wie zwischen Entwickler und Nodes bei einer Inanspruchnahme sauber differenziert werden kann. Bei Pflichten, die eindeutig einem Zeitpunkt vor oder nach Veröffentlichung zugeordnet werden kann, kann unter den gleichen rechtlichen Begriff der Entwickler oder die Nodes subsumiert werden, ohne dass die Grenzen der Auslegung überschritten werden müssen.

299 Zur umfassenden Kritik am § 10 UWG: Ohly in Ohly/Sosnitza UWG, § 10 Rn. 3; Micklitz in MüKo LautR, § 10 UWG Rn. 186; Podszun/Busch/Henning-Bodewig, Beho¨ rdliche Durchsetzung des Verbraucherrechts?, https://tinyurl.com/ym9kf6rb, S. 151ff.

104

§8

Dezentrale Anwendungen der Sharing Economy

Haftung

Essentieller Bestandteil für ein neues Geschäftsmodell sind für alle Beteiligten die damit einhergehenden Haftungsrisiken. Während der Entwickler die Haftung bei der Kalkulation seiner Investition berücksichtigen muss, um gegebenenfalls Anpassungen am bisherigen Modell vorzunehmen, ist es für den Nutzer maßgeblich für die Bildung des erforderlichen Vertrauens. Gerade bei einer Technologie, die bisher vor allem mit dem spekulativen Charakter von Bitcoin in Verbindung gebracht wird, ist die eindeutige Verteilung von Risiken geeignet, um Vertrauen bei Nutzern aufzubauen. Die möglichen Schadensrisiken werden am konkreten Beispiel der DAO (dezentralised autonomous organisation) deutlich. Hier führte ein fehlerhaft programmierter Smart Contract, der es Dritten ermöglichte, Token zu entwenden, zu einem Schaden von über 50 Mio US-$.300 Dieses Beispiel illustriert auch unmittelbar die zwei wesentlichen Probleme, die mit einem fehlerhaften Code dezentraler Anwendungen verbunden sind. Der Schadensumfang ist kaum vorhersehbar, und es handelt sich auf den ersten Blick um die Verletzung reiner Vermögensinteressen, die nur im Rahmen vertraglicher Schadensersatzansprüche ersatzfähig sind. Es gilt also, den Verursacher der Schäden und eine Anspruchsgrundlage zu finden. Der Anspruchsgegner muss nach den allgemeinen Grundsätzen der Zurechnung bestimmt werden, während Anspruchsgrundlagen neben den allgemeinen Schadensersatznormen des BGB auch im Produkthaftungsgesetz zu suchen sind.

I.

Haftung des Entwicklers

Zur Vereinfachung der Darstellung wird bei der Haftung zunächst zwischen dem Entwickler und den Nodes unterschieden. Neben der Vereinfachung entspricht diese Aufteilung auch der chronologischen Abfolge der Haftung. Während die Verantwortlichkeit des Entwicklers bereits vor Veröffentlichung der dezentralen Anwendung beginnt, sind die Nodes erst nach der Veröffentlichung der Anwendung an dieser beteiligt und können dementsprechend auch erst ab dem Zeitpunkt der Veröffentlichung verantwortlich sein.

300 Es wurden insgesamt 3,5 Mio. Ether entwendet, deren Zeitwert 50 Mio. $ entsprach.Nach heutigem Kurs wäre es sogar ein Wert von über 3,5 Mrd. €, https://tinyurl.com/3hmxapzj, abgerufen am 18. 1. 2021.

Haftung

1.

105

Vertragliche Haftung

Die vertraglichen Haftungsgrundlagen der §§ 280ff. BGB sind insoweit vorzuziehen, als durch sie Vermögensinteressen am umfassendsten geschützt sind. Zwingende Voraussetzung ist das Bestehen eines Vertragsverhältnisses zwischen dem Geschädigten und dem Entwickler der Blockchain. a. Vertragliche Beziehungen bei Überlassung der DApp Geschädigter ist in jedem Fall auch Nutzer der Blockchain, da ansonsten eine Bezahlung mittels Token nicht möglich wäre. Auch wenn die Anwendung dezentral gestaltet ist, handelt es sich im Kern immer noch um eine App und damit um Software.301 Dementsprechend unterscheiden sich die möglichen Vertragstypen und -beziehungen nicht wesentlich von den bereits bekannten. Grundsätzlich sind die allgemeinen Grundlagen des Vertragsschlusses zu berücksichtigen und nach den §§ 133, 157 (analog) zu bestimmen, ob und zwischen wem Willenserklärungen abgegeben werden und damit vertragliche Beziehungen entstehen. aa. Lizenzvertrag Zunächst könnte als Schuldverhältnis ein Lizenzvertrag in Frage kommen. Da das Urheberrecht selbst nicht gem. § 29 I UrhG übertragbar ist, muss der Urheber (in diesem Fall Entwickler) zwangsläufig zumindest konkludent ein Nutzungsrecht einräumen.302 In diesem Rahmen liegt dementsprechend auch ein Schuldverhältnis zwischen dem Entwickler und einem Nutzer vor. Dies kann aber letztlich nicht zur Begründung von Schadensersatzansprüchen für Fehler der Anwendung führen. Hierfür fehlt es zunächst an der Kausalität zwischen Pflichtverletzung und Schaden.303 Die Pflichten des Lizenzgebers umfassen zwar auch die Schutzpflichten des § 241 II BGB, diese erstrecken sich aber nicht auf die inhaltlichen Anforderungen der Anwendung. Stattdessen muss der Lizenzgeber auf die Interessen des Lizenznehmers nur insoweit Rücksicht nehmen, wie diese im Zusammenhang mit dem Lizenzvertrag stehen. Schäden aus dem fehlerhaften Code der Anwendung resultieren zwar aus der Nutzung der Software, nicht aber aus der Rechtmäßigkeit dieser Nutzung. Dieselben Schäden würden auch dann entstehen, wenn die Software ohne Berechtigung des Urhebers genutzt werden würde. Insoweit kann die Gegenüberlegung überzeugen, dass der Urheber ansonsten lieber die widerrechtliche Nutzung billigen würde. Ohne Lizenzvertrag 301 Vgl. OLG Köln, Urt. v. 8. 4. 2005-6 U 194/04, GRUR-RR, 2005, 303, 304; Mössner in BeckOGK BGB, § 90 Rn. 79.1. 302 A.Nordemann in Loewenheim Hdb UrhG, § 23 Rn. 2ff.; J.B.Nordemann in Fromm/Nordemann UrhG, § 29 Rn. 7f. 303 Koglin, Opensourcerecht, S. 179.

106

Dezentrale Anwendungen der Sharing Economy

bestünde kein Schuldverhältnis und somit auch kein vertraglicher Schadensersatzanspruch. Dies würde letztlich dem Charakter des Urheberrechts als Schutzgesetz zugunsten des Urhebers widersprechen.304 Die mangelnde Übertragbarkeit des Urheberrechts soll diesen gerade vor der widerrechtlichen Nutzung schützen und nicht zu einer solchen zwingen. Die Haftung kann demnach nicht an den Lizenzvertrag, sondern nur an einen Überlassungsvertrag der Software selbst angeknüpft werden. bb. Vertragspartner bei Verwendung eines App-Stores Die vertraglichen Verhältnisse lassen sich jedoch insoweit vereinheitlicht betrachten, als ein App-Store zum Beziehen der Anwendung verwendet wird. Hierbei wird im Umfeld eines generellen App-Stores die DApp heruntergeladen. Dies läuft identisch zu einer bisherigen App ab, sodass der Nutzer in der Regel ein Logo der App sieht, ggf. beim Anklicken mit Leistungsbeschreibung und neben diesem Logo auf »herunterladen/installieren« klicken kann. Dabei kann bei den beiden marktstärksten Stores »GooglePlay« und Apples »App-Store« noch danach differenziert werden, dass bei Google zunächst die Anwendungsbeschreibung in jedem Fall vor dem Installieren geöffnet werden muss, während es bei Apple auch möglich ist, direkt aus einer Liste ohne nähere Beschreibung die Anwendung herunterzuladen. Bezüglich der vertraglichen Beziehungen beim App-Download über einen App-Store gibt es einen gesicherten Meinungsstand in der Literatur, der auch für die Überlegungen zu DApps fruchtbar gemacht werden kann. 1) Empfängerhorizont des Nutzers Entscheidend für den Nutzer ist die Identität des Vertragspartners. In Betracht kommen sowohl der Store-Betreiber als auch der Entwickler der Anwendung. Auszulegen ist aus Sicht eines objektiven Empfängers §§ 133, 157 BGB. Hierbei kollidieren zwei Wahrnehmungen auf Seiten des Nutzers. Einerseits befindet er sich im generellen Umfeld des App-Stores. Wenn auch nicht ausdrücklich, so erkennt er auf Grund der Markenzeichen, in welchem App-Store er sich befindet. Hieraus geht zunächst die generelle Erwartungshaltung hervor, dass rechtsgeschäftliche Handlungen ohne weitere Angaben vom App-Store Betreiber ausgehen. Andererseits wird ihm bei jeder App der Entwickler der Anwendung genannt. Die Nennung des Entwicklers neben dem Symbol der Anwendung soll nach einer Meinung in der Literatur nicht genügen, um den objektiven Empfängerhorizont dahingehend zu verändern, dass der Nutzer von einem Vertrag mit dem

304 Hierzu ausführlich Koglin, Opensourcerecht, S. 179ff.

Haftung

107

Entwickler statt mit dem App-Store-Betreiber ausgeht.305 Bei den meist verbreiteten Stores wird regelmäßig nicht hinreichend informiert, um erkennbar zu machen, dass der Entwickler der App Vertragspartner werden soll.306 Hiergegen werden unterschiedliche Argumente vorgebracht, die eine andere Auslegung des objektiven Empfängerhorizontes rechtfertigen sollen. Teilweise wird zur Auslegung auch auf den Bestell- und Bezahlvorgang abgestellt.307 Dies hilft aber im konkreten Fall von DApps nicht weiter, da diese unentgeltlich angeboten werden. Beim unentgeltlichen Herunterladen von Apps erscheint üblicherweise kein gesondertes Rechnungs- oder Bestellfenster. Stattdessen kann unmittelbar in der Beschreibung der App auf Herunterladen geklickt werden, ohne dass weitere Informationen zum Vertragspartner erscheinen. Bei diesem Vorgang kann das bloße Nennen des Entwicklers neben der App nicht ausreichen, um die Erwartungen des Nutzers zu verändern. Dieser kann berechtigterweise davon ausgehen, dass es sich hierbei lediglich um eine Beschreibung des Produktes handelt, nicht aber zum Wechsel des Vertragspartners führt. Um im Rahmen der Auslegung doch noch zur Annahme des Entwicklers als Vertragspartner zu kommen, verbleibt die Berücksichtigung der AGB des AppStore Betreibers (sog. Auslegungslösung).308 Dies setzt natürlich voraus, dass der App-Store-Betreiber entsprechende AGB verwendet, in denen er Ausführungen zum Vertragspartner macht. Wenn die AGB vorsehen, dass der App-Store-Betreiber nicht Vertragspartner wird, handelt es sich letztlich um AGB eines Dritten. In wie weit diese überhaupt beim Vertragsschluss zwischen Entwickler und Nutzer zu berücksichtigen sind, ist bereits aus Diskussionen zu Online-Auktionsplattformen bekannt. Hier entschied schon der BGH im Jahr 2001, dass ein Rückgriff auf die AGB des Plattformbetreibers zum Zwecke der Auslegung in Betracht komme, wenn Erklärungen nicht aus sich selbst heraus verständlich seien.309 Zur Plattform »ebay« wurde diese Rechtsprechung vertieft und konkretisiert, um vermeintlich »unfaire« Praktiken der Teilnehmer zu unterbinden.310 Dieser »Auslegungslösung« schließt sich letztlich auch die Literatur an.311

305 Kremer in Auers-Reinsdorff/Conrad Hdb. IT-und Datenschutzrecht, § 28 Rn. 15; Kremer, CR 2011, 769, 770ff.; Feldmann, DSRITB 2011, 47 (50). 306 Kremer in Auers-Reinsdorff/Conrad Hdb. IT-und Datenschutzrecht, § 28 Rn. 15. 307 Ewald in Kilian/Heussen, Computerrechts-Handbuch, Rn. 52ff.; z. T. auch Lachenmann, ITRB 2015, 99f. 308 Buhl, Der App-Download, S. 111f. 309 Noch zur Plattform ricardo.de: BGH, Urt. v. 7. 11. 2001 -VIII ZR 13/01, MMR 2002, 95, 96f. 310 So im Ansatz bereits: LG Berlin, Urt. v. 20. 7. 2004-4 O 293/04, NJW 2004, 2831f.; zur vorzeitigen Loslösung von einem Angebot/ Auktion: BGH, Urt. v. 10. 12. 2014 – VIII ZR 90/14, NJW 2015, 1009, 1010f.; zum »shell bidding«: BGH, Urt. v. 24. 8. 2016 – VIII ZR 100/15, NJW 2017, 468, 469; zur Abweichung von den Plattform-AGB: BGH, Urt. v. 24. 8. 2016 – VIII ZR 100/15, NJW 2017, 1660, 1661.

108

Dezentrale Anwendungen der Sharing Economy

Berücksichtigt man, dass die AGB der Plattform in jedem Fall im Rahmen des Nutzungsvertrages, sowohl vom Anbieter, als auch vom Nutzer, akzeptiert werden müssen, spricht auch nichts gegen eine Übertragung dieser Auslegungslösung auf App-Stores.312 Bei dieser werden die Erklärungen des Anbieters und des Nutzers der Plattform vor dem Hintergrund der AGB des Plattformbetreibers ausgelegt, da beide Parteien den AGB gegenüber dem Plattformbetreiber zugestimmt haben.313 Somit kann die jeweils andere Partei nach dem objektiven Empfängerhorizont auch erwarten, dass im Zweifel ohne entgegenstehende Angaben die AGB Grundlage der Willenserklärung sind. Dennoch wird ein Rückgriff auf die AGB für App-Stores teilweise abgelehnt.314 Worin die Differenzierung von App-Stores und sonstigen Online-Plattformen liegen soll, wird hierbei jedoch nicht deutlich. Wie auch bei sonstigen Plattformen muss es auf den objektiven Empfängerhorizont ankommen, der sich nicht kategorisch für ein bestimmtes Geschäftsmodell ablehnen lässt. Insbesondere verkennt diese Meinung, dass es sich bei der Heranziehung der AGB nicht um eine »Einbeziehung« im strengen Sinne der §§ 305ff. BGB handelt, sondern eben nur um eine Auslegungshilfe. Die daraus resultierende fehlende Möglichkeit der Inhaltskontrolle, ist entgegen Stimmen der Literatur315 kein Hindernis für die Auslegungslösung. Zum einen findet eine Überprüfung der AGB bereits bei der Vereinbarung der Nutzungsvereinbarungen statt, also zwischen Store-Betreiber und Nutzer. Auch wenn die Klauselverbote der §§ 308ff. BGB nicht auf Mehrpersonenverhältnisse zugeschnitten sind, so kann doch eine Überprüfung anhand von § 307 BGB erfolgen. Zum anderen handelt es sich nur um eine Auslegungsgrundlage. Den AGB kommt keine verbindliche Regelung zu. Die AGB werden nur berücksichtigt, wenn sie auch mit dem objektiven Empfängerhorizont des Nutzers übereinstimmen. Solange der Store-Betreiber AGB in seinen Nutzungsbedingungen aufführt, die Rückschlüsse auf den Vertragspartner zulassen, sind diese im Rahmen der Willenserklärung bei der Auslegung nach §§ 133, 157 (analog) zu berücksichtigen. Allerdings sind entsprechende AGB keine Selbstverständlichkeit. Selbst wenn es hierzu Regelungen gibt, sind diese nicht immer hinreichend eindeutig, um hierüber zu einem eindeutigen Ergebnis bei der Auslegung zu kommen. Genauso wenig können die AGB alleine dazu führen, dass der App-Store-Betreiber in keinem Fall Vertragspartner wird. Auch hier kann die Ausgestaltung 311 Pfeiffer, NJW 2017, 1437; Wagner/Zenger, MMR 2013, 343; Deutsch, MMR 2004, 586; wobei auch diverse Probleme i. V. m. dieser Lösung diskutiert werden, insbesondere im Rahmen von Abweichungen von AGB. 312 Näher hierzu: Buhl, Der App-Download, S. 38ff. 313 Neubauer/Steinmetz in Hoeren/Sieber/Holznagel Hdb. Multimedia-Recht, Teil 14 Rn. 24. 314 Kremer in Auer-Reinsdorff/Conrad Hdb. IT-und Datenschutzrecht, § 28 Rn. 16. 315 Spindler, ZIP 2001, 809, 811; Rüfner, MMR 2000. 597, 598; Wiebe, MMR 2001, 105, 110.

Haftung

109

des App-Stores dazu führen, dass entgegen den AGB nach objektivem Empfängerhorizont eine Willenserklärung des Store-Betreibers vorliegt. Es bleibt festzuhalten, dass das bloße Nennen des Anbieters/Entwicklers neben der DApp nicht ausreichen kann, um den objektiven Empfängerhorizont dahingehend zu verändern, dass es sich um ein Angebot des Entwicklers handeln soll. Die Nennung des Entwicklers ist letztlich nur eine bloße Produktinformation, die für die Nutzer, unter anderem in Hinblick auf die zu erwartetende Qualität, relevant ist. Da es sich um eine relevante Produktinformation handelt, muss der Nutzer aber nicht davon ausgehen, dass der Entwickler sein Vertragspartner ist. Wird in den AGB deutlich hervorgehoben, dass der Entwickler Vertragspartner werden soll und widerspricht der Auftritt im App-Store dieser Annahme nicht (bspw. fehlende Angabe des Entwicklers), so kann die Erklärung des Nutzers objektiv nur dahingehend verstanden werden, dass dieser einen Vertrag mit dem Entwickler eingehen möchte.316 2) Rechtsbindungswille des Entwicklers Nun ist zwar geklärt, wie sich die Person des Vertragspartners bestimmt. Zum Vertragsschluss gehört aber auch der Rechtsbindungswille beider Vertragsparteien, bestimmt nach dem objektiven Empfängerhorizont. Ein Rechtsbindungswille liegt nur vor, wenn für einen verständigen Dritten erkennbar ist, dass mit der Erklärung eine Bereitschaft zur vertraglichen Bindung besteht.317 Hieran könnten aufgrund der Unentgeltlichkeit des Downloads Zweifel bestehen, wobei die Unentgeltlichkeit allein nur ein Indiz sein kann. Maßgeblich ist die wirtschaftliche und rechtliche Bedeutung sowie die generelle Interessenlage der Parteien.318 Besonders relevant als Anhaltspunkte für einen Rechtsbindungswillen sind bei DApps die für den Leistenden erkennbaren, aus einer mangelhaften Leistung resultierenden, Gefahren und das eigene rechtliche oder wirtschaftliche Interesse des Leistenden.319 Hier unterscheidet sich die DApp teilweise von anderen Apps. Der Entwickler hat gerade nicht die Möglichkeit die DApp gegen Entgelt zu vertreiben, und diese Möglichkeit steht ihm

316 Im Ergebnis ebenso: Klein/Datte, CR 2016, 587, 588ff.; diess. CR 2017, 174, 175; Lenz, Rechtliche Stellung von App-Stores, S. 68. 317 Zu unentgeltlichen Leistungen BGH, Urt. v. 17. 5. 1971 -VII ZR 146/69, NJW 1971, 1404, 1405; generell Möslein in BeckOGK BGB, § 145 Rn. 111; Busche in MüKoBGB, § 145 Rn. 7. 318 BGH Urt. v. 06-07-1995 -III ZR 176/94, NJW 1995, 3389; BGH, Urt. v. 22. 6. 1956 -I ZR 198/54, NJW 1956, 1313f. 319 BGH, Urt. v. 22. 6. 1956 -I ZR 198/54, NJW 1956, 1313f.; RG Urt. v. 30. 04. 1936 -VI 447/35, RGZ 151, 203, 208.

110

Dezentrale Anwendungen der Sharing Economy

erst recht nicht zu einem späteren Zeitpunkt zur Verfügung.320 Auch das Bilden einer Marke ist insoweit nicht unmittelbar zielführend, da auch weitere DApps nicht gegen Entgelt vertrieben werden können.321 Dennoch verfolgt der Anbieter ein eigenes wirtschaftliches Interesse. Indem innerhalb der DApp nur mit Token Transaktionen abgewickelt werden können, schafft er durch Vertrieb der DApp eine Nachfrage für diese Token, die er er zumindest zu Beginn als einziger abietet. Durch die Verbreitung der DApp fördert er also den Verkauf seiner Token gegen Entgelt. Auch die Risiken einer mangelhaften Leistung sind dem Entwickler hinreichend bekannt. Je nach Ausrichtung schafft der Entwickler mit der DApp eine Aktionsplattform, die in Konkurrenz zu herkömmlichen Apps der Sharing Economy tritt. Indem Transaktionen nur über die Anwendung mittels Token erfolgen können, leistet der Entwickler die Infrastruktur für Anwendungen, die gemessen an den korrespondierenden Unternehmen in der Sharing Economy einen Milliarden-Umsatz ermöglichen.322 Damit einhergehend können auch die Schäden aus einem fehlerhaften Programmcode den Umfang von mehreren Millionen überschreiten, wie das Negativbeispiel der DAO gezeigt hat.323 Auch wenn das Anbieten der DApp selbst eine unentgeltliche Leistung ist, handelt es sich aufgrund des erheblichen eigenen wirtschaftlichen Interesses des Entwicklers und erheblichen Risiken einer fehlerhaften DApp nicht um ein reines Gefälligkeitsverhältnis. Vielmehr lässt das Vertreiben der DApp über einen App Store einen Rechtsbindungswillen erkennen, sodass ein Schuldverhältnis mit Schutzpflichten zwischen Entwickler und Nutzer entsteht. 3) Erklärung des App-Store-Betreibers Nach Analyse der Handlungen des Nutzers und des Entwicklers verbleibt noch das Verhalten des App-Store-Betreibers. An dieser Stelle soll nicht vertieft werden, über welche Vertretungsketten der App-Store-Betreiber an der Abgabe der Willenserklärung des Entwicklers beteiligt ist.324 Es sei nur angemerkt, dass der kategorische Ausschluss einer Botenstellung nicht vollständig überzeugt. Wenn der Entwickler ein Angebot abgibt, dann ist es in der gesamten Produktbe-

320 Vgl. hierzu die Annahme von Oberhem, die deswegen von einem Rechtsbindungswillen bei App-Entwicklern ausgeht: Oberhem, Vertrags-und Haftungsfragen bei Open-Source Software, S. 96. 321 Oberhem, Vertrags-und Haftungsfragen bei Open-Source Software, S. 96. 322 Uber, Bericht zu: Weltweiter Umsatz von Uber im Zeitraum der Jahre 2013 bis 2018 (in Milliarden US-Dollar) durch Statista: https://tinyurl.com/4advnjhc abgerufen am 22. 10. 2019. 323 Https://tinyurl.com/2a94rmpb, abgerufen am 18. 1. 2021. 324 Siehe dazu: Buhl, S. 46ff.

Haftung

111

schreibung zu sehen.325 Nicht ausreichend ist hingegen die bloße Darstellung der App im App Store. Hierbei mag zwar die Reichweite der Erklärung bestimmt werden, der Inhalt wird aber nicht verändert. Die Erklärung, die dem Nutzer zugeht, wird also allein durch den Entwickler bestimmt. Dies ist der klassische Fall einer Botenstellung.326 Soweit dennoch von einer Stellvertretung ausgegangen werden soll, löst sich das vermeintliche Problem der Offenkundigkeit jedenfalls über § 164 I 2 BGB, indem der Entwickler ausdrücklich bei der Anwendung genannt wird. 4) Zwischenergebnis Von beiden Seiten werden demnach Willenserklärungen zum Abschluss eines Vertrages zur unentgeltlichen Überlassung der App abgegeben. Die genaue Charakterisierung kann zu diesem Zeitpunkt dahinstehen, da in jedem Fall Schutzpflichten zugunsten des Erwerbers bestehen. Damit geht die Begründung von primären Leistungspflichten, vor allem zur Überlassung der Anwendung nicht zwingend einher. Im Rahmen von Schutzpflichtverletzungen kann ein Schadensersatz begründet sein. cc. Fälle fehlender Transparenz Kurz sollen die Fälle betrachtet werden, in denen nach dem objektiven Empfängerhorizont keine Willenserklärung des Entwicklers vorliegt. In diesen Fällen wird aufgrund des allgemeinen Erscheinungsbildes des App-Stores von einer Willenserklärung des Store-Betreibers auszugehen sein. Wenn schon der Rechtsbindungswille beim Entwickler problematisch ist, könnte dies erst recht für eine unentgeltliche Überlassung durch einen Dritten gelten. Aber auch hier bestehen erhebliche finanzielle und rechtliche Interessen auf Seiten des StoreBetreibers. Aus wirtschaftlicher Sicht dient auch das Anbieten kostenloser Software dem Interesse des Betreibers, den eigenen Store am Markt zu etablieren oder sich gegenüber der Konkurrenz durch einen möglichen großen Angebotsrahmen hervorzuheben. Aus rechtlicher Sicht gebietet gerade die Stellung als Nicht-Entwickler eine Annahme des Rechtsbindungswillen. Der Store-Betreiber möchte gerade bei fehlendem Einfluss auf den Inhalt der Anwendung einen möglichst weiten Ausschluss der Haftung bewirken und sich gegebenenfalls bestimmte Rechte vorbehalten. Dies gelingt am effektivsten über die Einbezie325 Dies ist schon deswegen anzunehmen, indem in der Beschreibung nicht nur die DApp als Leistung selbst beschrieben wird, sondern auch Nutzungsbedingungen des Entwicklers einbezogen werden. 326 A.A. Buhl, der schon die »Redaktionskompetenz« des Store-Betreibers für eine eigene WE ausreichen lässt: Buhl, S. 47; selbst bei Apple, wo die App ohne ein Aufrufen erfolgen kann, verbleibt als Erklärung nur die App Darstellung. Die Entscheidung über das Logo und überhaupt das Einstellen im Store liegt aber ebenfalls beim Entwickler.

112

Dezentrale Anwendungen der Sharing Economy

hungen der Nutzungsbedingungen des Stores. Diese werden bereits als Rahmenvertrag bei der allgemeinen Nutzung des Stores vereinbart.327 Insofern muss aber auch das konkrete Herunterladen in den Rechtsbindungswillen der Beteiligten aufgenommen werden, sodass zumindest ein Mindestmaß an Rechtsbindungswille besteht. Auch wenn es sich nur auf die Einbeziehung der konkreten Anwendung in den Rahmenvertrag richtet, besteht in jedem Fall auch ein Vertragsverhältnis (Rahmenvertrag), der auch die konkrete Anwendung umfasst. dd. Vertragspartner ohne Verwendung eines App-Stores Aber auch jenseits von App-Stores gibt es hinreichend Möglichkeiten zum Verbreiten von Open Source Software in Form von DApps. Vor allem über Foren wie Github o. ä. kann Open Source Software schnell an eine Vielzahl von Personen weitergegeben werden, ohne dass der Umweg über den App-Store erforderlich ist. Die Foren werden aber in der Regel nicht den gleichen Markt ansprechen. Während App-Stores gezielt auf den Endkunden als herkömmlichen App-Nutzer ausgerichtet sind, ist Github vorwiegend an Programmierer gerichtet. Diese Unterscheidung ist für die Frage des Vertragsschlusses nur insoweit relevant, als es sich bei den Entwicklern um Unternehmer handeln könnte. 1) Entwickler als Vertragspartner Stellt der Entwickler die Anwendung selbst in einem allgemein zugänglichen Forum zur Verfügung, so unterscheidet sich dies auf seiner Seite nicht maßgeblich von einem App-Store. Allerdings sind Foren regelmäßig nicht als einheitlicher Marktplatz gestaltet, sodass der Nutzer nicht davon ausgeht, mit dem Betreiber des Forums einen Vertrag zu schließen. Hier ist also von einem Vertragsschluss zwischen Entwickler und Nutzer auszugehen. 2) Dritter als Vertragspartner Problematisch wird es im Rahmen von Foren erst, wenn die Anwendung nicht vom Entwickler, sondern von einem Dritten eingestellt wird. Aufgrund der Open-Source Eigenschaft der Blockchain kann letztlich jeder Node-Betreiber sein. Wenn der Maßstab für den Rechtsbindungswillen des Entwicklers die wirtschaftliche und rechtliche Relevanz des Geschäfts ist, er auch als entscheidendes Kriterium bei Dritten genutzt werden. Während sich das finanzielle Interesse des Entwicklers aus dem Verkauf von Token ergibt, trifft dies auf NodeBetreiber nur noch sehr eingeschränkt zu. Zwar ist es auch möglich, dass diese Inhaber von Token sind, der Umfang wird aber regelmäßig deutlich geringer sein. Jedenfalls sind sie zu Beginn der Blockchain nicht alleiniger Inhaber aller Token. 327 Klein/Datta, CR 2016, 587, 590.

Haftung

113

Jenseits von dem Verkauf von Token, können Node-Betreiber aber gleichzeitig auch Miner sein. Die Belohnung für ein erfolgreiches Mining kann teilweise einen erheblichen Umfang annehmen.328 Ein finanzielles Interesse an der Verbreitung kann sich somit daraus ergeben, dass eine höhere Verbreitung zu mehr Blöcken führt, die gemint werden müssen. Ähnlich zum Entwickler der Blockchain steigen auch bei Minern die Einnahmen mit der Verbreitung. Allerdings führt eine höhere Verbreitung auch zu einer höheren Anzahl von Minern, sodass Konkurrenz geschaffen würde. Dies hängt zwar letztlich stark vom jeweiligen Konsens-Mechanismus ab, ein direkter Anstieg von Erlös im Verhältnis zur Verbreitung eines einzelnen Miners ist jedoch nicht zwingend. Selbst wenn eine Verbindung zwischen Verbreitung und Mining Erlös besteht, kommt es letztlich immer noch auf den objektiven Empfängerhorizont an.329 Der Besucher eines Forums kann nicht zwischen einzelnen Node-Betreibern unterscheiden. Es ist für ihn nicht ersichtlich, ob der Node-Betreiber gleichzeitig auch als Miner fungiert. Stattdessen erlangt er, in der Regel von einer anonymisierten Person, kostenlos eine Software. Da auch keine Geschäftsbedingungen vereinbart werden und dem Node-Betreiber in der Regel auch keine Risiken bekannt sein dürften, sprechen die Indizien, die zuvor zwischen Entwickler und Nutzer angewandt wurden, gegen eine vertragliche Beziehung der Anwendung. Regelmäßig stehen altruistische Motive bei demjenigen im Falle einer anonymen Verbreitung im Vordergrund, der die Anwendung über ein Forum verbreitet. Gerade im Rahmen von Open Source Software dürfte überwiegender Motivationsgrund die Verbreitung der Software an eine möglichst große Gruppe von Personen sein, die diese nutzen und weiterentwickeln. Soweit keine sonstigen Anhaltspunkte hinzutreten, erfolgt die unentgeltliche Überlassung auf Foren oder auch auf sonstige Art und Weise zwischen Dritten und Nutzern auf Grundlage reiner Gefälligkeit. Es besteht somit kein Schuldverhältnis, auf das ein Schadensersatzanspruch gestützt werden kann. ee. Zwischenergebnis Insgesamt kommen vertragliche Beziehungen nur dann in Betracht, wenn der Entwickler selbst die Anwendung verbreitet. Sobald eine Verbreitung über Dritte erfolgt, die nicht App-Store-Betreiber sind und auch sonst keine unmittelbaren wirtschaftlichen Ziele verfolgen, erfolgt die Überlassung im Rahmen von Gefälligkeiten. Die Haftungsunterschiede, die sich hierdurch ergeben, sind aber auch gerechtfertigt. Derjenige, der die Anwendung über einen App Store oder direkt vom Entwickler bezieht, bringt ihnen ein erhöhtes Vertrauen entgegen im Ge328 Für Bitcoin beläuft sich die Belohnung derzeit auf 12,5 Bitcoin, was nach derzeitigem Kurs etwas über 425.000 € entspricht, vgl. https://coinmarketcap.com abgerufen am 18. 1. 2021. 329 Möslein in BeckOGK BGB, § 145 Rn. 112.

114

Dezentrale Anwendungen der Sharing Economy

gensatz zu demjenigen, der die dezentrale Anwendung durch einen anonymen Dritten erlangt. Vertragliche Haftungsgrundlagen ergeben sich somit nur beim Bezug vom Entwickler. b. Pflichtverletzungen Ist der Vertragspartner bestimmt, muss sein Pflichtprogramm präzisiert werden. Letztlich sind die Pflichten, wie auch bei sonstigen Vertragsverhältnissen, aus dem Vertrag heraus zu bestimmen. Wie sich schon bei den Schwierigkeiten zur Bewertung des Rechtsbindungswillen zeigt, ist es zweifelhaft, ob hier ein Vertragsverhältnis mit Primärleistungspflichten entsteht. Stattdessen könnte es sich auch um ein Schuldverhältnis handeln, bei dem ausschließlich Schutzpflichten begründet werden.330 Der Begründung von Schutzpflichten kann sich der Entwickler aufgrund seines eigenen finanziellen Interesses an der Verbreitung nicht allein Aufgrund der Unentgeltlichkeit entziehen. Die Argumentation lässt sich aber nicht auf die Leistungspflicht erstrecken. Dem Nutzer entstehen keine besonderen Gefahren daraus, dass er die Anwendung gar nicht erst erlangt. Erst recht werden solche nicht mit wirtschaftlichen Vorteilen auf der Seite des Entwicklers aufgewogen. Auch erlangt der Entwickler umgekehrt keinen wirtschaftlichen Vorteil, wenn er die DApp dem Nutzer nicht zur Verfügung stellt. Wenn man auf den objektiven Empfängerhorizont im Rahmen der Auslegung abstellt, muss man zu dem Ergebnis kommen, dass der Entwickler sich nicht zu einer Leistung verpflichten möchte und der Nutzer hieran auch kein berechtigtes wirtschaftliches Interesse hat, welches eine Primärleistungspflicht rechtfertigen würde. Es handelt sich bei dem Vertrieb von DApps also nicht um einen gesetzlich typisierten Vertrag, sondern lediglich um eine Gefälligkeit mit rechtsgeschäftlichem Charakter, bei dem sich die Parteien gem. § 311 II Nr. 3 BGB dazu verpflichten, auf die Rechtsgüter des Anderen Rücksicht zu nehmen. Es werden ausschließlich Schutzpflichten i. S. d. § 241 II BGB begründet. Gegen diese Schutzpflichten kann vor allem dann verstoßen werden, wenn Fehler in der DApp vorliegen, die bei der späteren Verwendung zu Schäden an den Rechtsgütern des Nutzers führen. Erneut sei hier die DAO genannt, da es ein Musterbeispiel für Vermögensschäden durch fehlerhaften Programmcode bietet. Der Code der DAO ermöglichte es Dritten ohne Zustimmung der Beteiligten Werteinheiten in Form von

330 Bachmann in Müko BGB, § 241 Rn. 176; Bork, BGB AT, Rn. 682; Brox/Walker SchuldR AT, § 2 Rn. 30; Medicus/Petersen Bürgerliches Recht, Rn. 368; Schwerdtner NJW 1971, 1673, 1675.

Haftung

115

Ether331 auf eigene Blockchainadressen zu transferieren. Zwar werden in der Regel bei DApps innerhalb der Sharing Economy keine Investmentpools gebildet, dennoch ist es denkbar, dass ein fehlerhafter Programmcode einen Schaden beim Transfer von Entgelten auf eine falsche Adresse verursacht. Neben diesen unmittelbaren Vermögensschäden sind weitere Probleme denkbar, die zu einem Schaden führen können. Innerhalb der Blockchain ist es auch möglich, illegale Inhalte und Viren zu verteilen.332 Allerdings werden sie regelmäßig nicht durch den Entwickler in die Blockchain eingefügt. Das Einfügen wird regelmäßig erst durch Programmfehler oder fehlende Sicherheitsmechanismen möglich. Insoweit lassen sich also auch solche Probleme auf den Entwickler selbst zurückführen. Die damit einhergehenden Schäden sind mittelbare Vermögensschäden, indem Daten kopiert oder gesperrt oder strafrechtliche Sanktionen gegen den Nutzer ausgesprochen werden. Letztlich lassen sich die möglichen Pflichtverletzungen ex ante nicht abschließend feststellen, sie werden aber immer darin übereinstimmen, dass der Entwickler selbst einen fehlerhaften Code verbreitet oder nicht ausreichend Sicherheitsmaßnahmen gegenüber der Implementierung schädlicher Inhalte durch Dritte getroffen hat. c. Haftungsmaßstab In welchem Umfang die Pflichtverletzungen zu einer Haftung führen, hängt vom anzuwendenden Haftungsmaßstab ab. Ordnet man die Überlassung der DApp als Gefälligkeit mit Schutzpflichten ein, deutet sich der klassische Streit über den Haftungsmaßstab innerhalb von Gefälligkeitsverhältnissen mit rechtsgeschäftlichem Charakter an.333 aa. Allgemeiner Haftungsmaßstab Am leichtesten ließe sich die Frage nach dem Haftungsmaßstab beantworten, wenn sich eine gesetzliche Regelung hierzu finden ließe. Aufgrund der unentgeltlichen Überlassung der DApp, wäre die naheliegende Lösung, auf die Schenkung und § 521 BGB abzustellen und somit die Haftung auf grobe Fahrlässigkeit zu beschränken. Allerdings handelt es sich gerade nicht um eine Schenkung, sondern um eine bloße Gefälligkeit ohne Bindung an ein Leistungsversprechen. Dieser Differenzierung steht im vorliegenden Fall nicht entgegen, dass Gefälligkeiten schenkungsähnlicher Art bisher überwiegend abge331 Die DAO war keine selbstständige Blockchain, sondern nutzte als Netzwerkgrundlage die Blockchain Ethereum, sodass die Werteinheiten dieses Netzwerkes genutzt wurden. 332 Beaucamp/Henningsen/Florian, MMR 2018, 501ff.;zur Verbreitung von Viren https://medi um.com/towardsblockchain/how-to-use-blockchains-for-spreading-viruses-690a5a4c65cf abgerufen am 18. 1. 2021. 333 Als Übersicht mit weiteren Nachweisen: Bachmann in MüKo BGB, § 241 Rn. 183–192.

116

Dezentrale Anwendungen der Sharing Economy

lehnt werden.334 Die grundsätzliche Ablehnung lässt sich mit dem Charakter der Schenkung rechtfertigen. Die Ausgestaltung der Schenkung mit der Pflicht zur Verschaffung des Eigentums einerseits und der Formvorschrift mit der Möglichkeit zur Heilung andererseits, erfasst alle unentgeltlichen Eigentumsübertragungen. Für einen entsprechenden Fall der Gefälligkeit bleibt faktisch kein Raum. Liegt ein formloses Schenkungsversprechen vor, besteht kein wirksamer Anspruch auf Erfüllung der Schenkung. Nach objektiven Kriterien lässt sich dieser Fall aber nicht von einem »Versprechen zur Schenkung« ohne Rechtsbindungswillen unterscheiden. Sobald hingegen das Versprechen erfüllt, die Eigentumsübertragung also stattgefunden hat, oder die Form eingehalten wurde, besteht nach der Definition des § 516 BGB entweder ein Schuldverhältnis oder aber eine Leistung ohne Rechtsgrund.335 Das Gefälligkeitsverhältnis setzt hingegen schon nach dem natürlichen Sinn einen Rechtsgrund für die Leistung voraus.336 Die Übertragung des Eigentums ohne gleichzeitige Abrede über die Untentgeltlickeit, wenn auch konkludent, aber mit Rechtsgrund lässt sich insoweit nicht konstruieren. Aufgrund der festen Definition der Schenkung in § 516 BGB ist eine Gefälligkeit im Bereich der Schenkung nicht vorstellbar. Von der Schenkung unterscheidet sich die Überlassung einer DApp. Indem lediglich eine Programmkopie, nicht aber Eigentum an einer Sache des Übertragenden verschafft wird, fehlt es am erforderlichen Merkmal der Entreicherung für die Schenkung.337 Da dieser Fall im Gegensatz zur unentgeltlichen Übereignung aber nicht gesetzlich definiert und somit auch nicht vom Anwendungsbereich der gesetzlichen Gefälligkeit nach dem Willen des Gesetzgebers ausgenommen ist, spricht auch nichts gegen die Einordnung der Überlassung der DApp als Gefälligkeit. Dasselbe Ergebnis ließe sich auch mit einer Qualifikation der Überlassung als ein Vertrag eigener Art erreichen. Da die Rechten und Pflichte gleich wären, d. h. Schutzpflichten ohne Primärleistungspflichten, wäre es nur eine sprachliche Unterscheidung, die über das zugrundeliegende Problem des Haftungsmaßstabs hinwegtäuscht. Letztendlich kann die Haftungsprivilegierung des § 521 BGB nicht unmittelbar herangezogen werden. Die Wertungen des § 521 BGB und sonstiger gesetzlicher Haftungsprivilegierungen könnten sich aber dennoch übertragen lassen.

334 Bruns, VersR 2018, 789, 792. 335 Vgl. Harke in BeckOGK BGB, § 516 Rn. 61. 336 Grüneberg in Palandt, Vor § 241 Rn. 8; Sutschet in BeckOK BGB, § 241 Rn. 23; Schreiber, Jura 2001, 810, 811; differenziert: Rötzer, Die Uneigennützigkeit im Zivilrecht, S. 29ff.; Grigoleit, VersR 2018, 769, 781. 337 Gehrlein in BeckOK BGB, § 516, Rn. 4; Harke in BeckOGK BGB, § 516 Rn. 49; Koch in MüKo BGB, § 516 Rn. 6.

Haftung

117

bb. Übertragung gesetzlicher Haftungsprivilegien Wie auch bei sonstigen Gefälligkeiten, lassen sich dem Gesetz diverse unentgeltliche Verträge entnehmen, die eine entsprechende Haftungsprivilegierung vorsehen. Ob hier auch an eine Gesamtrechtsanalogie, wie für alle Gefälligkeiten, möglich wäre, kann im Rahmen dieser Arbeit dahinstehen. An der bislang allgemein vertrenen Ansicht, dass es an der Planwidrigkeit der Regelungslücke aufgrund der Regelungen des Auftragsrechts fehle, hat Grigoleit aber in jüngerer Vergangenheit berechtigte Zweifel geweckt.338 Indem sich die Verbreitung der DApp zwar nicht als Schenkung qualifizieren lässt, dies aber lediglich an der Entreicherung scheitert, ist es naheliegend, das Haftungsprivileg des § 521 BGB auf die Überlassung der DApp zu übertragen. Argumentativer Schwerpunkt für die analoge Anwendung des § 521 BGB ist die vergleichbare Interessenlage. Sie wird teilweise mit dem Argument abgelehnt, dass es hierfür an dem Austauschverhältnis von Pflichten der Parteien im Rahmen von Gefälligkeitsverhältnissen fehlt. Entgegen der echten Verträge, liege kein Verpflichtungswille der Parteien vor, sodass eine Anwendung der Haftungsprivilegierung nicht angemessen sei.339 Dies bezieht sich allerdings ausdrücklich auf deliktische Anspruchsgrundlagen d. h. solche, bei denen keinerlei vertragliche Beziehungen bestehen.340 Davon zu trennen ist die Frage, ob nicht schon eine rechtsgeschäftliche Verbindung, bezogen auf Schutzpflichten, zwischen den Parteien vorliegt.341 In einem Rechtsverhältnis mit Schutzpflichten, stehen sich zumindest diese gegenüber. Grundsätzlich kann auch hier eingewendet werden, dass die Haftungserleichterung das Äquivalent zur Leistungsverpflichtung ist.342 Der dahinterstehende Gedanke ist, dass die Verpflichtungen sich gleichwertig gegenüber stehen sollen. Zwar erhält der Begünstigte ein Leistungsversprechen, da er aber seinerseits kein Entgelt bezahlt, werden die Sorgfaltspflichten des Leistenden auf grobe Fahrlässigkeit reduziert. Dieser Gedanke könnte auch auf Gefälligkeiten mit Schutzpflichten übertragen werden. Entgegen der vorübergehenden Überlassung von Gegenständen treffen bei der dauerhaften Übertragung den Begünstigten kaum Schutzpflichten. Er muss die Gegenstände weder zurückgeben, noch im Umgang auf die Interessen des Übertragenden in einem erhöhten Maße Acht geben. Auf der anderen Seite muss der Übertragende aber bedenken, dass der Gegenstand geeignet sein kann auf die 338 Grigoleit, VersR 2018, 769, 774ff. 339 Im Grundsatz ohne Argumentation bereits: RG Urt. v. 22. 11. 1934 -VI 288/34, RGZ 145, 390, 395; BGH, Urt. v. 22. 6. 1956, I ZR 198/54, BGHZ 21, 102, 110; Urt. v. 30. April 1959 – II ZR 126/ 57 –, BGHZ 30, 40, 46; Mit Argumentation und weiteren Fundstellen der Literatur: BGH Urt. 09. 06. 1992 -VI ZR 49/91, NJW 1992, 2474, 2475. 340 BGH Urt. 09. 06. 1992 -VI ZR 49/91, NJW 1992, 2474, 2475. 341 Spallino, VersR 2016, 1224, 1225. 342 BGH Urt. 09. 06. 1992 -VI ZR 49/91, NJW 1992, 2474, 2475.

118

Dezentrale Anwendungen der Sharing Economy

Rechtsgüter des Begünstigten in einem erheblichen Maß einzuwirken, seien es Mangelschäden oder Mangelfolgeschäden. Auch bei den Schutzpflichten zeigt sich also eine Diskrepanz zwischen den Pflichten beider Parteien. Zur Reduzierung dieser Diskrepanz ist es gerechtfertigt, auch hier das Überlassen in der Haftung zu privilegieren und den Haftungsmaßstab zu reduzieren. Das Ergebnis kann auch aus der Nähe zur Schenkung hergeleitet werden. Zumindest bei der formlosen Schenkung besteht ebenfalls keine Leistungspflicht; durch die nachträgliche Heilung wird lediglich die Rückforderung ausgeschlossen. Dass es sich bei der Überlassung der DApp nicht um eine formlose Schenkung, sondern um ein sonstiges Schuldverhältnis mit Schutzpflichten handelt, entstammt nicht einem andersartigen Rechtsbindungswillen, sondern dem mangelnden Kriterium der Entreicherung in Folge der Überlassung. Das Kriterium der Entreicherung hat auf Sinn und Zweck der Haftungsprivilegierung aber keinen Einfluss. Die Interessenlage ist gleich, sodass auch die Übertragung auf die Überlassung von dezentralen Anwendungen geboten ist. Bislang unberücksichtigt bleibt, ob § 521 BGB im Rahmen des Schenkungsrechts auf Schutzpflichten überhaupt anwendbar ist. Wenn § 521 BGB schon in der direkten Anwendung keine Schutzpflichten erfasst, würde auch im Rahmen der Analogie eine Übertragung auf Schuldverhältnisse ohne Leistungspflichten ausgeschlossen sein. cc. Haftungsmaßstab bei Schutzpflichtverletzungen Bei der Schenkung wird die Anwendung der Haftungsprivilegierung auf Schutzpflichten teilweise angezweifelt. So soll sich die Haftungsprivelegierung des § 521 nur auf die Verletzung von Leistungspflichten beschränken.343 Dies wird teilweise auf die historische Entwicklung des § 521 gestützt344, teils auf eine Abwägung zwischen Schutzbedürftigkeit des Beschenkten und dem Altruismus des Schenkers und somit rein rechtspolitischen Erwägungen345. Der dahinterstehende Gedanke ist letztlich, dass die Verletzung deliktisch geschützter Rechtsgüter, die keinen Bezug zur Leistung der Sache aufweisen, für alle gleichermaßen untersagt ist und auch für den Schenker kein Grund für eine geringere Rücksichtspflicht besteht346. Dem wird entgegengehalten, dass eine Abgrenzung von Schutzpflichten und Leistungspflichten kaum sicher vorgenommen werden kann, wenn sich die Schutzpflichten auf den Leistungsgegenstand beziehen. Würde man den § 521 in 343 Stoll, JZ 1985, 383, 384ff.; ders. Das Handeln auf eigene Gefahr, 1961, 341 ff.; Schlechtriem, VersR 1973, 581, 585; ders. Vertragsordnung und außervertragliche Haftung, S. 332 ff; Mansel in Jauernig BGB, § 521 Rn. 1. 344 Stoll, JZ 1985, 384ff. 345 Schlechtriem, VersR 1973, 581, 585. 346 Harke in BeckOGK BGB, § 521 Rn. 12.

Haftung

119

diesen Fällen nicht anwenden, käme es zu einen zwingenden Wertungswiderspruch mit § 524, der Haftung für Sachmängel.347 Für solche haftet der Schenker schließlich nur bei Arglist. Im Fall von DApps unterscheiden sich die Meinungen letztlich aber nur in der Herleitung. Auch bei grds. Ablehnung der Anwendbarkeit des § 521 wird eine Korrektur über die Bestimmung des Pflichtenprogramms vorgenommen.348 Ob man nun das Pflichtprogramm anpasst, oder aber die Pflichten bestehen lässt und den Verantwortungsmaßstab korrigiert, macht im Ergebnis keinen Unterschied. Auch wenn theoretisch auf den ersten Blick eine Divergenz dort bestehen kann, wo eine nicht angepasste Pflicht grob fahrlässig verletzt wird, wird dies praktisch nicht vorkommen. Die Schutzpflichten bestehen zwar mit Begründung des Schuldverhältnisses, werden konkret aber erst ex post bestimmt, wenn eine mögliche Verletzung geltend gemacht wird. Insoweit wird auch mit der erstgenannten Auffassung das Pflichtprogramm derart ausgestaltet werden, dass bei grobem Verschulden keine Anpassung des Pflichtenprogrammes erfolgt. Für die Anwendung bei DApps wird es aufgrund der eingeschränkten Einwirkungsmöglichkeiten jenseits des bloßen Leistungsgegenstandes, der DApp, bei den Pflichtverletzungen um einen Bezug zur DApp selbst gehen. Da sich die Ergebnisse nicht unterscheiden, das Pflichtenprogramm nach der ersten Ansicht aber detailliert für den Einzelfall bestimmt werden müsste, wird, um eine allgemein verbindliche Aussage treffen zu können, das Haftungsprivileg des § 521 BGB im Folgenden auch auf Schutzpflichten erstreckt, die im Bezug zum Leistungsgegenstand stehen. Insgesamt führt dies dazu, dass das Haftungsprivileg auch für Schutzpflichten gilt und in diesem Umfang die Regelung des § 521 BGB aufgrund der vergleichbaren Interessenlage analog auf die Fälle der Haftung für DApps übertragen werden kann. Aus der gleichen Überlegung ergibt sich auch die Haftung für Sachmängel analog § 524 BGB. Der Entwickler der DApp haftet somit grundsätzlich für grobe Fahrlässigkeit und Vorsatz sowie bei Sachmängeln für Arglist. Dieses Modell ist einer Herleitung aus einem Vertrag sui generis mit der individuellen Bestimmung des Haftungsmaßstabs ausschließlich nach dem Willen der Parteien, §§ 133, 157 BGB, vorzuziehen. Der Gesetzgeber hat eine regulatorische Wertung getroffen, die nicht vom Einzelfall abhängen soll, sondern allgemein verbindlich für diese Vertragstypen Geltung beansprucht. Diese

347 BGH, Urt. v. 20. 11. 1984 – IVa ZR 103/83, NJW 1985, 794, 796; OLG Saarbrücken, Urteil vom 28. 8. 2013 – 1 U 97/12, NJW-RR, 2014, 139, 140f.; Gerhardt, JuS 1970, 597, 600; Thiele, JZ 1967, 649, 653f. 348 Stoll, JZ 1985, 383, 386; Schlechtriem, VersR 1973, 581, 587.

120

Dezentrale Anwendungen der Sharing Economy

Wertung erstreckt sich über die Analogie auch auf die Fälle der Veräußerung von DApps, sodass der Haftungsmaßstab nicht am Einzelfall bestimmt werden muss. d. Schaden Im Rahmen vertraglicher Ansprüche ist jeder Vermögensschaden im Rahmen der allgemeinen Grundsätze, §§ 249ff. BGB, ersatzfähig. Erwähnenswert ist lediglich, dass Token ein Teil des Vermögens sind. Der Wert des Token kann anhand des Sekundärmarktes bestimmt werden. Eine dezentrale Anwendung ohne handelbare Token im Rahmen der Sharing Economy ist hingegen nicht zu erwarten; hier wäre die Feststellung des Schadens schwierig. Die häufigsten Schäden dürften reine Vermögensschäden im Rahmen von Tokenverlusten oder Schäden an der Hardware von Nutzern sein. e. Zwischenergebnis Auch wenn es einige Besonderheiten bei der Haftung von Anwendungsentwicklern gibt, lassen sich Haftungsfragen mit Methoden des Schuldrechts beantworten. Vertragliche Sonderverbindungen mit Schutzpflichten bestehen dort, wo der Entwickler seine Blockchain selbst verbreitet und Dritte lediglich als Vermittler auftreten. Die Pflichten sind anhand der vertraglichen Vereinbarung zwischen Entwickler und Nutzer zu bestimmen, wobei die allgemeinen Rücksichtsnahmepflichten gem. § 241 Abs. 2 BGB konkretisiert werden. Für deren Verletzung haftet der Entwickler bei Abwesenheit individueller Vereinbarungen nur für Vorsatz und grobe Fahrlässigkeit, was zwar die Haftung insgesamt deutlich einschränkt, aufgrund der Unentgeltlichkeit der Leistung aber angemessen ist. Schäden sind hingegen voll ersatzfähig im Rahmen der §§ 249ff. BGB. Wesentliche Beschränkungen des vertraglichen Schadensersatzanspruches gegen Anwendungsentwickler sind somit einerseits der verhältnismäßig enge Kreis der Anspruchssteller andererseits der reduzierte Haftungsmaßstab. 2.

Produkt-und Produzentenhaftung für fehlerhafte Software

Die Lücken, die sich aus der Begrenzung des Kreises der Anspruchssteller und des Haftungsmaßstabes ergeben, könnte die deliktische Haftung des Entwicklers schließen, sei es durch Produzenten- oder Produkthaftung. Bei beiden sind auch Dritte geschützt, soweit ein relevantes Rechtsgut beeinträchtigt ist. Bei Software und somit auch DApps kann es zwischen den Ansprüchen aber zu Unterschieden kommen.

Haftung

121

a. Produzentenhaftung Ausgangspunkt für die deliktische Produzentenhaftung gem. § 823 I BGB ist die Verantwortlichkeit für eine geschaffene Gefahrenquelle.349 Auch wenn die Bezeichnung dies suggeriert (Produkt- oder Produzentenhaftung)350, ist im Gegensatz zu § 2 ProdHaftG für die Haftung gem. § 823 I BGB kein Produkt im technischen Sinne erforderlich. Es ist lediglich auf die Schaffung einer Gefahrenquelle und die Pflicht zur Beherrschung dieser Gefahr abzustellen.351 Dies zeigt sich unter anderem in der Ausdehnung der Produzentenhaftung auf Fälle, die sich nicht dem Produktbegriff des § 2 ProdHaftG zuordnen lassen, wie beispielsweise von Bau-und Dienstleistungen.352 Nach den dort zugrunde gelegten Maßstäben lässt sich die Haftung auch auf die Verbreitung von DApps übertragen. Auch durch sie wird eine Gefahrenquelle geschaffen, die durch die Vielzahl möglicher Viren und Sicherheitslücken eine Gefahr für die Rechtsgüter des Nutzers begründet. aa. Betroffene Rechtsgüter Wegen der Beschränkung des § 823 I BGB auf besondere Rechtsgüter und den Ausschluss des reinen Vermögensschutzes müssen die betroffenen Rechtsgüter im Einzelnen bestimmt werden. Soweit Viren und Sicherheitslücken bestehen, die es Dritten ermöglichen auf Daten des Nutzers zuzugreifen, besteht das Problem auch bei jeder anderen Software. Dort führen die Veränderung und Löschung von Daten außerhalb der Blockchain zu einer Eigentumsverletzung.353 Da die Daten der Blockchain aber ihrer Natur nach grds. unveränderbar sind354, betrifft dies überwiegend nur die sonstigen Daten des Nutzers. In manchen dezentralen Anwendungen besteht jedoch die Möglichkeit einer nachträglichen Datenveränderung. Bei einer sog. 51 %-Attacke erlangt der Angreifer bspw. einen überwiegenden Teil der Rechenleistung und kann somit den Inhalt bestätigter

349 BGH, Urt. v. 26. 11. 1968 -VI ZR 212/66, NJW 1969, 269; Spindler in BeckOGK BGB, § 823 Rn. 615. 350 Zur Differenzierung der Terminologie: Hartmann, BB, 2012, 267, Fn.1. 351 Spindler in BeckOGK BGB, § 823 Rn. 622; Foerste in Foerste/Graf v. Westphalen Hdb. Produkthaftung, § 20 Rn. 13. 352 Bspw. auch auf unbewegliche Sachen: Abfall: BGH NJW 1976, 46; Foerste in Foerste/Graf v. Westphalen Hdb. Produkthaftung, § 20 Rn. 13; zu Strom: BGH Urt. v. 25. 2. 2014 – VI ZR 144/ 13, NJW 2014, 2106 und Wasser: Urt. v. 4. 10. 1972 – VIII ZR 117/71, NJW 1970, 2300; Wagner in MüKo BGB, § 823 Rn. 784. 353 OLG Karlsruhe Urt. v. 07-11-1995, 3 U 15/95, NJW 1996, 200, 201; OLG Oldenburg Beschl. v. 24. 11. 2011, 2 U 98/11 -BeckRS 2011,28832; Wagner in MüKo BGB, § 823 Rn. 220; Spindler in BeckOGK BGB, § 823 Rn. 136. 354 Böhme/Pesch, DuD 2017, 473; Beinke/Tönnissen/Teuteberg, HMD Praxis der Wirtschaftsinformatik 2019, 660, 671f.

122

Dezentrale Anwendungen der Sharing Economy

Blöcke beeinflussen und verändern.355 Wenn auf die Blockchain an sich abgestellt wird, könnten Zweifel daran bestehen, ob dies zu einer Eigentumsverletzung des Einzelnen führt, da alle Node-Betreiber innerhalb der Blockchain schreibberechtigt sind, dies aber nicht zwingend für den einzelnen Nutzer gelten muss und nicht alle Nutzer die Blockchain selbst abgespeichert haben.356 Unzweifelhaft bleibt das Recht am Datenträger bestehen und damit auch die physische Integrität des Speichermediums.357 Zu einer Eigentumsverletzung kommt es, wenn der Geschädigte einen Teil der Blockchain heruntergeladen hat, der verändert wird. Problematischer sind die Fälle, in denen der Geschädigte lediglich Nutzer der Anwendung, aber kein Node-Betreiber ist. In diesen Fällen nutzt er zwar die dezentrale Anwendung, hat diese aber nicht auf einem eigenen Speichermedium gespeichert. Er nutzt Node-Betreiber als Schnittstelle zur Interaktion. Da auch er über einen public und private key verfügt, können auch ihm Schäden durch die Veränderung der Blockchain entstehen, indem Transaktionen verändert werden, an denen sein public key beteiligt ist. Das Problem des Schadens bei fehlendem dinglichen Besitzrecht am Speichermedium erinnert an die Diskussion über Cloud-Dienste. Zu diesen besteht zwar in der Regel bezüglich der zentralisierten Organisation der Server ein struktureller Unterschied, gemein ist aber die Auslagerung von Daten durch den Geschädigten.358 Im Rahmen des § 823 I BGB werden die Daten nur dann geschützt, wenn sie als ein »sonstiges Recht« qualifiziert werden können oder ein »Eigentum« an Daten möglich ist.359 Daten erfüllen mangels Körperlichkeit nicht den Sachbegriff i. S. d. § 90 BGB.360 Soweit man ein Dateneigentum annehmen möchte, ginge dessen Definition über den klassischen Eigentumsbegriff hinaus. Unabhängig davon, ob die 355 Bei einer 51 %-Attacke ermöglicht es die überwiegende Rechenleistung dem Angreifer die mathematischen Rätsel im Rahmen des Proof of Work Konsens Mechanismus als erster zu lösen und hierdurch den Inhalt des nächsten Blocks zu bestimmen. Je höher der Vorsprung in Rechenpower desto eher ist es dem Angreifer auch möglich bereits bestätigte Blöcke nachträglich zu verändern. Grundlagen zur 51 %-Attacke: Bae/Lim, 51 %-Attacks, S. 81; Ye/ Li u.w., Analysis of Security in Blockchain: Case Study in 51 %-Attack Detecting, 5th International Conference on Dependable Systems and Their Applications, S. 14. 356 Vgl. Eigentumsrecht bei Schreibberechtigung: Hoeren, MMR 2013, 486, 487; mit Weiterverweis Bräutigam/Klindt, NJW, 2015, 1137, 1139. 357 BGH, Urt. v. 14. 07. 1993 – VIII ZR 147/92, NJW 1993, 2436, 2437; OLG Oldenburg, Beschl. v. 24. 11. 2011-2 U 98/1, BeckRS 2011, 28832; OLG Karlsruhe, Urt. v. 07. 11. 1995-3 U 15/95, NJW 1996, 200, 201; König, NJW 1993, 3121, 3124; Wagner in MüKo BGB, § 823 Rn. 220. 358 Darstellung von Cloud-Computing: Nägele/Jacobs, ZUM, 2010, 281, 282; Schuster/Reichl, CR 2010, 38ff. 359 Grundlegend: Zech, Information als Schutzgegenstand, 2012, 37 ff. 360 Wagner in MüKo BGB, § 823 Rn. 219; OLG Dresden Beschl. v. 5. 9. 2012 – 4 W 961/12, NJWRR 2013, 27, 28; Zech, Information als Schutzgegenstand, S. 326 ff.

Haftung

123

Ausdehnung des Eigentumsbegriffs in sonstigen Bereichen erforderlich oder wünschenswert ist, kann im Haftungsrecht darauf verzichtet werden. Über die sonstigen Rechte des § 823 I BGB besteht hinreichend Freiraum, den Schutz von Daten zu gewährleisten, ohne in den Numerus Clausus der Sachenrechte eingreifen zu müssen. Zwar wird auch hierbei teilweise an der Notwendigkeit gezweifelt, da die Daten hinreichend über den Schutz des Eigentums am Speichermedium geschützt sein sollen.361 Allerdings wird diese Auffassung dem zunehmend externen Speichern von Daten nicht gerecht.362 Neben den CloudDiensten sind die dezentralen Anwendungen als weitere große technologische Entwicklung anzusehen, bei der der Nutzer seine Daten nicht mehr auf eigenen Speichermedien hinterlegt. Wenn schon bei Cloud-Diensten die wirtschaftliche Bedeutung und die Gefahr von Schutzlücken hervorgehoben wurde,363 ist dieses Problem mit Einführung der Blockchain nur noch verstärkt worden. Anknüpfungspunkt für die Einordnung als sonstiges Recht ist die Vergleichbarkeit mit den in § 823 I BGB explizit genannten Rechtsgütern und demnach die Frage, ob Daten selbst als absolutes subjektives Recht qualifiziert werden können.364 Um ein subjektives Recht darstellen zu können, muss das Recht am Datenbestand eine Zuordnungs-und Ausschlußfunktion haben.365 Soweit es sich bei dem public und private key nicht um personenbezogene Daten handelt, ergibt sich die Ausschlussfunktion unter anderem aus dem strafrechtlichen Schutz der Daten gem. § 303a StGB.366 Problematischer ist die Zuordnung der Daten zu einem Berechtigten. Hierzu soll erneut die strafrechtliche Diskussion fruchtbar gemacht werden.367 Nach überwiegender Auffassung wird auf den Skripturakt, also den Schaffungsprozess, abgestellt.368 Dies erscheint bei der Blockchain nicht ausreichend, da ansonsten alle Full-Nodes, die die komplette Blockchain speichern, Berechtigte wären. Nicht hingegen der einzelne Nutzer, da dieser die Speicherung mittels des Minings lediglich in Auftrag gibt, selbst aber auf das eigentliche Speichern keinen Einfluss hat. Stattdessen muss bei derartigen Mehrpersonenverhältnissen auf den Auftrags-bzw. Weisungsgeber abgestellt 361 Vgl. Zech, Informationen als Schutzgegenstand, S. 386; Steinrötter, MMR 2017, 731, 733f. 362 Meier/Wehlau, NJW 1998, 1585, 1588f.; Faustmann, VuR 2006, 260, 262; Spindler in BeckOGK BGB, § 823 Rn. 184; Wagner in MüKo BGB, § 823 Rn. 219, 294ff. 363 Faustmann, VuR 2006, 260, 262; Spindler in BeckOGK BGB, § 823 Rn. 184; Wagner in MüKo BGB, § 823 Rn. 219, 294ff. 364 Schiemann in Erman BGB § 823 Rn. 35; Fikentscher/Heinemann, SchuldR, Rn. 1568; Wagner in MüKo BGB, § 823 Rn. 267. 365 Canaris in FS Steffen, 1995, S. 85, 90; Hager in Staudinger BGB, § 823 Rn. B 124; D. Looschelders, Schuldrecht BT, S. 536; allein auf die Zuordnungsfunktion abstellend Habersack, Die Mitgliedschaft-subjektives und »sonstiges« Recht(?), 1996, S. 130 ff. 366 Wagner in MüKo BGB, § 823 Rn. 296; Hoeren, MMR 2013, 486, 491. 367 Zech, Informationen als Schutzgegenstand, S. 388f.; Hoeren, MMR 2013, 486. 368 BayObLG, Urt. v. 24. 6. 1993-5 St RR 5/93, JR 1994, 476, 477; Hilgendorf, JuS 1996, 509, fortgesetzt 890, 893; Wolff in LK StGB, § 303a Rn. 10.

124

Dezentrale Anwendungen der Sharing Economy

werden.369 Er ist als Inhaber des private key Verantwortlicher für die Speicherung, da er die Speicherung in der Blockchain veranlasst und authentifiziert. Soweit trotz des Vorliegens der Ausschluss- und Zuweisungsfunktion darüberhinausgehend eine Rechtfertigung für die Einbeziehung als »sonstiges« Recht verlangt wird370, kann auf die verfassungsrechtlichen Grundlagen abgestellt werden. Wegen der Feststellung des Grundrechts der Vertraulichkeit und Integrität informationstechnischer Systeme371, des Grundrechts auf informationelle Selbstbestimmung372 sowie des zunehmenden Schutzes der Datensicherheit durch den Gesetzgeber, sowohl durch das BDSG gegen öffentliche Verarbeitung als auch durch §§ 202 a ff, 303a ff. StGB, kann nur von einem Wertungswiderspruch ausgegangen werden, wenn dieser Schutz sich nicht auch in das Zivilrecht erstreckt.373 Es genügt nicht der Schutz über § 823 II i. V. m. einem Schutzgesetz, da hierfür zumindest im Rahmen des § 303 a StGB eine vorsätzliche Tat erforderlich ist. Bei feindlichen Angriffen auf die Blockchain ist Vorsatz offenkundig. Im Übrigen sind die gespeicherten Daten nicht hinreichend gesichert. Die Beständigkeit und Unveränderlichkeit der Blockchain ist noch nicht hinreichend erforscht und nicht allgemein verbindlich abgesichert. Unabhängig von der Eigenschaft als Node-Betreiber sollten die auf der Blockchain gespeicherten Daten als sonstiges Recht i. S. d. § 823 I geschützt sein. Damit erstreckt sich der Rechtsgüterschutz auf alle Nutzer der dezentralen Anwendung. Kein Schaden ist hingegen anzunehmen, wenn Stoffgleichheit zwischen Schaden und der durch die Mangelhaftigkeit verursachten Entwertung der Software besteht.374 Stoffgleichheit liegt vor, wenn sich der Schaden ausschließlich auf die dezentrale Anwendung selbst auswirkt. Soweit lediglich die Nutzung unmöglich gemacht oder eingeschränkt wird, betrifft dies zunächst nur das Integritätsinteresse des Geschädigten.375 Dieses ist zumindest soweit relevant, als die dezentrale Anwendungen zur kostengünstigen Leistungsbeschaffung verwendet werden. Der durch die fehlende Nutzungsmöglichkeit eintretende Wertverlust376 der Token ist ebenfalls nicht ersatzfähig.377 Dieser Schaden besteht 369 370 371 372 373 374 375 376 377

Lenckner/Winkelbauer, CR 1986, 824, 829; Hilgendorf, JR 1994, 476, 479. Dorner, CR 2014, 617, 625. BVerfGE Urt. v. 27. 2. 2008 – 1 BvR 370/07, 1 BvR 595/07, NJW 2008, 822. BVerfG Urt. v. 15. 12. 1983 – I BvR 484/83, BVerfGE 65, 1, 49. So auch Zech, Information als Schutzgegenstand, 383; Spindler in BeckOGK BGB, § 823 Rn. 185. BGH Urt. v. 18. 1. 1983 -VI ZR 310/79, NJW 1983, 810, 812ff.; BGH Urt. v. 18. 1. 1983 – VI ZR 270/80, NJW 1983, 812, 813. Spindler in BeckOGK BGB, § 823 Rn. 156. Vgl. Bestimmung des Wertes anhand des Metcalf ’schen Gesetzes: § 4 I 2. b. bb. 3). Vgl. zum Wertverlust von Aktien bei Beeinträchtigung des Mitgliedschaftsrechts: Frodermann/Schäfer in Frodermann/Jannott, HdB des Aktienrechts, Kapitel 7, Rn. 277.

Haftung

125

nicht in einer Verletzung der Daten auf der Blockchain (Entzug der Token), sondern in der fehlenden Nutzungsmöglichkeit der Anwendung. Der damit einhergehende Wertverlust ist aber nicht Teil des Rechts an den Daten. Ebenfalls nicht ersatzfähig ist der bloße Verlust einer Verdienstmöglichkeit, die auch bei der Annahme von Daten als sonstiges Recht ein reiner Vermögensschaden bleibt. Soweit man nun auf einen Eingriff in den eingerichteten und ausgeübten Gewerbebetrieb ausweichen möchte, fehlt es in der Sharing Economy in aller Regel an einem verfestigten Substrat von Vertriebsmitteln.378 Schäden an sonstigen Rechtsgütern durch Fehler oder gezielte Datenmanipulation in der dezentralen Anwendung sind nach den bisherigen Maßstäben zu beurteilen, beispielsweise Schäden an Schnittstellenkomponenten zur realen Welt, bei denen die Nutzung einer Leistung zumindest vorübergehend beeinträchtigt wird. Als Beispiel sollen automatisierte Türschlösser genannt werden, die den Zugang zu Wohnungen erst nach einer in der dezentralen Anwendung bestätigten Transaktion ermöglichen. Wenn die Daten in der Blockchain manipuliert wurden, wirkt sich dies sowohl auf die Funktionsfähigkeit des Schlosses, als auch auf die Möglichkeit des Zugangs zur Wohnung aus. Auch auf diese Weise können das Eigentum und der Besitz geschädigt werden.379 bb. Verletzungshandlung und Verkehrssicherungspflichten Wie bereits angesprochen ist unmittelbarer Anknüpfungspunkt für die Schädigung zunächst der Angriff auf die Integrität der Blockchain durch einen Dritten. Die Schädigung tritt unmittelbar durch die Veränderung der Blockchain ein, ohne dass eine weitere Handlung dazwischentritt. Die Nodes der dezentralen Anwendung müssen die Änderungen nicht erst bestätigen, sondern der Angreifer ersetzt die Rechenleistung der Nodes mit seiner eigenen und ist somit unmittelbar verantwortlich für die verifizierten Änderungen in der Blockchain. Es können zwar Maßnahmen zur Erschwerung solcher Angriffe getroffen werden.380 Ein Angriff kann letztlich aber nicht verhindert werden, da Schwachstellen der Blockchain-Technologie immanent sind. Die Verantwortlichkeit des Angreifers steht außer Frage. Teilweise werden Angriffe auf die Blockchain aber auch durch fehlerhaften Code in der dezentralen Anwendung ermöglicht, insbesondere bei der Verwendung von Smart Contracts. Insoweit stellt sich die Frage, ob den Entwickler oder

378 BGH Urt. v. 18. 1. 1983 -VI ZR 270/80, NJW 1983, 812, 813. 379 Beispiel für verknüpfte Hardware mit dezentralen Anwendungen: https://www.blockchain s.com/products/ abgerufen am 18. 1. 2021; Maßstab für Ersatzfähigkeit von vorübergehender Eigentums-und Besitzbeeinträchtigung: BGH Urt. v. 21. 6. 2016 – VI ZR 403/14, NJWRR 2017, 219ff.; mit weiteren Nachweisen Spindler in BeckOGK BGB, § 823 Rn 131, 171. 380 Bae/Lim, 51 %-Attacks, S. 81.

126

Dezentrale Anwendungen der Sharing Economy

die Gesamtheit der Nodes Verkehrsicherungspflichten zur Verhinderung solcher Veränderungen in der dezentralen Anwendung treffen. Ausgangspunkt für die Verantwortlichkeit des Anwendungsentwicklers ist die Inverkehrgabe eines gefährlichen Produktes, das eine Gefahrenquelle eröffnet.381 Wie bereits gezeigt, scheitert die Verantwortung hierfür nicht an der fehlenden Sacheigenschaft der Blockchain, da Produkte nicht körperlich sein müssen. Im Übrigen ist anerkannt, dass sich Verkehrssicherungspflichten auch aus gefährlichem Tun ergeben können.382 Entscheidend ist die Beherrschbarkeit der Gefahrenquelle. Für den Anwendungsentwickler beschränkt sie sich auf den Zeitpunkt der Veröffentlichung, ab dem er die Kontrolle über die dezentrale Anwendung verliert. Vor diesem Zeitpunkt besteht noch keine Gefahr für die Rechtsgüter Dritter. Sanktioniert wird die Inverkehrgabe eines gefährlichen Produktes. Die Verkehrspflichten erstrecken sich aber mangels Beherrschbarkeit nicht mehr auf nachträgliche Veränderungen der Blockchain durch Dritte, soweit eine daraus resultierende Gefährdung nicht Ausfluss eines Fehlers des Entwicklers ist. Wenn bei sonstigen Produkten die Verkehrspflichten vor Verbreitung aufgrund der Einflussmöglichkeit besonders hoch sind,383 muss dies erst recht für die dezentrale Anwendung gelten, bei der der Entwickler nach Veröffentlichung seine Einflussmöglichkeiten verliert. Wie auch bei sonstigen Produkten können die Fehlerquellen nach Konstruktions-, Fabrikations- und Instruktionsfehlern vor sowie den Produktbeobachtungspflichten nach Veröffentlichung differenziert werden.384 1) Konstruktionsfehler Grundlegende und damit in der Regel die bedeutsamsten Fehler können bei der Entwicklung des Programms als Konstruktionsfehler auftreten. Als Konstruktionsfehler sind Fehler einzustufen, die während der Programmerstellung, Programmierung, Codierung und Kompilierung entstehen.385 Erfasst werden Fehler in der technischen Planung, die eine gefahrlose Nutzung der Anwendung von vornherein ausschließen und damit über die Gefahr der Anwendung an sich

381 Grds. Zur Haftung für Gefahrenquellen: vgl. BGH, Urt. v.17. 06. 1997 -VI ZR 156/96, NJW 1997, 2517, 2519; BGH, Urt. v. 01-07-1993 -III ZR 167/92, NJW 1993, 2612, 2613f.; mit weiteren Verweisen: Spindler in BeckOGK BGB, § 823 Rn. 818, Fn.4507. 382 Wagner in MüKo BGB, § 823 Rn. 409; Förster in BeckOK BGB, § 823, Rn. 302; Spindler in BeckOGK BGB, § 823 Rn. 391ff. 383 Förster in BeckOK BGB, § 823, Rn. 699. 384 Überblick über die einzelnen Fehlerkategorien: Michalski, BB 1998, 961, 962ff. 385 Lehmann, NJW 1992, 1721, 1723; Reese, DStR 1994, 1121; Littbarski in Taeger/Pohle Comp. Hdb., Teil 18, Rn. 63.

Haftung

127

hinausgehen.386 Gefahren, die sich aus der technischen Umsetzung und nicht der Anwendung selbst ergeben, sind bei dezentralen Anwendungen schwer zu bestimmen. Ein unerwünschtes Ergebnis würde immer als Fehler des Codes und somit als Konstruktionsfehler der Software anzusehen sein. Geht man nach dem Selbstverständnis der Blockchain-Gemeinschaft und vor allem der sog. »Cyberpunks« aus, soll die Begrifflichkeit des Konstruktionsfehlers für dezentrale Anwendungen nicht gelten. Mit dem Ansatz »Code is Law«387 sollen sich die Regeln, denen eine dezentrale Anwendung folgt, nicht aus dem Recht, sondern aus dem Code ergeben.388 Dementsprechend ist der Code die Grundlage für die zulässigen Verhaltensweisen in der Anwendung. Oder anders gesagt: alles was man tun kann, darf man tun. Danach würden Fälle fehlerhaften Codes nicht mehr als Konstruktionsfehler und damit auch nicht mehr von der Haftung erfasst, da die Risiken keine Fehler, sondern zulässige Verhaltensweisen sind, unabhängig davon, ob diese vom Entwickler gewollt sind. Diesem radikalen Ansatz kann aber der Grundsatz der Produzentenhaftung entgegengehalten werden, wonach die Haftung aus der Verkehrserwartung an das Produkt resultiert, und nicht aus einem feststehenden objektiven Maßstab.389 Sofern sich die dezentrale Anwendung an einen offenen Personenkreis und innerhalb der Sharing Economy vor allem an Verbraucher richtet, ist der erwartete Maßstab losgelöst von den philosophischen Grundannahmen der Blockchain-Gemeinschaft, sodass auch ein fehlerhafter Code in der Form von Sicherheitslücken bei der dezentralen Anwendung als Konstruktionsfehler anzusehen ist. Auch bei der 51 %-Attacke könnte man Zweifel haben, ob sie noch vom Fabrikationsfehler erfasst ist oder nicht vielmehr eine der dezentralen Anwendung immanente Gefahr darstellt, die der bestimmungsgemäße Gebrauch mit sich bringt.390 Letztere wäre anzunehmen, wenn jede dezentrale Anwendung der Gefahr einer 51 %-Attacke unterliegt. Dies ist zwar grundsätzlich der Fall, dennoch sind nicht alle dezentrale Anwendungen gleichermaßen hiervon betroffen.391 Die Gefährdung durch solche Angriffe kann sowohl durch den gewählten

386 OLG Schleswig Urt. v. 19. 10. 2007-17 U 43/07, NJW-RR 2008, 691; OLG Koblenz Urt. v. 29. 8. 2005-12 U 538/04, NJW-RR 2006, 169,170; OLG Hamm Urt. v. 19. 1. 2000-3 U 10/99, NJW-RR 2001, 1248, 1249. 387 Ursprünglich geprägt durch Lessig, Code: and other Laws of Cyberspace V. 2.0, S. 5. 388 Hütten, The soft spot of hard code, https://doi.org/10.1111/glob.12217, 329, 336. 389 BGH, Urteil vom 17-10-1989 -VI ZR 258/88, NJW, 1990, 906f.; Förster in BeckOK BGB, § 823 Rn. 704. 390 Vgl. OLG Hamm Urt. v. 19. 1. 2000-3 U 10/99, NJW-RR 2001, 1248, 1249. 391 Auch mit weiteren Sicherheitslücken und Bewertung dieser Gefahren für unterschiedliche Konsensmechanismen: Sayeed/Marco-Gisbert, Assessing Blockchain Consensus and Security Mechanisms against the 51 %-Attack, https://doi.org/10.3390/app9091788.

128

Dezentrale Anwendungen der Sharing Economy

Konsens-Mechanismus als auch die konkrete Ausgestaltung des Konsens-Verfahrens verringert werden.392 Insoweit unterscheidet sich die dezentrale Anwendung aber nicht von herkömmlicher Software. Auch bei dieser wird regelmäßig angemerkt, dass komplexe Programme nicht fehlerfrei hergestellt werden können.393 Ausgangspunkt der Diskussion ist dabei, dass es zu Beginn innovativer Technologien nicht mit realistischem Aufwand möglich ist, bei komplexen Systemen alle Fehler zu erkennen und zu beheben.394 Die Meinungen unterscheiden sich letztlich nur darin, wie die Sicherheitserwartung des Verkehrs ausgelegt wird und ob die Anforderungen an den Hersteller am Maßstab der Wirtschaftlichkeit gemessen werden. Auch wenn allgemein bekannt ist, dass komplexe Software nicht fehlerfrei programmiert werden kann, solle dies nicht zu einer Herabsetzung der Sicherheitserwartung des Verkehrs führen.395 So sei zwar hinzunehmen, dass das Äquivalenzinteresse durch fehlerhafte Software beeinträchtigt werde, so z. B. wenn das Programm abstürze oder nur langsam reagiere, nicht aber dass das Integritätsinteresse verletzt werde. So würde trotz technischer Kenntnisse jeder Nutzer erwarten, dass das Programm die sonstigen Rechtsgüter nicht beeinträchtigt.396 Dem wird entgegengehalten, dass auch Nutzer nur den aktuellen Stand der Technik erwarten.397 Auch wenn jeder Nutzer erwarte, dass eine Software sein Integritätsinteresse nicht verletze, könne im Rahmen der deliktischen Haftung nur der aktuelle Stand der Technik erwartet werden. Soweit der Hersteller alles in seiner Macht stehende getan habe, um einen Schaden zu vermeiden, könne ihm für das Inverkehrbringen der Software kein Vorwurf gemacht werden.398 Die Produzentenhaftung hat nicht den Sinn, sämtliche Gefahren neuer Technologien dem Hersteller aufzuerlegen. Vielmehr soll sichergestellt werden, dass der Hersteller alles Mögliche zur Abwendung der Gefahren veranlasst. Würde man vom Produzenten eine absolute Sicherheit verlangen, so würde bereits bei Gegenständen des alltäglichen Lebens ein unüberschaubares und unbeherrschbares Haftungsrisiko auftreten.399 Allerdings treffen den Produzenten im Rahmen des Zumutbaren umfassende Sorgfaltspflichten, Schäden abzuwenden.400

392 Vgl. Bae/Lim, 51 %-Attacks, S. 81. 393 Allgemeiner Überblick über die Problematik: Taeger, Außervertragliche Haftung für fehlerhafte Computerprogramme, S. 186ff. 394 Belli in Gorny/Kilian, Computer-Software und Sachmängelhaftung, 68, 85. 395 Taeger, Außervertragliche Haftung für fehlerhafte Computerprogramme, S. 187. 396 Taeger, Außervertragliche Haftung für fehlerhafte Computerprogramme, S. 186f. 397 Foerste in Foerste/Graf v. Westphalen Hdb. Produkthaftung, § 24, Rn. 103ff. 398 Vgl. Foerste in Foerste/Graf v. Westphalen Hdb. Produkthaftung, § 24, Rn. 104. 399 v. Bar, Produktverantwortung und Risikoakzeptanz, 29, 30. 400 v. Bar, Produktverantwortung und Risikoakzeptanz, 29, 41.

Haftung

129

Dem kann auch nicht entgegengehalten werden, dass die Gefahr um jeden Preis auszuschließen sei, da ansonsten bewusst eine unbeherrschbare Gefahr für andere geschaffen würde.401 Solche Gefahren bestehen bei allen Produkten.402 Sie sind Teil der technischen Entwicklung und die Risiken ihrer Entwicklung und Nutzung können nicht ausschließlich dem Produzenten auferlegt werden.403 Die Schutzpflichten stehen somit immer in einem Abwägungsverhältnis zu der vom Verkehr erwarteten Sicherheit und den Möglichkeiten des Produzenten zur Gefahrenabwehr.404 Überträgt man dies auf die Möglichkeit von 51 %-Angriffen und sonstigen Anfälligkeiten der Blockchain-Technologie, ist die produzentenrechtliche Verantwortlichkeit differenziert. Die Sicherheitserwartungen für dezentrale Anwendungen sind bislang nur schwer zu bestimmen. Gerade aufgrund der bisherigen Skepsis gegenüber der Technologie wird man bei bestehenden Anwendungen wohl nicht davon ausgehen können, dass die Nutzer eine absolute Sicherheit der Anwendung erwarten. Sobald aber massentaugliche Anwendungen angeboten werden, dürfte sich dies spätestens ändern. Insoweit wird man an die Blockchain-Technologie die gleichen Anforderungen wie an sonstige Software stellen können. Mangels vergleichbarer Anwendungen kann aber nicht nur der aktuelle Stand der Technik als Bezugspunkt ausreichend sein. Dieser setzt zwingend in der Praxis erprobte Methoden voraus, die es bei neuen Technologien zu Beginn nicht geben kann.405 Da dies aber nicht den Ausschluss von Verkehrspflichten zur Folge haben kann, muss als Ersatz auf den aktuellen Stand von Wissenschaft und Technik abgestellt werden. Während bei bisheriger Software auf technische Normen als Grundlage zur Bestimmung des Zustandes von Wissenschaft und Technik zurück gegriffen werden kann,406 ist dies bei der Blockchain mangels entsprechender Normen nicht möglich. Der Aufwand, der zur Ermittlung des Standes von Wissenschaft und Technik erforderlich ist, ist somit höher als bei bereits besser erforschten Technologien. Dieser zusätzliche Aufwand ist aber aufgrund der höheren und unbekannten Risiken, die mit neuen Technologien einhergehen, den Entwicklern zuzumuten. Eine besondere Relevanz kommt dabei der Wissenschaft zu. Soweit es noch keine vergleichbaren Anwendungen gibt, muss der Stand der Wissen401 Dies vertretend: Koch/Schnupp, Software-Recht, S. 166. 402 Vgl. Pfeifer, Produktfehler oder Fehlverhalten von Produzenten, S. 89. 403 Vgl. Foerste in Foerste/Graf v. Westphalen Hdb. Produkthaftung, § 24, Rn. 108, der es spätestens am Verschulden scheitern lässt, wenn alle denkbaren Vorgaben von Wissenschaft und Technik eingehalten wurden. 404 v. Bar, Produktverantwortung und Risikoakzeptanz, 29, 39. 405 Foerste in Foerste/Graf v. Westphalen Hdb. Produkthaftung, § 24 Rn. 18; OLG Koblenz Urt. v. 21. 12. 1972-1 Ss 238/72, BB 1973, 216; Obenhaus/Kuckuck, DVBl 1980, 154; Marburger, Regeln der Technik im Recht, S. 157. 406 Förster in BeckOK BGB, § 823, Rn. 693.

130

Dezentrale Anwendungen der Sharing Economy

schaft berücksichtigt werden, welche Ausgestaltung der dezentralen Anwendung das erforderliche Maß an Sicherheit mit sich bringt. Die 51 %-Schwäche von dezentralen Anwendungen ist eine der Technologie innewohnende Gefahr, die sich nicht gänzlich ausschließen lässt. Allerdings gibt es ständige Bestrebungen, das Konsens-Verfahren zu verbessern und so Angriffe zu erschweren.407 Auf diese Art und Weise können zwar die 51 %-Attacken nicht ausgeschlossen werden, die Gefahr durch den aktuellen Stand von Wissenschaft und Technik aber deutlich reduziert werden. Auf aktuelle Entwicklungen ist Rücksicht zu nehmen, sodass bspw. das bisherige Bitcoin-Protokoll nicht mehr dem aktuellen Stand der Technik entsprechen könnte. Diese Darstellung anhand des Problems der 51 % Attacken kann gleichermaßen auf sonstige Bereiche der Blockchain übertragen werden. Zusammenfassend lässt sich damit festhalten, dass auch bei dezentralen Anwendungen Konstruktionsfehler denkbar sind. Die Haftung für sie ist weder aufgrund ihrer Natur als Software, noch aufgrund der natürlichen Angreifbarkeit der Blockchain ausgeschlossen. Der Umfang der Prüfpflichten des Entwicklers gehen wegen der Neuartigkeit der Technologie über die Pflichten bisheriger Softwareentwickler hinaus, indem er sich umfassend über sichere Konsensmechanismen und Anwendungsstruktur in Wissenschaft und Technik informieren muss. Vor allem für Smart Contracts muss aufgrund ihrer Langlebigkeit und Unveränderlichkeit detailliert die lückenlose Programmierung kontrolliert werden, bevor sie in die dezentrale Anwendung integriert werden. 2) Fabrikation-und Instruktionsfehler Im Gegensatz zu Konstruktionsfehlern erfassen Fabrikationsfehler nur einzelne Teile der Serie und sind auf fehlerhafte Vervielfältigung zurückzuführen.408 Der Vertrieb von dezentralen Anwendungen wird allerdings regelmäßig nicht über die Vervielfältigung von Datenträgern erreicht, sondern durch das Bereitstellen auf dem Server. Handelt es sich um den Server eines Dritten, haftet der Entwickler für Fehler in der Datenübertragung nur bis zu dem Zeitpunkt, zu dem das Programm fehlerfrei auf dem Server des Dritten abrufbereit ist.409 Soweit das Programm fehlerfrei konstruiert wird, beruhen Fehler bei der Datenübertragung auf der verwendeten Hardware.410 Wird die Anwendung somit auf dem eigenen Server bereitgestellt, kann der Entwickler über die allgemeinen Haftungsregeln für die Hardware verantwortlich sein. Da die Software ansonsten identisch re-

407 Bae/Lim, 51 %-Attacks, S. 81. 408 Spindler in BeckOGK BGB, § 823 Rn. 642; Urt. v. 21. 4. 1956 -VI ZR 36/55, VersR 1956,410, 411; vgl. auch Taeger, Außervertragliche Haftung für fehlerhafte Computerprogramme, S. 250. 409 Taeger, Außervertragliche Haftung für fehlerhafte Computerprogramme, S. 243. 410 Taeger, Außervertragliche Haftung für fehlerhafte Computerprogramme, S. 243.

Haftung

131

produziert wird, ist die Haftung für Fabrikationsfehler im Rahmen von dezentralen Anwendungen ausgesprochen gering. Gleiches gilt auch für die Instruktionsfehler. Gefahren, die sich trotz fehlerfreier Herstellung aus dem Programm selbst ergeben411, sind nur sehr eingeschränkt vorstellbar. Gefahren die sich unmittelbar aus der Anwendung selbst ergeben, sind einerseits die Gefahren aus der Sicherheit der Blockchain, andererseits aus der Verwendung von Wallets. Um eine Transaktion zu bestätigen ist die Verwendung eines »private keys« erforderlich. Geht dieser verloren oder wird vergessen, sind auch die dazugehörigen Token unwiederbringlich verloren. Gleichzeitig ist der private key die einzige Möglichkeit, eine Transaktion zu veranlassen, sodass jeder, der Kenntnis des private keys hat, auf die Token zugreifen kann. Die Sicherheit und Verwaltung von private keys wird zwar ebenfalls stetig optimiert, die grundlegende Gefahr bleibt jedoch bestehen.412 Es handelt sich bei den Sicherheitslücken der Blockchain selbst und der Verwendung von private keys auch nicht um offensichtliche Gefahren. Jedenfalls dann nicht, wenn sich die Anwendung an eine Vielzahl von Verbrauchern richtet.413 Bei diesen können keine vertieften technischen Kenntnisse vorausgesetzt werden; vor allem nicht, wenn sich diese von bisherigen, gut bekannten Technologien unterscheiden. So kann sich eine besondere Instruktionspflicht gerade daraus ergeben, dass Passwörter in Zeiten des Internets vielfältig vergeben werden und der Verlust in der Regel mit nur geringem Aufwand wieder hergestellt werden kann. Insgesamt spielen die Fabrikations- und Instruktionspflichten des Entwicklers aber nur eine untergeordnete Rolle. 3) Produktbeobachtungspflicht Die bisher beschriebenen Pflichten waren solche, die der Entwickler vor Veröffentlichung der DApp beachten musste. Ab dem Zeitpunkt der Veröffentlichung entsteht die Pflicht zur Produktbeobachtung.414 Teil dieser Produktbeobachtungspflicht ist die aktive Nachforschung des Entwicklers durch selbständige Recherche einschlägiger Fachliteratur, wissenschaftlicher Erkenntnisse und die Erfahrungen von Konkurrenten.415 Auf einem derartig neuen und aktiven Markt 411 BGH, Urt. v. 13. 2. 1975 -VI ZR 44/74, NJW 1975, 1957; BGH, Urt. v. 12-11-1991 -VI ZR 7/91, NJW 1992, 560. 412 Zu den Schwächen von private keys und der möglichen Optimierung: Liu u.w., An efficient method to enhance Bitcoin wallet security, https://ieeexplore.ieee.org/stamp/stamp.jsp?tp =&arnumber=8285737. 413 Vgl. zu offensichtlichen Gefahren: BGH, Urteil vom 14-03-1995 -VI ZR 34/94, juris; Spindler in BeckOGK BGB, § 823 Rn. 654. 414 Spindler in BeckOGK BGB, § 823 Rn. 661. 415 BGH Urt. v. 12. 11. 1991 -VI ZR 7/91, NJW 1992, 560; Urt. v. 17. 10. 1989 -VI ZR 258/88, NJW 1990, 906, 908; Brüggemeier, WM 1982, 1294; Spindler in BeckOGK BGB, § 823 Rn. 661ff.

132

Dezentrale Anwendungen der Sharing Economy

wie dem der dezentralen Anwendungen sind für den Entwickler von DApps vor allem die Entwicklungen der Konkurrenz und die Fortschritte der Wissenschaft entscheidend. Zu der aktiven Beobachtungspflicht tritt die passive. Der Entwickler muss Beschwerden und Hinweisen auf konkrete Gefahren nachgehen und selbständig erforschen.416 Neben der dezentralen Anwendung als solcher sind von der Produktbeobachtungspflicht auch Fehler erfasst, die erst durch die Interaktion mit anderen Anwendungen auftreten. Bei einer geschlossenen DApp ohne ergänzende Schnittstellen spielt dies nur eine untergeordnete Rolle, da lediglich die Interaktion mit dem Betriebssystem gesichert sein muss. Teilweise finden sich bei den Anwendungsentwicklern aber auch Bestrebungen, die Plattforminteraktion zu ermöglichen und vor allem auch die Datenportabilität für Nutzer zu ermöglichen. Ist eine entsprechende Funktion in der dezentralen Anwendung vorgesehen, muss der Entwickler auch das Verhalten der Anwendungen zu verbundenen Anwendungen überprüfen. Erkennt der Entwickler bei seiner Produktbeobachtung einen Fehler der DApp, so folgen hieraus nach den bisherigen Grundsätzen der Produzentenhaftung eine Warn- und/oder Rückrufpflicht.417 Grundsätzlich wird zwischen Warn- und Rückrufpflicht nach dem gefährdeten Rechtsgut differenziert.418 Dies ist bei dezentralen Anwendungen grundsätzlich »nur« das Recht an den gespeicherten Daten, das auf abstrakter Ebene nur schwer mit höherrangigen Rechtsgütern wie Leib und Leben vergleichbar ist. Dabei darf aber nicht unberücksichtigt bleiben, dass die gespeicherten Daten einen erheblichen finanziellen Wert haben und im Rahmen der Anwendung einer digitalen Währung entsprechen. Wie man am Beispiel der DAO gesehen hat, können Schäden durch Programmfehler im Rahmen von dezentralen Anwendungen auch zu Schäden im zwei- und dreistelligen Millionenbereich führen.419 Eine derartige Gefährdung würde an sich ausreichen, eine Rückrufpflicht zu begründen. Bei dezentralen Anwendungen bildet sich hier aber ein Spannungsfeld zwischen den Gefahren für die Daten der Nutzer in der Blockchain und den mit dem Rückruf verbundenen Nachteile für die Nutzer. Ein Rückruf der Anwendung führt zum Wertverlust aller ausgegebenen Token. Im Gegensatz zu körperlichen Gegenständen und sonstiger Software sind in der Blockchain Vermögenswerte gespeichert, die durch den Rückruf nahezu vollständig entwertet werden. Diese 416 Tiedmann FS Hirsch, Körperverletzung und strafrechtliche Produktverantwortung, 765, 770f.; Wagner, VersR 2014, 905, 906. 417 BGH, Urteil vom 16. 12. 2008 -VI ZR 170/07, NJW 2009, 1080; Urt. v. 7. 12. 1993 -VI ZR 74/93, NJW, 1994, 517; Urt. v. 6. 7. 1990-2 StR 549/89, NJW1990, 2550. 418 Spindler in BeckOGK BGB, § 823 Rn. 665ff. 419 Bei der aktuellen Kursentwicklung sind auch Schäden in Höhe von mehreren Milliarden nicht mehr unrealistisch.

Haftung

133

Schäden gehen deutlich über den Nutzwert der Anwendung für den Einzelnen hinaus. Obwohl der Entwickler nicht für den Wertverlust der Token im Rahmen des Deliktsrechts haftet, kann ihm trotzdem keine Pflicht zum Schutze der Nutzer auferlegt werden, die letztlich nicht den Interessen der Nutzer entspräche und ggf. einen deutlich erheblicheren Schaden mit sich brächte. Für Sicherheitslücken ist aber auch die Warnpflicht nicht geeignet, den Wertverlust der Token zu verhindern. Erfolgt kein Rückruf, sondern lediglich eine Warnung vor der Sicherheitslücke, hat sie zum einen zur Folge, dass der Nutzwert der Anwendung fällt und damit einhergehend auch der Wert der Token. Gleichzeitig ermöglicht aber gerade die Warnung vor der Sicherheitslücke es Dritten, diese gezielt auszunutzen und den Schaden für die Nutzer zu vertiefen.420 Ein Ausgleich der Interessen der Nutzer am Schutz vor Gefahren einerseits und dem Werterhalt der Token andererseits kann im Rahmen der Produzentenhaftung nur schwer erreicht werden. Vor allem obliegt es dem Produzenten, auf eigene Gefahr zu entscheiden, welche Handlung zur Abwendung der Gefahr erforderlich ist.421 Rechtssicherheit kann hier für den Produzenten kaum bestehen und jede Wahl geht mit einem erheblichen Haftungsrisiko einher. Der Entwickler muss, wie nach den bisherigen Grundsätzen, eine Abwägung zwischen den bedrohten Interessen der Nutzer vornehmen. So kann beispielsweise gerade bei der Interaktion mit anderen Anwendungen eine Warnpflicht zur Verhinderung von Schäden eintreten, ohne dass der Nutzungswert der Anwendung erheblich reduziert wird. Auch bei sonstigen Gefahren, die nicht zum kompletten Wertverlust der Token führen, kann die Warnpflicht ausreichend sein. Vor allem bei mangelhaften Smart Contracts muss ein Fehler nicht zum kompletten Nutzungsausfall der Anwendung führen. Hier sind auch nur geringfügige Schäden denkbar, abhängig von dem Verwendungszweck des Smart Contracts. Bei Gefahren, die die Nutzung der Anwendung an sich gefährden, könnte eine Lösung das Anbieten eines Updates zur Fehlerbehebung sein. Hierbei stellt sich allerdings das Problem, dass der Entwickler an sich nicht für das Integritätsinteresse der Nutzer einzustehen hat. Dieses Problem stellte sich auch schon bei bisheriger Software vor dem Hintergrund volkswirtschaftlicher Schäden bei Sicherheitslücken von weit verbreiteter Software.422 In jüngerer Zeit wurde die Idee der Pflicht zum Softwareupdate als Rechtsfolge der Verantwortlichkeit des Produzenten wiederholt diskutiert.423 Hier wird 420 v. Bar, Produktverantwortung und Risikoakzeptanz, 29, 44ff.; Spindler in BeckOGK BGB, § 823 Rn. 668ff. 421 v. Bar, Produktverantwortung und Risikoakzeptanz, 29, 43; Hess in Martinek/Semler/Flohr HdB VertriebsR, § 12 Rn. 65. 422 Spindler, NJW 2004, 3145, 3147f. 423 Wiebe, NJW 2019, 625; Schrader/Engstler, MMR 2018, 356; Philipp Reusch, BB 2019, 904, 908f.

134

Dezentrale Anwendungen der Sharing Economy

aber eine Haftung aus § 823 I BGB auf Bereitstellung eines Software-Updates verneint, da die Fehlerhaftigkeit des Produktes nur das Integritätsinteresse des Nutzers betrifft. Im Grundsatz ist auch eine dezentrale Anwendung lediglich eine Software. Dennoch könnte eine Produzentenhaftung bei der dezentralen Anwendung mit der Pflicht zum Software-Update in Betracht kommen. Zum einen besteht bei Sicherheitslücken keine sonstige geeignete Maßnahme des Entwicklers, um die Gefahren, die von seiner Anwendung ausgehen, abzuwenden. Zum andern mag der Nutzer zwar keinen Anspruch auf eine fehlerfreie Anwendung haben, er muss aber vor den von dieser ausgehenden Gefahren umfassend geschützt werden, da sich sein Interesse nicht nur auf die Nutzung der Anwendung selbst bezieht, sondern auch auf die Sicherung seiner in der Blockchain gespeicherten Daten. Wenn durch ein Software-Update auch das Integritätsinteresse des Nutzer geschützt wird, dann nur soweit seine Rechtsgüter gefährdet sind. Insoweit erübrigt sich eine Betrachtung des Integritätsinteresse. Der Entwickler ist dazu verpflichtet, die geeigneten Maßnahmen zur Gefahrenabwehr zu treffen. Bei erheblichen Gefahren für die Daten der Nutzer muss er demnach auch die Sicherheitslücke in der DApp schließen. Auch wenn hierdurch die Nutzbarkeit der Anwendung wieder hergestellt wird, ist dies lediglich ein Reflex aus der Schutzpflicht des Entwicklers. Gleichwohl geht damit kein Anspruch des Nutzers auf eine fehlerfreie DApp einher. Für sonstige Fehler bleibt es bei dem Grundsatz, dass eine Haftung für das Integritätsinteresse nicht besteht. Hierbei bleibt noch unberücksichtigt, dass der Entwickler keinen Einfluss auf die tatsächliche Implementierung hat. Auch wenn er ein Software-Update zur Verfügung stellt, bedeutet dies nicht, dass es auch von der Mehrheit der Nodes übernommen und damit die Sicherheitslücke geschlossen wird. Im Gegensatz zu bisheriger Software können nicht mehr Nutzer und Entwickler entscheiden, ob ein Update in der DApp umgesetzt wird. Dass eine Umsetzung nicht gewährleistet wird, kann aber nicht zum Ausschluss der Pflicht des Entwicklers führen. Unabhängig von der Implementierung des Updates muss der Entwickler das seinerseits Zumutbare leisten, um die Gefahr abzuwenden. Auch wenn die finale Schadensabwehr nicht gesichert ist, bleibt die Pflicht des Entwicklers bestehen. Die Frage nach den Pflichten des Entwicklers wird damit unabhängig von Ansprüchen der Nutzer gegen die Nodes der Blockchain auf Implementierung eines Sicherheitsupdates beantwortet. Insgesamt besteht auch nach der Inverkehrgabe der Anwendung eine Produktbeobachtungspflicht, die Pflichten des Herstellers zur Warnung, Rückruf und Fehlerbehebung begründen kann. Dabei ist bei Sicherheitslücken das Update dem Rückruf mit der gravierenden Folge des Wertverlustes der Token für die Nutzer vorzuziehen. Bei sonstigen Fehlern, insbesondere der Interaktion mit anderen Anwendungen, ist eine Warnung hingegen ausreichend. Die letztend-

Haftung

135

liche Abwägung der erforderlichen und geeigneten Handlungspflichten und dem damit einhergehenden Haftungsrisiko bei einer fehlerhaften Abwägung obliegt dem Entwickler. cc. Vertretenmüssen und Beweislastumkehr Grundsätzlich gilt im Rahmen der Produkthaftung die Haftung des § 823 I BGB für Vorsatz und Fahrlässigkeit. Allerdings muss die vertragliche Haftung des Entwicklers berücksichtigt werden. Im Rahmen der vertraglichen Haftungsprivilegierung analog § 521 BGB haftet der Entwickler nur für Vorsatz und grobe Fahrlässigkeit. Die Haftungsprivilegierung ist bei Ansprüchen von Vertragspartnern grundsätzlich zu übertragen, soweit der deliktische Anspruch im Zusammenhang mit der DApp steht, was überwiegend der Fall sein dürfte. Spräche man sich gegen eine Übertragung des Haftungsprivilegs des § 521 BGB aus, liefe der vertragliche Schutz des Schenkers leer.424 Faktisch führt dies aber nur unmerklich zu einer Privilegierung des Entwicklers. Zwar verringert sich der Kreis der Anspruchssteller, die allgemeinen Verkehrssicherungspflichten bleiben aber bestehen. Insbesondere wird bei einer breitflächig genutzten DApp nicht zu jedem Nutzer ein vertragliches Verhältnis bestehen. Gerade im Rahmen der passiven Produktbeobachtungspflicht führt der korrigierte Haftungsmaßstab kaum zu einer Privilegierung. Erfährt der Entwickler von Gefahren für die Nutzer muss er auch hier die erforderlichen Schutzmaßnahmen ergreifen. Kommt es zum Haftungsfall wird zwar die Haftungssumme bei einer fahrlässigen Pflichtverletzung auf den Kreis der sonstigen Nutzer reduziert, gleichzeitig profitieren aber auch die Nutzer, die in einem Vertragsverhältnis zum Entwickler stehen, von den Updates und sonstigen Sicherheitsmaßnahmen. Gegenüber den sonstigen Nutzern, die in keinem Vertragsverhältnis zum Entwickler stehen, haftet der Entwickler nach wie vor für jede Form von Vorsatz und Fahrlässigkeit. Besonderheit der Produzentenhaftung ist lediglich die Beweislastumkehr hinsichtlich des Verschuldens. Hierbei ergeben sich für die DApp keine Abweichungen von den bisherigen Grundsätzen der Produzentenhaftung. Den Produktfehler muss zunächst der Geschädigte, hier der Nutzer, nachweisen.425 Besondere Bedeutung kommt hierbei dem Anscheinsbeweis zu. Dieser greift ein, wenn keine Anzeichen für eine nachträgliche Produktveränderung bestehen oder eine solche unmöglich ist.426 Aufgrund der Transparenz des Codes der Anwendung und der Historie kann für die Blockchain eindeutig nachgewiesen werden, 424 BGH, Urt. v. 20. 10. 1953 -I ZR 125/52, NJW 1954, 145; Urt. v. 23. 3. 1966 -I b ZR 150/6346, NJW 1967, 42; Medicus in FS Odersky, 589, 597; Harke in BeckOGK BGB, § 521 Rn. 16. 425 OLG Schleswig, Urt. v. 24. 4. 2012 – 11 U 123/11, NJOZ 2013,1366, 1367; Wagner in MüKo BGB, § 823 Rn. 1014. 426 RG Urt. v. 06. 11. 1919 – VI 215/19, RGZ 97, 116, 117.

136

Dezentrale Anwendungen der Sharing Economy

welche Abschnitte des Codes vom Hersteller selbst und welche erst durch eine nachträgliche Veränderungen Teil der DApp geworden sind. Da dieser Fehler auch bei allen Nodes einheitlich auftritt, ist auch der Konstruktionsfehler eindeutig nachweisbar.427 Die Erschütterung des ersten Anscheins wird dem Entwickler regelmäßig nur dann gelingen, wenn er nachweist, dass nach damaligem Stand der Technik kein Entwicklungsfehler vorlag.428 Für das Verschulden gilt die Beweislastumkehr.429 Allein der Entwickler kann die Produktion der DApp überblicken. Die Aufklärung eines fehlenden Verschuldens im Produktionsvorgang fällt in seinen Verantwortungsbereich.430 dd. Zwischenergebnis Auch wenn der Entwickler für Produktfehler nach dem § 823 I BGB haftet, ist dieser Schutz durch die Limitierungen des Deliktsrechts beschränkt, insbesondere des ersatzfähigen Schadens. Letztlich führt die Beschränkung auf Schäden bei Datenveränderung nur zu einem Schutz vor dem Verlust von Token. Sonstige Schäden sind über das geschützte Rechtsgut »Daten« nicht ersatzfähig. Wenn eine vertragliche Beziehung zum Entwickler besteht, so ist dieser über die Analogie zu § 521 BGB nur für grobe Fahrlässigkeit und Vorsatz verantwortlich. Daraus ergibt sich, dass die Nutzung von DApps weitestgehend auf eigene Verantwortung des Nutzers erfolgt und dieser eintretende Schäden in weitem Umfang selbst tragen muss. Dies steht im Kontrast zur Unerfahrenheit des Nutzers mit der neuartigen Technologie und ihren Gefahren. Es kann nicht angenommen werden, dass bei massentauglichen DApps die Nutzer ausreichende Kenntnisse über die Gefahren der Anwendungen besitzen. Die Schadensrisiken stehen insgesamt in keinem Verhältnis zum Verantwortungsbewusstsein der Nutzer. b. Produkthaftung Neben die Haftung des Produzenten nach § 823 I BGB tritt die Verantwortlichkeit nach dem Produkthaftungsgesetz. Um einen Anspruch gem. § 1 I ProdHaftG auf Schadensersatz zu begründen, müssen im Wesentlichen zwei Hürden genommen werden: die Klassifizierung der DApp als Produkt i. S. d. § 2 ProdHaftG und eine qualifizierte Schädigung an Körper, Gesundheit oder Beschädigung einer Sache.

427 BGH, Urt. v. 9. 5. 1955 -II ZR 31/54, NJW 1995, 1105; BGH, Urt. v. 26. 11. 1968 -VI ZR 212/66, NJW 1969, 267, 274. 428 Vgl. BGH, Urt. v. 11. 06. 1996 -VI ZR 202/95, NJW 1996, 2507, 2508; Spindler in BeckOGK BGB; § 823 Rn. 724. 429 BGH, Urt. v. 26. 11. 1968 -VI ZR 212/66, NJW 1969, 269; Spindler in BeckOGK BGB, § 823 Rn. 716ff. 430 BGH, Urt. v. 19. 11. 1991 -VI ZR 171/91, NJW 1992, 1039; BGH, Urt. v. 26. 11. 1968 -VI ZR 212/ 66, NJW 1969, 269.

Haftung

137

Wie bereits festgestellt handelt es sich bei der DApp um Software. Daher kann auf die Diskussion zur Erfassung von Software im Rahmen des ProdHaftG zurückgegriffen werden.431 Es ist lediglich als Besonderheit der DApp zu berücksichtigen, dass sie von vornherein nicht auf einem physischen Datenträger an den Nutzer übergeben, sondern mittels Download über Webseiten geladen wird. Fraglich ist also, ob die DApp losgelöst von einer physischen Verkörperung als Produkt zu behandeln ist. Vom Wortlaut des § 2 ProdHaftG ausgehend ist der Begriff der beweglichen Sache i. S. d. § 2 ProdHaftG entscheidend. Teilweise wird für die Begriffsbestimmung unmittelbar auf die Definition des § 90 BGB abgestellt, sodass die Software als solche nicht als Produkt erachtet wird.432 Diese Meinung stützt sich unter anderem auch auf die Erwägungsgründe des Gesetzentwurfes, der zwar nach Vorgabe der Richtlinie die Elektrizität einbezieht, ansonsten aber ausschließlich auf den Sachbegriff des § 90 BGB abstellt.433 Sonstige Güter, die in einen Grenzbereich fallen, wie z. B. Fernwärme, sollten im Gesetzestext ausdrücklich nicht aufgegriffen werden, da hier die Definition des § 90 BGB als Abgrenzung für ausreichend erachtet wurde.434 Dem engen Verständnis des § 2 ProdHaftG werden sowohl historische als auch teleologische Argumente entgegengehalten. Indem es sich um eine Umsetzung der Produkthaftungsrichtlinie (ProfHaftRl)435 handelt, sollen sich Indizien aus Anmerkungen der Kommissionsmitglieder zu der Richtlinie ergeben.436 Aus den Anmerkungen ergibt sich aber keineswegs ein klares Verständnis.437 Hier wird lediglich festgestellt, dass sich die ProdHaftRl auf bewegliche Sachen bezieht.438 Der Rückschluss der Kommission, dass daher auch die Software erfasst sei, wird weder begründet noch anhand des Kriteriums der physischen Manifestation abgegrenzt. Insoweit ermöglicht diese Auskunft keine Rückschlüsse auf den Willen des Gesetzgebers bei der Umsetzung der Richtlinie. Nachvollziehbar wird hingegen begründet, dass es aus Sicht des Verbraucherschutzes keinen Unterschied machen kann, ob die Software über einen 431 Taeger, Außervertragliche Haftung für fehlerhafte Computerprogramme, S. 160ff.; Robin in BeckOGK ProdHaftG, § 2 Rn. 49ff.; Wagner in MüKo BGB, ProdHaftG § 2 Rn. 21ff.; BGH, Urt. v. 04. 11. 1987 -VIII ZR 314/86, NJW 1988, 406ff. 432 Graf v. Westphalen, NJW 1990, 83, 87; Honsell, JuS 1995, 211, 212; Bartsch, CR 1989, 692, 694; Wiebe zum Produktsicherheitsgesetz: NJW 2019, 625, 626. 433 BT-Dr 11/2447, S. 16. 434 BT-Dr 11/2447, S. 16. 435 Richtlinie des Rates zur Angleichung der Rechts-und Verwaltungsvorschriften der Mitgliedstaaten über die Haftung für fehlerhafte Produkte 85/374/EWG. 436 Rebin in BeckOGK ProdHaftG, § 2 Rn. 52; Förster in BeckOK BGB, § 2 ProdHaftG Rn. 22. 437 Antwort der Kommission auf schriftliche Anfrage: 89/C 114/76 auf Frage Nr. 706/88, ABl. C 114 v. 8. 5. 1989, 42. 438 Antwort der Kommission auf schriftliche Anfrage: 89/C 114/76 auf Frage Nr. 706/88, ABl. C 114 v. 8. 5. 1989, 42.

138

Dezentrale Anwendungen der Sharing Economy

physischen Datenträger verkörpert oder unverkörpert übertragen wird.439 Ein solches Verständnis zur Erreichung des Ziels des Verbraucherschutzes der ProdHaftRl muss jedoch auch mit dem Wortlaut und dem Willen des Gesetzgebers vereinbar sein. Indem der Gesetzgeber ausdrücklich die nichtkörperliche Elektrizität einbezieht, aber keine sonstigen Immaterialgüter, und auch am Begriff der beweglichen Sache festhält, kann Software nur unter § 2 ProdHaftG fallen, wenn eine körperlich losgelöste Software zum damaligen Zeitpunkt vom Gesetzgeber nicht vorstellbar war.440 Die damalige Literatur zeigt, dass die Möglichkeit zur Fernübertragung von Software zum Zeitpunkt der Verabschiedung des ProdHaftG nicht vorstellbar war.441 Es wird zwar schon die Frage erörtert, ob die Software selbst auch ohne Datenträger unter § 2 ProdHaftG fallen würde Dies wird anschließend aber in Hinblick auf die fehlende Nutzbarkeit der Software abgelehnt.442 Selbst zehn Jahre später muss die Möglichkeit zur Fernübertragung von Software noch umständlich erläutert werden.443 Aufgrund dieser Beispiele kann weder unterstellt werden, dass der Gesetzgeber Software bewusst aus dem Anwendungsbereich herausnehmen wollte, noch dass eine Rechtsfortbildungssperre die Ausdehnung des Produktbegriffes auf reine Software verbietet.444 Somit ist auch die DApp als Software eine bewegliche Sache i. S. d. § 2 ProdHaftG. Das ProdHaftG ist grundsätzlich auf die DApp anwendbar. Es bleibt zu klären, ob durch eine fehlerhafte DApp auch ersatzfähige Schäden i. S. d. § 1 ProdHaftG entstehen können. Dabei kann, wie bei der Produzentenhaftung nach § 823 I BGB, die Verletzung von Körper und Leben vernachlässigt werden. Die durch die DApp enstehenden Schäden beeinträchtigen primär die gespeicherten Daten. Diese müssten eine andere Sache i. S. d. § 1 I ProdHaftG sein. Nur vereinzelt wird in der bisherigen Literatur ausdrücklich festgehalten, dass hierfür auf den Sachbegriff des § 90 BGB abgestellt werden muss.445 Im Übrigen wird dies, teils unter Verweis auf § 303 StGB, ohne weitere Ausführungen vorausgesetzt.446 Damit scheiden die veränderten Daten selbst als Beschädigungsobjekt aus, da es diesen an der erforderlichen Körperlichkeit einer Sache

439 Taeger, Außervertragliche Haftung für fehlerhafte Computerprogramme, S. 164f.; Rebin in BeckOGK BGB, § 2 ProdHaftG Rn. 52; Meier, CR 1990, 95, 99; Heymann, CR 1990, 176, 177; Dörner, Jura 1993, 578, 580. 440 Wagner in MüKo BGB, § 2 ProdHaftG Rn. 27. 441 Mehrings, NJW 1986, 1904. 442 Mehrings, NJW 1986, 1904. 443 Taeger, Außervertragliche Haftung für fehlerhafte Computerprogramme, S. 162. 444 Wagner in MüKo BGB, § 2 ProdHaftG Rn. 27. 445 Förster in BeckOK BGB, § 1 ProdHaftG Rn. 19. 446 Seibl in BeckOGK BGB, § 1 ProdHaftG Rn. 33; ohne jegliche Erklärung: Wagner in MüKo BGB, § 1 ProdHaftG Rn. 8ff.

Haftung

139

mangelt.447 Wie schon bei der Eigentumsbeeinträchtigung im Rahmen des § 823 I BGB könnte aber auf das Speichermedium als Sache abgestellt werden. Die Festplatte selbst ist unzweifelhaft ein körperlicher Gegenstand und somit eine Sache gem. § 90 BGB. Allerdings muss sie auch eine »andere« Sache gem. § 1 I S. 2 ProdHaftG sein. Der Bezugspunkt lässt sich nur in Verbindung mit dem Wortlaut des § 2 ProdHaftG verstehen. Da dort ein Produkt als bewegliche Sache definiert wird und § 1 ProdHaftG auf das Produkt abstellt, muss im Rahmen der »anderen« Sache eine Abgrenzung zum festgestellten Produkt vorgenommen werden, mithin die Abgrenzung zwischen DApp und Speichermedium. Da die DApp selbst keine Sache i. S. d. § 90 BGB, wohl aber eine bewegliche Sache i. S. d. § 1 ProdHaftG ist, ist ein Vergleich anhand des natürlichen Wortverständnisses mit einer Sache i. S. d. § 90 BGB nicht sinnvoll. Das Ergebnis wäre, wie schon bei der ursprünglichen Subsumtion im Rahmen des § 2 ProdHaftG, dass die DApp eben etwas anderes als das Speichermedium ist. Indem aber festgestellt wird, dass die DApp dennoch ein Produkt sein kann und somit auch ein Vergleich im Rahmen des § 1 ProdHaftG möglich sein muss, fällt der Vergleich nach der natürlichen Vorstellung schwer. Zumindest für den Vergleich muss die DApp so behandelt werden, als könnte sie ein körperlicher Gegenstand sein. Bildhaft lässt sich dies vorstellen, indem man die DApp als fest abgrenzbaren, räumlichen Bereich auf dem Speichermedium betrachtet. Dann stellt sich die DApp als Teil des Speichermediums dar. Die Frage, wann bei Teilen einer Sache ein Schaden an einer »anderen« Sache eintritt, wird hingegen umfangreich im Schrifttum und Rechtsprechung diskutiert.448 Grundsätzlich ist der Begriff der anderen Sache nach der Verkehrsanschauung zu bestimmen.449 Dabei soll nicht auf das kleinste mögliche Einzelteil abgestellt werden, sondern auf das Produkt, wie es der Kunde erworben hat.450 Uneinigkeit besteht darüber, ob im Übrigen auf die Rechtsprechung zum Weiterfresserschaden des BGH zur Abgrenzung abgestellt werden darf.451 Bei der Datenveränderung innerhalb der DApp handelt sich allerdings nicht um einen Weiterfresserschaden, sodass auch die Diskussion hierzu nicht weitergehend ausgeführt werden muss. Betrachtet man die DApp weiterhin 447 Redeker, NJW 1992, 1739; Moritz, CR 1994, 257, 259ff.; Schneider in Schneider/ Graf v. Westphalen, Software-Erstellungsverträge, B 15; Ohly in Vieweg/Gerhäuser, Digitale Daten in Geräten und Systemen, S. 123; Bartsch, CR 2010, 553, 554f.; Stresemann in MüKo BGB, § 90 Rn. 25. 448 D. Looschelders, JR 2003, 309, 310; Wagner, AcP, 2017, 707, 723f.; Katzenmeier, NJW 1997, 486, 492; Graf v. Westphalen, Jura 1992, 511, 513f.; Keilholz, BauR 1987, 259, 260f.; OLG Stuttgart, Urt. v. 24. 9. 2009-7 U 89/09, NZM 2010, 626, 628. 449 BT-Dr 11/2447, S. 16. 450 BT-Dr 11/2447, S. 16. 451 Ablehnend: OLG Stuttgart, Urt. v. 24. 9. 2009-7 U 89/09, NZM 2010, 626, 628; D. Looschelders, JR 2003, 309, 310; befürwortend: Graf v. Westphalen, Jura 1992, 511, 513f.; Keilholz, BauR 1987, 259, 260f.

140

Dezentrale Anwendungen der Sharing Economy

als abgegrenzten Bereich auf dem Speichermedium, so erfolgen die Veränderungen nur innerhalb dieses Bereiches. Der Rest des Speichermediums wird nicht beeinträchtigt. Genauso wenig ist das Speichermedium beschädigt, falls man die DApp von diesem entfernt. Auch wenn diese Darstellung die Vorgänge der Datenspeicherung auf Datenträgern stark vereinfacht, genügt es, um die Frage nach der Verkehrsauffassung zu beantworten. Nach dem allg. Verständnis wird nicht eine »andere Sache« in Form des Speichermediums beschädigt, wenn Änderungen an der DApp vorgenommen werden. Erst wenn Schäden jenseits des abgegrenzten Bereiches der DApp eintreten, handelt es sich um einen Weiterfresserschaden, bei dem auf die erwähnte Diskussion eingegangen werden müsste. Nach der Verkehrsauffassung kann es sich nicht um die Beschädigung einer anderen Sache i. S. d. § 1 I S. 1 ProdHaftG handeln, wenn lediglich Daten innerhalb der Blockchain verändert werden. Eine Vielzahl von Schäden ist gem. § 1 I ProdHaftG nicht ersatzfähig. Anwendungsfälle könnten sich aber bei Schäden an Schnittstellenkomponenten ergeben. Es kann auch nicht auf die Daten selbst als beeinträchtigtes Rechtsgut abgestellt werden, da im Gegensatz zu § 823 I BGB keine Ausdehnung des Anwendungsbereichs durch einen unbestimmten Rechtsbegriff (»sonstiges Recht«) erfolgt. Insgesamt stellt die DApp zwar ein Produkt im Sinne des Produkthaftungsrechts dar. Solange allerdings lediglich Schäden durch die Veränderungen von Daten in der DApp entstehen, sind sie nicht im Rahmen des § 1 I ProdHaftG ersatzfähig. 3.

Haftung bei maßgeblichem Einfluss

Über die bisher diskutierte Haftung hinaus könnte der Anwendungsentwickler auch für die über die Plattform geschlossenen Verträge verantwortlich sein. Zunächst ist festzuhalten, dass eine deliktische Haftung über die zuvor aufgezeigten Schutzpflichten hinaus nicht in Betracht kommt. Auch das ProdHaftG hilft mangels Veräußerung einer Sache in der Sharing Economy nicht weiter. Letztlich bleibt eine Haftung auf Grundlage von vertraglichen und vertragsähnlichen Beziehungen. Vertragspartner wird der Entwickler für die angebotenen Leistungen nicht.452 Darüber hinaus gibt es zwischen Nutzer und Entwickler weder Vertragsverhandlungen noch bahnt sich ein Vertragsverhältnis i. S. d. § 311 II BGB an. Auch

452 Siehe dazu: § 4 I. 1. a. aa. 1).

Haftung

141

kann hier kein Plattformnutzungsvertrag zur Auslegung der Schutzpflichten gem. § 241 II BGB herangezogen werden. Es muss daher auf den Ansatz zur Vertrauenshaftung von Plattformbetreibern zurückgegriffen werden.453 Möchte man die Haftung an §§ 280 I, 241 II BGB anknüpfen, müsste der Anwendungsentwickler ein besonderes Vertrauen i. S. d. § 311 III BGB für sich in Anspruch nehmen. Dabei können zunächst die beiden anerkannten Fallgruppen des § 311 III BGB diskutiert werden.454 Wenn schon unmittelbare aus einer Transaktion erwirtschaftete Provisionen und Gewinne nicht für ein eigenes wirtschaftliches Interesse ausreichen, muss dies erst recht für den Gewinn durch eine deutlich im Voraus der Transaktion erfolgte Veräußerung von Token gelten.455 Konkret für Plattformen wird teilweise auf die Steigerung der Nutzerzahl als eigenes wirtschaftliches Interesse abgestellt.456 Auch wenn dies unter dem Gesichtspunkt des notwendigen unmittelbaren wirtschaftlichen Nutzens aus der Gegenleistung zweifelhafter scheint457, kann dies für den Anwendungsentwickler abgelehnt werden. Sein wirtschaftliches Interesse begrenzt sich auf den Zeitpunkt der Veröffentlichung. Ein unmittelbarer Nutzen aus späteren Nutzerzahlen besteht nicht. Soweit er weiterhin Inhaber von Token ist, steigt der Wert mit zunehmender Nutzerzahl. In diesem Rahmen ist er aber lediglich ähnlich einem Aktionär anzusehen.458 Für den Anwendungsentwickler besteht somit kein für § 311 III BGB erforderliches unmittelbares wirtschaftliches Interesse. Der Anwendungsentwickler könnte aber durch die Schaffung der Infrastruktur ein besonderes persönliches Vertrauen in Anspruch nehmen. Er mag zwar eine Gewähr für die Sicherheit der Anwendung übernehmen, aber hierauf kann keinesfalls ein Vertrauen in die angebotenen Leistungen gestützt werden. Der Entwickler hat zum Zeitpunkt des Vertragsschlusses zwischen Nutzer und Anbieter keinen Einfluss mehr auf die Anwendung und tritt auch nicht gegenüber dem Nutzer nach außen hin auf. Ein besonderes Vertrauen ließe sich unter Umständen auf Bewertungs-und Rankingalgorithmen stützen.459 Gerade bei Bewertungen trifft der Entwickler aber keine eigene Aussage, sondern es kommt 453 Siehe dazu § 2 III 2.; Busch, Effektiver Verbraucherschutz im Online-Handel, https://tin yurl.com/2nxenjx8, S. 34ff. 454 Überblick: Sutschet in BeckOK BGB, § 311 Rn. 121ff. 455 Zu den Anforderungen an das wirtschaftliche Interesse: BGH, Urt. v. 06. 06. 1994 -II ZR 292/ 91, NJW 1994, 2220ff.; Urt. v. 27. 03. 1995 -II ZR 136/94, NJW 1995, 1544ff.; Urt. v. 5. 10. 2001 -V ZR 275/00, NJW 2002, 208ff. 456 Hauck/Blaut, NJW, 1425, 1429. 457 BGH Urt. v. 5. 10. 2001 -V ZR 275/00, NJW 2002, 208, 210; Urt. v. 27. 03. 1995 -II ZR 136/94, NJW 1995, 1544. 458 Dies korrespondiert letztlich zu Kategorisierung der Token als wertpapierähnlich, vgl. §4 I. 2.b. dd. 459 Busch, Effektiver Verbraucherschutz im Online-Handel, https://tinyurl.com/2nxenjx8, S. 33.

142

Dezentrale Anwendungen der Sharing Economy

gerade darauf an, dass es sich um subjektive Meinungen anderer Nutzer handelt.460 Hieraus ergibt sich letztlich der Wert von Bewertungen auf Plattformen. Wenn es für den durchschnittlichen Nutzer aber nicht um eigene Aussagen des Entwicklers handelt, kann hieraus auch kein besonderes Vertrauen diesem gegenüber begründet werden. Bei Rankingalgorithmen greift dieses Argument nicht. Gerade wenn es sich um einen intransparenten Algorithmus handelt, kann für eine eigene Auswahl des Entwicklers argumentiert werden. Selbst wenn er aber noch Einfluss auf die Anwendung hätte, ginge aus einem Ranking wie »unsere Besten« o. ä. aber kein Vertrauen bezüglich eines konkreten Vertragsverhältnisses hervor. Inhaltlich wird dabei weder ein Produkt besonders beworben noch eine konkrete Aussage zur vertraglichen Leistung getroffen. Anders ließe sich nur dann argumentieren, wenn ein Anbieter trotz Kenntnis des Entwicklers von mehrfachen, schwerwiegenden Pflichtverletzungen positiv in Rankings hervorgehoben wird. Allerdings hat auch hierauf der Entwickler keinen Einfluss mehr. Selbst wenn ihm ein solcher Anbieter bekannt ist, ist es dem Entwickler nicht möglich, das Ranking anzupassen. Es kommt somit darauf an, ob der Entwickler durch die ursprüngliche Entwicklung des Rankingalgorithmus’ dauerhaft ein persönliches Vertrauen begründet. Hierbei kollidiert letztlich die Möglichkeit der tatsächlichen Einflussnahme mit der Vorstellung des durchschnittlichen Nutzers. Von letzterem kann aktuell letztlich nicht erwartet werden, dass ihm die fehlende Möglichkeit zur Einflussnahme durch den Entwickler bewusst ist. Dies gilt vor allem dann, wenn die Anwendung im Front-End-Interface nicht als eine dezentrale Anwendung erkennbar ist. Diese Kollision muss letztlich zulasten des Nutzers aufgelöst werden. Die Haftung des § 311 II, III BGB erstreckt sich auf den Einwirkungsbereich des Vertragspartners.461 Ihm ist kein Vorwurf daraus zu machen, dass er einen Rankingalgorithmus erstellt. Dieser wird gerade von den Nutzern gewünscht und ist zur angemessenen Nutzung der Anwendung notwendig. Soweit hier nicht schon Kriterien verwendet werden, die eine spätere Schädigung der Rechtsgüter der Nutzer nahelegen, kann der Entwickler nicht für eine Diskrepanz zwischen Rankingergebnis und tatsächlicher Lage verantwortlich gemacht werden. Insgesamt nimmt der Anwendungsentwickler kein besonderes Vertrauen für sich in Anspruch. Der Entwickler einer dezentralen Anwendung haftet den Nutzern gegenüber nicht gem. § 280 I, 241 II, 311 III BGB für Schäden, die ihnen aus dem Vertrag mit

460 Leistner in FS Köhler, Die Haftung von Kauf- und Buchungsportalen mit Bewertungsfunktionen, 415, 426. 461 Sutschet in BeckOK BGB, § 311 Rn. 56.

Haftung

143

einem Anbieter entstehen. Genauso wenig haftet er dem Anbieter gegenüber für die Solvenz des Nutzers.

II.

Haftung der Node-Betreiber

Wesentliches Problem der Haftung des Entwicklers ist, dass mit ihr zwar gegebenenfalls Schadensersatz gewährt werden kann, die Schadensursache aber selbst nicht behoben wird und künftige Beeinträchtigungen zu befürchten sind. Selbst wenn der Entwickler im Rahmen seiner Produktbeobachtungspflicht zur Bereitstellung eines Updates verpflichtet ist, führt sie nicht automatisch zur Implementierung des Updates. Änderungen an der DApp können nur von einer Mehrheit der Nodes umgesetzt werden. Neben der Frage der Haftung für bereits eingetretene Schäden, ist daher zu entscheiden, ob und in welchem Rahmen die Nutzer einen Anspruch gegen die Node-Betreiber auf Korrektur der Anwendung haben. Wenn eine derartige Korrektur ausbleibt, stellt sich anschließend die Frage, ob die Node-Betreiber für künftige Schäden einstehen müssen. Neben die schadensrechtlichen Korrekturen tritt zuletzt noch die Frage, ob die Nodes dafür verantwortlich sind, dass die DApp den gesetzlichen Vorgaben entspricht und gegebenenfalls angepasst werden muss. Für Haftungsansprüche stellt sich zunächst die Frage, ob es eine Gesamtheit der Nodes gibt, die als Kollektiv in Anspruch genommen werden kann. Dazu muss zunächst geklärt werden, ob die Gesamtheit der Nodes eine eigene Rechtspersönlichkeit bildet. 1.

Haftung als Gesellschaft

Der Zusammenschluss der Nodes zur Aufrechterhaltung und Fortführung der DApp könnte den Willen zur Förderung eines gemeinsamen Zwecks darstellen und zur Einordnung als Gesellschaft bürgerlichen Rechts (GbR) führen. Dies hätte weitreichende Folgen für die Rechte und Pflichten der Node-Betreiber: unter anderem für die Geschäftsführungsbefugnis, §§ 709ff. BGB, die Auflösung bei Kündigung eines Gesellschafters, § 723 BGB, die Haftung jedes Gesellschafters für die Verbindlichkeiten der Gesellschaft, analog § 128 HGB. Schon die Rechtsfolgen wecken Zweifel an der Einordnung als GbR. Durch die Anwendung des § 128 HGB analog für die GbR könnte jeder Node-Betreiber für die gesamten Verbindlichkeiten der Gesellschaft in Anspruch genommen werden.462 Diesem stünde dann ein Regressanspruch gem. § 426 BGB gegen die anderen Gesell462 BGH, Urt. v. 27. 9. 1999 -II ZR 371–98, NJW 1999, 3483; Boesche in Oetker HGB, § 128 Rn. 12 mwN.

144

Dezentrale Anwendungen der Sharing Economy

schafter zu. Da dem Node-Betreiber aber eine überwiegende Anzahl der sonstigen Node-Betreiber unbekannt ist, lässt sich dieser Anspruch nicht realisieren. Die damit hervorgerufene zufällige Haftung eines Node-Betreibers für die gesamten Verbindlichkeiten der Gesellschaft kann juristisch und praktisch nicht überzeugen. Grundlage für eine Ablehnung der Einstufung der Node-Betreiber als GbR kann dabei einerseits der fehlende rechtsgeschäftliche Wille zum Gesellschaftsvertrag oder das Fehlen eines gemeinsamen Zweckes sein. a. Gemeinsamer Zweck Teilweise wird der gemeinsame Zweck mit einem Vergleich zu öffentlichen Gütern abgelehnt.463 Bei öffentlichen Gütern teilen alle Nutzer den gleichen Zweck und das Interesse an der Nutzung des Gutes, seien aber nicht über einen gesellschaftsrechtlich relevanten gemeinsamen Zweck miteinander verbunden.464 Da DApps öffentliche, freizugängliche Blockchains sind, kann zwar niemand von der Nutzung ausgeschlossen werden. Zur Einstufung als öffentliches Gut wird argumentiert, dass die Blockchain im Hinblick auf Technik und Verwendungszweck unveränderlich sei.465 Dies entspricht aber gerade nicht der Eigenschaft einer öffentlichen DApp. Diese ist veränderlich und nicht an die ursprüngliche Form gebunden. Sie kann durch die Mehrheit der Nodes verändert und weiterentwickelt, der ursprüngliche Zweck aufgehoben oder die DApp umgewidmet werden. Insofern lässt sich auch ein gemeinsamer Zweck erkennen. Die Nodes arbeiten zum Erhalt der Blockchain zusammen und wirken an ihrer Weiterentwicklung durch Abstimmung über mögliche Veränderungen mit. Warum dies den Anforderungen des § 705 BGB nicht genügen soll, ist nicht nachvollziehbar.466 Der gemeinsame Zweck im Sinne des § 705 BGB ist denkbar weit gefasst und umfasst jeden wirtschaftlichen oder ideellen Zweck, solange er gesetzlich zulässig ist.467 Insbesondere wird auch das Halten und Verwalten von beweglichen und unbeweglichen Sachen erfasst.468 Zwar handelt es sich bei der DApp nicht um eine Sache, es wird aber deutlich, dass auch das bloße Verwalten und Aufrechterhalten ausreichender Zweck sein kann. Gegen die Annahme eines gemeinsamen Zwecks wird auch argumentiert, die Nodes würden den Zweck der Berechnung einzelner 463 464 465 466

Schwintowski/Klausmann/Kadgien, NJOZ 2018, 1401, 1402. Schwintowski/Klausmann/Kadgien, NJOZ 2018, 1401, 1402. Schwintowski/Klausmann/Kadgien, NJOZ 2018, 1401, 1402. Zweifelnd: Möllenkamp/Shmatenko in Hoeren/Sieber/Holznagel Hdb. Multimedia-Recht, 13.6 Rn. 76. 467 Schäfer in MüKo BGB, § 705, Rn. 144. 468 OLG Düsseldorf Beschl. v. 21. 8. 1972 3 W 113/72, DNotZ 1973, 91ff.; ablehnend Petzoldt, DNotZ 1973, 91ff.; Flume, DB 1973, 2470.

Haftung

145

Blöcke gegen Entgelt verfolgen.469 Zum einen lässt das eine Vielzahl neuer Konsensmechanismen außer Betracht, zum andern kann der Zweck, der bei einzelnen Blockchains zweifelsfrei im Vordergrund steht, den Zweck der Aufrechterhaltung und Weiterentwicklung der DApp nicht verdrängen. Die Aufrechterhaltung und Weiterentwicklung ist nicht derart untergeordnet, dass sie vollkommen durch den individuellen Zweck der Blockberechnung verdrängt werden würde. b. Gesellschaftsvertrag Dennoch wird zwischen den Node-Betreibern keine GbR begründet. Letztlich fehlt es am Rechtsbindungswillen auf Abschluss eines Gesellschaftsvertrages. Die Voraussetzungen richten sich dabei grundsätzlich nach den §§ 104ff. BGB. Es muss von jedem Teilnehmer eine Willenserklärung abgegeben werden, die alle wesentlichen Bestandteile im Hinblick auf die Gesellschaftsgründung enthält.470 Sie muss somit grundsätzlich sowohl den gemeinsamen Zweck als auch die anderen Gesellschafter erfassen.471 Bei der Bestimmbarkeit der anderen Gesellschafter entsteht das erste Problem. Innerhalb der dezentralen Anwendung sind die beteiligten Nodes nicht bekannt. Im Unterschied zu Publikumsgesellschaften, bei denen nur Schlüsselmitglieder allen anderen bekannt sind,472 sind im Falle der dezentralen Anwendung sämtliche Mitglieder unbekannt. Die fehlende Kenntnis der Gesellschafter wird bisher als Ausschlussgrund für eine GbR angenommen.473 Der Rückschluss ist nicht zwingend; denkbar ist, dass sich der Wille der Gesellschafter darauf erstreckt, innerhalb der Gesellschaft anonym zu bleiben. Ein solcher Wille wird bei Betrachtung der Haftungsfolgen aber kaum anzunehmen sein. Durch Gründung einer Gesellschaft werden auch die haftungsrechtlichen Folgen begründet. Die Gesellschafter haften unabhängig von der Klassifizierung als Außen-oder Innengesellschaft für die Verbindlichkeiten der Gesellschaft; bei der Außen-GbR gem. § 128 HGB,474 bei der Innen-GbR gem. § 427 BGB als Gesamtschuldnerschaft.475 In diesem Kontext ist es für jeden Gesellschafter essentiell, die anderen Gesellschafter zu kennen, um den eigenen Haftungsumfang erkennen zu können. Soweit einige wenige solvente Gesellschafter bekannt sind, mag das Haftungsrisiko bewusst in Kauf genommen werden. Sind hingegen keinerlei Gesellschafter bekannt, würde der Beitretende 469 470 471 472 473 474

Möllenkamp/Shmatenko in Hoeren/Sieber/Holznagel Hdb. Multimedia-Recht, 13.6 Rn. 76. Geibel in BeckOGK BGB, § 705 Rn. 12ff. Geibel in BeckOGK BGB, § 705 Rn. 12ff. Geibel in BeckOGK BGB, § 705 Rn. 13. Geibel in BeckOGK BGB, § 705 Rn. 13. BGH, Urt. v. 7. 4. 2003 -II ZR 56/02, NJW 2003, 1803, 1805; Merkel/Richrath in Schimansky/ Bunte/Lwowski Bankrechts Hdb., § 98 Rn. 162. 475 Schäfer in MüKo BGB, § 714 Rn. 10.

146

Dezentrale Anwendungen der Sharing Economy

ein unüberschaubares Haftungsrisiko durch die Abgabe der Willenserklärung auf Abschluss eines Gesellschaftsvertrages eingehen. Dieser Wille kann keinem Node-Betreiber unterstellt werden. Anzunehmen ist, dass der Node-Betreiber die Haftung für seine eigenen Handlungen übernimmt, nicht aber im Rahmen eines Kollektivs haften möchte. Im Gegensatz zur DAO bringen die Node-Betreiber auch keine erhebliche wirtschaftlichen Werte ein, die einer rechtlichen Absicherung bedürften und die ein Indiz für den Rechtsbindungswillen liefern könnten.476 Gegen die Annahme einer Willenserklärung spricht auch, dass sich keiner der Node-Betreiber zu einem Beitrag verpflichten möchte. Darüber hinaus scheitert die Annahme einer Gesellschaft auch an der erforderlichen Stabilität. Die Anzahl der Node-Betreiber unterliegt starker Fluktuation, ohne dass der Einzelne von der Zahl der beteiligten Nodes Kenntnis hat. Dem wird teilweise entgegengehalten, dass die Nodes sich wissentlich an einem System beteiligen, auf das sich die Nutzer verlassen und sich die Nodes somit nicht einer rechtlichen Verantwortlichkeit entziehen dürfen.477 Auch in der dezentralen Anwendung gelten die Grundsätze zur Haftung und insbesondere zur Bestimmung einer vertraglichen Bindung. Daher ist final auf den Rechtsbindungswillen der einzelne Node-Betreiber zur Gründung oder zum Beitritt in eine Gesellschaft abzustellen. Auch wenn eine Gesellschaft abgelehnt wird, hat dies nicht zur Folge, dass sich der Node-Betreiber sämtlicher Haftung entziehen kann. Die Verneinung einer Gesellschaft bedeutet letztlich nur, dass jeder NodeBetreiber allein für sein eigenes Verhalten haftet. Die vertraglichen Grundsätze dürfen nicht zugunsten einer vermeintlich leichteren Rechtsdurchsetzung überdehnt werden.478 Letztlich ist festzuhalten, dass die Node-Betreiber im Rahmen einer dezentralen Anwendung der Sharing Economy grundsätzlich keine Willenserklärung zur Gründung einer Gesellschaft abgeben und sie somit auch nicht Teil einer GbR sind. Es gibt keine gemeinschaftliche Entität, die insgesamt für die Haftung in Betracht kommt Stattdessen müssen die einzelnen Nodes individuell verantwortlich sein. Dabei sind Umstände, die zu einer Haftung führen, von vornherein stark begrenzt.

476 Teichmann, ZfPW 247, 269. 477 Zetsche u.w., The distributed Liability of Distributed Ledgers, https://tinyurl.com/bdenxyju abgerufen am 18. 1. 2022. 478 Zetsche u.w. beziehen sich bei Ihren Ausführungen nicht ausschließlich auf das deutsche Recht. Es werden aber Grundsätze für das Common Law und BGB dargestellt.

Haftung

2.

147

Vertragliche Haftung

Für eine vertragliche Haftung bedarf es einer irgendwie gearteten vertraglichen Verbindung zwischen Node-Betreiber und Anspruchsteller. Dabei scheiden die sonstigen Node-Betreiber als Anspruchsteller bereits aus. Zwischen den NodeBetreibern besteht keine gesellschaftsrechtliche und keine sonstige vertragliche Verbindung. Gegenüber anderen Node-Betreibern bestehen somit auch keine vertraglichen Verpflichtungen, bei deren Verletzung Schadensersatz verlangt werden könnte. Als Anspruchsteller kommen lediglich die Nutzer der dezentralen Anwendung in Betracht. Es könnte aufgrund des Betreibens der Anwendung sowohl eine vertragliche Verbindung zu allen Node-Betreibern bestehen als auch zu dem einzelnen Node-Betreiber, der an der Verifizierung einer Transaktion beteiligt ist. a. Nodes Anknüpfungspunkt für eine vertragliche Beziehung zu allen Node-Betreibern wäre die Nutzung der dezentralen Anwendung. Bei bisherigen Plattformmodellen wird davon ausgegangen, dass üblicherweise schon mit aktiver Nutzung der Plattform ein Vertrag zwischen Plattformbetreiber und Nutzer begründet wird.479 Bei dezentralen Anwendungen gibt es aber keinen Plattformbetreiber mehr.480 Auch wenn sich nichts an der Erklärung des Nutzers ändert, gibt es keine entsprechende Willenserklärung des »Plattformbetreibers«. Es müssten also alle Node-Betreiber eine Willenserklärung auf Abschluss eines Nutzungsvertrages abgeben. Auch wenn die Erklärung nicht nur ausdrücklich, sondern auch konkludent erfolgen kann, fehlt es an einer Willenserklärung der Nodes. Die Infrastruktur wurde nicht von den Nodes geschaffen, sondern lediglich den Nutzern zugänglich gemacht. Sie nehmen dabei grundsätzlich keinen inhaltlichen Einfluss auf die Gestaltung der Infrastruktur. Letztendlich beschränkt sich die Tätigkeit der Nodes in diesem Rahmen darauf, die dezentrale Anwendung abzuspeichern und dem Nutzer den Zugang zu verschaffen. Weder Nutzer noch NodeBetreiber haben Kenntnis von der jeweiligen Vertragspartei oder auch nur von der bloßen Zahl der Vertragsparteien. Woran die Willenserklärung eines einzelnen Nodes geknüpft werden soll, ist in dieser Konstellation nicht ersichtlich. Zwischen den Node-Betreibern und Nutzern besteht kein Vertragsverhältnis.

479 Hauck/Blaut, NJW 2018, 1425; i.E. auch Schwintowski/Klausmann/Kadgien, NJOZ 2018, 1401; Vilgertshofer, Online-Plattformen und vertragliche Haftung, S. 155. 480 Anders Schwintowski/Klausmann/Kadgien: hier wird nicht darauf eingegangen, ob es noch einen zentralen Plattformbetreiber gibt.

148

Dezentrale Anwendungen der Sharing Economy

b. Miner Zuletzt kann noch auf das einzelne, die Transaktion verifizierende Node als Vertragspartei abgestellt werden, wobei Erklärungen den einzelnen Parteien zugeordnet werden können. Der Nutzer gibt an eine unbestimmte Anzahl von Minern nach Abschluss des Vertrages mit dem Anbieter der Leistung die Aufforderung ab, die konkrete Transaktion zu validieren. Ein Preis für das Validieren wird für den Fall ausgeschüttet, dass die Transaktion erfolgreich verifiziert und in der Blockchain gespeichert wird. Der Miner wiederum erhält die Aufforderung und führt nach seinem Ermessen die notwendigen Schritte zur Validierung durch.481 Ihm ist dabei bewusst, dass er den Preis (in Form von Token) nur erhält, wenn dieser Prozess erfolgreich abgeschlossen wird. Der Nutzer gibt dabei ein Angebot auf Abschluss eines Vertrages ab. Aus Sicht eines objektiven Empfängers liegt ein Rechtsbindungswille vor. Da der Miner teils erhebliche Kosten für die Validierung auf sich nimmt, muss er auch darauf vertrauen können, dass bei erfolgreichem Validieren der versprochene Preis bezahlt wird. Das Angebot des Nutzers ist dabei aber durch zwei wesentliche Faktoren geprägt. Einerseits richtet er das Angebot zwar an eine Vielzahl von Personen, gleichzeitig möchte er aber nur einmal den Vertrag abschließen. Hierbei ist die Blockchain-Technologie behilflich, wodurch eine konkrete Transaktion auch nur ein einziges Mal validiert werden kann. Der Nutzer verlangt für seine Gegenleistung, dass eine vollständige Validierung der Transaktion erfolgt. Die Validierung ist erst mit dauerhafter Speicherung in der Blockchain als vollständig anzusehen. Eine dauerhafte Speicherung erfolgt, wenn 51 % aller Nodes den validierten Block in ihre Blockchain aufgenommen haben. In diesem Fall kann der Block zwar noch durch externen Eingriff verändert oder gelöscht werden, innerhalb der Blockchain gilt er aber als offizieller Block und ist fester Bestandteil. Das Risiko einer nachträglichen Veränderung trägt aber der Nutzer. Durch Abschluss der Validierung nimmt der Miner das Angebot des Nutzers an. Diese vertragliche Konstellation erfüllt den Tatbestand der Auslobung gem. § 661ff. BGB. Ob es bei einer solchen überhaupt einer Annahme bedarf oder die tatsächliche Vornahme der Handlung entscheidend ist, kann im Rahmen von dezentralen Anwendungen dahinstehen.482 Dass ein Miner ohne Kenntnis der Auslobung handelt ist nicht denkbar, sodass er auch zwingend mit dem Willen zur Erfüllung der Auslobung handelt.

481 Die Anforderungen an diesen Prozess sind vom Konsensmechanismus im Einzelfall abhängig. 482 Grundlegend hierzu: Lohsse in BeckOGK BGB, § 661ff. Rn. 7ff.

Haftung

149

Im Rahmen der Auslobung trifft den Miner keine Handlungspflicht.483 Er haftet dem Nutzer somit auch nur nach §§ 280 I, 241 II BGB für die Verletzung von Schutzpflichten.484 Der Miner haftet somit zwar nicht für Mängel der Leistung, stattdessen aber für Mangelfolgeschäden, die das Integritätsinteresse beinträchtigen.485 Sie sind aufgrund der Natur der dezentralen Anwendung aber kaum denkbar. Die zu verwendenden Daten werden vom Nutzer übermittelt. Die Verifizierung läuft im Anschluss vollautomatisch ab und es kommt nur zu einer Implementierung in die Blockchain, wenn die Verifizierung zutreffend erfolgt ist. Eine Veränderung der übermittelten Daten, egal ob vorsätzlich oder fahrlässig, ist praktisch kaum möglich, aber theoretisch vorstellbar. Für die Buchung fehlerhafter Beträge haftet dann der Miner, falls der Nutzer den Beweis erbringen kann, dass eine Veränderung der Daten erst im Einflussbereich des Miners erfolgte. Die Widerlegung des vermuteten Verschuldens wird dem Miner aber dann gelingen, wenn es sich nicht um einen grundsätzlichen Fehler in der Software der dezentralen Anwendung handelt. Handelt es sich um einen Einzelfall, trifft den Miner nicht den Vorwurf, dass er die im Verkehr erforderliche Sorgfalt gem. § 276 I, 2 BGB außer Acht gelassen hat. Insoweit muss den automatisierten Prozessen zugunsten des Miners Rechnung getragen werden. Erst wenn der Miner Kenntnis von Softwarefehlern hat oder hätte haben müssen und er dennoch weiter die Software zur Verifizierung von Transaktionen nutzt, kann ihm ein vorwerfbares Verhalten zu Last gelegt werden.486 Letztlich haftet somit nur der Miner gegenüber dem Nutzer vertraglich und auch nur bezüglich des Integritätsinteresses gem. §§ 280 I, 241 II BGB. 3.

Deliktische Haftung

Im Gegensatz zur vertraglichen Haftung der Nodes kommt für die deliktische Haftung wegen seiner Einflussmöglichkeit auf die Infrastruktur jedes einzelne Node in Betracht, während der Miner weitestgehend von einer Haftung ausgenommen ist. a. Miner Wie schon im Bereich der vertraglichen Haftung angesprochen, sind auch deliktische Handlungen des Miners überschaubar. Eine Haftung kommt aufgrund der gleichen Handlung auch gem. § 823 I BGB in Betracht, wenn der Miner zur Verifizierung vorsätzlich oder fahrlässig fehlerhafte Software für diesen Prozess 483 Schäfer in MüKo BGB, § 661ff. Rn. 39. 484 Schäfer in MüKo BGB, § 661ff. Rn. 39; Lohsse in BeckOGK BGB, § 661ff. Rn. 25; KotzianMarggraf/Kneller in BeckOK BGB, § 661ff. Rn. 6. 485 Lohsse in BeckOGK BGB, § 661ff. Rn. 25. 486 Vgl. zur Verallgemeinerungsfähigkeit: Schaub in BeckOGK BGB, § 276, Rn. 88.13.

150

Dezentrale Anwendungen der Sharing Economy

einsetzt. Die Bemessung des Fahrlässigkeitsmaßstabes ergibt sich, wie auch bei der vertraglichen Haftung, aus § 276 II BGB. Der Miner darf grundsätzlich auf die ordnungsgemäße Funktion der Software vertrauen. Problematisch wird die rechtliche Bewertung, wenn zwar Mängel bekannt sind, nur der Miner noch keine Kenntnis hiervon erlangt hat. Dann stellt sich die Frage, welchen Aufwand der Miner zur Informationsbeschaffung aufwenden muss, um sich über mögliche Fehler zu informieren. Gerade bei einer neuartigen Technologie muss das Vertrauen in diese begrenzt sein. Auch der Miner kann nicht einfach davon ausgehen, dass jede dezentrale Anwendung fehlerfrei funktioniert. Gleichzeitig kann von ihm aber auch keine ausufernde Informationsbeschaffung verlangt werden. In Anlehnung an die Definition der Insiderinformation aus dem Kapitalmarktrecht487 und der gruppentypischen Bestimmung der Fahrlässigkeit488 sollte sich die Informationsbeschaffung auf allgemein zugängliche Informationsquellen beschränken, bei der von einem Erreichen eines Großteils der Bereichsöffentlichkeit ausgegangen werden kann. Die Bereichsöffentlichkeit betrifft hier die Nutzer und Nodes der konkreten dezentralen Anwendung. Für die Veröffentlichung genügen grundsätzlich einschlägige Foren. Auch wenn diese auf den ersten Blick schwer bestimmbar erscheinen, lässt sich die Bestimmung durch konkrete Anhaltspunkte in der Praxis vereinfachen. Insbesondere wenn die Bekanntmachung in weiteren Forenbeiträgen und Diskussionen aufgegriffen wird, kann von einer hinreichenden Publizität ausgegangen werden, über die sich auch der einzelne Miner hätte informieren müssen. Darüber hinaus treffen den Miner aber keine weiteren Informationsbeschaffungspflichten. Wie schon bei der deliktischen Haftung des Entwicklers werden auch hier die Daten als solche als geschütztes Rechtsgut angesehen. Jenseits einer Haftung aus § 823 I BGB kommt vor allem eine Haftung gem. § 823 II BGB i. V. m. § 303a StGB und § 826 BGB bei vorsätzlicher Manipulation der Transaktion in Betracht. In diesem Rahmen ist auch das reine Vermögen vor Schaden, der aus der Datenmanipulation resultiert, geschützt, sodass es auf das Problem der Daten als sonstiges Rechtsgut nicht ankommt. b. Nodes Die Gesamtheit der Nodes übernimmt mit Veröffentlichung der dezentralen Anwendung die Rolle des Entwicklers als maßgeblich einflussnehmende Partei. Für den Anwendungsentwickler resultieren aus seiner Stellung als Produzent Produktbeobachtungspflichten und gegebenenfalls auch Handlungspflichten zur Fehlerbehebung.489 Gerade bei der Gefahr einer schwerwiegenden Schädi487 Allg.: Assmann in Assmann/Schneider/Mülbert Wertpapierhandelsrecht, Art. 7 MAR Rn. 6ff. 488 Schaub in BeckOGK BGB, § 276, Rn. 73. 489 Vgl. § 4 III. 2. bb. 3).

Haftung

151

gung der Nutzer, trifft den Entwickler die Pflicht, ein Update zur Schließung der Sicherheitslücke zu veröffentlichen.490 Diese Pflicht ist jedoch zum Schutz der Beteiligten nur dann effektiv, wenn solche Updates in der dezentralen Anwendung unter Mitwirkung einer Mehrheit der Nodes auch umgesetzt werden. Für die Pflicht zur Umsetzung von Sicherheitsupdates und auch für sonstige Maßnahmen, die im Einflussbereich der Nodes liegen, kann zwar nicht auf die Produzentenhaftung, wohl aber auf eine Verkehrssicherungspflicht abgestellt werden. Für eine Gefahrenquelle haftet grundsätzlich derjenige, der diese beherrscht oder unterhält und einen Nutzen aus ihr zieht.491 Der Nutzen kann dabei sowohl wirtschaftlicher als auch ideeller Art sein, wobei sich der Umfang des Pflichtenprogrammes an der Wirtschaftlichkeit orientieren kann.492 Die Gefahrenquelle ist in der dezentralen Anwendung zu sehen. Sie wird durch die Nodes unterhalten und beherrscht. Sofern es sich bei einem Node nicht um einen Miner handelt, ist der Zweck allerdings lediglich ideeller Art. Auch wenn bisher von Nodes als Gesamtheit gesprochen wurde, trifft jeden einzelnen NodeBetreiber die Verkehrspflicht. In seinem Rahmen muss jedes Node das Zumutbare zur Gefahrenabwehr unternehmen.493 Dadurch, dass die Verkehrspflicht nicht die Gesamtheit der Nodes als solche betrifft, sondern jedes einzelne Node, kann sich auch der Umfang der Verkehrspflichten unterscheiden. Wendet man den Grundsatz des wirtschaftlichen Nutzens an, treffen die Miner umfangreichere Verkehrspflichten als die »normalen« Node-Betreiber. Abhängig von der individuellen Leistungsfähigkeit treffen wirtschaftlich starke Nodes umfassendere Pflichten als wirtschaftlich schwächere Nodes. Die deshalb notwendige Einzelfallprüfung der Verkehrspflicht eines Nodes lässt sich jedoch in einem gewissen Umfang generalisieren. Auf oberster Stufe mit der umfangreichsten Verkehrspflicht stehen wirtschaftlich starke Miner oder Mining Pools, die einen umfangreichen wirtschaftlichen Nutzen aus der Verifizierung von Transaktionen ziehen. Auf mittlerer Stufe befinden sich sonstige Miner, die in begrenztem Umfang einen wirtschaftlichen Nutzen ziehen, und wirtschaftlich besonders starke Nodes. Auf unterster Stufe stehen sonstige Nodes, die sich nicht durch besondere wirtschaftliche Stärke auszeichnen und lediglich ideelle Interessen aus der dezentralen Anwendung ziehen bzw. sie lediglich für private Zwecke nutzen.

490 Vgl. § 4 III. 2. bb. 3). (S. 139). 491 Spindler in BeckOGK BGB, § 823 Rn. 392; v. Bar, Verkehrspflichten. S. 113, 125; BGH, Urt. v. 18. 12. 1972 -III ZR 121/70, NJW 1973, 460, 461; Urt. v. 20. 09. 1994 -VI ZR 162/93, NJW 1994, 3348; Urt. v. 16. 01. 1990 -VI ZR 109/89, NJW-RR, 1990. 409, 410ff. 492 v. Bar, Verkehrspflichten, S. 126. 493 v. Bar, Verkehrspflichten, S. 127.

152

Dezentrale Anwendungen der Sharing Economy

Den drei Stufen muss jeweils auch ein Pflichtprogramm zugeordnet werden. Eine grundlegende Pflicht betrifft dabei alle Nodes und knüpft an die Pflicht des Entwicklers an. Hat der Entwickler eine Gefahr erkannt und hierfür ein Update zur Schließung der Sicherheitslücke veröffentlich, sind alle Nodes zur Umsetzung dieses Updates verpflichtet. Dabei wird vom Idealfall eines Updates ausgegangen, das lediglich die Sicherheitslücke schließt ohne sonstige Auswirkungen auf die Anwendung zu haben. Bei sonstigen Updates, die auch inhaltlichen Einfluss auf die dezentralen Anwendungen haben, muss abgewogen werden, ob sie überhaupt geeignet sind, die Gefahr abzuwenden und ob damit nicht andere (wirtschaftliche) Gefahren für die Nutzer entstehen. Bei der Abwägung hat die Sicherheit der Nutzer grundsätzlich Vorrang. Ideelle Vorstellungen von der dezentralen Anwendung haben unberücksichtigt zu bleiben. Diese Pflicht endet letztlich darin, dass jedes Node zur Durchführung des Updates verpflichtet ist, sofern sie grundsätzlich zur Abwendung der Gefahr geeignet scheinen. Auf mittlerer Stufe wird die Pflicht um Recherchepflichten ergänzt, um Updates zutreffend bewerten zu können, ob hiervon eine erhöhte Sicherheit für die Nutzer erwartet werden kann. Wirtschaftlich starken Nodes kann zugemutet werden, dass sie sich auch vertieft mit einem Update beschäftigen, um zu ermitteln, ob es tatsächlich die Gefahr beseitigt oder ob damit zusätzliche Gefahren begründet werden. Zuletzt kann von Mining Pools und Nodes mit großem wirtschaftlichen Interesse an der dezentralen Anwendung auch erwartet werden, dass nicht nur Updates vom Hersteller umgesetzt werden, sondern bei Auftreten einer Sicherheitslücke auch selbstständig Updates entwickelt und den anderen Nodes vorgeschlagen werden. Für die Verantwortlichkeit gelten die allgemeinen Grundsätze der Fahrlässigkeit gem. § 276 BGB, wobei sich die Fahrlässigkeit in Wechselwirkung mit der Verkehrspflicht befindet. Je umfangreicher die Verkehrspflicht, desto niedriger sind die Anforderungen an die Verantwortlichkeit. Trotz dieser Klassifizierung bleibt es bei einer Einzelfallbetrachtung, die sich aber an diesen Gruppen orientieren sollte. Die Nodes haften selbstständig für sich gem. § 823 I BGB. Ein Anspruch aus § 823 I BGB würde letztlich aber am erforderlichen Beweis der Kausalität scheitern, da nicht nachgewiesen werden kann, dass die Handlung des Anspruchsgegners nicht hinweggedacht werden kann, ohne dass der Schaden entfiele.494 Ob ein Sicherheitsupdate installiert wird oder nicht, ist letztlich ein Mehrheitsbeschluss. Die Konstellation der Node-Betreiber unterscheidet sich in diesem Punkt nicht von sonstigen Gremienentscheidungen. § 830 I S. 1 BGB findet mangels Mittäterschaft keine Anwendung. Stattdessen ist auf § 830 I S. 2 BGB 494 Vgl. Freund in MüKo StGB, § 15 Rn. 322.

Haftung

153

abzustellen, der den Fall der alternativen Kausalität erfasst. Soweit die Mehrheit aber nicht nur von einer Stimme abhängt, handelt es sich nicht mehr um den klassischen Fall der alternativen Kausalität. Auch bei Hinwegdenken der Stimme des Einzelnen tritt der Schaden durch Mehrheitsbeschluss weiterhin ein. Es kann aber nicht Sinn und Zweck des § 830 I S. 2 BGB sein, die Haftung dann entfallen zu lassen, wenn es sich um eine Mischung aus kumulativer und alternativer Kausalität handelt.495 Eine Verantwortlichkeit nach § 830 I S. 2 BGB muss auch dann bestehen, wenn jede Einzelstimme im Zusammenwirken mit anderen Stimmen kausal ist.496 Die Nodes haften als Alternativtäter im Ergebnis nicht unmittelbar gem. § 823 I BGB, aber stattdessen gem. § 830 I S. 2 BGB i. V. m. § 421 BGB als Gesamtschuldner. 4.

Rechtsdurchsetzung

Auch wenn sowohl vertragliche als auch deliktische Ansprüche gegen alle oder einzelne Nodes bestehen können, sind diese in der Praxis nur so viel wert, wie die Ansprüche auch durchgesetzt werden können.497 Die Anonymität der Nodes ist eine wesentliche Funktion von dezentralen Anwendungen.498 Auch wenn vereinzelt technische Möglichkeiten geschaffen werden, um Mitglieder von dezentralen Anwendungen zu identifizieren499, sind die technischen Voraussetzungen für einen Anspruchsteller kaum umsetzbar. Für einen Nutzer, der seine Ansprüche geltend machen möchte, sind die Anspruchsgegner faktisch anonym. Durch technischen Fortschritt mag sich dies mit der Zeit verändern. Dass eine De-Anonymisierung in näherer Zukunft aber für private Nutzer möglich sein wird, ist nicht zu erwarten. Der Anspruchsteller kann sich auch nicht an einen zentralen Intermediär wenden, um entsprechende Daten über den Anspruchsgegner zu erlangen. Eine Rechtsdurchsetzung ist gegenüber Node-Betreibern faktisch ausgeschlossen. Denkbar ist allerdings, dass dem Anspruchsteller aus seinem persönlichen Umfeld ein Node-Betreiber bekannt ist. Diesen könnte er, soweit ihm auch gerichtlich der Beweis der Node-Eigenschaft des Klagegegners gelingt, gerichtlich 495 496 497 498 499

Ausführlich: Fleischer, BB 2004, 1645, 1646ff. Wagner in MüKo BGB, § 830 Rn. 79. Spindler, MMR, 2018, 48, 51ff. Kaulartz/Heckmann, CR 2016, 618, 620; Spindler/Bille, WM 2015, 1357, 1359. Hara u.w., Profiling of Malicious Users Using Simple Honeypots on the Ethereum Blockchain Network, https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9169469 abgerufen am 18. 1. 2021; Yin u.w., Regulating Cryptocurrencies: A Supervised Machine Learning Approach to De-Anonymizing the Bitcoin Blockchain, https://doi.org/10.1080/07 421222.2018.1550550, abgerufen am 18. 1. 2022; mit technischen Ansätzen auf Basis von Machine Learning; Spindler/Bille, WM 1357, 1359.

154

Dezentrale Anwendungen der Sharing Economy

in Anspruch nehmen. Gem. § 421 BGB haftet der Node-Betreiber dann für den vollen Schaden und müsste seinerseits andere Node-Betreiber gem. § 426 I oder II BGB für den Ausgleich der jeweiligen Anteile in Anspruch nehmen. Nun stünde der Node-Betreiber vor der Hürde, andere Nodes der dezentralen Anwendung identifizieren zu müssen. Selbst wenn ihm einzelne weitere Nodes bekannt sind, haften diese gegenüber dem Regressgläubiger nur als Teilschuldner500 und es obliegt Letzterem, die anderen Gesamtschuldner zu identifizieren oder aber den Beweis für den Ausfall eines Gesamtschuldners zu erbringen.501 Der Nachweis des Ausfalls dürfte zwar in der Regel aufgrund der Anonymität gelingen.502 Das Risiko hierfür trägt aber weiterhin den Schuldnerausgleich geltend machende Node-Betreiber.503 Es hängt letztlich weitestgehend vom Zufall ab, ob und in welchem Umfang der Node-Betreiber bei anderen Nodes Regress nehmen kann. Gleichermaßen zufällig scheint es, dass der Node-Betreiber mehr oder weniger zufällig für die gesamte Forderung in voller Höhe haftet. Dem ist zwar entgegenzuhalten, dass diese Lösung auch sinnvoll ist, da sonst der Geschädigte und nicht der Schädiger das Ausfallrisiko tragen würde. Dennoch kann die Lösung nicht vollständig überzeugen. Auch bei den Node-Betreibern wird es sich in der Regel um natürliche Personen mit durchschnittlichem Vermögen handeln. Dem steht ein Schaden gegenüber, der das Vermögen des Einzelnen regelmäßig erheblich übersteigen wird. Deutlicher wird es noch, wenn aufgrund der Öffentlichkeit des Gerichtsverfahrens erst andere Geschädigte von der Identität des Node-Betreibers erfahren und diesen ebenfalls in Anspruch nehmen. Wenngleich nicht rechtlich anfechtbar, so ist die Lösung keinesfalls praxistauglich. Die Existenzgefährdung des Schädigers für ein fahrlässig übersehenes Sicherheitsupdate in Kauf zu nehmen, mag rechtlich logisch sein. Aus Wertungsgesichtspunkten ist es hingegen untragbar.504

500 Kreße in BeckOGK BGB, § 426 Rn. 40; BGH, Urt. v. 24. 4. 1952 -III ZR 78 u. 79/51, NJW 1952, 1087ff. 501 BGH, Urt. v. 13. 5. 1955 -I ZR 137/53, NJW 1955, 1314. 502 Vgl. Heinemeyer in MüKo BGB, § 426 Rn. 40; Kreße in BeckOGK BGB, § 426 Rn. 83. 503 Kreße in BeckOGK BGB, § 426 Rn. 40. 504 Anders Zetsche u.w.: The Distributed Liability of Distributed Ledgers, https://tinyurl.com /bdenxyju abgerufen am 18. 1. 2022, S. 1403f., die nicht von einer Inanspruchnahme des Einzelnen ausgehen.

Zwischenergebnis

III.

155

Zwischenergebnis

Insgesamt lassen sich sowohl die vertragliche und auch die deliktische Haftung sowohl auf den Anwendungsentwickler als auch die Nodes anwenden. Die in diesen Bereichen entwickelten Fallgruppen lassen sich weitestgehend übertragen und schaffen ein umfassendes Haftungssystem. Auch wenn hierdurch nicht sämtliche Schäden, die durch Fehler in der dezentralen Anwendung entstehen können, ersatzfähig sind, so entspricht dies aber der gesetzlichen Wertung. Lediglich das Produkthaftungsgesetz ist aufgrund seiner Einschränkungen der ersatzfähigen Schäden nur in Einzelfällen nützlich. Das Haftungssystem für die Nodes kann zwar mittels der Schutzpflichten gem. § 241 II BGB und den Verkehrspflichten i.R.d. § 823 I BGB detailliert ausgestaltet werden. Bei einer Gesamtbetrachtung der Folgen kann es aber nicht überzeugen. Die Auswahl des ersatzpflichtigen Schädigers erfolgt zufällig und trotz bestehender Gesamtschuld ist ein erfolgreicher Regress von vornherein unwahrscheinlich. Dies deckt sich mit den Problemen der Rechtsdurchsetzung des Geschädigten. Mangels Kenntnis konkreter Node-Betreiber wird dieser in den meisten Fällen trotz seines Anspruches den Schaden tragen müssen.

Teil 3: Handlungsoptionen für eine Anpassung des Regulierungsrahmens

Die beispielhafte Anwendung geltender Rechtsnormen auf dezentrale Anwendungen der Sharing Economy hat gezeigt, dass sich nicht alle Probleme der neuen Technologie mit geltendem Recht lösen lassen. Dabei haben sich vier unterschiedliche Wirkungsgrade bestehender Normen offenbart. Normen, 1. …unter die sich dezentrale Anwendungen umfassend subsumieren lassen und dabei ausreichend auslegungsfähig sind, um den Veränderungen der Technologie Rechnung zu tragen, ohne Einbußen im Regelungsrahmen hinnehmen zu müssen; z. B. kapitalmarktrechtliche Regulierung sowie vertragliche und deliktische Haftung des Entwicklers. 2. … die zwar umfassend anwendbar und im Rahmen von dezentralen Anwendungen inhaltlich sinnvoll sind, aber auf Ebene der Rechtsdurchsetzung erhebliche Defizite aufweisen, sodass sie zwar inhaltlich erforderlich, in der Praxis aber ineffizient sind, z. B. Haftung der Miner und Node-Betreiber und die Verantwortlichkeit für die Umsetzung von Informationspflichten nach UWG und BGB. 3. … die sich zwar anwenden lassen, aber weder inhaltlich sinnvoll noch erforderlich zur Regulierung sind; z. B. einzelne Normen der Marktzugangsregulierung wie § 5 II ZwVbG Berlin. 4. … die sich aufgrund der Technologie oder des veränderten Geschäftsmodells von dezentralen Anwendungen nicht anwenden lassen, obwohl hierfür ein berechtigtes Interesse besteht; z. B. Marktzugangsbeschränkungen wie § 2 PBefG. Unproblematisch sind Normen zu 1., bei denen sich zeigt, dass auch bestehendes Recht geeignet sein kann, erhebliche Erneuerungen in Technologien und Geschäftsmodellen zu erfassen und interessengerecht zu regulieren. Das Gegenstück bilden die Normen zu 3., die aufgrund der Neuerungen von dezentralen Anwendungen nicht mehr erforderlich sind. Die Überholung von Normen durch

158

Handlungsoptionen für eine Anpassung des Regulierungsrahmens

tatsächliche Veränderungen ist allerdings nicht negativ zu sehen, sondern als natürliche Entwicklung in den hier behandelten Bereichen. Bei beiden Arten bedarf es keiner weiteren Anpassung. Normen i. S. d. Nr. 1 sind weiterhin anzuwenden; Normen i. S. d. Nr. 3 sind mittels teleologische Reduktion nicht anzuwenden. Während Normen zu 3. schlicht im Bereich von dezentralen Anwendungen obsolet geworden sind, können Normen zu 1. als Anknüpfungspunkt dienen für die Auslegung, welche Anforderungen Normen erfüllen müssen, um weiterhin anwendbar zu bleiben. Um künftig eine angemessene Regulierung von dezentralen Anwendungen zu erreichen, sind die Normen zu 2. und 4. entscheidend. Beide sind Ausdruck unterschiedlicher Arten von Regelungslücken: Normen zu 4. auf der Rechtsanwendungs- und Normen zu 2. auf der Rechtsdurchsetzungsebene. Zu beiden Arten werden im Folgenden erste Ansätze zur Schließung dieser Regelungslücken im Bereich von dezentralen Anwendungen in der Sharing Economy dargelegt.

§9

Spannungsfeld Regulierung und Innovation

Bei dezentralen Anwendungen in der Sharing Economy handelt sich um eine Verbindung einer neuen Technologie mit einem neuen Geschäftsmodell. Bevor Regelungslücken in diesem Bereich geschlossen werden können, muss sich mit der Frage auseinandergesetzt werden, in welchem Rahmen Regulierung bei neuen Technologien oder Geschäftsmodellen überhaupt wünschenswert ist. Dabei können sich Regulierung und Innovation als sich behindernd gegenüberstehen, indem die Regulierung zu einer Behinderung und Limitierung der Innovation führt.505 Das Ziel einer Regulierung sollte aber sein, Innovation zu fördern, indem sie sichere Rahmenbedingungen für Entwickler und Investoren schafft und Hürden dort senkt, wo sie den Marktzugang behindern.506 Während bei bisherigen Geschäftsmodellen eine offene Überlegung zwischen Ex-Ante und Ex-Post Regulierung möglich war, stellt sich das Problem im Rahmen von dezentralen Anwendungen, dass eine bereits veröffentlichte Anwendung nicht mehr der Kontrolle einer Partei untersteht.507 Umso schwieriger gestaltet sich eine nachträgliche Regulierung. Zu bevorzugen sind daher im Falle einer dezentralen Anwendung vorausgehende, marktzugangsbeschränkende Normen.

505 Ranchordas, S. 445f.; Bernstein, 31 Cardozo L. Rev. 2257, 2264f. 506 Ranchordas, S. 445f. 507 Detailliert zur Abgrenzung und Vorteilen von Ex-Ante und Ex-Post Regulierung: Haucap/ Kruse, Ex-Ante-Regulierung oder Ex-Post-Aufsicht für netzgebundene Industrien?, https:// www.econstor.eu/obitstream/10419/23541/1/paperno25.pdf.

Marktzugangsbeschränkungen

159

Marktzugangsbeschränkungen können im Rahmen der Sharing Economy vor allem zwei unterschiedliche Ansätze verfolgen. Sie können einerseits den bestehenden Markt vor Mitbewerbern schützen, andererseits die Nutzer vor möglichen Gefahren der angebotenen Leistungen. Beim Schutz des Marktes vor neuen Mitbewerbern handelt es sich um Fragen des Kartellrechts. Es muss bestimmt werden, ob es sich aus ökonomischer Sicht um einen »neuen Markt« handelt und welcher volkswirtschaftliche Nutzen aus einer vergleichbaren Regulierung oder Deregulierung zum »alten Markt« gezogen werden kann.508 Das soll jedoch nicht Gegenstand dieser Arbeit sein. Sie soll vielmehr gezielt darauf eingehen, wie Nutzer vor den Gefahren der angebotenen Leistungen geschützt werden können, wenn diese nicht mehr über eine Plattform sondern durch eine dezentrale Anwendung vermittelt werden. Die Anwendung geltenden Rechts auf plattformbasierte Geschäftsmodelle der Sharing Economy hat nicht zur Förderung der Innovation, sondern zum Ausschluss dieser Geschäftsmodelle vom Markt geführt.509 Zur Schließung der Lücke, die die fehlende Anwendbarkeit der Marktzugangsbeschränkungen bei dezentralen Anwendungen erzeugt hat, könnte zwar eine Regelung ausreichen, die die Anwendbarkeit auf den Anwendungsentwickler erstreckt. Sie würde damit aber gleichzeitig eine mögliche Innovation vom Markt fernhalten. Die fehlende Regelung bietet stattdessen die Chance, den schon bei der Sharing Economy geforderten Ausgleich von Schutz und Marktinnovation510 von vornherein zu berücksichtigen und zu ermöglichen.

§ 10 Marktzugangsbeschränkungen Bei der Regulierung des Personennahverkehrs ist eine zukunftsfähige Regelung zu suchen, die sich nicht darauf beschränkt den Unternehmerbegriff immer weiter aufzuweichen oder einzelne Ausnahmen zuzulassen. Stattdessen sollten Innovationen unabhängig von der konkreten technologischen Umsetzung der Zugang zum Markt ermöglicht werden, soweit der Schutz der Nutzer gewährleistet werden kann. Grund für die fehlende Anwendbarkeit von § 2 PBefG und 508 Grundlegend zur Innovation in der Ökonomie: Schumpeter, Theorie der wirtschaftlichen Entwicklung, 1997; Zusammenfassend: Elsenbast, MMR 2006, 575ff. 509 In Deutschland OLG Frankfurt zu Uber: Urt. v. 09. 06. 2016-6 U 73/15, juris, mit dem Leitsatz: »Die Durchführung entgeltlicher Personenbeförderungsaufträge ohne Genehmigung verstößt gegen das Personenförderungsgesetz und stellt zugleich eine unlautere geschäftliche Handlung dar. (…) Das hiergegen gerichtete Verbot ist sowohl mit dem Verfassungsrecht als auch mit dem Unionsrecht vereinbar.« 510 Ranchordas, S. 474f.; Terryn, EuCML 2016, 45, 51; Solmecke/Lengersdorf, MMR 2015, 493, 497.

160

Handlungsoptionen für eine Anpassung des Regulierungsrahmens

vergleichbaren Marktzugangsschranken ist das Abstellen auf einen »Unternehmer« oder überhaupt auf eine natürliche oder juristische Person.511 Damit kommt als Adressat für diese Regelungen nur noch der Entwickler der dezentralen Anwendung in Betracht (soweit man nicht wieder jeden einzelnen Anbieter in Anspruch nehmen möchte). Wie beispielhaft für § 2 PBefG gezeigt, ist der Entwickler aber in keinem Fall mit dem Anbieter der Leistung zu vergleichen.512 Dies gilt auch, wenn man versucht, die Uber-Kriterien auf ihn anzuwenden. Lücken der Marktzugangsbeschränkungen entstehen somit bei allen dezentralen Anwendungen, wenn sie auf den Anbieter der Leistung als Regelungssubjekt abstellen. Der Anwendungsentwickler ist kein geeigneter Adressat einer Beschränkung, da er selbst nicht am Markt aktiv wird. Eine adressatenbezogene Genehmigung verfehlt bei dezentralen Anwendungen den Anknüpfungspunkt, von dem die Gefahr ausgeht. Sie geht nicht vom Entwickler, sondern von der Anwendung selbst aus. Anknüpfungspunkt einer Marktzugangsschranke muss die dezentrale Anwendung als Regelungsobjekt sein. Wendet man die bisherigen Regelungen einfach auf die dezentrale Anwendung selbst an, wird auch das weitestgehend fehlschlagen. Die Beispiele aus § 13 I PBefG zeigen, dass auch die Zulassungsvoraussetzungen eng auf ein Regelungssubjekt zugeschnitten sind. Auch hier muss geprüft werden, ob ein sinnvolles Äquivalent für ein Regelungsobjekt gefunden werden kann. Schaut man sich die Voraussetzungen des § 13 I PBefG genauer an, lassen sich drei wesentliche Merkmale für eine Genehmigung identifizieren: die Zuverlässigkeit und die persönliche und fachliche Eignung des Unternehmers. Keine dieser Voraussetzungen lassen sich ohne weiteres auf die dezentrale Anwendung übertragen. Stattdessen müssen die dahinterliegenden Prinzipien berücksichtigt werden. Die Voraussetzungen des § 13 I PBefG wollen sowohl die Qualität der Beförderungsleistung als auch das Vertrauen des Fahrgastes in den Unternehmer schützen und fördern. Diesen Schutz kann die dezentrale Anwendung nicht aus sich selbst heraus gewährleisten. Die Zuverlässigkeit und Eignung der Fahrer muss nach wie vor separat festgestellt werden. Die dezentrale Anwendung muss hingegen für sich genommen »zuverlässig« sein und sicherstellen, dass keine unzulässigen Leistungen angeboten werden. Sie muss gewährleisten können, dass Fahrer, die diese persönliche und fachliche Eignung/ Zuverlässigkeit nicht aufweisen, ihre Dienste nicht mittels der Anwendung anbieten können. Letztlich führt es dazu, dass zwei unterschiedliche Marktzugangsschranken geschaffen werden müssen. 511 § 2 I PBefG: »Wer im Sinne des § 1 I (…) Personen befördert, muß im Besitz einer Genehmigung sein.« 512 § 4 I.1.a.aa.2).

Marktzugangsbeschränkungen

161

Einerseits muss festgelegt werden, unter welchen Voraussetzungen private Fahrer eine Transportleistung anbieten dürfen. Diese Diskussion ist identisch mit der bisherigen Diskussion zur Sharing Economy. Anschließend muss festgelegt werden, wie die dezentrale Anwendung sicherstellen kann, dass auch nur die zum Markt zugelassenen Fahrer die Anwendung nutzen können. Bei der Diskussion, ob auch private Fahrer Zulassungsvoraussetzungen erfüllen müssen, ist zunächst auf die Erwartungshaltung der Nutzer abzustellen.513 Grundsätzlich kann nicht die gleiche Erwartungshaltung an einen privaten, wie an einen professionellen Anbieter gestellt werden. Insbesondere im Bereich der fachlichen Eignung wird niemand davon ausgehen, dass der private Fahrer gleichermaßen die Routen kennt wie ein Taxifahrer. Andererseits würde es aber auch niemand kritisieren, wenn der private Fahrer Navigationsapps zur Bestimmung der Route nutzt. Im Gegenteil könnte dies sogar das Vertrauen stärken, da sich der Fahrgast bezüglich es kürzesten Weges nicht mehr nur auf den Fahrer verlassen muss. Bei der Gewährleistung der Sicherheit wird auch beim Privaten darauf vertraut, dass das Fahrzeug einer regelmäßigen Kontrolle unterzogen wird und eine Haftpflichtversicherung für eventuelle Schäden besteht. Diese Erwartungshaltung kann der Fahrgast hingegen nicht selbstständig überprüfen. Für sicherheitsrelevante Merkmale der Beförderung müssen auch für einen privaten Dienstleister vergleichbare Maßstäbe wie für Taxiunternehmer gelten und objektiv überprüft werden.514 Die dezentrale Anwendung kann im Anschluss dann als zuverlässig eingestuft werden, wenn nur bereits überprüfte Fahrer mittels der Anwendung ihre Leistungen anbieten können. Dies kann mittels Smart Contracts erreicht werden. Spätestens bei der Transaktion kann geprüft werden, ob beim Anbieter eine entsprechende Zulassung im Profil hinterlegt ist. Dies lässt sich zwar am einfachsten mittels einer geteilten Datenbank erreichen, die von der dezentralen Anwendung abgefragt werden kann. Auch bei analogen Genehmigungen ist die Überprüfung möglich, wenngleich mit deutlich erhöhtem Aufwand im Vergleich zur zuverlässigen Erkennung und Verifizierung der Genehmigung durch einen Algorithmus. Ist keine entsprechende Genehmigung für den Anbieter hinterlegt, erfolgt auch keine Transaktion bzw. wird dem Anbieter kein Auftrag vermittelt. Die Befugnis zur Zulassung einer Blockchain muss behördlich erteilt werden. Essentielle Frage ist dabei, wem die Kompetenz zugewiesen werden muss. Am naheliegendsten ist im Falle der Personenbeförderung die Zuordnung zu den

513 Ranchordas, S. 469ff. 514 Ranchordas, S. 474f.; Haucap/Kehder, Welchen Ordnungsrahmen braucht die Sharing Economy?, https://www.econstor.eu/bitstream/10419/174508/1/1013753003.pdf, S. 30.

162

Handlungsoptionen für eine Anpassung des Regulierungsrahmens

Verkehrsbehörden, d. h. zu der branchenspezifischen Aufsichtsbehörde.515 Die Vorteile liegen dabei auf der Hand. Branchenspezifische Behörden verfügen über die Expertise zur Bestimmung der Zuverlässigkeit von Personen für die jeweilige Branche, und es würde eine einheitliche Zuständigkeit für gewerbliche und private Anbieter sowie für die dezentrale Anwendungen bestehen. Defizite zeigen sich allerdings beim technologischen Verständnis der dezentralen Anwendung. Von einer regionalen Verkehrsbehörde516 kann grundsätzlich nicht erwartet werden, dass eine hinreichende Expertise für die Bewertung einer dezentralen Anwendung besteht. Selbst auf Landesebene müsste eine entsprechende fachliche Qualifikation erst geschaffen werden, was wiederum mit erheblichen Kosten für die Verwaltung verbunden wäre. Stattdessen empfiehlt sich eine Überprüfung durch zugelassene aber private technische Prüforganisationen, ähnlich zur PKW-Hauptuntersuchung gem. Nr. 1 Anlage VIII b StVZO. Für die Prüfung der dezentralen Anwendung sind weniger die branchenspezifischen Kenntnisse als vielmehr das technische Verständnis entscheidend. Die branchenbezogene Zuverlässigkeit der Anbieter wird bereits mit der Genehmigung und der dazugehörigen Datenbank überprüft. Es muss bei der dezentralen Anwendung lediglich geprüft werden, ob das Vorhandensein einer Genehmigung zwingende Voraussetzung für das Anbieten der Leistung ist, d. h. es muss lediglich die Implementierung des Smart Contracts geprüft werden. Dies setzt jedoch voraus, dass sich betriebswirtschaftlich private Stellen rentieren und eine ausreichende Nachfrage besteht. Dies ist bei der aktuellen Anzahl von dezentralen Anwendungen noch nicht erkennbar. Insgesamt wirkt die Schaffung zweier neuer Marktzugangsschranken und privater Prüforganisationen nicht wie eine Förderung der Blockchain-Wirtschaft durch Reduzierung regulatorischer Anforderungen. Die Überprüfung privater Fahrer, wenngleich eine neue Schranke, stellt keine erhebliche Belastung für die bisherigen Behörden dar. Die Schaffung neuer Rechtsgrundlagen für die Zulassung privater Anbieter in den jeweiligen Branchen braucht hingegen Zeit und ist vom politischen Willen abhängig. Auch die Überprüfung gestaltet sich problematisch und hängt, soweit es durch private Stellen übernommen werden soll, von der Nachfrage ab. Diese Voraussetzungen werden aber der Abwägung mit den Gefahren für die Nutzer gerecht. Es ist weder für die volkswirtschaftliche noch die soziale Innovation erforderlich, dass Technologien in beschränkten Märkten »getestet« werden. Der Mehrwert von dezentralen Anwendungen der Sharing Economy 515 Grundsätzlich zu Abwägung zwischen brachenspezifischer und Wettbewerbsbehörde: Haucap/Kruse, Ex-Ante-Regulierung oder Ex-Post-Aufsicht für netzgebundene Industrien?, https://www.econstor.eu/obitstream/10419/23541/1/paperno25.pdf, S. 9ff. 516 Vgl. für Niedersachsen liegt die Zuständigkeit gem. § 16 IV ZuStVO-Verkehr beim Landkreis oder bei den kreisfreien Städten.

Verbraucherschutz

163

erschöpft sich nicht in solchen Märkten, sondern erstreckt sich auch auf zulassungsfreie Angebote. Sofern nicht der Schutz der Nutzer gewährleistet wird, muss ein Marktzugang von entsprechenden Anwendungen verhindert werden. Im derzeitigen Entwicklungsstadium und Verbreitung dezentraler Anwendungen scheinen diese Schranken kaum überwindbar. Setzen sich dezentrale Anwendungen aber in anderen Bereichen, sowohl in der Sharing Economy als auch insgesamt, durch, wird auch der Nutzen zur Umsetzung der Schranken steigen. Schranken sollten hingegen nicht dort künstlich geschaffen werden, wo sie nicht dem Schutz der Nutzer dienen. Ob der deutsche Gesetzgeber derartige Schranken im Rahmen von Dienstleistungen der Informationsgesellschaft überhaupt erlassen darf, ist gemäß der EuGH Rechtsprechung nach der Gesamtsicht der angebotenen Dienstleistung zu beurteilen.517 Stellt sich die Anwendung als eine Gesamtdienstleistung dar, die nicht nur die Vermittlung übernimmt, sondern auch die Beförderung selbst steuert, ist der deutsche Gesetzgeber im Rahmen des PBefG berechtigt, hierfür Schranken aufzustellen. Wird jenseits der Vermittlung hingegen keine weitere Dienstleistung erbracht oder ist eine anderweitige Dienstleistung der Vermittlung in ihrer Bedeutung untergeordnet, obliegt es dem europäischen Gesetzgeber entsprechende Schranken zu erlassen. Nach dieser Bewertung hängt es vom Einzelfall ab, welche Anwendung den Schranken des PBefG unterfallen. Wie sich beim PBefG gezeigt hat, führt die Einzelfallbetrachtung zu einer erheblichen Rechtsunsicherheit und ist nicht geeignet den Gefahren konsequent zu begegnen. Obwohl der deutsche Gesetzgeber teilweise zum Erlasse der Schranken berechtigt wäre, kann nur eine europäische Regelung langfristig einheitliche und zufriedenstellende Ergebnisse erreichen. Zuletzt muss berücksichtigt werden, dass ein Verbot von dezentralen Anwendungen nach bestehendem Recht nicht möglich ist, solange keine neuen Schranken geschaffen werden. Insoweit besteht in jedem Fall eine Handlungspflicht der Legislative: sei es die Umsetzung zu ermöglichen oder generell in beschränkten Märkten zu untersagen.

§ 11 Verbraucherschutz Die Anwendung von Verbraucherschutzvorschriften hat zumindest in Verbindung mit dem UWG keine Schwierigkeiten im Bereich von dezentralen Anwendungen bereitet. Der Anwendungsentwickler unterliegt den gleichen Designpflichten wie schon bisherige Plattformbetreiber. Zumindest zum Zeitpunkt

517 EuGH Urt. v. 20. 12. 2017-C-434/15.

164

Handlungsoptionen für eine Anpassung des Regulierungsrahmens

der Veröffentlichung der dezentralen Anwendung ist ein Verantwortlicher identifiziert, der gewährleisten muss, dass eine Selbstkennzeichnung möglich ist. Ähnlich wie bei den Marktzugangsschranken kann auch beim Verbraucherschutz über eine automatisierte Kontrolle mittels Smart Contracts diskutiert werden, sodass zwangsläufig angegeben werden muss, ob der Anbieter Verbraucher oder Unternehmer ist. Denkbar ist auch, dass die Nutzerdaten automatisiert ausgelesen werden und eine automatische Klassifizierung durch den Algorithmus vorgenommen wird, soweit für die Abgrenzung zwischen Verbraucher und Unternehmer feste Schwellenwerte eingeführt werden.518 Ungeklärt ist allerdings, wie Verbraucherrechte durchgesetzt werden können, wenn sie nicht vom Entwickler berücksichtigt wurden oder sich nachträglich verändert haben. Selbst wenn der Entwickler zum Zeitpunkt der Veröffentlichung für die Einhaltung von Designpflichten verantwortlich ist, kann die dezentrale Anwendung nicht mehr »abgestellt« oder »zurückgerufen« werden. Beides liegt außerhalb der Handlungsmöglichkeiten des Entwicklers. Der DSA zeigt zwar einen guten Ansatz, wie sowohl Entwickler und Nodes in Anspruch genommen werden können, indem lediglich von der »Online-Plattform« gesprochen wird und es der Auslegung der einzelnen Norm vorbehalten bleibt, ob es sich dabei um den Entwickler oder die Nodes handelt. In Art. 22 Abs. 3 DSA ist zwar ein Blacklisting von Unternehmern vorgesehen, die ihren Informationspflichten nicht oder unrichtig nachkommen. Es sind aber keine konkreten Sanktionen vorgesehen, falls die Online-Plattform (in Form des Entwicklers oder der Nodes) ihren Verpflichtungen nicht nachkommt. Art. 42 DSA verpflichtet zwar die Mitgliedstaaten solche Sanktionen zu erlassen. Ansatzpunkte für die Sanktionierung von Entwicklern und Nodes finden sich aber nicht. Die Probleme des Verbraucherrechts stehen dabei stellvertretend für jede nachträgliche Regulierung der dezentralen Anwendung. Die bisherige Arbeit hat gezeigt, dass eine Inanspruchnahme von Node-Betreibern nicht zielführend ist und keine effektive Regulierung darstellt. Gleichzeitig kann ein Totalverbot nicht zielführend sein, da in vielen Bereichen der Nutzen der Innovation die damit einhergehenden Gefahren überwiegt und vor allem nicht zu früh die Innovation beschränkt werden soll.519 Ansätze zur Regulierung von dezentralen Anwendungen finden sich bisher fast ausschließlich im Bereich von Kryptowährungen, sei es in der Literatur oder Gesetzgebung.520 Besondere Beachtung findet dabei der Ansatz zum Blacklisting 518 Wie vorgeschlagen durch Haucap/Kehder, Welchen Ordnungsrahmen braucht die Sharing Economy?, https://www.econstor.eu/bitstream/10419/174508/1/1013753003.pdf, S. 30. 519 Hughes/Middlebrook, Advancing a Framework for Regulating Crytocurrency Payments Intermediarires, 32 Yale J. on Reg. 2015, 496, 547. 520 Sotirpolou/Ligot, ECFR 2019, 652–675; Hughes/Middlebrook, Advancing a Framework for Regulating Crytocurrency Payments Intermediarires, 32 Yale J. on Reg. 2015, 496; Liech-

Verbraucherschutz

165

von Token und Blockchain-Adressen. Mangels geeigneter unmittelbarer Adressaten wird bei dezentralen Anwendungen, wie auch in der Sharing Economy, nach regulatorischen Intermediären geschaut.521 In Betracht kommen vor allem die Token-Exchanges und Wallet-Provider.522 Vor allem im Bereich der Geldwäsche wird vorgeschlagen, Adressen und Token, die eine verdächtige Herkunft aufweisen, vom Handel auf Plattformen auszuschließen.523 Hierzu wird eine Datenbank geschaffen, in der bekannte Adressen und Transaktionen mit illegalem Hintergrund aufgelistet werden. Sämtliche Transaktionen einer Plattform werden mit dieser Liste abgeglichen und bei Übereinstimmung blockiert. Diesen Ansatz kann man ausdehnen und auf sonstige Regulierungen übertragen. Bestehen nachträgliche Gefahren, die ein Verbot der Anwendung notwendig machen, können die Token vom Handel auf Token-Exchanges ausgeschlossen werden. Dies führt letztlich dazu, dass keine neuen Mitglieder der dezentralen Anwendung beitreten und bisher erworbene Token nicht mehr in Fiat-Währung getauscht werden können, so dass das Netzwerk früher oder später mangels Vertrauens der Nutzer zum Erliegen kommt. Es kann in modifizierter Weise aber auch für sonstiges regulatorisches Eingreifen genutzt werden. Im ersten Schritt muss nicht zwangsläufig der Handel untersagt werden. Bei geringeren Verstößen kann zunächst auch eine Strafzahlung verhängt werden. Verstößt eine Anwendung gegen die rechtlichen Vorgaben, müssen Anreize gesetzt werden, damit Entwickler Änderungen vorschlagen und die Nodes diese übernehmen. Hierzu wird für jeden Handel der Token eine Strafzahlung festgesetzt, die die Parteien an den Staat zahlen müssen, wenn Token erworben werden. Die Höhe der Strafzahlung kann dabei prozentual am Wert des Tokens und nach Dauer und Schwere des Verstoßes der dezentralen Anwendung bemessen werden. Geht der Verstoß ausschließlich von einem Nutzer der dezentralen Anwendung aus, z. B. den Händler, der seine Unternehmereigenschaft nicht offengelegt hat, kann das gleiche Verfahren, wie im Rahmen der Geldwäsche mit schwarzen Listen genutzt werden. Hierbei ist aber gegebenenfalls der Aufwand zur Identifizierung von einzelnen Transaktionen mit dem Verstoß ins Verhältnis zu setzen. Es ist davon auszugehen, dass Strafen abhängig von der Höhe genug Anreiz setzen, Anwendungen der Sharing Economy an Gesetzesänderungen anzupassen. Im Ausnahmefall kann notfalls auch wie bei der Geldwäsche der Handel im Ganzen untersagt werden. tensteinisches Gesetz v. 3. 12. 2019 über Token und VT-Dienstleister; Maltesischer Virtual Financial Assets Act. 521 Grundlegend zu regulatorischen Intermediären: Abbott/Levi-Faur, The RIT Model, 14. 522 Sotirpolou/Ligot, ECFR 2019, 652, 666. 523 Möser/Narayanan, Effective Crytocurrency Regulation Through Blacklisting, https://malte moeser.de/paper/blacklisting-regulation.pdf.

166

Handlungsoptionen für eine Anpassung des Regulierungsrahmens

Bei der Anwendung dieser Methode auf die Prävention von Geldwäsche wurden zwei grundsätzliche Probleme erkannt. Durch Erstellung von Datenbanken hinsichtlich Transaktionen und Adressen kann die Privatsphäre des einzelnen Nutzers beeinträchtigt werden, indem eine Nachverfolgung zu einer realen Person erleichtert wird.524 Sanktioniert man generell jeden Handel mit dem entsprechenden Token, ist eine Liste mit Adressen und Transaktionen nicht erforderlich und Probleme der Privatsphäre stellen sich nicht. Bei der Inanspruchnahme von Token-Exchanges wird bei der Geldwäsche angenommen, dass die Transaktionen auf anderem Weg abgewickelt und so nicht alle Transaktionen erfasst werden können.525 Für dezentrale Anwendungen der Sharing Economy kann diese Gefahr vernachlässigt werden. Im Gegensatz zur Geldwäsche ist nicht davon auszugehen, dass die Nutzer Transaktionen auf sonstige Weise vornehmen. Der Nutzen der Anwendung dürfte selten ausreichen, das fehlende Vertrauen in inoffizielle Bezugsquellen zu überwinden. Zugleich reichen vereinzelte Transaktionen nicht aus, um die Effizienz der Maßnahme zu gefährden, da eine überwiegende Anzahl an Nutzern weiterhin über die bekannten Token-Exchanges handeln und gerade der unkomplizierte Tausch der Token in Fiat-Währung den Wert der Anwendung ausmacht. Insgesamt gestaltet sich die Anwendung von Strafzahlungen bei Transaktionen als effektives und vielseitiges Instrument zur nachträglichen Regulierung von dezentralen Anwendungen. Zu Berücksichtigen bleibt bei der Einführungen solcher Strafen aber, dass die Strafen nur mittelbar die verantwortlichen Nodes treffen. Primär richtet sich die Strafe gegen die Nutzer, die für die mangelnde Umsetzung nicht verantwortlich sind und denen (abhängig von der Art des Rechtsverstoßes) auch kein Vorwurf aus der Nutzung der Anwendung gemacht werden kann. Die Node-Betreiber erleiden letztlich keine Einbußen durch Strafzahlungen, sofern Sie nicht selber Inhaber von Token sind. Die Beeinträchtigung Nichtverantwortlicher muss letztlich bei der Festsetzung der Höhe der Strafzahlung mit der zu erwartenden Gefahr für die Nutzer rechtswidriger Anwendungen in Ausgleich gebracht werden.

524 Https://blog.chainalysis.com/reports/service-level-data abgerufen am 18. 1. 2021; Meiklejohn u.w., A Fistful of Bitcoins: Characterizing Payments Among Men with No Names, http://dx.doi.org/10.1145/2504730.2504747. 525 Möser/Narayanan, Effective Crytocurrency Regulation Through Blacklisting, https://malte moeser.de/paper/blacklisting-regulation.pdf, S. 4.

Haftung

167

§ 12 Haftung Die vertraglichen und gesetzlichen Haftungsregime lassen sich unproblematisch auf die dezentrale Anwendung übertragen. Problematisch ist nicht primär die Frage der Haftung, sondern die der Rechtsdurchsetzung. Diese besteht auch unabhängig von der Einordnung der Blockchain-Mitglieder als eigenständige Gesellschaft, da auch in diesem Fall die Mitglieder selbst weitestgehend anonym bleiben. Die Anonymität in Verbindung mit den teils stark begrenzten Kenntnissen der Blockchain-Mitglieder über ihre eigene Verantwortung innerhalb der Anwendung, führt zu einem untauglichen Haftungsregime für dezentrale Anwendungen. Die Konstellation erinnert stark an die Situation vieler Kapitalgesellschaften, im deutschen Raum vor allem die AG. Hier lassen sich zwar die einzelnen Anteilseigner theoretisch feststellen, sie sind aber selber selten Haftungssubjekt. Sie können gleichermaßen an Beschlüssen der Hauptversammlung mitwirken, wenngleich keine fachlichen oder rechtlichen Kenntnisse vorliegen müssen. Ein adäquates Haftungsregime für dezentrale Anwendungen könnte sich an dem einer Kapitalgesellschaft orientieren. Essentielles Merkmal der Kapitalgesellschaften ist die Trennung der Gesellschaft und ihren Anteilseignern.526 Wenn eine Inanspruchnahme der Blockchain-Mitglieder ohnehin keinen Erfolg verspricht oder es an der Liquidität des Schuldners scheitert, spricht zunächst auch nichts gegen eine Haftungsprivilegierung, soweit ein Ausgleich geschaffen wird. Bei Kapitalgesellschaften liegt dieser Ausgleich in den Vorschriften über die Mindestkapitalanforderungen.527 Betrachtet man das Mindestkapital allerdings als Absicherung der Gläubiger, so gibt es hieran Kritik, die auch im Folgenden berücksichtigt werden soll.528 Allem voran wird die Höhe des Mindestkapitals als nicht ausreichend und unflexibel erachtet.529 Die Höhe des Nennkapitals von Kapitalgesellschaften orientiert sich nicht an der Größe des Unternehmens, sondern ist sowohl für die GmbH als auch die AG im Minimum festgesetzt. Es findet auch keine anschließende gesetzliche Anpassung statt und ist in seiner Finanzierung strikt geregelt. Als Ausgangspunkt einer neuen Regelung kann man zunächst die gleichen Vorschriften zur Aktiengesellschaft auf die dezentralen Anwendungen übertragen. Im Vorfeld einer Veröffentlichung könnte der Entwickler zur Einzahlung eines Nennkapitals auf ein Treuhandkonto verpflichtet werden. Dadurch würde zumindest ein Mindestmaß an Absicherung der Gläubiger realisiert werden. 526 Grigoleit in Grigoleit AktG, § 1 Rn. 17; Wüsthoff in BeckOGK AktG, § 1 Rn. 36ff. 527 Wüsthoff in BeckOGK AktG, § 1 Rn. 84; Heider in MüKo AktG, § 1 Rn. 97. 528 Kirchner in FS Raiser, Zur Ökonomischen Theorie der juristischen Person, 181, 191f.; Kübler, WM 1990, 1853, 1855ff.; Bauer, Gläubigerschutz durch Nennkapital, S. 1ff. 529 Kirchner in FS Raiser, Zur Ökonomischen Theorie der juristischen Person, 181, 191.

168

Handlungsoptionen für eine Anpassung des Regulierungsrahmens

Allerdings würde die dezentrale Anwendung an ein reguläres Konto gebunden werden, wofür bei besseren Alternativen kein Bedarf besteht. Ebenso wird kein allgemein festgesetzter Betrag den Ansprüchen einer dezentralen Anwendung gerecht, da schon kleine Fehler zu deutlich höheren Haftungssummen führen können und ein Mehrwert gegenüber der Inanspruchnahme der einzelnen Blockchain-Mitglieder nur gering wäre. Es soll zwar ein Nennkapital für dezentrale Anwendungen bestehen. Dies soll aber weder starr noch ex ante eingezahlt werden. Stattdessen besteht für dezentrale Anwendungen die Möglichkeit, eine separate Adresse (Account) innerhalb der Blockchain für den Nennbetrag zu bilden bei dem die Verfügungsbefugnis individuell geregelt werden kann. Anstatt einer vorausgehenden Einzahlung wird das Nennkapital mit jeder weiteren Transaktion aufgebaut, indem ein Bruchteil der Transaktionskosten an die dafür bestimmte Adresse übertragen wird. Bei dieser Konstruktion stellen sich drei grundsätzliche Probleme. Auch bei einer graduellen Einzahlung muss die minimale Höhe des Nennkapitals nach einem Grundsatz erfolgen. Am einfachsten wäre die Festlegung eines prozentualen Anteils einer jeden Transaktion, ohne dass ein Minimal-oder Maximalbetrag festgesetzt wird. Mit der Zeit würde dieses Vorgehen aber dazu führen, dass die eingezahlten Beträge die zu deckenden Risiken übersteigen können und dann zu überflüssigen Transaktionskosten führen. Um dies zu verhindern, muss es neben der prozentualen Einzahlung einen Höchstbetrag geben, ab dem keine weiteren Einzahlungen erforderlich sind. Der Höchstbetrag sollte sich am erwarteten Haftungsrisiko orientieren. Dabei könnte an die Vorschriften über die Bildung von Rückstellungen gem. § 249 HGB angeknüpft werden. Bilanzpflichtige Unternehmen müssen gem. § 249 HGB Rückstellungen für ungewisse Verbindlichkeiten bilden. Ohne konkreten Schadensfall ist es aber ausgesprochen schwer zu bewerten, welches grundsätzliche monetäre Risiko eine dezentrale Anwendung mit sich bringt. Es müsste wohl für jede dezentrale Anwendung ein individueller Betrag durch einen unabhängigen, zertifizierten Gutachter festgestellt werden. Neben der Ungenauigkeit bringt dieses Vorgehen einen erheblichen Mehraufwand mit sich, der die Umsetzung einer dezentralen Anwendung gefährden könnte und auch nicht notwendig ist. Stattdessen kann ein System genutzt werden, dass bereits der Risikobewertung von Finanzsystemen dient. Mit der Eigenkapitalrichtlinie530 wurde in der Europäischen Union eine risikoabhängige Höhe des Kernkapitals von Finanzinsti530 Richtlinie 2013/36/EU des Europäischen Parlaments und des Rates vom 26. Juni 2013 u¨ ber den Zugang zur Ta¨tigkeit von Kreditinstituten und die Beaufsichtigung von Kreditinstituten ¨ nderung der Richtlinie 2002/87/EG und zur Aufhebung der und Wertpapierfirmen, zur A Richtlinien 2006/48/EG und 2006/49/EG.

Haftung

169

tuten eingeführt, welches sich an Basel III531 orientiert. Die Nutzung dieses Systems wurde zumindest für den Bereich von Kryptowährungen bereits vereinzelt in Betracht gezogen.532 Die Verwendung eines vergleichbaren Rahmens ermöglicht es, einerseits eine risikoabhängige Bewertung vorzunehmen, andererseits durch eine einmalige abstrakte Regelung die erforderlichen Bewertungsaufwendungen zu reduzieren. Die konkrete Höhe der prozentualen Rückstellungen müssen sich dabei nicht an der für Banken festgesetzten Höhe von 8 % der Risikoaktiva, sondern könnten sich an einem verallgemeinerten Haftungsrisiko von dezentralen Anwendungen orientieren. Vorschläge für eine angemessene Höhe bedürfen empirischer Feststellung. Bei der Programmierung einer automatischen Bildung von Rückstellungen muss darauf geachtet werden, dass Einzahlungen nur bis zum Erreichen des erforderlichen Betrages erfolgen. Wurden Rückstellungen gebildet und der Nennbetrag in erforderlicher Höhe erreicht, bleibt das Problem der Verfügungsbefugnis. Dabei kommt entweder eine autonome Verfügungsbefugnis der BlockchainMitglieder oder eine staatlich-zentralisierte Verfügungsbefugnis durch Gerichte in Betracht. Die Verfügungsbefugnis durch die Blockchain-Mitglieder würde dann letztlich auf ein eigenständiges System von Online Dispute Resolution (ODR) hinauslaufen. Hierzu wurden bereits detaillierte Ansätze für unterschiedliche blockchain-basierte Dispute Resolution Anwendungen entwickelt.533 Am vielversprechendsten scheinen dabei Systeme, bei denen für eine Jury zufällig Mitglieder der dezentralen Anwendung ausgesucht werden, die durch Mehrheit über die vorgebrachten Ansprüche entscheiden können. Die Stärke dieser Organisation liegt dabei in der Möglichkeit zur schnellen Abwicklung von Streitigkeiten. Sie weist allerdings auch die Schwäche üblicher Jurysysteme in Form von fehlender Fachkenntnis der ausgewählten Jurymitglieder auf, sodass weitgehend juristische Laien über Ansprüche entscheiden. Selbst wenn ein ODR-System in die dezentrale Anwendung integriert wird, muss dem Anspruchssteller zumindest auch der Weg zu den Gerichten offen stehen, sodass zumindest diese zwingend die Verfügungsbefugnis über die Rückstellungen innehaben müssen. Die konkrete technische Umsetzung für dies Verfahren ist jedoch noch unklar. Der vorgeschlagene Ansatz zur Schließung von Haftungslücken ist mit erheblichem legislativen Aufwand verbunden. Es müssen Risikobewertungen von dezentralen Anwendungen und allgemeingültige Prozentsätze für die Nennka531 Basel III: https://www.bis.org/publ/bcbs188.pdf. 532 Zetsche u.w.: The Distributed Liability of Distributed Ledgers, 1403ff., https://tinyurl.com /bdenxyju abgerufen am 18. 1. 2021, die nicht von einer Inanspruchnahme des Einzelnen ausgehen. 533 Rabinovich-Einy/Katsch: Blockchain and the inevebility of disputes, 14ff.

170

Handlungsoptionen für eine Anpassung des Regulierungsrahmens

pitalquote entwickelt werden. Darüber hinaus müssen einheitliche technische Standards bezüglich der Gewährleistung der Verfügungsbefugnis der Gerichte entwickelt und festgesetzt werden. Bei dem derzeitigen Stand von dezentralen Anwendungen ist mit einer Umsetzung dieser Maßnahmen in der mittelfristigen Zukunft nicht zu rechnen.

Fazit

Unabhängig davon, ob die Blockchain-Technologie nur als Hype oder als neue Ära des Internets wahrgenommen wird, stellen hierauf beruhende Anwendungen eine neue Herausforderung für unser Rechtssystem dar. Damit ist keinesfalls gemeint, dass das Rechtssystem mit jeder neuen Technologie bereits wieder veraltet ist, sondern dass jedes Mal aufs Neue geprüft werden muss, wie gut die Sachverhalte in der Realität noch von bestehenden Rechtsnormen erfasst werden können. Auch dezentrale Anwendungen sind keine vollkommene Neuheit, sondern vertiefen nur bereits bestehende Trends der Digitalisierung und Globalisierung. Dabei bilden sich in einzelnen Bereichen Alleinstellungsmerkmale der Technologie, die das Rechtssystem in diesem Umfang bislang nicht abdecken musste. Während schon bisherige Plattformen mit verteilten Datenstrukturen arbeiten, ist die Dezentralisierung der Herrschaftsgewalt über ein System mittels der dezentralen Anwendungen in bisher nicht bekannten Ausmaßen möglich. Schon der Beginn des Internets war mit der Hoffnung verbunden, dass die neue Technologie zur Dezentralisierung und Demokratisierung führen würde. Stattdessen bildeten sich Intermediäre, die in Form von Plattformen einen überwiegenden Teil der wirtschaftlichen Vorteile des Internets genießen. Ob die Blockchain-Technologie die Hoffnung nach einer Dezentralisierung von wirtschaftlichen Vorteilen erfüllen kann, ist bei derzeitigem Stand der Entwicklung nicht abzuschätzen. Anhand eines konkreten Geschäftsmodells wurde untersucht, wie unterschiedliche Bereiche des Rechts auf rein dezentrale Geschäftsmodelle anwendbar sind und reagieren können. Die Dezentralisierung von Verantwortung stellt für die bisherige Rechtsordnung eine erhebliche Herausforderung dar. Zwar kennt auch sie eine Mehrzahl von Verantwortlichen und Adressaten und auch ausdifferenzierte Formen von Kooperationen mehrerer Individuen. Neu ist hingegen die Anonymität und schiere Masse an Personen, die für Maßnahmen und Ansprüche in Frage kommen. Stoßen die bisherigen öffentlich-rechtlichen Vorschriften zur Regulierung der Sharing Economy schon an ihre Grenzen bei neuartigen Plattformmodellen, so ist ein Scheitern umso wahrscheinlicher, je dezentraler eine Anwendung aufge-

172

Fazit

baut ist. Unter die bisherigen Kategorien von Verantwortlichen lassen sich die handelnden Akteure einer dezentralen Anwendung nicht mehr subsumieren. Mit den bisherigen Schranken für geschützte Märkte lassen sich Anwendungsentwickler und Mitglieder der Blockchain nicht mehr in Anspruch nehmen. Ohne eine Anpassung der Marktzugangsschranken können dezentrale Anwendungen ohne weitere Hindernisse veröffentlicht werden und lassen sich auch nachträglich mit den bisherigen Methoden nicht mehr untersagen. Was schon bei bisherigen Modellen der Sharing Economy befürchtet wird, tritt bei dezentralen Anwendungen ein. Jeder einzelne Nutzer müsste bei einem Rechtsverstoß von den Ordnungsbehörden adressiert werden. Eine effektive Regulierung wäre nicht mehr möglich. Im Gegensatz hierzu zeigen die Regelungen des BGB und des UWG, dass auch bisherige Normen geeignet sind, Sachverhalte der Blockchain-Technologie zu erfassen; sei es auf der Ebene des Verbraucherrechts, der vertraglichen oder der deliktischen Haftung. In allen Bereichen können die Sachverhalte unter bisherige Normen subsumiert und vertretbare Ergebnisse erzielt werden. Allerdings zeigen sich auch hier Schwächen älterer Rechtsnormen. Nie zuvor bestand das Bedürfnis, eine derart große Anzahl von unbekannten Personen in Anspruch zu nehmen. Trotz der Regelungen zur Haftung, zur Gesamtschuldnerschaft und zur gesellschaftsrechtlichen Sonderbeziehung bestehen keine zuverlässigen Mechanismen zur Rechtsdurchsetzung. In der Praxis sind die Ansprüche nur wenig wert, solange sie sich nicht gegen den Anwendungsentwickler richten. Betrachtet man die Haftung auf einer Wertungsebene, kann man an die Fairness des Haftungsregimes nach geltendem Recht zweifeln. Die Nutzer von dezentralen Anwendungen sind überwiegend Verbraucher und Kleinunternehmer. Die dabei entstehenden Haftungssummen decken sich nicht mit der Solvenz der Schuldner. Eine geeignete Risikoverteilung besteht nicht. Die genannten Probleme lassen sich mit unterschiedlichen Mitteln von Rechtsanpassung und innovativen Regulierungsansätzen beheben. Der Aufwand ist dabei teils erheblich, um angemessene Ergebnisse zu erreichen. Die in dieser Arbeit vorgeschlagenen Lösungsansätze sind dabei nicht als zwingende Handlungsempfehlungen zu verstehen, sondern als Optionen, um in einzelnen Bereichen eine gezielte Anpassung der rechtlichen Vorgaben zu erreichen. Dabei bietet gerade die Regulierung über Marktintermediäre einen effektiven umfangreichen Einsatz, um unabhängig von der ausgehenden Gefahr Einfluss auf eine bestehende dezentrale Anwendung zu nehmen. Dank der flexiblen Anpassung der Transaktionsstrafen, kann sie als Anreiz für die Blockchain-Mitglieder zur Anpassung der Anwendung bis hin zum kompletten Ausschluss der Anwendung vom Sekundärmarkt genutzt werden, ist aber letztlich nur eine Ultima Ratio, die den Problemherd der Rechtsverstöße nicht zu löschen vermag.

Fazit

173

Ob langfristig Änderungen von Marktzugangsbeschränkungen und Haftungssystemen zu erwarten sind, hängt primär von der künftigen wirtschaftlichen Relevanz dezentraler Systeme ab. Die naheliegende rechtspolitische Überlegung zum aktuellen Zeitpunkt möglichst geringfügige Restriktionen aufzubauen, ist zur Förderung von Innovation und Forschung verständlich. Geringe Restriktionen können aber auch den umgekehrten Effekt herbeiführen und eine Verbreitung von dezentralen Anwendungen unterdrücken. Bereits jetzt leidet die Blockchain-Technologie unter dem Misstrauen, das ihr von weiten Teilen der Gesellschaft entgegengebracht wird. Ein frühzeitiger Regulierungsansatz, nicht nur für Token, sondern gerade auch für dezentrale Systeme, kann Vertrauen in die Technologie schaffen und so die Verbreitung der Technologie unterstützen. Während sich aktuell primär Investoren und Spekulanten von der Blockchain-Technologie angesprochen fühlen, würde eine frühzeitige Regulierung eine Verbreitung von verbrauchertauglichen Anwendungen fördern. Der untersuchte Bereich von dezentralen Anwendungen in der Sharing Economy bildet einen Querschnitt für öffentlich-und zivilrechtliche Regelungen. Die untersuchten Bereiche sind zwar nicht abschließend, sind aber repräsentativ für diese Bereiche. Die grundlegenden Erkenntnisse lassen sich auch auf sonstige dezentrale Anwendungen übertragen. Insbesondere sind die Regulierungsansätze nicht auf Geschäftsmodelle der Sharing Economy beschränkt. Bei den vorgestellten Regulierungsansätzen handelt es sich nicht um das berüchtigte »Law of the Horse«, das für jedes neue Phänomen eine Regelung schaffen möchte. Es wurde gezeigt, in welchen Bereichen die abstrakten Normen nicht mehr ausreichen, um die praktischen Anwendungsfälle zu erfassen. Die Befürchtung Easterbrooks, dass dadurch allgemeine Prinzipen vernachlässigt werden und auf Unterschiede statt Gemeinsamkeiten abgestellt wird, bewahrheitet sich nicht. Gerade die Erarbeitung der gemeinsamen Grundlagen und die Erkenntnis, dass diese Grundlagen einheitlich anwendbar sein müssen, unabhängig von der Technologie, führt zu dem Bedürfnis einer neuen Regulierung. Würden die nach geltendem Recht entstehenden Ergebnisse hingenommen, entstünden Regelungslücken in Bereichen, die die Verbraucher und die öffentliche Sicherheit gefährden würden. Die Normen dienen nicht dazu, ein eigenes Rechtssystem für dezentrale Anwendungen zu schaffen. Sondern stattdessen die dezentralen Anwendungen der gleichen Regulierung zu unterwerfen, der auch bisherige Geschäftsmodelle unterliegen.

Glossar

Anwendungsentwickler: Verantwortliche natürliche oder juristische Person, die eine DApp der Öffentlichkeit zugänglich macht, unabhängig davon, ob sie unmittelbar an der Entwicklung beteiligt war oder lediglich eine bereits fertige DApp erworben und veröffentlich hat. Dezentralized Autonomous Organisation (DAO): DApp, bei der durch den Verkauf von Token Vermögen zur gemeinsamen Investition gesammelt wurde. Bekannt geworden vor allem durch einen Programmfehler, der es Dritten ermöglichte 50 Mio US-$ nach damaligem Kurz zu entwenden. Dezentrale Anwendung (DApp): Softwareprogramm, dessen Quellcode öffentlich zugänglich und auf einer programmeigenen Blockchain hinterlegt ist. Sie ist vollständig dezentral gespeichert und Veränderungen werden mittels eines Konsensmechanismus implementiert. Fiat Währung: Nationale Währung, die nicht an den Preis eines Rohstoffes wie Gold oder Silber gebunden ist und von nationalen Stellen als anerkanntes Zahlungsmittel ausgegeben wird. Front-End-Interface: Der Teil der Anwendung, der für den Nutzer sichtbar ist, z. B. in Form von Benutzer-/Bedienoberflächen oder grafischen Darstellungen. Initial Coin Offering (ICO): Vertriebsform für Token einer DApp. Der Ablauf ist ähnlich zur Wertpapierveräußerung (Initial Public Offering). Token werden gleichzeitig einer Vielzahl von Interessenten angeboten, durch deren Wettbieten sich der Handelskurs des Token bildet.

176

Glossar

Konsensmechanismus: Algorithmus in der DApp, der eine Einigung über den Status zwischen seinen Teilnehmern ermöglicht. Bekannteste Beispiele sind der von der Bitcoin-Blockchain verwendete Proof of Work und von der EthereumBlockchain verwendete Proof of Stake Mechanismus. Kryptowährung: kryptographisch verschlüsseltes digitale Rechnungseinheit, die auf Grundlage einer Blockchain geschaffen wurde. Bislang handelt es sich um privat ausgegebene Einheiten, die nicht den Status einer anerkannten FiatWährung erreicht haben. Miner: natürliche oder juristische Person, die innerhalb einer DApp Token minet. Mining ist die Schaffung neuer Token durch Verifizierung bisheriger Transaktionen auf Grundlage des verwendeten Konsensmechanismus. Node: Recheneinheit, die mittels Speicherung der DApp an dieser beteiligt ist. Full Node: Speicherung der gesamten DApp, inbesondere der Blockchain, wodurch sie vollwertiges Mitglied der DApp sind. Half Node: Speicherung eines kleinen Teils der DApp, der zwar die Interaktion mit anderen Full-Nodes ermöglicht, aber selbst kein vollwertiges Mitglied ist und auch nicht am Konsensverfahren beteiligt werden kann. Node Betreiber: natürliche oder juristische Person, die ein Node im eigenen Herrschaftsbereich unterhält. Online Dispute Resolution (ODR): Online Streitbeilegung, bei der die Kommunikation der Parteien technologiebasiert erfolgt. Private Key: Sicherheitsschlüssel, bestehend aus Zahlen, Buchstaben oder Zeichen, der es einem ermöglicht auf die Token einer zugewiesenen Adresse zuzugreifen. Er kann dem PIN einer EC- oder Kreditkarte gleichgesetzt werden. Public Key: öffentliche einsehbare Adresse innerhalb der DApp, der Token zugewiesen werden können. In Verbindung mit dem Private Key können Token einer anderen Adresse zugewiesen werden. Es entspricht der bisherigen Kontonummer bei Bankkonten. Smart Contracts: Computerprotokolle, die auf Grundlage einer Wenn-DannBedingung Verträge oder Ereignisse automatisiert abwickeln können.

Glossar

177

Token: Rechnungseinheiten einer Blockchain. Investment-Token: Token, die dem Inhaber eine Unternehmens-, Gewinn- oder Stimmrechtsbeteiligung gewährleisten. Currency-Token: Token, die als Austausch für Waren oder Dienstleistungen vorgesehen sind und eine Alternative zu staatlich anerkannten Fiat-Währungen darstellen sollen. Sie sind nicht an einer DApp gebunden, sondern sollen unabhängig von der verwendeten Plattform als Zahlungsmittel verwendet werden. Utility-Token: Token, die innerhalb einer DApp zum Austausch für eine Leistung verwendet werden. Im Gegensatz zu Currency-Token sind sie anwendungsgebunden. Token Exchanges: digitaler Handelsplatz für Token. Sie funktionieren ähnlich zu Wertpapierbörsen, wobei zumindest teilweise die Token-Exchanges nicht nur Vermittler, sondern auch Kommisionäre für die Transaktion sind. Durch das paaren von Angebot und Nachfrage bildet sich auf dem Handelsplatz ein Tokenkurs. Dieser kann zwischen unterschiedlichen Token Exchanges variieren. Wallet: digitale Geldbörse, die Public und Private Keys für unterschiedliche Token speichern und verwalten. Wallet Provider: natürliche oder juristische Person, die digitale Geldbörsen öffentlich anbietet. 51 % Attacke: Angriff auf die Inegrität der DApp durch Dritte, bei der 51 % der zum Konsens erforderlichen Eigenschaft kontrolliert wird und somit eine einzige Person über den Konsens der DApp entscheiden kann. Beim Proof-of-Work verfahren, muss der Angreifer 51 % der an der DApp beteiligten Rechenleistung erlangen. Beim Proof-of-Stake 51 % der geschaffenen Token einer DApp.

Literaturverzeichnis

Abbott, Kenneth/Levi-Faur, David/Snidal, Duncan: Theorizing Regulatory Intermediaries: The RIT Model, The ANNALS of the American Academy of Political and Social Science, 2017, S. 14–35. Arcade City: Whitepaper, https://docs.google.com/document/d/1Fm39dHCJmAAZ-P5CqOc4P2f0Vx__84AhDD98LPNLVY/edit#heading=h.idjvzo63u1nd (abgerufen am 18. 1. 2021). Assmann, Heinz-Dieter: Konzeptionelle Grundlagen des Anlegerschutzes, ZBB 1989, S. 49– 63. Assmann, Heinz-Dieter/Lenz, Jürgen/Ritz, Corinna: Verkaufsprospektgesetz Verkaufsprospekt-Verordnung Verkaufsprospektgebühren-Verordnung, Köln, 2001. Assmann, Heinz-Dieter/Schneider, Uwe/Mülbert, Peter: Kommentar zum Wertpapierhandelsrecht, 8. Aufl., Köln, 2023. Auer-Reinsdorff, Astrid/Conrad, Isabell: Handbuch IT- und Datenschutzrecht, 3. Aufl. München, 2019. Bae, Jaewon/Lim, Hyuk: Random Mining Group Selection to Prevent 51 % Attacks on Bitcoin, 48th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops, 2018, S. 81–82. Baliga, Arati, Understanding Blockchain Consensus Models, https://www.persistent.com /wp-content/uploads/2017/04/WP-Understanding-Blockchain-Consensus-Models.pdf (abgerufen am 18. 1. 2021). Bamberger, Heinz/Roth, Herbert u.w.: Kommentar zum BGB, 4. Aufl., München, 2019. v. Bar, Christian: Verkehrspflichten, Berlin, 1980. v. Bar, Christian: Die Grenzen der Haftung des Produzenten in v. Bar Produktverantwortung und Risikoakzeptanz, München, 1998, S. 29–47. Bartsch, Michael: Anmerkungen zu OLG Stuttgart 6 U 135/87, CR 1989, S. 692–694. Bartsch, Michael: Software als Rechtsgut – Zur Wahrnehmung von Software aus Sicht des Rechts, zur Begriffsbildung im Recht und zu den praktischen Konsequenzen, CR 2010, S. 553–559. Bauer, Michael: Kommentar zum Personenbeförderungsgesetz, Köln, 2010. Basel Committee on Banking Supervision: Basel III: International framework for liquidity risk measurement, standards and monitoring, https://www.bis.org/publ/bcbs188.pdf (abgerufen am 18. 1. 2021).

180

Literaturverzeichnis

Bauer, Marcus: Gläubigerschutz durch eine formelle Nennkapitalziffer – Kapitalgesellschaftsrechtliche Notwendigkeit oder überholtes Konzept?, Bern, 1995. Beaucamp, Guy /Seifert, Jens: Soll der Zweckveranlasser weiterleben?, JA, 2007, S. 577–580. Beaucamp, Sophie/Henningsen, Sebastian/Florian, Martin: Strafbarkeit durch Speicherung der Bitcoin-Blockchain? Ein Lösungsversuch aus technischer und rechtlicher Sicht, MMR 2018, S. 501–507. Beinke, Jan/Tönnissen, Stefan/Teuteberg, Stefan: Disruptionspotenzial und Implikationen der Blockchain-Technologie am Fallbeispiel der Zeitarbeit – Eine Prozess- und Schwachstellenanalyse, HMD Praxis der Wirtschaftsinformatik 2019, S. 660–676. Behme, Casper/Zickgraf, Peter: Zivil- und gesellschaftsrechtliche Aspekte von Initial Coin Offerings (ICOs), ZfPW 2019, S. 66–93. Behrens, Alexander/Schadtle, Kai: Erlaubnispflichten für Bank- und Finanzdienstleistungen im Zusammenhang mit Kryptowerten nach Umsetzung der Fünften EU-Geldwäscherichtlinie, WM 2019, S. 2099–2104. Belli, Fevzi: Modellierung von Software-Fehlern zur Bestimmung und Optimierung der Zuverlässigkeit in Gorny/Kilian Computer-Software und Sachmängelhaftung, Stuttgart, 1985, S. 68–87. Beres, Ferenc u.w.: Blockchain is Watching You: Profiling and Deanonymizing Ethereum Users, https://arxiv.org/abs/2005.14051 (abgerufen am 18. 1. 2021). Bernstein, Gaia: In the Shadow of Innovation, Cardozo Law Review, Vol. 31, No. 6, S. 2257– 2312. Beutin, Nikolas: Share Economy 2017 – The New Business Model, https://www.pwc.de/de /digitale-transformation/share-economy-report-2017.pdf (abgerufen am 2. 11. 2021). Blockchain Bundesverband: Positionspapier zur Regulierung von Token, https://tinyurl.c om/tjr2rykh (abgerufen am 18. 1. 2021). Bossauer, Paul: Dezentralisierung der Sharing Economy – Potentiale Blockchain-basierter Sharing-Plattformen, https://tinyurl.com/34js4e79 (abgerufen am 18. 1. 2021). Böhme, Rainer/Pesch, Paulina: Technische Grundlagen und datenschutzrechtliche Fragen der Blockchain-Technologie, DuD 2017, S. 473–481. Borck, Reinhard: Allgemeiner Teil des Bürgerlichen Gesetzbuches, 4. Aufl., Tübingen, 2016. Börner, Rene: Kryptowährungen und strafbarer Marktmissbrauch, NZWiSt 2018, S. 48–54. Bräutigam, Peter/Klindt, Thomas: Industrie 4.0, das Internet der Dinge und das Recht, NJW 2015, S. 1137–1142. Brönnecke, Tobias/Schmidt-Kessel, Fabian: Der Anwendungsbereich der Vorschriften über die besonderen Vertriebsformen nach Umsetzung der Verbraucherrechterichtlinie, VuR 2014, S. 3–8. Brox, Hans/Walker Wolf-Dietrich: Allgemeines Schuldrecht, 46. Aufl., München, 2022. Brüggemeier, Gert: Bestandsaufnahme und Perspektiven weiterer judizieller Rechtsentwicklungen, WM 1982, S. 1294–1309. Bruns, Alexander: Unentgeltliche Verträge und Gefälligkeitsverhältnisse – Die Perspektive des Versicherungsrechts, VersR 2018, S. 789–796. Buck-Heeb, Petra: Kapitalmarktrecht, 11. Aufl., Heidelberg, 2020. Buhl, Samir: Der App-Download, Münster, 2019. Bundesministerium fu¨ r Wirtschaft und Energie (BMWi): Sharing Economy im Wirtschaftsraum Deutschland, https://tinyurl.com/38tjnaau (abgerufen am 18. 1. 2021).

Literaturverzeichnis

181

Busch, Christoph u.w.: The Rise of the Platform Economy: A New Challenge for EU Consumer Law?, EuCML, 2016, S. 3–10. Busch, Christoph/Dannemann, Gerhard/Schulte-Nölke, Hans: Ein neues Vertrags- und Verbraucherrecht für Online-Plattformen im Digitalen Binnenmarkt? Diskussionsentwurf für eine mögliche EU-Richtlinie, MMR 2016, S. 787–792. Busch, Christoph: The Sharing Economy at the CJEU: Does Airbnb pass the ›Uber test‹? – Some observations on the pending case C-390/18 – Airbnb Ireland, EuCML 2018, S. 172– 174. Busch, Christoph: Europäische Modellregeln für Online-Vermittlungsplattformen, in Rott, Peter/Tonner, Klaus, Online-Vermittlungsplattformen in der Rechtspraxis, Baden-Baden, 2018, S. 150–167. Busch, Christoph: Self-Regulation and Regulatory Intermediation in the Platform Economy in Cantero Gamito, Marta/ Micklitz, Hans-Wolfgang, The Role of the EU in Transnational Legal Ordering: Standards, Contracts and Codes, Cheltenham 2020, S. 115–134. Busch, Christoph: Effektiver Verbraucherschutz im Online-Handel: Verantwortung und Haftung von Internetplattformen, Rechtsgutachten im Auftrag des Verbraucherzentrale Bundesverband e.V, 2019, https://tinyurl.com/2nxenjx8 (abgerufen am 18. 1. 2021). Busch, Christoph u.w.: Sharing Economy in Deutschland: Stellenwert und Regulierungsoptionen für Beherbergungsdienstleistungen, https://doi.org/10.5771/9783845296906 (abgerufen am 18. 1. 2021). Busch u.w.: The ELI Model Rules on Online Platforms, EuCML 2020, S. 61–70. Bydlinski, Franz: Juristische Methodenlehre und Rechtsbegriff, 2. Aufl. Wien, 1991. Canaris, Claus-Wilhelm: Die Feststellung von Lücken im Gesetz, 2. Aufl. Berlin, 1983. Canaris, Claus-Wilhelm: Der Schutz der obligatorischen Forderungen nach § 823 I BGB in Festschrift für Erich Steffen, Berlin, 1995, S. 85–99. Calabresi, Guido: The Costs of Accidents, London, 1970. Cardozo Blockchain Projekt: Not So Fast – Risks Related to the Use of a »SAFT« for Token Sales, https://tinyurl.com/38nynf 7u (abgerufen am 18. 1. 2021). Coase, Ronald: The Nature of the Firm, Economica, Vol. 4: Iss. 16, S. 386–405. Denninger, Erhard/Bäcker, Matthias/Graulich, Kurt: Handbuch des Polizeirechts; 7. Aufl., München, 2021. Deutsch, Andreas: Vertragsschluss bei Internetauktionen – Probleme und Streitstände, MMR 2004, S. 586–589. Dörner, Heinrich: Gewährleistung für Softwaremängel, Jura 1993, S. 578–582. Dorner, Michael: Big Data und »Dateneigentum« – Grundfragen des modernen Daten- und Informationshandels, CR 2014, S. 614–628. Dreyer, Holger/Haskamp, Thomas: Die Vermittlungstätigkeit von Plattformen, ZVertriebsR 2017, S. 359–363. Easterbrook, Frank: Cyberspace and the Law of the Horse, University of Chicago Legal Forum 1996, S. 207–216. Elsenbast, Wolfgang: Ökonomische Konzepte zur Regulierung »neuer Märkte« in der Telekommunikation, MMR 2006, S. 575–579. Engel, Martin/Stark, Johanna: Verbraucherrecht ohne Verbraucher?, ZEuP 2015, S. 32–51. Ennuschat, Jörg/Wank, Rolf/ Winkler, Daniela: Kommentar zur Gewerbeordnung, 9. Aufl., München 2020.

182

Literaturverzeichnis

Erman, Walter: Kommentar zum Bürgerlichen Gesetzbuch, 16. Aufl., Köln, 2020. Evans, David: Economic Aspects of Bitcoin and Other Decentralized Public-Ledger Currency Platforms, https://core.ac.uk/download/pdf/208684586.pdf (abgerufen am 18. 1. 2021). Faber, Wolfgang: Elemente verschiedener Verbraucherbegriffe in EG-Richtlinien, zwischenstaatlichen Übereinkommen und nationalem Zivil- und Kollisionsrecht, ZEuP 1998, S. 854–892. Faustmann, Jörg: Der deliktische Datenschutz, VuR 2006, S. 260–264. Feldmann, Thorsten: Mobile Apps: Zivilrecht-Telemedienrecht-Datenschutzrecht in Taeger, DSRI-Tagungsband, Oldenburg, 2011, S. 47–66. Fezer, Karl-Heinz/Büscher, Wolfgang/Obergfell, Eva: Kommentar zum UWG, 3. Aufl., München, 2016. Fielitz, Karl/ Grätz, Thomas: Kommentar zum Personenbeförderungsgesetz, Köln, LoseBl. (September 2016). Fikentscher, Wolfgang/Heinemann, Andreas: Schuldrecht, Berlin, 2017. Fleischer, Holger: Zur Verantwortlichkeit einzelner Vorstandsmitglieder bei Kollegialentscheidungen im Aktienrecht, BB 2004, S. 2645–2652. Flume, Werner: Das »Halten und Verwalten« eines Vermögens oder Vermögensgegenstands als BGB-Gesellschaft in zivilrechtlicher und steuerrechtlicher Sicht, DB 1973, S. 2470–2473. Foerste, Ulrich/Graf v. Westphalen, Friedrich: Produkthaftungshandbuch, 3. Aufl., München, 2012. Fries,Martin/Paal, Boris: Smart Contracts, Tübingen, 2019. Frodermann, Jürgen/Jannott, Dirk: Handbuch des Aktienrechts, 9. Aufl., Heidelberg, 2017. Fromm, Friedrich/Nordemann, Wilhelm: Kommentar zum Urheberrechtsgesetz, 12. Aufl., Stuttgart, 2018. Fuchs, Andreas: Kommentar zum WpHG, 2. Aufl., München, 2016. Gerhardt, Walter: Der Haftungsmaßstab im gesetzlichen Schutzverhältnis (Positive Vertragsverletzung culpa in contrahendo), JuS 1970, S. 597–603. Gersdorf, Hubertus/Paal, Boris: Beck’scher Online-Kommentar zum Informations- und Medienrecht, 39. Ed., München, Stand 1. 8. 2022. Girasa, Rosario: Regulation of Crypotcurrencies and Blockchain Technologies – National and International Perspectives, https://doi.org/10.1007/978-3-319-78509-7 (abgerufen am 18. 1. 2021). Graf v. Westphalen, Friedrich: Das neue Produkthaftungsgesetz, NJW 1990, S. 83–93. Graf v. Westphalen, Friedrich: »Weiterfressende« Schäden und kein Ende? Anmerkungen zur Interpretation von § 1 Abs. 1 Satz 2 ProdHaftG, Jura 1992, S. 511–514. Grigoleit, Hans: Unentgeltliche Verträge und Gefälligkeitsverhältnisse – Die Perspektive des Haftungsrechts, VersR 2018, S. 769–789. Grigoleit, Hans: Kommentar zum Aktiengesetz, 2. Aufl., München, 2020. Goette, Wulf/Habersack, Mathias/Kalss, Susanne: Münchener Kommentar zum Aktiengesetz Band 1, 5. Aufl., München, 2019. Groß, Wolfgang: Kapitalmarktrecht, 8. Aufl., München, 2022. Gsell, Beate/Krüger, Wolfgang/Lorenz, Stephan/Reymann, Christoph: beck-online.Grosskommentar zum Zivilrecht, München, Stand 1. 12. 2022.

Literaturverzeichnis

183

Götting, Horst-Peter/Nordemann, Axel: Handkommentar zum UWG, 3. Aufl., BadenBaden, 2016. Götz, Volkmar/Geis, Max-Emanuel: Allgemeines Polizei- und Ordnungsrecht, 17. Aufl., München, 2022. Habersack, Mathias: Die Mitgliedschaft: subjektives und »sonstiges« Recht, Tübingen, 1996. Habersack, Mathias/Mülbert, Peter/Schlitt, Michael: Unternehmensfinanzierung am Kapitalmarkt, 4. Aufl., Köln, 2019. Hacker, Philipp/Thomale: Crypto-Securities Regulation: ICOs, Token Sales and Cryptocurrencies under EU Financial Law, European Company and Financial Law Review (ECFR) 2018, S. 645–696. Hahn, Christopher/Wons, Adiran: Initial Coin Offering – Unternehmensfinanzierung auf Basis der Blockchain-Technologie, Wiesbaden, 2018. Hara, Kazuki u.w.: Profiling of Malicious Users Using Simple Honeypots on the Ethereum Blockchain Network, https://ieeexplore.ieee.org/document/9169469 (abgerufen am 18. 1. 2021). Hargrave, John/Sahdev, Navroop/Feldmeier, Olga: How Value is Created in Tokenized Assets, http://dx.doi.org/10.2139/ssrn.3146191 (abgerufen am 18. 1. 2021). Harte-Bavendamm, Henning/Henning-Bodewig, Frauke: Kommentar zum UWG, 5. Aufl., München, 2021. Hartmann, Bernd/Mann, Thomas/Mehde, Veith: Landesrecht Niedersachsen, 3. Aufl., Baden-Baden, 2020. Hartmann, Volker: Der Kfz-Hersteller im Spannungsfeld zwischen Produkthaftungsrecht und UWG, BB 2012, S. 267–273. Hau, Wolfgang/Poseck, Roman: Beck’scher Online-Kommentar zum BGB, 65.Ed., München, Stand 1. 2. 2023. Haucap, Justus/Kruse, Jörn: Ex-Ante-Regulierung oder Ex-Post-Aufsicht für netzgebundene Industrien?, https://www.econstor.eu/obitstream/10419/23541/1/paperno25.pdf (abgerufen am 18. 1. 2021). Haucap, Justus/Kehder, Christiane: Welchen Ordnungsrahmen braucht die Sharing Economy?, https://www.econstor.eu/bitstream/10419/174508/1/1013753003.pdf (abgerufen am 18. 1. 2021). Hauck, Ronny/Blaut, Heiko: Die (quasi-)vertragliche Haftung von Plattformbetreibern, NJW 2018, S. 1425–1430. Havinga, Tetty/Verbruggen, Paul: Understanding Complex Governance Relationships in Food Safety Regulation: The RIT Model as a Theoretical Lens, The ANNALS of the American Academy of Political and Social Science, 2017, S. 58–77. Heinze, Christian: Kommentar zum Personenbeförderungsgesetz, Baden-Baden, 2007. Heinze, Christian/Fehling, Michael/Fiedler, Lothar: Kommentar zum Personenbeförderungsgesetz, 2. Aufl., München, 2014. Hemke, Katja: Methodik der Analogiebildung im öffentlichen Recht, Berlin, 2006. Henssler, Martin: beck-online.Grosskommentar zum Aktiengesetz, München, 2023. Herberger, Maximilian u.w.: juris Praxiskommentar BGB, 9. Aufl., Saarbrücken 2020. Hermann, Peter/Schlingloff, Jochen: Münchener Kommentar zum Lauterkeitsrecht, 3. Aufl., München, 2020. Heymann, Thomas: Haftung des Softwareimporteurs, CR 1990, S. 176–179.

184

Literaturverzeichnis

Hilbig-Lugani, Katharina: Neuerungen im Außergescha¨ ftsraum- und Fernabsatzwiderrufsrecht, ZJS 2013, S. 441–452. Hilgendorf, Eric: Anmerkungen zu BayObLG 5 St RR 5/93, JR 1994, S. 476–480. Hilgendorf, Eric: Grundfälle zum Computerstrafrecht, JuS 1996, S. 890–894. Hirte, Heribert/Möllers, Thomas: Kölner Kommentar zum WpHG, Köln, 2014. Hoeren, Thomas: Dateneigentum – Versuch einer Anwendung von § 303a StGB im Zivilrecht, MMR 2013, S. 486–491. Hoeren, Thomas/Sieber, Ulrich/Holznagel, Bernd: Handbuch Mulitmedia-Recht, München, LoseBl. (August 2020). Hofert, Eduard: Regulierung der Blockchains, Tübingen, 2018. Hommelhoff, Peter: Börsenhandel von GmbH- und KG-Anteilen?, ZHR 1989, S. 181–215. Honsell, Heinrich: Zur Einarbeitung und Wiederholung, JuS 1995, S. 211–215. Hopt, Klaus: Der Kapitalanlegerschutz im Recht der Banken: gesellschafts-, bank- und börsenrechtliche Anforderungen an das Beratungs- und Verwaltungsverhalten der Kreditinstitute, München, 1975. Hopt, Klaus: Grunsatz- und Praxisprobleme nach dem Wertpapierhandelsgesetz – insbesondere Insidergeschäfte und Ad-Hoc-Publizität, ZHR 1995, S. 135–163. Hughes, Jane/ Middlebrook, Stephen: Advancing a Framework for Regulating Cryptocurrency Payments Intermediaries, Yale Journal on Regulation, Vol. 32 Iss. 2, S. 495– 559. Hütten, Moritz: The soft spot of hard code: blockchain technology, network governance and pitfalls of technological utopianism, https://doi.org/10.1111/glob.12217 (abgerufen am 18. 1. 2021). Ingold, Albert: Die »Sharing Economy« der kurzzeitigen Unterkunftsvermietung als Herausforderung für das Gewerbe-, Bau- und Ordnungsrecht, DÖV 2016, S. 595–602. Jauernig, Othmar (Begr.): Kommentar zum BGB, 18. Aufl., München, 2021. Joecks, Wolfgang/Miebach, Klaus: Münchener Kommentar zum StGB, 4. Aufl., München, 2020. Just, Clemens u.w.: Wertpapierprospektgesetz (WpPG) und EU-Prospektverordnung, München, 2007. Kantar Millward Brown, BrandZ – Top 100 Most valuable global brands 2020, zitiert nach statista, https://tinyurl.com/4nc5r73u (abgerufen am 18. 1. 2021). Katzenmeier, Christian: Produkthaftung und Gewährleistung des Herstellers teilmangelhafter Sachen, NJW 1997, S. 486–493. Kaulartz, Markus: Die Blockchain-Technologie – Hintergründe zur Distributed Ledger Technology und zu Blockchains, CR 2016, S. 474–480. Kaulartz, Markus/Heckmann, Jörn: Smart Contracts – Anwendungen der BlockchainTechnologie, CR 2016, S. 618–624. Keilholz, Kurt: Die Bedeutung der EG-Produkthaftpflichtrichtlinie 1985 für das private Baurecht, BauR 1987, S. 259–265. Kersting, Christian: Die Dritthaftung für Informationen im Bürgerlichen Recht, München, 2007. Kirchner, Christian: Zur ökonomischen Theorie der juristischen Person – Die juristische Person im Gesellschaftsrecht im Lichte der Institutionenökonomik, in FS Thomas Raiser, Berlin, 2005, S. 181–202.

Literaturverzeichnis

185

Klein, Urs/Datta, Amit: Vertragsstrukturen beim Erwerb kostenloser Apps – Der AppAnbieter als Vertragspartner des Nutzers, CR 2016, S. 587–590. Klein, Urs/Datta, Amit: Kostenlose Apps – eine vertragsrechtliche Analyse – Warum werbefinanzierte Gratis-Apps nicht verschenkt werden, CR 2017, S. 174–181. Klems, Markus u.w.: Trustless Intermediation in Blockchain-Based Decentralized Service Marketplaces in Maximilien/Vallecillo, Service-Oriented Computing, Berlin, 2017, S. 731–739. Klöhn, Lars/Parhofer, Nicolas/Resas, Daniel: Initial Coin Offerings (ICOs) – Markt, Ökonomik und Regulierung, ZBB 2018, S. 89–140. Koch, Frank/Schnupp, Peter: Software-Recht, Berlin, 2011. Koglin, Olaf: Opensourcerecht, Bern, 2007. Köhler, Helmut/Bornkamm, Joachim/Feddersen, Jörn u.w.: Kommentar zum UWG, 41. Aufl., München, 2023. König, Michael: Software (Computerprogramme) als Sache und deren Erwerb als Sachkauf, NJW 1993, S. 3121–3124. Koopman, Christpoh/Mitchell, Matthew/Thierer, Adam: The Sharing Economy and Consumer Protection Regulation: The Case for Policy Change, Journal of Business, Entrepreneurship and the Law (JBEL) 2015, S. 529–545. Kramer, Urs/Hinrichsen, Tim: Der Fall Uber – Taxen, Mietwagen und der technologische Fortschritt, GewArch 2015, S. 145–150. Kremer, Sasche: Vertragsgestaltung bei Entwicklung und Vertrieb von Apps für mobile Endgeräte, CR 2011, S. 769–776. Krüger, Fabian/Lampert, Michael: Augen auf bei der Token-Wahl – privatrechtliche und steuerliche Herausforderungen im Rahmen eines Initial Coin Offering, BB 2018, S. 1154–1160. Kübler, Friedrich: Transparenz am Kapitalmarktrecht – Wirtschaftspolitische Grundfragen aktueller Regelungsprobleme, AG 1977, S. 85–92. Kübler, Friedrich: Kapitalmarktgerechte Aktien?, WM 1990, S. 1853–1858. Lachenmann, Matthias: Mobile Apps, ITRB, 2015, S. 99–100. Landmann, Robert/Rohmer, Ernst (Begr.): Kommentar zur Gewerbeordnugn und ergänzende Vorschriften, München, LoseBl. (Februar 2020). Laufhütte, Heinrich/ Rissing-van Saan, Ruth/Tiedemann, Klaus: Leipziger Kommentar zum Strafgesetzbuch, 12. Aufl., Berlin, 2008. Lehmann, Matthias: Produkt- und Produzentenhaftung für Software, NJW 1992, S. 1721– 1725. Leistner, Matthias: Die Haftung von Kauf- und Buchungsportalen mit Bewertungsfunktionen in FS Köhler, München, 2014, S. 415–428. Lenckner, Theodor/Winkelbauer, Wolfgang: Computerkriminalität – Möglichkeiten und Grenzen des 2. WiKG (II), CR 1986, S. 654–661. Lenz, Jörn: Rechtliche Stellung von App-Stores: Eine zivil- und wettbewerbsrechtliche Analyse, Wiesbaden, 2018. Lenz, Jürgen/Ritz, Corinna: Die Bekanntmachung des Bundesaufsichtsamts für den Wertpapierhandel zum Wertpapier-Verkaufsprospektgesetz und zur Verordnung über Wertpapier-Verkaufsprospekte, WM 2000, S. 904–910. Lessig, Lawrence: Code: And Other Laws of Cyberspace, Version 2.0, New York, 2006.

186

Literaturverzeichnis

Li, Jun u.w.: LBRY: A Blockchain-Based Decentralized Digital Content Marketplace, https://ieeexplore.ieee.org/document/9126007/authors#authors (abgerufen am 18. 1. 2021). Liu, Yi u.w.: An efficient method to enhance Bitcoin wallet security, https://ieeexplore.ie ee.org/stamp/stamp.jsp?tp=&arnumber=8285737 (abgerufen am 18. 1. 2021). Loewenheim, Ulrich: Handbuch des Urheberrechts, 3. Aufl., München, 2021. Looschelders, Dirk: Neuere Entwicklungen des Produkthaftungsrechts, JR 2003, S. 309– 315. Looschelders, Dirk: Schuldrecht Besonderer Teil, 17. Aufl., München, 2022. Loschelder, Michael/ Danckwerts, Rolf: Handbuch des Wettbewerbsrechts, 5. Aufl., München, 2019. Ludwigs, Markus: Rechtsfragen der Sharing Economy am Beispiel der Modelle Uber und Airbnb, NVwZ, 2017, S. 1646–1653. Luther, Christoph: Die juristische Analogie, JURA 2015, S. 449–453. Manne, Henry: Insider Trading and the Stock Market, New York, 1966. Marburger, Peter: Regeln der Technik im Recht, Köln, 1979. Marcks, Peter: Makler- und Bauträgerverordnung (MaBV), 10. Aufl. München, 2019. Martinek, Michael/Semler, Franz-Jörg/Flohr, Eckhard: Handbuch des Vertriebsrecht, 4. Aufl., München, 2016. Maultzsch, Felix: Verantwortlichkeit der Plattformbetreiber, in Blaurock, Uwe/SchmidtKessel, Martin/Erler, Katharina, Plattformen, Baden-Baden, 2018, S. 223–256. Maume, Philipp: Der umgekehrte Verbrauchervertrag, NJW 2016, S. 1041–1045. Medicus, Dieter: Zur Reichweite gesetzlicher Haftungsmilderungen in FS Odersky, Berlin, 1996, S. 589–604. Medicus, Dieter/Petersen, Jens: Bürgerliches Recht, 28. Aufl., München, 2021. Meier, Klaus: Produzentenhaftung des Softwareherstellers – § 823 Abs. 1 BGB und das Produkthaftungsgesetz, CR 1990, S. 95–100. Meier, Klaus/Wehlau, Andreas: Die zivilrechtliche Haftung für Datenlöschung, Datenverlust und Datenzerstörung, NJW 1998, S. 1585–1591. Meiklejohn, Sarah u.w.: A Fistful of Bitcoins: Characterizing Payments Among Men with No Names, http://dx.doi.org/10.1145/2504730.2504747 (abgerufen am 21. 1. 2021). Mehrings, Josef: Computersoftware und Gewährleistungsrecht, NJW 1986, S. 1904–1909. Michalski, Lutz: Produktbeobachtung und Rückrufpflicht des Produzenten, BB 1998, S. 961–965. Moritz, Hans-Werner: Überlassung von Programmkopien – Sachkauf oder Realakt in Vertrag sui generis?, CR 1994, S. 257–263. Mozina, Damjan: Retail business, platform services and information duties, EuCML, 2016, S. 25–30. Möser, Malte/Narayanan, Arvind: Effective Cryptocurrency Regulation Through Blacklisting, https://maltemoeser.de/paper/blacklisting-regulation.pdf (abgerufen am 18. 1. 2021). Möstl, Markus/ Weiner, Bernhard: Beck’scher Online-Kommentar zum Polizei- und Ordnungsrecht Niedersachsen, 26. Ed., München, 1. 2. 2023. Münzer, Jens: Bitcoins – Aufsichtsrechtliche Bewertung und Risiken für Nutzer, BaFin Journal 2014, S. 26–30. Nägele, Thomas/Jacobs, Sven: Rechtsfragen des Cloud Computing, ZUM 2010, S. 281–292.

Literaturverzeichnis

187

Nakamoto, Satoshi: Bitcoin: A Peer-to-Peer Electronic Cash System, 2008, https://bictoin.o rg/bitcoin.pdf (abgerufen am 18. 1. 2021). Neus, Werner: Ökonomische Agency-Theorie und Kapitalmarktgleichgewicht, Wiesbaden, 1989. Oberhaus, Werner/Kuckuck, Bernd: Funktion und Strukturmerkmale des Begriffs »Stand von Wissenschaft und Technik« für die erforderliche Schadensvorsorge im Atomrecht – Beispiel – § 7 Abs 2 Nr 3 Atomgesetz – AtG, DVBl 1980, S. 154–157. Oberhem, Carolina: Vertrags- und Haftungsfragen beim Vertrieb von Open-Source-Software, Hamburg, 2008. Oetker, Hartmut: Kommentar zum HGB, 7. Aufl., München, 2021. Ohly, Ansgar/Sosnitza, Olaf: Kommentar zum UWG, 8. Aufl., München, 2023. Orna, Rabinovich-Einy/ Ethan, Katsh: Blockchain and the Inevitability of Disputes: The Role for Online Dispute Resolution, Journal of Dispute Resolution 2019, S. 47–75. Painter, Richard: Insider Trading and the Stock Market Thirty Years Later, 50 Case W. Res. L. Rev. 305. Palandt, Otto (Begr.): Kommentar zum BGB, 82. Aufl. München, 2023. Pielow, Johann-Christian: Beck’scher Online-Kommentar zur Gewerbeordnung, 58. Ed., München, Stand 1. 6. 2022. Peterson, Timothy: Metcalfe’s Law as a Model for Bitcoin’s Value, http://dx.doi.org/10.21 39/ssrn.3078248 (abgerufen am 18. 1. 2021). Petzold, Rolf: Anmerkungen zu OLG Düsseldorf 3 W 113/72, DNotZ 1973, S. 91–96. Pfeifer, Alex: Produktfehler Oder Fehlverhalten des Produzenten: Das Neue Produkthaftungsrecht in Deutschland, Den USA und Nach der EG-Richtlinie, Berlin, 1987. Pfeiffer, Thomas: Von Preistreibern und Abbruchjägern – Rechtsgeschäftslehre bei OnlineAuktionen, NJW 2017, S. 1437–1444. Podszun, Rupprecht/Busch, Christoph/Henning-Bodewig, Frauke: Behördliche Durchsetzung des Verbraucherrechts?, Studie im Auftrag des BMWI, https://tinyurl.com/ym 9kf6rb (abgerufen 18. 1. 2021). Puppe, Ingeborg: Kleine Schule des juristischen Denkens, Stuttgart, 2011. Ranchordas, Sofia: Does Sharing Mean Caring? Regulating Innovation in the Sharing Economy, 16 Minn. J.L. Sci. & Tech. 2015, S. 414–475. Redeker, Helmut: Wer ist Eigentümer von Goethes Werther?, NJW 1992, S. 1739–1740. Reese, Jürgen: Produkthaftung und Produzentenhaftung für Hard– und Software, DStR 1994, S. 1121–1127. Reinicke, Dietrich/Tiedtke, Klaus: Schutz des Bürgen durch das Haustürwiderrufsgesetz, ZIP 1998, S. 893–896. Reusch, Philipp: Mobile Updates – Updatability, Update-Pflicht und produkthaftungsrechtlicher Rahmen, BB 2019, S. 904–909. Rogers, Brishen: The Social Cost of Uber, University of Chicago Law Review Online, Vol. 82: Iss. 1, S. 85–102. Rohr, Jonathan/Aaron Wright: Blockchain-Based Token Sales, Initial Coin Offerings, and the Democratization of Public Capital Markets, https://hastingslawjournal.org/wp-con tent/uploads/70.2-Rohr-1.pdf (abgerufen am 18. 1. 2021). Rüfner, Thomas: Virtuelle Marktordnungen und das AGB-Gesetz, MMR 2000, S. 597–602. Rötzer, Hans: Die Uneigennützigkeit im Zivilrecht, Augsburg, 2008.

188

Literaturverzeichnis

Säcker, Franz/Rixecker, Roland/Oetker, Hartmut/Limper, Bettina: Münchener Kommentar zum Bürgerlichen Gesetzbuch, 9. Aufl., München, 2023. Saive, David: Haftungsprivilegierung von Blockchain-Dienstleistern gem. §§ 7 ff. TMG (§§ 7 ff. TMG), CR 2018, S. 186–193. Sayeed, Sarwar/Marco-Gisbert, Hector: Assessing Blockchain Consensus and Security Mechanisms against the 51 % Attack, https://doi.org/10.3390/app9091788 (abgerufen am 18. 1. 2021). Schenke, Wolf-Rüdiger: Polizei- und Ordnungsrecht, 10. Aufl., Heidelberg, 2018. Scherer, Peter: Blockchain im Wertpapierbereich, Tübingen, 2020. Schrey, Joachim/Thalhofer, Thomas: Rechliche Aspekte der Blockchain, NJW 2017, S. 1431–1436. Schimansky, Herbert/Bunte, Hermann-Josef/Lwowski, Hans-Jürgen: Bankrechts-Handbuch, 5. Aufl., München, 2017. Schlechtriem, Peter: Vertragsordnung und außervertragliche Haftung, Frankfurt a.M., 1972. Schlechtriem, Peter: Abgrenzungsfragen bei der positiven Vertragsverletzung, VersR 1973, S. 581–594. Schmittmann, Jens: Wie lange ist der Verkäufer bei Internet-Auktionen noch Verbraucher?, VuR, 2006, S-223–226. Schneider, Jochen/Graf v. Westphalen, Friedrich: Software-Erstellungsverträge, 2. Aufl., Köln, 2014. Schrader, Paul/Engstler, Jonathan: Anspruch auf Bereitstellung von Software-Updates? Unklare Begründung eines eingeschränkt notwendigen Anspruchs, MMR 2018, S. 356– 361. Schreiber, Klaus: Haftung bei Gefälligkeiten, Jura 2001, S. 810–814. Schulte-Nölke, Hans: Kundenschutz statt Verbraucherschutz, VEuR 2013, S. 1–2. Schulte-Nölke, Hans: The Brave New World of EU Consumer Law – Without Consumers, or Even Without Law?, EuCML 2015, S. 135–139. Schulte-Nölke, Hans: Plattformverträge und Vertrauensschutz in Blaurock/Maultzsch, Vertrauensschutz im digitalen Zeitalter, Baden-Baden, 2020, S. 167–220. Schumpeter, Joseph: Theorie der wirtschaftlichen Entwicklung, 9. Aufl., Berlin, 1997. Schuster, Fabian/Reichl, Wolfgang: Cloud Computing & SaaS: Was sind die wirklich neuen Fragen? Die eigentlichen Unterschiede zu Outsourcing, ASP & Co liegen im Datenschutz und der TK-Anbindung, CR 2018, S. 38–43. Schwerdtner, Peter: Der Ersatz des Verlustes des Schadensfreiheitsrabattes in der Haftpflichtversicherung, NJW 1971, S. 1673–1678. Schwintowski, Hans-Peter/Klausmann, Nikolas/Kadgien, Michael: Das Verhältnis von Blockchain-Governance und Gesellschaftsrecht, NJOZ 2018, S. 1401–1406. Solmecke, Christian/Lengersdorf, Bonny: Rechtliche Probleme bei Sharing Economy – Herausforderungen an die Gesetzgebung auf dem Weg in eine geteilte Welt, MMR 2015, S. 493–497. Sotiropoulou, Anastasia/Ligot, Stephanie: Legal Challenges of Cryptocurrencies: Isn’t It Time to Regulate the Intermediaries?, European Company and Financial Law Review, 2019, Vol. 16 Iss. 5, S. 652–676. Spallino, Dennis: Voraussetzungen für einen stillschweigenden Haftungsverzicht bei einem Gefälligkeitsverhältnis, VersR 2016, S. 1224–1228.

Literaturverzeichnis

189

Spindler, Gerald IT-Sicherheit und Produkthaftung – Sicherheitslücken, Pflichten der Hersteller und der Softwarenutzer, NJW 2004, S. 3145–3150. Spindler, Gerald: Vertragsabschluss und Inhaltskontrolle bei Internet-Auktionen, ZIP 2001, S. 809–819. Spindler, Gerald/Bille, Martin: Rechtsprobleme von Bitcoins als virtuelle Währung, WM 2014, S. 1357–1369. Spindler, Gerald: Haftung ohne Ende? Über Stand und Zukunft der Haftung von Providern, MMR 2018, S. 48–52. Spindler, Gerald: Initial Coin Offerings und Prospektpflicht und -haftung, WM 2018, S. 1209–2118. Spindler, Gerald: Regulierung durch Technik in Verbraucherrecht 2.0 – Verbraucher in der digitalen Welt, doi.org/10.5771/9783845284569-333 (abgerufen am 2. 11. 2021). v. Staudinger, Julius (Begr.): Kommentar zum BGB, Berlin, Neubearbeitung von 2017. Steinrötter, Björn: Vermeintliche Ausschließlichkeitsrechte an binären Codes – Justizministerkonferenz spricht sich gegen »Dateneigentum« aus, MMR 2017, S. 731–736. Stoll, Hans: Das Handeln auf eigene Gefahr, Berlin, 1961. Stoll, Hans: Anmerkungen zu: BGH Iva ZR 104/83, JZ 1985, S. 383–386. Taeger, Jürgen: Außervertragliche Haftung für fehlerhafte Computerprogramme, Tübingen, 1995. Taeger, Jürgen/Pohle, Jan: Computerrechts-Handbuch, München, LoseBl. (Mai 2022). Taubitz, Jochen: Ökonomische Analyse und Haftungsrecht – Eine Zwischenbilanz, AcP 1996, S. 114–167. Teichmann, Christoph: Digitalisierung und Gesellschaftsrecht, ZfPW 2019, S. 247–272. Terryn, Evelyne The sharing economy in Belgium – a case for regulation?, EuCML 2016, S. 45–51. Tiedmann, Klaus: Körperverletzung und strafrechtliche Produktverantwortung in FS Hirsch, Berlin, 1999, S. 765–778. Thiele, Wolfgang: Leistungsstörung und Schutzpflichtverletzung, JZ 1967, S: 649–657. Vieweg, Klaus/Gerhäuser, Heinz: Digitale Daten in Geräten und Systemen, Köln, 2010. Vilgertshofer, Fabian: Online-Plattformen und vertragliche Haftung, München, 2019. Wagner, Gerhard: Produktvigilanz und Haftung, VersR 2014, S. 905–916. Wagner, Gerhard: Produkthaftung für autonome Systeme, AcP 2017, S. 707–765. Wagner, Tobias/Zenger, Ralph: Vertragsschluss bei eBay und Angebotsrücknahme – Besteht ein »Loslösungsrecht« vom Vertrag contra legem?, MMR 2013, S. 343–348. Weitnauer, Wolfgang: Initial Coin Offerings (ICOs): Rechtliche Rahmenbedingungen und regulatorische Grenzen, BKR 2018, S. 231–236. Wehr, Matthias: Kommentar zum Bundespolizeigesetz, 2. Aufl., Nomos, Baden-Baden, 2015. Wiebe, Andreas: Anmerkungen zu: OLG Hamm: Internetauktion – ricardo.de, MMR 2001, S. 105–111. Wiebe, Gerhard: Produktsicherheitsrechtliche Pflicht zur Bereitstellung sicherheitsrelevanter Software-Updates, NJW 2019, S. 625–630. Wimmer, Norber/Weiß, Mari: Taxi-Apps zwischen Vermittlertätigkeit und Personenbeförderung – Die verwaltungsgerichtliche Entscheidungspraxis zu den Uber-Angeboten, MMR, 2015, S. 80–85.

190

Literaturverzeichnis

Windoffer, Alexander: Wider die Zweckentfremdung – Ordnungsrechtliche Grenzen der »Sharing Economy« bei kurzfristigen Vermietungen, LKV 2016, S. 337–343. Wobst, Felix/Ackermann, Julian: Der Zweckveranlasser wird 100 – Ein Grund zum Feiern?, JA, 2013, S. 916–920. Wolf, Manfred (Begr.)/Lindacher, Walter/Pfeiffer, Thomas: Kommentar zum AGB-Recht, 7. Aufl., München, 2020. Ye, Congcong u.w.: Analysis of Security in Blockchain: Case Study in 51 %-Attack Detecting, 5th International Conference on Dependable Systems and Their Applications (DSA), Dalian, 2018, S. 15–24. Yin, Hao Hua Sun u.w.: Regulating Cryptocurrencies: A Supervised Machine Learning Approach to De-Anonymizing the Bitcoin Blockchain, Journal of Management Information Systems, https://doi.org/10.1080/07421222.2018.1550550 (abgerufen am 18. 1. 2021), Vol. 36 No. 1, S. 37–73. Zech, Herbert: Information als Schutzgegenstand, Tübingen, 2012. Zetsche, Dirk u.w.: The Distributed Liability of Distributed Ledgers: Legal Risks of Blockchain, https://tinyurl.com/bdenxyju (abgerufen am 18. 1. 2021). Zetsche, Dirk u.w.: The ICO Gold Rush: It’s a Scam, It’s a Bubble, It’s a Super Challenge for Regulators, http://dx.doi.org/10.2139/ssrn.3072298 (abgerufen am 18. 1. 2021). Zickgraf, Peter: Initial Coin Offerings – Ein Fall für das Kapitalmarktrecht?, AG 2018, S. 293–308. Zöllner, Lukas: Kryptowerte vs. Virtuelle Währungen – Die überschießende Umsetzung der Fünften EU-Geldwäscherichtlinie, BKR 2019, 2020, S. 117–125. Zott, Thomas: Regulating Airbnb – Economic Methods to Improve the Regulatory Framework for Homesharing Practices?, EuCML 2020, S. 252–255.