Rechtliche Herausforderungen bei der Umsetzung von Microservices

Inhaltsverzeichnis

Microservices sind überschaubare, logisch und technisch voneinander unabhängige Einzeldienste, die jeweils nach fachlichen Kriterien beziehungsweise auf Use Cases zugeschnitten und von fachlich unabhängigen Teams entwickelt werden. Über standardisierte Schnittstellen und Netzwerke interagieren die einzelnen Microservices miteinander und bilden somit das Gesamtsystem. Im Idealfall kann ein Microservice seine Aufgabe ohne weitere (Micro-)Services erfüllen, sodass jedes Team in Bezug auf "seinen" Microservice eigene Technikentscheidungen treffen und ihn unabhängig von den anderen Systemkomponenten weiterentwickeln, skalieren und ausliefern oder austauschen kann.

Diese Merkmale haben verschiedene rechtliche Implikationen, die bei der Durchführung von Microservice-Projekten in den Blick genommen werden sollten. Zwar werfen solche Projekte aus IT-rechtlicher Sicht in der Regel keine völlig neuen Fragestellungen und Herausforderungen auf, die nicht schon aus anderen Kontexten bekannt sind. Sie können jedoch die bekannten (und teilweise ungelösten) rechtlichen Problemstellungen anders bündeln oder gewichten. Deswegen sind insbesondere bei Microservice-Projekten, die in einem Auftragnehmer-Auftraggeber-Verhältnis durchgeführt werden, klare vertragliche Regelungen notwendig, damit beide Parteien wissen, womit sie rechnen müssen.

Flexible Arbeitsweise erfordert agile Vertragsgestaltung

Die Flexibilität, die der Entwicklung und dem Deployment von Microservices innewohnt, legt nahe, dass der vertragliche Leistungsumfang nicht von Anfang an feststeht. Das kann zu Unsicherheiten oder sogar Missverständnissen hinsichtlich der Rechte und Pflichten der Vertragsparteien und im schlimmsten Fall zu zeit- und kostenintensiven Rechtsstreitigkeiten führen. Deshalb empfiehlt es sich, auch auf eine entsprechend flexible Vertragsgestaltung zu setzen statt auf starre Verträge des klassischen und eher schwerfälligen Wasserfallmodells, bei dem sich der Projektablauf etappenweise und quasi bis ins Detail vorzeichnen lässt.

In der Praxis ist es zudem häufig so, dass mehrere Teams simultan mit der Entwicklung unterschiedlicher Einzeldienste beschäftigt sind, was ebenfalls eine flexible Herangehensweise erfordert. Vertraglich (zwischen Auftraggeber und Auftragnehmer) sollte sich diese Flexibilität und Prozessorientiertheit auf jeden Fall widerspiegeln, um für eine gewisse Rechtssicherheit sorgen zu können.

Vertragstypologie immer auch abhängig vom Willen der Parteien

Für die Vertragsgestaltung bei agilen Projekten ist es von besonderer Bedeutung zu wissen, um was für eine Art von Vertrag es sich handelt. Bei Verträgen, die Softwareentwicklung zum Gegenstand haben, wird eine Einordnung als reiner Werk- oder Dienstvertrag auf beiden Seiten meistens der Realität nicht gerecht. In der Gesamtschau der Aufgabenverteilung wird zwar vieles für die Einordnung als Dienstvertrag sprechen: Eine zentrale Steuerung des Projekts beim Auftraggeber und keine Beschaffenheits- oder feste Vergütungsvereinbarung, da es sich um ein stets anzupassendes Produkt handelt. Allerdings sind Auftraggeber schutzlos gestellt, wenn Entwickler die Leistung fehlerhaft oder schlecht erfüllt haben. Bei einem Dienstvertrag ist schließlich lediglich eine Leistung (Programmieren) geschuldet und kein Erfolg (fertiges Softwareprodukt), daher werden Auftraggeber auch zahlen müssen, wenn das Endprodukt nicht vollständig ihren Vorstellungen entspricht.

Den Interessen gerechter ist es wohl, in den einzelnen Entwicklungsabschnitten (Sprints) jeweils einzelne Werkverträge zu sehen und daneben einen Rahmenvertrag abzuschließen, der all diese Sprints in Bezug zueinander setzt. Für eine korrekte Vertragseinordnung ist letztlich auch immer das maßgeblich, was die Parteien tatsächlich wollen. Dieser Wille sollte daher in den einzelnen Vertragsklauseln unmissverständlich zum Ausdruck kommen. Mehrdeutige Formulierungen sind unbedingt zu vermeiden. Stattdessen sollten bewusst vertragstypische Begriffe (zum Beispiel den der Abnahme) genutzt werden.

Auf detaillierte Beschreibung der Vertragsmodalitäten achten!

Im B2B-Bereich sind die Regelungen des BGB für gewöhnlich nicht zwingend. Das bedeutet, dass die Parteien völlig frei hinsichtlich der Vertragsgestaltung sind. Das bringt klare Vor-, aber auch gewichtige Nachteile mit sich: Kommt es zu einer Vertragsüberprüfung durch ein Gericht und enthält der Vertrag unklare Regelungen, wird das Gericht immer auf die gesetzlichen Pendants zurückgreifen und diese nötigenfalls auslegen. Hierbei kann es sich durchaus um für die Parteien unvorteilhafte Regelungen handeln.

Der Grad der Rechtssicherheit eines Vertrags liegt demnach zu einem großen Teil in den Händen der Vertragsparteien. Sie sollten unbedingt auf eine detaillierte Beschreibung der Vertragsmodalitäten achten. Im Fokus stehen unter anderem folgende Fragen: Was wird geschuldet? Ein Gesamtsystem auf Basis einzelner Microservices (eher IT-Systemlieferungsvertrag) oder lediglich einzelne Microservices (eher gewöhnlicher Softwareerstellungsvertrag)? Gleiches gilt für die nachfolgenden Aspekte.

Abnahme- und Vergütungsregelungen sind essenziell

Vor dem Hintergrund der schwierigen vertraglichen Einordnung sollten Auftraggeber und Auftragnehmer nicht vergessen, insbesondere Regelungen zur Abnahme und zur Vergütung zu treffen: Was soll abgenommen werden? Einzeldienste? Ein Gesamtsystem? Sinnvoll sind einzelne (Teil-)Abnahmen, die im Rahmen der Sprint-Review-Meetings erfolgen können. Wie verhält es sich, wenn Auftraggeber einen Microservice oder Teile desselben bereits während des Entwicklungsprozesses nutzen? Hierin kann man durchaus eine Abnahme sehen. Es sollten Regeln für sämtliche Modalitäten hinsichtlich der Abnahme detailliert werden. Hierzu gehören alle Faktoren, die sich auf die Abnahme in irgendeiner Art und Weise auswirken (können).

Gleiches gilt für Vergütungsregelungen: Erfolgt eine Vergütung einzelner Sprints oder eines Gesamtsystems? Was offenkundig erscheinen mag, lässt oftmals reichlich unbeabsichtigten Interpretationsspielraum – mit dem Ergebnis: Rechtsunsicherheit.

Für eine transparente Übertragung von Nutzungsrechten sorgen

Gerne wird vergessen, wie es sich mit der Übertragung von Nutzungsrechten verhält: Auftragnehmer gehen davon aus, dass sie einfache Nutzungsrechte übertragen, Auftraggeber denken, sie erwerben aufgrund der bezahlten Auftragsarbeit exklusive Nutzungsrechte. Eigentlich möchten Entwickler das Produkt jedoch anschließend gern weitervermarkten. Ohne eine Regelung zur Übertragung der Nutzungsrechte, greift die Zweckübertragungslehre gemäß § 31 Absatz 5 UrhG (Urhebergesetz), die danach fragt, welche Rechteübertragung zur Vertragserfüllung erforderlich ist.

Dieser wichtige Aspekt sollte nicht dem Zufall überlassen werden. Stattdessen sollten die Vertragsparteien gemeinsam und detailliert vereinbaren, zu welchem Zweck die Software erworben wird und welche Nutzungs- und Verwertungsrechte den Auftraggebern an der Software und gegebenenfalls sonstigen Leistungen zu welchem Zeitpunkt übertragen werden.

Unsicherheiten hinsichtlich Kündigung vertraglich beseitigen

Unter welchen Umständen können sich Partner vom Vertrag lösen? Im Sinne einer effektiven Planungs- und Kostenkontrolle sollten sich die Vertragsparteien auf ein Kündigungsrecht zum Ende eines jeden Sprints einigen. In dem Zusammenhang können die Vertragsparteien auch eine sogenannte Escrow-Klausel vereinbaren, aus der hervorgeht, wo beziehungsweise bei wem (sog. Escrow-Agent) der aktuelle Quellcode hinterlegt wird, damit sichergestellt ist, dass ein anderer Dienstleister das Projekt im Falle einer Kündigung finalisieren kann.

Vorsicht: Copyleft-Effekt auch bei Microservices denkbar

Vorsicht ist beim Umgang mit Open-Source-Software geboten. Wer für Teile eines einzelnen
Microservices oder für ein Gesamtsystem auf Open-Source-Komponenten zurückgreift, hat den sogenannten viralen Effekt von Open-Source-Lizenzen zu berücksichtigen. Er kann beispielsweise besagen, dass der jeweilige Quellcode nur verändert werden darf, wenn das Ergebnis ausschließlich unter der gleichen Lizenz weiterverbreitet wird und somit auch künftig der Öffentlichkeit zur Verfügung steht.

Das Landgericht Berlin hat 2011 etwa entschieden, dass die Gesamtheit der Programme auf einem Router, die durch die Verknüpfung eines Linux-Kernels mit weiteren, proprietären Programmen auf derselben Hardware entsteht, als "Sammelwerk" zu betrachten ist. Damit entfällt aufgrund der "Copyleft"-Klausel der GPL auch der Schutz der proprietären Teile der gesamten Firmware.

Datenschutzrecht: Auftraggeber wie Auftragnehmer gleichermaßen betroffen

Datenschutzrechtliche Aspekte müssen vor allem Auftraggeber berücksichtigen, da sie in der Regel den jeweiligen Microservice auch nutzen werden. Als solcher sollten sie jedoch darauf hinwirken, dass Auftragnehmer zum Beispiel das datenschutzrechtliche Grundprinzip "Privacy by Design" (Datenschutz durch Technikgestaltung) im Rahmen der Entwicklung nach Möglichkeit umsetzen.

Microservices und Edge Computing gehen Hand in Hand

Microservices sind prädestiniert für das sogenannte Edge Computing, also für die Datenverarbeitung direkt bei den betreffenden Geräten und Sensoren oder zumindest in unmittelbarer Nähe derselben. Gleichermaßen begründet dieser Umstand aber häufig einen Personenbezug (man denke nur an Fitnesstracker). Werden personenbezogene Daten verarbeitet, sind jedoch immer auch die Regelungen der Datenschutz-Grundverordnung (DSGVO) zu beachten.

Von besonderer Bedeutung ist die Beantwortung der Frage nach der datenschutzrechtlichen Verantwortlichkeit: In der Regel ist das den jeweiligen Microservice verwendende Unternehmen Verantwortlicher im Sinne der DSGVO. Es bestimmt schließlich allein über den Einsatz und die Nutzung des Service und somit über die Verarbeitung personenbezogener Daten.

Anders läge der Fall, wenn ein Microservice als Plug-in genutzt wird, das sich auf dem Server der Entwickler oder von Dritten befindet und ein entsprechendes Nutzungsrecht erworben wird. In diesem Fall läge eine klassische Auftragsverarbeitung im Sinne des Artikels 28 der DSGVO vor. Verantwortliche (Auftraggeber) und Auftragsverarbeiter (Auftragnehmer) müssten demnach eine Auftragsverarbeitungsvereinbarung (AVV) abschließen.

Die Haftung für Datensicherheitspannen liegt regelmäßig bei den Verantwortlichen: Sie entscheiden über Zwecke und Mittel der Verarbeitung personenbezogener Daten, unterliegen daher der Rechenschaftspflicht aus Art. 5 Abs. 2 der DSGVO und tragen damit die Beweislast für die Rechtmäßigkeit der Datenverarbeitung. Auch der Schutz der Endpunkte ist aufgrund der dezentralen Verarbeitung der Daten – wie bei klassischen IoT-Geräten – wichtig. Eine geteilte IT-Infrastruktur mit vielen Zugangspunkten bietet schließlich auch eine große Angriffsfläche für Sicherheitsrisiken. Über die Umstände der Verarbeitung personenbezogener Daten sowie etwaiger Risiken müssen Verantwortliche zudem die betroffenen Personen umfassend informieren.

Haftungsrechtliche Fragen bereits vertraglich beantworten

Was geschieht, wenn Bugs im Code die Bedienung oder einzelne Funktionen eines Microservices beeinträchtigen? Wer haftet, wenn aufgrund eines grob fahrlässigen Programmierfehlers wichtige Dokumente verschwinden? Erneut wird hier die Einordnung des Vertrags beziehungsweise seiner einzelnen (abgrenzbaren) Teile maßgeblich: Während es im werkvertraglichen Kontext ein umfassendes und für Auftraggeber oftmals vorteilhaftes Gewährleistungsrecht gibt, gilt im Rahmen eines Dienstvertrags lediglich das allgemeine Schuldrecht. Fristen, Mitwirkungspflichten sowie etwa feste Hardware- und Softwareumgebungen sollten unbedingt vertraglich geregelt werden. Gleiches gilt für die Aufnahme der Pflicht zur Dokumentation der Software (z. B. Bug-Listen) und die Durchführung von Tests etwa zur Überprüfung der Belastbarkeit oder der Konsistenz eines Microservices beziehungsweise des Gesamtsystems. Die Vertragsparteien sind gut beraten, solcherlei Fragen nach Möglichkeit bereits im Rahmen der Vertragsgestaltung zu beantworten. Zwar lassen sich Haftungsbeschränkungen leicht über die Allgemeinen Geschäftsbedingungen (AGB) integrieren, ein genereller Haftungsausschluss ist jedoch nach deutschem Recht unzulässig.

Auch sollte die Verfügbarkeit einzelner Module geregelt werden, insbesondere wenn Microservices aufeinander aufbauen und dadurch die Verwendbarkeit der gesamten Anwendung wegen Weiterentwicklung einzelner Module gefährdet ist.

In der Leistungsbeschreibung könnte daher zum Beispiel eine Verfügbarkeit von Modul A von 99 Prozent im Jahresmittel vereinbart werden, da sich eine hundertprozentige Verfügbarkeit möglicherweise nicht gewährleisten lässt. Gleiches gilt für Modul B und C etc. Auch eine Regelung hinsichtlich der Verfügbarkeit des Gesamtsystems kann sinnvoll sein.

Bei auf Microservices basierenden Smart Products, die autonom – also ohne menschliche Handlung – agieren, richtet sich die Haftung danach, ob die Datenverarbeitung automatisch erfolgt oder sich als bewusste Entscheidung der Nutzer durch Abgabe eines Befehls einordnen lässt. Roboter sind keine eigene Rechtspersönlichkeit und können daher (noch) nicht selbst haften.

Die Zurechnung des Prozesses muss gegenüber denjenigen erfolgen, die die letzte Verursachungshandlung vorgenommen haben: Bei Microservices können das entweder Entwickler oder Verkäufer einer Anwendung für deren Fehlerhaftigkeit sein. Daneben kommt zum Beispiel auch eine Haftung der Betreiber zusammen mit den Entwicklern in Betracht, bei der beide Seiten gleichermaßen zum Schadensersatz verpflichtet wären.

Fazit

Bei der Nutzung von Microservices stellen sich wichtige juristische Fragen: Entwicklungs-, Hosting- sowie Pflegeverträge für die Microservices – eine klare rechtliche Einordnung ist hier nicht immer einfach. Daneben stellt sich die Frage nach dem Datenschutzrecht sowie der Gestaltung von Haftungsklauseln. Trotz vertraglicher Absicherungen müssen beide Seiten große Sorgfalt bei der Vertragserfüllung walten lassen und gegebenenfalls für ein hohes Niveau an Qualitätssicherung sorgen.

Dennoch: Microservices lohnen sich. Sie bieten viele Vorteile durch den reduzierten Aufwand bei der Infrastruktur. Da dieses Architekturkonzept noch verhältnismäßig jung ist, ist die rechtliche Einordnung in einen bestimmten Vertragstypus, insbesondere in Hinblick auf Haftungsfragen, noch weitgehend ungeklärt. Somit treffen Auftraggeber und Auftragnehmer zwar auf einige Stolpersteine, gleichzeitig bieten sich aber auch viele Chancen.

Simone Rosenthal
ist Partnerin bei der Technologiekanzlei Schürmann Rosenthal Dreyer. Sie ist außerdem Geschäftsführerin der ISiCO Datenschutz GmbH, einem Unternehmen, das Analyse, Auditierung und Beratung in den Bereichen Datenschutz, Datenschutz-Compliance und Informationssicherheit anbietet. Schließlich ist sie Co-Founder von lawpilots, einem LegalTech für das digitale Lernen rund um die Themen Digitalisierung und Recht. (ane)