Nr. Kompetenzzentrum Trusted Cloud. Arbeitspapier Cloud Computing und Source Software

Transkript

1 5 Open Nr. Kompetenzzentrum Trusted Cloud Arbeitspapier Cloud Computing und Source Software

2 2 Arbeitsgruppe Rechtsrahmen des Cloud Computing Cloud Computing kann in Deutschland nur wirtschaftlich erfolgreich sein, wenn die rechtlichen Rahmenbedingungen eine effiziente Nutzung von Cloud-Diensten ermöglichen. Ein innovationsfreundlicher Rechtsrahmen ist daher von besonderer Bedeutung. Für die rechtlichen Aspekte von Cloud Computing hat das Bundesministerium für Wirtschaft und Energie (BMWi) daher innerhalb des Kompetenzzentrums Trusted Cloud eine eigene Arbeitsgruppe einrichten lassen. In der Arbeitsgruppe Rechtsrahmen des Cloud Computing erarbeiten Experten aus Wirtschaft, Anwaltschaft und Wissenschaft sowie Vertreter aus Datenschutzbehörden gemeinsam mit Projektbeteiligten aus dem Trusted-Cloud-Programm Lösungsvorschläge für rechtliche Herausforderungen. Sie wird geleitet von Prof. Dr. Georg Borges. Themenschwerpunkte sind u. a. Datenschutz, Vertragsgestaltung, Urheberrecht sowie Haftungsfragen und Strafbarkeitsrisiken. Darüber hinaus wird ein Pilotprojekt zur datenschutzrechtlichen Zertifizierung von Cloud-Diensten durchgeführt, das Impulse für die rechtssichere Nutzung von Cloud Computing und die Gewährleistung eines hohen Datenschutzniveaus setzen soll.

3 3 Inhaltsverzeichnis 1 Einleitung 4 2 Nutzungsbereitstellung der Software im Rahmen von SaaS nach OSS-Lizenzverträgen zulässig? 6 Lizenzprobleme bei veränderter OSS 6 Lizenzen mit konkreter Regelung zum Cloud Computing 6 Freie Lizenzen 7 Copyleft-Lizenzen ohne konkrete Regelung zum Cloud Computing 7 Risikosteuerung 11 3 OSS aus Sicht des Cloud-Kunden 12 4 Schlussfolgerungen 13 Autoren 14

4 4 1 Einleitung Open Source Software (kurz OSS genannt) ist kostenlos im Internet verfügbar, gewinnt zunehmend an Bedeutung und ist aus der heutigen IT-Landschaft nicht wegzudenken. Für Nutzer und Anbieter von Cloud-Computing-Leistungen stellen sich Fragen zu den Risiken der Verwendung von OSS, wenn die von ihnen zur Bereitstellung des Cloud- Dienstes eingesetzte Software OSS beinhaltet. Dies ist insbesondere dann der Fall, wenn der Anbieter in eigenentwickelte Software selbst oder durch beauftragte Dritte OSS-Komponenten integriert. Dieses Papier beschäftigt sich mit den Auswirkungen von OSS im Zusammenhang mit SaaS-Lösungen aus Anbieter- und Kundensicht.¹ In erster Linie muss der Anbieter sicherstellen, dass die OSS-Lizenzbedingungen eingehalten werden. Aber auch aus Kundensicht ist einiges zu beachten (dazu Kapitel OSS aus Sicht des Cloud-Kunden, Seite 12). OSS ist urheberrechtlich geschützt und damit bedarf die Nutzung von OSS der Einräumung entsprechender Nutzungsrechte, also einer Lizenz. Der notwendige Lizenzvertrag wird in der Regel beim Herunterladen bzw. der Installation der Software geschlossen. Der Begriff OSS umfasst ganz unterschiedliche Lizenzierungsmodelle.² Aller OSS ist gemein, dass Nutzungsrechte am Quellcode der OSS kostenfrei eingeräumt werden. Allerdings bestehen insbesondere bei den sogenannten Copyleft-Lizenzen auch erhebliche Einschränkungen für den Nutzer von OSS. In dem Arbeitspapier Lizenzierungsbedarf beim Cloud Computing³ ist bereits herausge arbeitet worden, dass der SaaS-Anbieter über die für den Einsatz der Software benötigten Nutzungsrechte zur Vervielfältigung (da das Ablaufenlassen der Software auf dem Server des Anbieters Vervielfältigungen auslöst) und öffentlichen Zugänglichmachung (bzw. ein ungeschriebenes Nutzungsrecht eigener Art für Cloud Computing) verfügen muss. Anders als der SaaS-Anbieter benötigt der Cloud-Kunde in der Regel dagegen nur Nutzungsrechte an dem Client, der zur Nutzung des SaaS-Angebots auf dem Computer des Kunden installiert werden muss. 1 Hier geht es also ausschließlich um Software as a Service. Fragen, die sich spezifisch im Zusammenhang mit Infrastructure as a Service oder Platform as a Service stellen, können hier nicht beantwortet werden. Der Begriff Cloud-Anbieter wird im Folgenden synonym für SaaS-Anbieter verwendet. Die OSS-spezifischen Probleme bei IaaS sind anderer Art als die hier im Zentrum stehenden Fragen. Nutzt der Kunde eine von ihm lizenzierte Software mittels der Infrastruktur eines IaaS-Anbieters, wird regelmäßig diese Nutzung auch dem Kunden zuzurechnen sein, sodass der zu Problemen führende Tatbestand des Vertriebs (bzw. der Übertragung der Softwarerechte) nicht erfüllt ist. Siehe dazu auch Ziffer 3. Allerdings können sich aus einschlägigen Lizenz bedingungen durchaus Einschränkungen für den Betrieb in einer IaaS-Umgebung ergeben, auch bei kommerzieller Software. Manche Lizenzbedingungen erkennen z. B. virtuelle Servereinheiten nicht an und stellen stattdessen für die Bestimmung der Lizenzkosten auf (alle) physischen Servereinheiten des Rechenzentrums ab. Von daher ist zu empfehlen, vor der Migration von Software auf eine Cloud-Infrastruktur die einschlägigen Lizenzen zu prüfen. 2 Zu den verschiedenen Lizenzmodellen siehe etwa 3 Trusted Cloud, Lizenzierungsbedarf beim Cloud Computing, ein Arbeitspapier der AG Rechtsrahmen des Cloud Computing (im Internet abrufbar unter:

5 5 Wie vor der Verwendung jeder Software sollte der SaaS-Anbieter auch vor der Verwendung von OSS prüfen, unter welchen Voraussetzungen die betroffenen OSS-Lizenzen die Nutzung der Software im Rahmen eines SaaS-Dienstes erlauben. Bei OSS ist eine derartige Untersuchung deshalb wichtig, weil einige der OSS-Lizenzen gewissermaßen als Ausgleich für die kostenlose Nutzungsrechtseinräumung einen Vertrieb der unter Verwendung der OSS-Komponente entwickelten Software nur unter der Voraussetzung gestatten, dass die Nutzungsrechte am Quellcode dieser Entwicklung in ihrer Gesamtheit ebenfalls jedermann unentgeltlich zur Verfügung gestellt werden (sog. Copyleft-Lizenzen). 4 Diese Ansteckung der Gesamtsoftware wird auch als viraler Effekt der Copyleft- Lizenzen bezeichnet (dazu Kapitel Nutzungsbereitstellung der Software im Rahmen von SaaS nach OSS-Lizenzverträgen zulässig?, Seite 6). Dieser Beitrag erteilt anknüpfend an das Arbeitspapier Lizenzierungsbedarf beim Cloud Computing einen Überblick darüber, was es aus Sicht des SaaS-Anbieters und -Kunden bei der Verwendung einer zu Teilen aus OSS-Komponenten bestehenden Software zu berücksichtigen gilt. Für den Cloud-Kunden ist das Thema OSS vor allem mittelbar von Bedeutung: Verstößt der Anbieter gegen OSS-Lizenzen, kann dies insbesondere dazu führen, dass der SaaS-Dienst eingestellt werden muss. 4 Unberührt bleibt das Recht des Dienstleisters, für die technische Zurverfügungstellung des Programms Gebühren zu verlangen; die Lizenz an sich ist jedoch kostenfrei, vgl. Ziffer 4 der GPL v.3.

6 6 2 Nutzungsbereitstellung der Software im Rahmen von SaaS nach OSS-Lizenzverträgen zulässig? Lizenzprobleme bei veränderter OSS Wie oben angedeutet, stimmen OSS-Lizenzverträge grundsätzlich insofern überein, als sie es dem Lizenznehmer gestatten, hierunter lizenzierte Software in unveränderter Form für eigene, interne Zwecke zu nutzen und unter gewissen Voraussetzungen auch zu ändern. Auch der Vertrieb von OSS in unveränderter Form ist zulässig, wobei in diesem Fall bei den Copyleft-Lizenzen die Nutzungsrechte am Quellcode jedermann kostenfrei angeboten werden müssen. Die Verwendung von OSS ist demnach weitgehend unproblematisch, sofern sie auch in veränderter Form nur intern genutzt wird 5 oder es zu keiner Modifikation der OSS kommt. Probleme ergeben sich jedoch, soweit die Software mit veränderten OSS-Komponenten verbreitet wird, was zu der Frage führt, unter welchen Bedingungen die OSS-Lizenzen den Vertrieb veränderter Software gestatten, z. B. im Wege des Software as a Service. Eine Veränderung liegt dabei auch dann vor, wenn eine Software aus verschiedenen, an sich unveränderten OSS-Bestandteilen und eigenentwickelten Komponenten zusammengesetzt wird. Dabei liegt eine Nutzung und Veränderung von OSS grundsätzlich auch vor, wenn nur Teile einer OSS verwendet werden (sog. Snippets), z. B. indem solche OSS-Teile in eine eigenentwickelte Software integriert werden. In dieser Hinsicht können die Lizenzen teils erheblich voneinander abweichen, wobei sich idealtypisch wie folgt zwischen den vorhandenen Lizenzmodellen unterscheiden lässt. Lizenzen mit konkreter Regelung zum Cloud Computing Teile der Open Source Community (z. B. die Free Software Foundation) möchten die freie Nutzung von OSS auch bei kommerzieller Verwendung innerhalb neuer Anwendungsszenarien sicherstellen und haben frühzeitig die Gefahr einer möglichen Regelungslücke ( loophole ) bestehender Copyleft-Lizenzen im Hinblick auf eine Nutzung von Software über Netzwerke bis hin zur Cloud erkannt. Die Frage der Zulässigkeit der beabsichtigten Nutzungsbereitstellung der Software als SaaS kann deshalb immer dann unproblematisch beantwortet werden, wenn sich die Lizenzbedingungen wie etwa die der GNU Affero General Public License, Version 3 (nachfolgend Affero GPLv3 Lizenz ) explizit hierzu äußern. 6 Diese Lizenz schließt in Ziffer 13 mit der Formulierung [...] if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network [...] an opportunity to receive the Corresponding Source of your version die Zurverfügung stellung 5 Unproblematisch ist jedoch grundsätzlich nur die interne Nutzung veränderter Software innerhalb einer juristischen Person. Wird eine veränderte Software innerhalb eines Konzerns anderen Gruppengesellschaften zur Verfügung gestellt, liegt in der Regel keine rein interne Nutzung im Sinne der Lizenztexte vor. 6 GNU Affero General Public License, Version 3, Ziffer 13 (im Internet abrufbar unter: Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. (...).

7 7 von Software über die Cloud als Vertriebsform mit ein, welche die (seitens des Anbieters unerwünschte) Pflicht des Anbieters auslöst, den Quellcode seines (unter Verwendung von entsprechender OSS erzielten) Entwicklungsergebnisses allen Kunden offenzulegen. In den meisten Fällen sucht man eine entsprechende Bestimmung in den Lizenztexten allerdings vergeblich, was zum einen darauf zurückzuführen ist, dass Cloud Computing eine vergleichsweise junge Technologieform darstellt, die bei Abfassung der Lizenztexte noch nicht bekannt war oder einfach nicht bedacht wurde. Zum anderen knüpft die Pflicht zur Herausgabe des Quellcodes in OSS-Lizenzen typischerweise an die Übergabe ( Distribution ) des Objektcodes an den Kunden an, die beim Cloud Computing allenfalls in Bezug auf den Client stattfindet. Es ist wegen der wirtschaftlichen Bedeutung des Cloud Computing allerdings davon auszugehen, dass zunehmend Regelungen zum Cloud Computing in die OSS-Lizenzbedingungen Eingang finden werden. Die Affero GPLv3 Lizenz ist zwar noch nicht weitverbreitet, gewinnt jedoch in der Open Source Community immer mehr Anhänger. Freie Lizenzen Als unproblematisch stellen sich die sog. freien Lizenzen dar. 7 Nach diesen Lizenzen bestehen auch bei Verbreitung einer Software, die eine unter der jeweiligen freien Lizenz stehende modifizierte OSS-Komponente enthält, keine Einschränkungen, insbesondere keine Verpflichtung zur Offenlegung des Quellcodes der gesamten Software. Es bestehen allenfalls bestimmte Dokumentationspflichten, die bei einem Vertrieb bzw. einer Veränderung zu erfüllen sind (z. B. Copyrighthinweis und Name des Autors). Copyleft-Lizenzen ohne konkrete Regelung zum Cloud Computing Wie bereits eingangs im Kapitel Lizenzprobleme bei veränderter OSS, Seite 6, erwähnt, begründen Copyleft-Lizenzen für den Fall der Verbreitung von Software, die unter Verwendung entsprechender OSS-Komponenten entwickelt worden ist, die Verpflichtung, die gesamte Software einschließlich selbst entwickelter oder zugekaufter Komponenten den Bedingungen dieser OSS-Lizenz zu unterstellen. 8 Daraus ergeben sich häufig Lizenzkonflikte, wenn nämlich unterschiedliche Lizenzen einander widersprechende Pflichten vorsehen. Nach den Copyleft-Lizenzen besteht jedenfalls die Verpflichtung zur Offenlegung des Quellcodes der gesamten Software. Die Software wird mit anderen Worten gewissermaßen von den OSS-Kom ponenten und seien sie auch noch so unbedeutend infiziert (sog. viraler Effekt). Vor diesem Hintergrund sollte in jedem Fall eine sorgfältige Trennung proprietärer Software von OSS-Komponenten wie etwa OSS Libraries oder anderen separierbaren OSS-Komponenten durch klare Schnittstellen gewähr leistet werden. Dies ist jedoch programmier technisch nicht immer mit angemes senem Aufwand möglich. 7 Typische Beispiele sind hier die sog. MIT- und BSD-Lizenzen, die in unterschiedlichen Versionen verwendet werden (sog. permissive licenses ). 8 Entsprechende OSS-Lizenzen werden als Copyleft-Lizenzen bezeichnet, wobei je nach Ausgestaltung der an die Offenlegungspflicht gestellten Anforderungen noch zwischen Lizenzen mit strenger Copyleft-Klausel und Lizenzen mit eingeschränkter Copyleft-Klausel differenziert wird. Jaeger/Metzger, Open Source Software, 3. Auflage, München 2011, Rz. 5, 24.

8 8 Da die Verpflichtung zur Offenlegung des Quellcodes in aller Regel an die Verbreitung der veränderten OSS geknüpft wird, kommt es entscheidend darauf an, ob die Nutzungsbereitstellung via Cloud als Verbreitung in diesem Sinne aufzufassen ist. Eine Verbreitung erfolgt zweifelsohne immer dann, wenn der Objektcode einer Software als Kopie veräußert wird. Ist also beispielsweise zur Nutzung eines Cloud-Dienstes ein auf dem Kundenrechner zu installierender Client notwendig, der dem Kunden vom Cloud-Anbieter zur Verfügung gestellt wird, liegt eine Verbreitung vor. Die Anwendungssoftware selbst läuft dagegen auf dem IT-System des Anbieters. Der Objektcode der Anwendungssoftware wird daher beim SaaS nicht veräußert oder übertragen. Siehe dazu Ziffer des Arbeitspapiers Lizenzierungsbedarf beim Cloud Computing. Auslegung des OSS-Lizenzvertrages am Beispiel der GPL 2.0 Da die in den englischen Originalfassungen regelmäßig verwendeten Begriffe distribution und publish nicht näher definiert werden bzw. auch vorhandene Definitionen nicht eindeutig sind, müssen die Begriffe ausgelegt werden. Dies fällt schwer, da der Großteil der Lizenzen aus dem US-amerikanischen oder skandinavischen Umfeld stammt und von der Terminologie des jeweiligen nationalen Urheberrechts geprägt ist. Die meisten OSS-Lizenzen enthalten zudem keine Rechtswahlklausel. Daher bestimmt sich das anwend bare Recht nach den Regeln des internationalen Privatrechts, die nicht immer zu eindeutigen Ergebnissen führen. Dies verkompliziert das Thema nochmals. Diese Auslegungsschwierigkeiten lassen sich exemplarisch an der GNU General Public License (GPL) Version (nachfolgend GPL 2.0 ) aus dem Jahre 1991 demonstrieren, welche als Vorbild für Copyleft-Lizenzen dient und auch heute noch eine der am weitesten verbreiteten OSS-Lizenzen darstellt. Die entscheidende Bestimmung der Lizenz findet sich unter Ziffer 2b), wo es heißt: You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. Der Begriff Program meint dabei die betroffene OSS. Eine Verpflichtung zur kostenfreien Lizenzierung des Werkes ( the work ) damit ist der Quellcode gemeint 10 besteht folglich dann, wenn die Nutzungsbereitstellung der Software via SaaS als distribute oder publish im Sinne der Vorschrift zu qualifizieren wäre. Nach US-amerikanischer Terminologie erfassen diese Begriffe nicht nur die körperliche Verbreitung (auf Datenträgern), sondern auch die Verbreitung (des Objektcodes) in unkörperlicher Form. Nach Auffassung des Herausgebers der GPL 2.0, der Free Software Foundation, ist mit dem Begriff Verbreitung ( distribute or publish ) jedenfalls die Veräußerung einer Kopie der Software (im Objektcode) gemeint. 11 Dieser wird im Rahmen von SaaS Dritten nicht zur Verfügung 9 Siehe 10 Vgl. Ziffer 1 der GPL 2.0, auf die die oben wiedergegebene Ziffer 2 b) mit der Formulierung under the Terms of this License Bezug nimmt: You may copy and distribute verbatim copies of the Program s source code 11 Dies lässt sich insbesondere aus der Definition des Begriffs convey in Ziffer 0 der GNU GPL 3.0 (im Internet abrufbar unter: schlussfolgern: To convey a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. Der Begriff convey ist in den neueren Versionen der GPL an die Stelle der Begriffe distribute und publish getreten und stimmt mit diesen grundsätzlich überein. Vgl. insofern die Antwort zu folgender Frage unter den Frequently Asked Questions about the GNU Licenses auf der Website der Free Software Foundation: Is convey in GPLv3 the same thing as what GPLv2 means by distribute? Im Internet abrufbar unter: Vgl. auch Pohle/Ammann, CR 2009, S. 273, 276; Jaeger/Metzger, GRUR 2008, S. 130, 134/135.

9 9 gestellt, weil die Anwendungssoftware lediglich auf den Servern des Cloud-Anbieters (und nicht etwa auf den Rechnern der Nutzer) abläuft. Auch wenn damit der Verfasser des Lizenztexts selbst davon ausgeht, dass SaaS keine Verbreitung im Sinne der Lizenz ist, verbleibt aber dennoch ein Risiko, dass ein mit der Sache befasstes Gericht insbesondere vor dem Hintergrund deutscher Urheberrechtsterminologie zu einer anderen Aus legung der Begrifflichkeiten gelangt zumal Copyleft-Lizenzen ursprünglich den Gedanken verfolgen, die kommerzielle Nutzung kostenlos zur Verfügung gestellter Software unter Ausschluss der Open Source Community zu verhindern. Die Nutzungsbereitstellung von Anwendungssoftware via SaaS ist also nach der GPL 2.0 zulässig (ohne die Pflicht, den Quellcode kostenfrei zur Verfügung zu stellen), wenn man hierin ein bloßes Ablaufenlassen bzw. Vervielfältigen der Software bzw. der hierin inkorporierten OSS-Komponenten erblickt. 12 Dies ist nach dem Verständnis der Free Software Foundation der Fall, weshalb sie auch die Affero GPLv3 Lizenz zur Beseitigung dieser Regelungslücke entwickelt hat. 13 Sofern und soweit die Anwendungssoftware veränderte OSS-Komponenten enthält, die unter Copyleft-Lizenzen ohne klare Regelung zum Cloud Computing gestellt sind, besteht für den Cloud-Anbieter also im Ergebnis ein rechtliches Restrisiko, zur Offenlegung des Quellcodes der gesamten Anwendungssoftware verpflichtet zu sein. In Anbetracht der Tatsache, dass die Software im Rahmen von SaaS nur auf den Servern des Cloud-Anbieters betrieben wird und Dritte mit ihr daher gewöhnlich nicht in Berührung kommen, ist das tatsächliche Risiko, mit einem entsprechenden Anspruch konfrontiert zu werden, gering. Schließlich folgt die Open Source Community selbst, die in der Vergangenheit schon Lizenzverletzungen verfolgt hat, üblicherweise der Interpretation der Free Software Foundation. Inkompatibilität der OSS-Lizenzen untereinander Ordnet man die Nutzungsbereitstellung von Software via SaaS als Verbreitung im Sinne der Copyleft-Lizenzen ein, sehen diese wie aufgezeigt vor, dass unter Einsatz von OSS entwickelte Software gesamthaft den Bedingungen der jeweiligen Lizenz unterfällt. Dies wirft für den Fall, dass mehrere Copyleft-Lizenzen betroffen sind, die Frage auf, welche Copyleft-Lizenz dann letztlich gelten soll. Die jeweiligen Lizenzen beanspruchen im Fall der Verbreitung jeweils alleinige Geltung. Soweit Lizenzen untereinander inkompatibel sind (z. B. weil sie widersprechende Angaben zur Lizenzherkunft im Quellcode fordern), besteht keine Möglichkeit, diesen Konflikt aufzulösen. Für den Cloud-Anbieter bedeutet dies, dass er die Lizenzbedingungen im Falle einer Verbreitung nicht einhalten kann und aus diesem Grunde seine Nutzungsberechtigung verliert. 12 Das Gleiche müsste für die GPL 3.0. gelten, da die Free Software Foundation bewusst von einer Ergänzung abgesehen hat. 13 Vgl. insofern die Antwort zu folgender Frage unter den Frequently Asked Questions about the GNU Licenses auf der Website der Free Software Foundation: A company is running a modified version of a GPL ed program on a web site. Does the GPL say they must release their modified sources? (abrufbar unter:

10 10 Einkauf der Anwendungssoftware oder Beauftragung Dritter mit der Softwareentwicklung Sofern der Cloud-Anbieter seine Anwendungssoftware (ganz oder teilweise) einkauft oder Dritte mit der (Weiter-)Entwicklung seiner Anwendungssoftware beauftragt, ist darüber hinaus zu beachten, dass die (nach Fertigstellung erfolgende) Übertragung der Nutzungsrechte an der Software vom Verkäufer bzw. Auftragsentwickler an den SaaS-Anbieter grundsätzlich den Tatbestand einer Verbreitung der Software im Sinne der Copyleft-Lizenzen erfüllt. Sofern in die Anwendungssoftware (unter anderem) Copyleft-Komponenten verbaut worden sind, trifft den Auftragsentwickler eine Pflicht zur Herausgabe des Quellcodes der erstellten Software an jedermann. Kommt er dieser Pflicht nicht nach, verliert der Übertragende seine Nutzungsberechtigung, sodass zweifelhaft ist, ob der erwerbende Cloud-Anbieter überhaupt Nutzungsrechte erwirbt. Fällt dies rechtzeitig auf, kann der Auftraggeber bei Auftragsentwicklungen schlicht Abnahme und Zahlung verweigern. Häufig wird die Verwendung von OSS jedoch nicht geprüft. Wird die so erstellte Software anschließend vom Cloud-Anbieter genutzt, läuft er in Gefahr, dazu aufgefordert zu werden, die Nutzung einzustellen und Schadensersatz zu leisten (siehe dazu auch sogleich Kapitel Risikosteuerung, Seite 11). Manche Lizenzen beinhalten Ausnahmen für Auftragsentwicklungen. So sieht etwa die GNU General Public License (GPL) Version 3.0 gemäß Ziffer 2 Abs. 2 ausdrücklich keine Verpflichtung zur Offenlegung des Quellcodes vor, wenn ein Dienstleister eingesetzt wird, um eine Software mit OSS-Komponenten zu erstellen, sofern der Dienstleister ausschließlich im Auftrag und unter Kontrolle des Auftraggebers also des Cloud- Anbieters handelt. Es sollten daher mit dem Auftragsentwickler eindeutige Vereinbarungen getroffen werden, welche OSS-Lizenztypen für den Auftrag zugelassen sind, ob eine OSS-Erweiterung erforderlich ist und wer welche OSS-Komponenten für die gewünschte Softwareumgebung beisteuert. Dies setzt allerdings voraus, dass der Auftraggeber sich mit dem Thema OSS auseinandersetzt und das erforderliche Know-how aufbaut. Damit kann ggf. vermieden werden, dass eine Pflicht zur Herausgabe des Quellcodes der Auftragsentwicklung an jedermann bereits zum Zeitpunkt ihrer Übergabe an den Cloud-Anbieter entsteht. Im Übrigen dürfte bei derartigen kundenspezifischen Auftragsentwicklungen aber auch das tatsächliche Risiko für die Geltendmachung eines Anspruchs auf Offenlegung des Quellcodes gegenüber dem Cloud-Anbieter recht gering ausfallen, da die Auftragsentwicklung anders als Standardsoftware eben nicht einer breiten Masse zugänglich gemacht wird, sondern außer dem Cloud-Anbieter nur noch dem Zugriff des jeweiligen Dienstleisters unterliegt. Allerdings sind viele engagierte Mitglieder der Open Source Community auch Angestellte von IT-Dienstleistern und Auftragsentwicklern. Zur Vermeidung entsprechender Risiken empfiehlt es sich, die Möglichkeit einer entsprechenden Freistellungsvereinbarung mit dem Auftragsentwickler zu prüfen. Erhöhte Relevanz kommt der Problematik jedenfalls dann zu, wenn der Cloud-Anbieter seine Software mit OSS-Komponenten etwa im Rahmen einer Unternehmenstransaktion (insbesondere in Form eines Asset Deals) veräußern möchte.

11 11 Risikosteuerung Eine Verletzung von OSS-Lizenzen führt nicht nur zu einem Wegfall des bestehenden Nutzungsrechts (womit das Risiko besteht, dass der Cloud-Anbieter auf Betreiben des Rechteinhabers die Nutzung der Software einstellen muss), sondern kann auch zu einer Offenlegungspflicht im Hinblick auf einen eigenen damit verbundenen Quellcode sowie Schadensersatzansprüchen (etwa der Programmierer der entsprechenden OSS-Komponente) führen. Schadensersatzansprüche können nach Wahl des Anspruchstellers durch Berechnung des konkreten Schadens des Rechteinhabers (der sich bei OSS in Grenzen halten dürfte, da für die Nutzung von OSS ohnehin keine Lizenzgebühren anfallen), eine fiktive Lizenzgebühr oder durch Abschöpfung des durch die unzulässige Verwendung der Software erzielten Gewinns geltend gemacht werden. Ein Cloud-Anbieter sollte die von ihm selbst betriebene, eigene IT-Umgebung 14 entsprechend im Hinblick auf verwendete OSS-Komponenten, etwa durch OSS Scan-Software 15, untersuchen und die Verwendung von OSS durch klare Regelungen (sog. Open Source Software Adoption Process) kontrollieren. Begleitende organisatorische Maßnahmen schaffen die notwendige Transparenz und das Bewusstsein, kritischen Quellcode zu identifizieren und auszutauschen oder alternativ eine OSS-Compliance wie Quellcodeveröffentlichung ohne Gefährdung der Eigenentwicklungen sicherzustellen. 14 Ein IaaS-Anbieter ist dagegen grundsätzlich nicht für die von seinen Kunden (auf Basis der vom IaaS-Anbieter zur Verfügung gestellten Infrastruktur) betriebene Software verantwortlich. Ausnahmsweise kann aber auch der IaaS-Anbieter in Haftung genommen werden, insbesondere wenn er von einem Urheberrechtsverstoß weiß und nichts unternimmt. Siehe dazu auch sogleich unter Kapitel OSS aus Sicht des Cloud-Kunden, Seite Derartige Scans werden zum Beispiel von den Dienstleistern Black Duck oder acellere durchgeführt.

12 12 3 OSS aus Sicht des Cloud-Kunden Der Betrieb von OSS-Komponenten durch den Kunden in einer Cloud-Umgebung des Anbieters wie etwa im Rahmen von IaaS oder PaaS ist grundsätzlich wie ein Rechenzentrumsbetrieb zu bewerten und nicht als Vertrieb im Sinne einer OSS-Lizenz zu qualifizieren. Allerdings muss auch ein Cloud-Kunde beachten, dass neue Copyleft-Lizenzen wie die Affero GPLv3 Lizenz die Nutzungsbereitstellung von Software in Netzwerken etwa über Web- oder Cloudapplikationen auch bei rein konzerninterner Abrufbarkeit erfassen. Wenn modifizierte OSS-Komponenten unter diesen Lizenzbedingungen damit vom Cloud-Kunden selbst in einer Private Cloud anderen Konzernmitgliedern oder eigenen Dienstleistern zur Nutzung zur Verfügung gestellt werden, muss zumindest diesen Dritten ebenso der modifizierte Quellcode offengelegt werden. Es sollte dem Cloud-Kunden jedoch auch bewusst sein, dass umgekehrt auch ein offengelegter Quellcode der OSS-Umgebung des Cloud-Anbieters noch keine freie Nutz barkeit der Webapplikation sicherstellt und einen Vendor Lock-in vermeidet. Vielmehr muss er darüber hinaus auch über die beim Cloud-Anbieter gespeicherten Daten über möglichst offene Schnittstellen (Application Programming Interfaces bzw. APIs) verfügen können. Ein Anspruch des Nutzers auf Bereitstellung solcher offenen Schnittstellen besteht grundsätzlich nur bei besonderer Vereinbarung Nach 69e Abs. 1 UrhG kann der Nutzer ohne Zustimmung des Rechtsinhabers nur eine ihm im Objektcode vorliegende Software dekompilieren, um die Interoperabilität herzustellen.

13 13 4 Schlussfolgerungen Obwohl viele OSS-Komponenten risikolos eingesetzt werden können, ist der Einsatz von OSS vor allem für den Cloud-Anbieter mit rechtlichen Risiken behaftet. Sie ergeben sich dann, wenn eine Software, in die Copyleft-Lizenzen unterstehende OSS-Komponenten verbaut worden sind, via SaaS zur Nutzung bereitgestellt wird. Vor diesem Hintergrund sollten Anbieter zunächst für Problembewusstsein bei den Inhouse-Entwicklern der Software sorgen und die Verwendung im eigenen Unternehmen organisieren, damit die Verwendung von OSS-Komponenten sauber dokumentiert wird, sodass die rechtlichen Risiken durch den Cloud-Anbieter vor ihrer Bereitstellung im Rahmen des Cloud- Dienstes geprüft und ggf. Maßnahmen zur Risikoverringerung ergriffen werden können. Sofern der Cloud-Anbieter seine Software von einem Dritten entwickeln lässt, sollten die Bedingungen für den Einsatz von OSS bereits im Entwicklungsauftrag geregelt werden. Der vollständige vertragliche Ausschluss der Verwendung von OSS ist die sicherste Variante, welche die Entwicklung jedoch auch teurer und langwieriger machen kann. Werden OSS-Komponenten eingesetzt, empfiehlt es sich, diese auftraggeberseitig beizustellen. Auf diese Weise kann im Streitfall argumentiert werden, dass eine Übertragung und damit eine urheberrechtliche Verbreitung der OSS-Komponente vom Auftragnehmer auf den Auftraggeber nicht erfolgt. Wenn der Cloud-Anbieter die Software dann jedoch z. B. im Rahmen einer Unternehmenstransaktion veräußern möchte, muss bei der Bewertung des Unternehmenswertes und der Risiken diesen modifizierten Komponenten Rechnung getragen werden. Trotz der bestehenden Rechtsrisiken ist jedoch festzustellen, dass bisher keine Gericht s- urteile bekannt geworden sind, die einen SaaS-Anbieter wegen der Verletzung einer OSS-Lizenz zur Offenlegung des Quellcodes, zur Unterlassung der SaaS-Dienstleistung oder zur Leistung von Schadensersatz verpflichtet haben. Der Konflikt zwischen dem Grundprinzip der Freiheit von OSS einerseits und proprietären Cloud-Lösungen andererseits zeigt sich jedoch in der aktuellen Entwicklung neuer OSS-Nutzungsbedingungen.

14 14 Autoren Dr. Marc Hilber LL.M. (Illinois), Oppenhoff & Partner Dr. Alexander Duisberg, Bird & Bird LLP Alexander Glaus, Deutsche Bank AG Björn Hajek, Infineon Technologies AG Rudi Kramer, DATEV eg Dr. Dirk Reintzsch, Oppenhoff & Partner Stephan Sädtler, Universität Passau Thomas von Bülow, 1&1 Internet AG Magda Wicker, Universität Kassel

15 Impressum Herausgeber Kompetenzzentrum Trusted Cloud Arbeitsgruppe Rechtsrahmen des Cloud Computing Im Auftrag des Bundesministeriums für Wirtschaft und Energie (BMWi) Gestaltung A&B One Kommunikationsagentur, Berlin Druck DCM Druck Center Meckenheim Stand: Mai 2014

16