Praxishandbuch Open Source

Praxishandbuch Open Source
Technische und rechtliche Rahmenbedingungen
für einen lizenzkonformen Einsatz von FOSS
im Unternehmen

Herausgegeben von

Christian Galetzka, LL.M.

Rechtsanwalt und Fachanwalt für IT-Recht, Würzburg

Chan-jo Jun

Rechtsanwalt und Fachanwalt für IT-Recht, Würzburg

und

Yvonne Roßmann

Rechtsanwältin und Fachanwältin für IT-Recht, Würzburg

Bearbeitet von

Lisa Breunung; Christian Galetzka, LL.M.; Florian Hackel;

Chan-jo Jun; Julia Kendziorra; Ulrich Kulke; Yvonne Roßmann

Fachmedien Recht und Wirtschaft | dfv Mediengruppe | Frankfurt am Main

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN: 978-3-8005-1763-3

© 2021 Deutscher Fachverlag GmbH, Fachmedien Recht und Wirtschaft, Frankfurt am Main

www.ruw.de

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Druck: WIRmachenDRUCK GmbH, Backnang

Printed in Germany

Vorwort

Jura ist normalerweise nicht sonderlich kreativ. Wenn wir eine Rechtsfrage prüfen, lesen wir erst einmal, was Gerichte oder andere Autoren in Büchern und Zeitschriften zu dem Thema gesagt haben. Bei Fragen zu Open Source Recht hat das nicht besonders gut funktioniert, weil die bisher größtenteils dogmatische Literatur die Grundlagen behandelte und häufig dort aufhörte, wo die aufgeworfenen Fragen in der Praxis begannen.

Wir haben daher das Buch geschrieben, das wir in den letzten Jahren gerne zum Einarbeiten und Nachschlagen benutzt hätten. Es kann jetzt die mehrtägigen Workshops zur Einarbeitung in das Open Source Thema verkürzen, um die freiwerdenden Kapazitäten und Budgets für spannende neue Fragen oder Einzelfallabwägungen freizumachen. Wir haben es gewagt, strittige Fragen zur Reichweite des Copyleft Effekts und der Strafbarkeit von Managern zu beantworten, die woanders noch nicht aufgeworfen, geschweige denn geklärt worden sind. Sie erkennen diese Kapitel daran, dass die Fußnoten seltener werden. Die neuen Fragestellungen sollen dabei nicht zusätzliche Verhinderungsgründe für den Einsatz von Open Source Software sein, sondern bieten differenzierte Argumentationsansätze für Rechtfertigungen. Auf die damit verbundenen Risiken weisen wir hin.

Neuland betreten wir nicht nur bei komplexen Rechtsfragen, sondern auch bei der praktischen Handreichung für die Installation von unternehmensinternen Compliance-Prozessen. Das Autorenteam besteht aus erfahrenen Anwälten einer Würzburger Kanzlei für IT-Recht. Im Open Source Bereich sind wir ausschließlich auf der Industrie- und Verwertungsseite tätig. Daher unterstellen wir bei den Beispielsfällen die Sicht desjenigen Anwenders, der Open Source Software aus fremden Quellen legal einsetzen will, und nicht desjenigen, der Geld mit der Verfolgung von Rechtsverletzungen verdienen will.

„Free and Open Source Software“ (FOSS) ist für Software-Entwicklung und produktiven Einsatz nicht mehr wegzudenken. Entwickler nutzen den im Internet regelmäßig kostenfrei verfügbaren Code, um eigene Entwicklungszeit und Ressourcen für proprietäre Entwicklungen zu sparen bzw. letztere um innovative Tools aus dem Open Source Portfolio anzureichern. Das weitverbreitet eingesetzte Betriebssystem „linux“ steht komplett unter Open Source Lizenzbedingungen zur Verfügung.

Es darf jedoch beim Einsatz von FOSS nicht übersehen werden, dass die Lizenzbedingungen der kostenfreien Software ebenso wie kommerzielle Lizenzen standardisiert bestimmte Vorgaben für die Verwendung treffen. Je nach Ausgestaltung der konkreten Lizenz oder Lizenzen können die Vorgaben leicht, aber zeitaufwendig bis im konkreten Projekt oder Produkt unmöglich umzusetzen sein.

Für die Erfassung und Beurteilung eingesetzter FOSS muss technisches und rechtliches Verständnis kombiniert werden. Dann ist es möglich, im Projektablauf zunächst einen vollständigen Überblick über die geltenden Lizenzbedingungen zu erhalten, bei Bedarf die Software-Architektur anzupassen und schließlich alle notwendigen Materialien für einen lizenzgerechten Einsatz zusammenzustellen. Ziel sollte ein für das jeweilige Unternehmen und dessen Anwendungsfälle passender Open Source Compliance-Prozess sein.

Wir erklären in diesem Buch für Praktiker, wie sich Rechtssicherheit zu Aufwand und Kosten ins Verhältnis setzen lässt und sich Themen oder Probleme an der Schnittstelle von Technik und Recht lösen lassen. So, wie Freie Software nicht i.S.v. Freibier verstanden werden soll, bedeutet pragmatisch auch nicht, dass die von uns diskutierten Lösungen die technischen und rechtlichen Herausforderungen schlicht ignorieren. Der Pragmatismus besteht darin, dass die vorgeschlagenen Lösungen in der Praxis umsetzbar sind.

Unser Dank gebührt vor allem unseren Co-Autoren und Kanzleikollegen Lisa Breunung, Florian Hackel, Julia Kendziorra und Ulrich Kulke, ohne deren tatkräftige Unterstützung und Mitwirkung an zahlreichen Einzelkapiteln dieses Buch nicht denkbar gewesen wäre, sowie unseren Rechtsanwaltsfachangestellten und wissenschaftlichen Mitarbeiterinnen, die bei der Entstehung des Buches und Bearbeitung von Einzelkapiteln geholfen haben. Nicht vergessen wollen wir auch den Rest des Teams sowie unsere Familien, die jeweils Kapazitätsengpässe abgefangen und Open Source Diskussionen ertragen haben. Danken möchten wir zudem Frau Brücker und Frau Grüttner aus dem Lektorat des R&W Verlags, die die Entstehung des Buches in seiner Erstauflage durch Beantwortung zahlreicher Fragen und Setzen fachlicher Impulse begleitet und bereichert haben. Wir freuen uns, mit dem dfv die passende Plattform für dieses Praxishandbuch zu haben, und danken Herrn Orth und Herrn Schneider dafür, dass sie und der dfv unsere Vision mittragen.

Wir wünschen Ihnen wertvolle Erkenntnisse aus der Lektüre und verarbeiten Rückfragen, Ergänzungswünsche und Kritik gerne oder bereitwillig auf unseren Kanälen (z.B. per E-Mail an Praxishandbuch-FOSS@junit.de) oder einer Folgeauflage.

Inhaltsübersicht

1  Vorwort

2  Inhaltsverzeichnis

3  Abkürzungsverzeichnis

4  Literaturverzeichnis

5  Kapitel I Free and Open Source Software (FOSS) – Idee und Risiken

6  Kapitel II Technische Grundlagen: Coding und Kompilierung

7  Kapitel III Rechtliche Grundlagen: insbesondere Lizenzvorgaben und Copyleft

8  Kapitel IV Die elementaren Prozessschritte: Ermittlung – Bewertung – Umsetzung

9  Kapitel V Ermittlung der eingesetzten FOSS

10  Kapitel VI Rechtliche Bewertung der eingesetzten FOSS

11  Kapitel VII Umsetzung des lizenzgerechten Einsatzes von FOSS in Produkten

12  Kapitel VIII Herausforderung: Weitergabe des Linux kernel

13  Kapitel IX Anhang: Compliance-Material und Checklisten

14  Glossar

15  Stichwortverzeichnis

16  Zusatzcontent zum Download

Inhaltsverzeichnis

1  Vorwort

2  Inhaltsübersicht

3  Abkürzungsverzeichnis

4  Literaturverzeichnis

5  Kapitel I Free and Open Source Software (FOSS) – Idee und Risiken 1. Wie naiver Einsatz kostenloser Software Ihr Unternehmen bedrohen kann a) Am Anfang stand die Idee: Freiheit von Copyrightzwängen aa) Wie sich FOSS verbreitet hat bb) Wo FOSS verzichtbar ist und wo nicht b) In welchen Fällen kostenlose Software teuer werden kann c) Was schlimmstenfalls passieren kann aa) Häufiger Irrtum: Copyleft führt automatisch zur Freigabe als FOSS bb) Ungenutztes Schädigungspotenzial der Rechtsinhaber (1) Rechtlicher Fokus (2) Realitätsfokus d) Was bisher geschah... aa) Harald Welte: Pionier der deutschen FOSS Rechtsprechung bb) Patrick McHardy: Kommerzialisierung der Rechtsverfolgung cc) Schlaglichter FOSS relevanter Verfahren im Ausland e) Das Who’s Who der Open Source Community aa) Free Software Foundation (FSF) bb) Open Source Initiative (OSI) cc) Apache Software Foundation (ASF) dd) Eclipse Foundation ee) Linux Foundation ff) Sonstige 2. Was FOSS eigentlich ist a) FOSS = Free Software + Open Source Software b) FOSS ≠ Closed Source Software aa) Kommerzielle Software bb) Freeware cc) Shareware dd) Was ist mit Public Domain?

 

6  Kapitel II Technische Grundlagen: Coding und Kompilierung 1. Welche Arten von Code gibt es? a) Source Code bzw. Quellcode b) Object Code c) Binärcode d) Executables 2. Von welchen Tools die Entwickler sprechen a) Entwicklungsumgebungen und Build-Tools b) Werkzeugkoffer zum Coden – Compiler, Parser, Linker und Interpreter 3. Juristen müssen diese Verlinkung verstehen a) Statische vs. dynamische Verlinkung b) So linken die verschiedenen Programmiersprachen aa) C und C++ bb) Python cc) Java 4. Diese Befehlsstrukturen müssen Juristen erst recht verstehen a) System Call b) System Call zum Aufruf unselbstständiger System- oder Programmfunktionen c) System Call zum Aufruf selbstständiger Anwendungsprogramme – Process Call d) Mounten von Dateisystemen e) Pipes f) Sockets g) Aufruf über Kommandozeile

7  Kapitel III Rechtliche Grundlagen: insbesondere Lizenzvorgaben und Copyleft 1. FOSS Lizenzen sind AGB – es gilt Schenkungsrecht a) Wie FOSS Lizenzen einbezogen werden aa) Wirksame Einbeziehung bb) Wirksamkeit b) Wie Vertragsgrundlagen bei Ansprüchen helfen können aa) Lizenzvertrag mit schenkungsvertragsrechtlichen Elementen bb) Vertragsabschluss cc) Schriftform 2. Was FOSS Lizenzen generell ausmacht a) Kein Problem bei der reinen Nutzung b) Probleme fangen erst bei der Weitergabe an c) Das Leitmotiv: Freigabe von Source Code und Copyleft 3. Die wirklich entscheidenden juristischen Kriterien a) Hinter „Weitergabe“ stehen verschiedene Verwertungshandlungen b) EuGH: Erschöpfung schlägt jede Lizenz c) Für eine Veränderung muss man programmieren aa) Vergleiche U. S.- und deutsche Rechtsterminologie bb) Wann genau die Grenze zur Veränderung überschritten wird d) Wann ein Code Bestandteil über die Hürde der Schutzfähigkeit springt aa) Allgemeine Kriterien für die Schutzfähigkeit bb) Kriterien der Rechtsprechung cc) Begriff des „Elements“ dd) Das Problem mit der Nachweisbarkeit 4. Am Ende ein Scheinproblem: Rechtswahl- und Gerichtsstandsklauseln 5. Definiere Copyleft 6. Auslegung von derivative work entscheidet über das Copyleft a) Orientierung an U. S. Copyright Act b) Maßgeblich ist Veränderung bzw. Bearbeitung nach UrhG c) Auslegung der GPL-2.0: Wann liegt ein derivative work vor? aa) Abgrenzungskriterien helfen für eine Annäherung bb) Formal: Vertreibe Copyleft Software getrennt cc) Inhaltlich-funktionale Einheit kann derivative work sein dd) Besser: Trenne zusätzlich technisch d) Was das alles bezogen auf den konkreten Einzelfall bedeutet aa) Bearbeitung eines einzelnen Werks bb) Interaktion von proprietären Software-Komponenten mit GPL Software e) Derivative work führt zu Copyleft, Kurzformel 7. Taxonomie der Lizenzen a) FOSS Lizenzen mit strengem Copyleft aa) Die GPL-2.0 bb) Die GPL-3.0 cc) Die AGPL-3.0 dd) Weitere Lizenzen mit strengem Copyleft b) FOSS Lizenzen mit beschränktem Copyleft aa) Die LGPL bb) Die MPL cc) Die EPL-2.0 c) FOSS Lizenzen ohne Copyleft d) Sonstige Software-Klassen 8. Das Who’s Who der FOSS Lizenzen a) Die GPL-2.0 und GPL-3.0 b) Die AGPL-3.0 c) Die LGPL d) Die MPL-2.0 e) Die EPL f) Die BSD Lizenzen g) Apache Lizenzen h) MIT 9. Nicht jeder Lizenzverstoß erzeugt Strafbarkeit a) Objektiver Tatbestand: Zunächst jede unerlaubte Verwertung aa) Heilungsmöglichkeiten in FOSS Lizenzen schützen nicht zuverlässig bb) Allein auf den Zeitpunkt der Verwertungshandlung kommt es an b) Subjektiver Tatbestand: Vorsatz erfordert konkrete Kenntnis c) Keine Strafbarkeit bei nachträglicher Kenntnis d) Keine Verfolgung ohne Strafantrag 10. Exkurs: Recht ist relativ – Wie viel Rechtssicherheit darf es heute sein? a) Der bequeme Weg b) Scannen alleine schafft nur Scheinsicherheit

8  Kapitel IV Die elementaren Prozessschritte: Ermittlung – Bewertung – Umsetzung 1. Der Dreiklang des Compliance-Prozesses 2. Exkurs: FOSS Risiken als „Goldgrube“ in der Due Diligence a) Irgendein FOSS Risiko findet sich immer b) Effektive Klauselinhalte für den Kaufvertrag

 

9  Kapitel V Ermittlung der eingesetzten FOSS 1. Prüftiefe abhängig von Herkunft der FOSS a) Warum Eigenentwicklungen voll geprüft werden sollten b) Die Wahl bei zugelieferten Software-Produkten aa) Vertrauen ist gut, Kontrolle ist besser? bb) Vollprüfung vs. Stichproben c) Exkurs: Was im Vertrag bzgl. FOSS geregelt sein sollte 2. Prüftiefe abhängig vom Einsatz der Software a) Keine Weitergabe: wie intern es dafür sein muss aa) „Dual Use“ bei Tooling Software bb) Weitergabe von Werkzeugen wie Compiler und Parser b) Wo die Weitergabe nicht offenkundig, aber trotzdem zu bejahen ist aa) Konzerninterne Weitergabe oder Weitergabe „im kleinen Kreis“ bb) Aufruf von FOSS über einen Browser cc) Weitergabe bei der Nutzung von Clouddiensten (1) Weitergabe durch Übermittlung der FOSS an eine Cloud (2) Weitergabe aufgrund von Zugriffsmöglichkeit durch Dritte c) Was Cleared Code Base bedeutet und warum sie sinnvoll ist 3. Bill-of-Material: Was ist drin und woher nehmen a) Notwendige und optionale Inhalte b) Was ist wirklich drin: File Lizenzen und Dependencies aa) File Lizenzen aus den Header Informationen der einzelnen Files bb) Automatisch eingebundene Abhängigkeiten, sogenannte Dependencies c) Manuelle Bestandslisten selten vollständig d) Ziel: Automatisierte Erfassung aus Entwicklungsumgebungen e) Code Scans als essenzieller Prozessbaustein aa) „Header“ Scan vs. „Snippet“ Scan vs. „Cloud“ Scan bb) „Daily“/„Nightly“ Scan vs. Code Audit cc) Details zu gängigen Scantools aus der Praxis

10  Kapitel VI Rechtliche Bewertung der eingesetzten FOSS 1. Vorspann: Clustering nach Compliance-Leveln a) Kategorie A: Panisch b) Kategorie B: Konservativ c) Kategorie C: Liberal d) Kategorie D: Leichtfertig e) Wenn der CEO das Risiko kalkulieren will aa) Eintrittswahrscheinlichkeit bb) Schadenspotenziale (1) Gesetzliche Ansprüche (2) Ansprüche aus Vertrag 2. Shopping list für die rechtliche Bewertung a) Bill-of-Material (BOM) b) Schicksal des Endprodukts c) Sonderproblem: Strukturen und Deadlines in der Projektverwaltung 3. Whitelist/Blacklist-Ansätze: Begrenzter Nutzen a) Sortierung nach Gefährlichkeit von FOSS Klauseln naheliegend b) Listen führen zu pauschalem Verbot von zulässigem Einsatz 4. Legitime Shortcuts bei der rechtlichen Prüfung a) Vereinfachtes Prüfungsschema: Grundfrage Weitergabe b) Warum auch interne Software erfasst werden sollte c) Schnelle Bewertung von FOSS unter Lizenzen ohne Copyleft aa) Beifügen von Informationen genügt bb) Umgehung der Pflichtangaben durch Relizenzierung? 5. Schutz vor Copyleft Infektion a) Einhaltung der Vorgaben zum beschränkten Copyleft als „letzte Ausfahrt“ aa) Ausweg Verlinkung für LGPL bb) Differenzierte Betrachtung für EPL b) Hinreichende Abgrenzung der Software-Bestandteile aa) Grundannahme/„Daumenregel“ bb) System Calls/Process Calls zur Verhinderung von Copyleft bei GPL c) License Exceptions: gut gemeint, nur halb durchdacht? d) Copyleft detailliert und am Fall aa) Grundfall: WordPress und „Forking“ (1) Kein Lizenzwechsel erlaubt (2) Verstoß gegen Copyleft der GPL bb) Spezielle Anwendungsfälle der Interaktion (1) Einheitliche Installationsroutine des CMS mit proprietären Software-Komponenten und Vertrieb auf einem Datenträger (2) Verwendung/Aufruf von proprietären Standardkomponenten über WordPress-eigene Schnittstellen (3) Hinzufügen eigener proprietärer Funktionskomponenten in WordPress (a) Ergänzungen/Veränderungen von WordPress-eigenem Code (b) Änderung durch Austausch von Funktionskomponenten (4) Verlinkung von proprietären Programmbibliotheken mit WordPress e) LG Berlin – Irrläufer-Urteil zur Reichweite des Copyleft aa) Grundsätze der Entscheidung LG Berlin – Surfsitter bb) Gegenpol: LG Mannheim und OLG Karlsruhe cc) In Berlin hätte es besser laufen können ... f) Linux kernel, user space und UAPI: die „Büchse der Pandora“ 6. Gefahr durch Ablauf-/Signaturprüfungen („TiVo“) a) TiVo-Maßnahmen verhindern Veränderung installierter Software b) Ausdrückliche Beschränkungen der Tivoisierung in FOSS Lizenzen aa) GPL/AGPL-3.0 bb) LGPL-3.0 cc) Regelungen zu Tivoisierung in der GPL-2.0 c) Faktische Beschränkungen der Tivoisierung in LGPL aa) LGPL-2.0 bb) LGPL-2.1 cc) Funktionserhaltende Austauschbarkeit d) Exceptions als Befreiung von Lizenzvorgaben, auch bzgl. Tivoisierung e) Wie das Problem mit Tivoisierungsbeschränkungen gelöst werden kann 7. Oft übersehen: Wenn Lizenzen allergisch aufeinander reagieren a) Was Lizenzinkompatibilität bedeutet b) Wie Lizenzinkompatibilität durch Copyleft entstehen kann c) Welche FOSS Lizenzen konkret allergisch aufeinander reagieren aa) Apache-2.0 vs GPL bb) LGPL vs. GPL vs. GPL cc) Copyleft vs. Copyleft with Exceptions d) Lizenzkompatibilität: Wie prüfen 8. Technische Anpassungen zur Rettung des legalen Einsatzes a) Austausch oft die leichteste Lösung b) Zwischenschichten als Schutzwall gegen Copyleft? aa) „Ränder“-Lösung über GPL mit Exception bb) Legitime Ausgestaltung separierender Zwischenlayer c) Techniker können die Einhaltung von Exception-Vorgaben bestätigen d) Innovative Ansätze, LGPL Austauschbarkeit zu erreichen aa) Verwendung von individuellen Authentifizierungsschlüsseln bb) Support-Lösung cc) Docker/Snap-Lösung dd) Aufteilungslösung e) Irrelevanter Link bei mitgelieferter Standard Library? f) Zwei Verlinkungen, kein Copyleft: technisches Argument bei Standard Library 9. Rechtliche Argumentation als ultima ratio a) Wo kein Schutz, da kein Problem b) Bearbeiterurheber: Rechtsverfolgung aussichtslos? c) Wie viel toxisches Copyleft kann ein Werk schadlos wegstecken? d) Möglicher Einsatz trotz fehlender File Lizenz e) Wie man Erschöpfung bei der FOSS Verbreitung nutzen kann

11  Kapitel VII Umsetzung des lizenzgerechten Einsatzes von FOSS in Produkten 1. Copyright, Lizenzen & Co.: Leicht zu erstellen, aber zeitaufwendig a) Welche verpflichtenden Angaben FOSS Lizenzen verlangen b) „Written Offer“ als Arbeitserleichterung c) Wie diese Pflichtangaben aussehen sollten d) Und noch wichtiger: Was nicht vergessen werden sollte e) Wann ein Link auf die Pflichtangaben nicht ausreicht 2. Source Code Bereitstellung: Was zu tun ist a) Was genau bereitzustellen ist b) Es muss nicht immer ein Datenträger sein c) Das betrifft nicht immer nur Source Code 3. Verzicht auf Pflichtangaben oder wann man sich den „Kram“ sparen kann

12  Kapitel VIII Herausforderung: Weitergabe des Linux kernel 1. Pflichtangaben 2. Verlinkungen auf Kernel Funktionen 3. Binär-Blobs 4. Anwendungscode und kurze Textdateien 5. Dateien ohne Copyrightvermerke 6. Hardware-Treiber 7. Lizenzkompatibilität 8. Bereinigung der Code Base

13  Kapitel IX Anhang: Compliance-Material und Checklisten 1. Beispiel Chart zur Kategorisierung der Lizenzen 2. Beispiel One Pager zur Einordnung der Lizenzen und Lizenzvorgaben 3. Beispiel Whitelist/Blacklist 4. Beispiel FOSS Compliance-Musterprozess 5. Beispiel Übersicht zur Information über Vor- und Nachteile des FOSS Einsatzes 6. Beispiel Darstellung Pflichtangaben 7. Übersicht der Rechtsprechung und Rechtsverfolgung bei FOSS 8. Lizenzkompatibilitätsmatrix 9. Praxisfall: Vertragsverhältnisse und Auswirkungen bei FOSS in Produkten 10. Pool von FOSS Vertragsklauseln a) Klauselvorschlag zur Definition von FOSS im Vertrag b) Ökonomisch effiziente Klausel zur Verwendung von FOSS c) Umfassende Klausel zur Verpflichtung des Auftragnehmers

14  Glossar

15  Stichwortverzeichnis

16  Zusatzcontent zum Download