XI Inhaltsverzeichnis

1. Vorwort
2. Inhaltsübersicht
3. Abkürzungsverzeichnis
4. Literaturverzeichnis
5. Kapitel I Free and Open Source Software (FOSS) – Idee und Risiken
   1. 1. Wie naiver Einsatz kostenloser Software Ihr Unternehmen bedrohen kann
      1. a) Am Anfang stand die Idee: Freiheit von Copyrightzwängen
         1. aa) Wie sich FOSS verbreitet hat
         2. bb) Wo FOSS verzichtbar ist und wo nicht
      2. b) In welchen Fällen kostenlose Software teuer werden kann
      3. c) Was schlimmstenfalls passieren kann
         1. aa) Häufiger Irrtum: Copyleft führt automatisch zur Freigabe als FOSS
         2. bb) Ungenutztes Schädigungspotenzial der Rechtsinhaber
            1. (1) Rechtlicher Fokus
            2. (2) Realitätsfokus
      4. d) Was bisher geschah...
         1. aa) Harald Welte: Pionier der deutschen FOSS Rechtsprechung
         2. bb) Patrick McHardy: Kommerzialisierung der Rechtsverfolgung
         3. cc) Schlaglichter FOSS relevanter Verfahren im Ausland
      5. e) Das Who’s Who der Open Source Community
         1. aa) Free Software Foundation (FSF)
         2. bb) Open Source Initiative (OSI)
         3. cc) Apache Software Foundation (ASF)
         4. dd) Eclipse Foundation
         5. ee) Linux Foundation
         6. ff) Sonstige
   2. 2. Was FOSS eigentlich ist
      1. a) FOSS = Free Software + Open Source Software
      2. b) FOSS ≠ Closed Source Software
         1. aa) Kommerzielle Software
         2. bb) Freeware
         3. cc) Shareware
         4. dd) Was ist mit Public Domain?
6. Kapitel II Technische Grundlagen: Coding und Kompilierung
   1. 1. Welche Arten von Code gibt es?
      1. a) Source Code bzw. Quellcode
      2. b) Object Code
      3. c) Binärcode
      4. d) Executables
   2. 2. Von welchen Tools die Entwickler sprechen
      1. a) Entwicklungsumgebungen und Build-Tools
      2. b) Werkzeugkoffer zum Coden – Compiler, Parser, Linker und Interpreter
   3. 3. Juristen müssen diese Verlinkung verstehen
      1. a) Statische vs. dynamische Verlinkung
      2. b) So linken die verschiedenen Programmiersprachen
         1. aa) C und C++
         2. bb) Python
         3. cc) Java
   4. 4. Diese Befehlsstrukturen müssen Juristen erst recht verstehen
      1. a) System Call
      2. b) System Call zum Aufruf unselbstständiger System- oder Programmfunktionen
      3. c) System Call zum Aufruf selbstständiger Anwendungsprogramme – Process Call
      4. d) Mounten von Dateisystemen
      5. e) Pipes
      6. f) Sockets
      7. g) Aufruf über Kommandozeile
7. Kapitel III Rechtliche Grundlagen: insbesondere Lizenzvorgaben und Copyleft
   1. 1. FOSS Lizenzen sind AGB – es gilt Schenkungsrecht
      1. a) Wie FOSS Lizenzen einbezogen werden
         1. aa) Wirksame Einbeziehung
         2. bb) Wirksamkeit
      2. b) Wie Vertragsgrundlagen bei Ansprüchen helfen können
         1. aa) Lizenzvertrag mit schenkungsvertragsrechtlichen Elementen
         2. bb) Vertragsabschluss
         3. cc) Schriftform
   2. 2. Was FOSS Lizenzen generell ausmacht
      1. a) Kein Problem bei der reinen Nutzung
      2. b) Probleme fangen erst bei der Weitergabe an
      3. c) Das Leitmotiv: Freigabe von Source Code und Copyleft
   3. 3. Die wirklich entscheidenden juristischen Kriterien
      1. a) Hinter „Weitergabe“ stehen verschiedene Verwertungshandlungen
      2. b) EuGH: Erschöpfung schlägt jede Lizenz
      3. c) Für eine Veränderung muss man programmieren
         1. aa) Vergleiche U. S.- und deutsche Rechtsterminologie
         2. bb) Wann genau die Grenze zur Veränderung überschritten wird
      4. d) Wann ein Code Bestandteil über die Hürde der Schutzfähigkeit springt
         1. aa) Allgemeine Kriterien für die Schutzfähigkeit
         2. bb) Kriterien der Rechtsprechung
         3. cc) Begriff des „Elements“
         4. dd) Das Problem mit der Nachweisbarkeit
   4. 4. Am Ende ein Scheinproblem: Rechtswahl- und Gerichtsstandsklauseln
   5. 5. Definiere Copyleft
   6. 6. Auslegung von derivative work entscheidet über das Copyleft
      1. a) Orientierung an U. S. Copyright Act
      2. b) Maßgeblich ist Veränderung bzw. Bearbeitung nach UrhG
      3. c) Auslegung der GPL-2.0: Wann liegt ein derivative work vor?
         1. aa) Abgrenzungskriterien helfen für eine Annäherung
         2. bb) Formal: Vertreibe Copyleft Software getrennt
         3. cc) Inhaltlich-funktionale Einheit kann derivative work sein
         4. dd) Besser: Trenne zusätzlich technisch
      4. d) Was das alles bezogen auf den konkreten Einzelfall bedeutet
         1. aa) Bearbeitung eines einzelnen Werks
         2. bb) Interaktion von proprietären Software-Komponenten mit GPL Software
      5. e) Derivative work führt zu Copyleft, Kurzformel
   7. 7. Taxonomie der Lizenzen
      1. a) FOSS Lizenzen mit strengem Copyleft
         1. aa) Die GPL-2.0
         2. bb) Die GPL-3.0
         3. cc) Die AGPL-3.0
         4. dd) Weitere Lizenzen mit strengem Copyleft
      2. b) FOSS Lizenzen mit beschränktem Copyleft
         1. aa) Die LGPL
         2. bb) Die MPL
         3. cc) Die EPL-2.0
      3. c) FOSS Lizenzen ohne Copyleft
      4. d) Sonstige Software-Klassen
   8. 8. Das Who’s Who der FOSS Lizenzen
      1. a) Die GPL-2.0 und GPL-3.0
      2. b) Die AGPL-3.0
      3. c) Die LGPL
      4. d) Die MPL-2.0
      5. e) Die EPL
      6. f) Die BSD Lizenzen
      7. g) Apache Lizenzen
      8. h) MIT
   9. 9. Nicht jeder Lizenzverstoß erzeugt Strafbarkeit
      1. a) Objektiver Tatbestand: Zunächst jede unerlaubte Verwertung
         1. aa) Heilungsmöglichkeiten in FOSS Lizenzen schützen nicht zuverlässig
         2. bb) Allein auf den Zeitpunkt der Verwertungshandlung kommt es an
      2. b) Subjektiver Tatbestand: Vorsatz erfordert konkrete Kenntnis
      3. c) Keine Strafbarkeit bei nachträglicher Kenntnis
      4. d) Keine Verfolgung ohne Strafantrag
   10. 10. Exkurs: Recht ist relativ – Wie viel Rechtssicherheit darf es heute sein?
       1. a) Der bequeme Weg
       2. b) Scannen alleine schafft nur Scheinsicherheit
8. Kapitel IV Die elementaren Prozessschritte: Ermittlung – Bewertung – Umsetzung
   1. 1. Der Dreiklang des Compliance-Prozesses
   2. 2. Exkurs: FOSS Risiken als „Goldgrube“ in der Due Diligence
      1. a) Irgendein FOSS Risiko findet sich immer
      2. b) Effektive Klauselinhalte für den Kaufvertrag
9. Kapitel V Ermittlung der eingesetzten FOSS
   1. 1. Prüftiefe abhängig von Herkunft der FOSS
      1. a) Warum Eigenentwicklungen voll geprüft werden sollten
      2. b) Die Wahl bei zugelieferten Software-Produkten
         1. aa) Vertrauen ist gut, Kontrolle ist besser?
         2. bb) Vollprüfung vs. Stichproben
      3. c) Exkurs: Was im Vertrag bzgl. FOSS geregelt sein sollte
   2. 2. Prüftiefe abhängig vom Einsatz der Software
      1. a) Keine Weitergabe: wie intern es dafür sein muss
         1. aa) „Dual Use“ bei Tooling Software
         2. bb) Weitergabe von Werkzeugen wie Compiler und Parser
      2. b) Wo die Weitergabe nicht offenkundig, aber trotzdem zu bejahen ist
         1. aa) Konzerninterne Weitergabe oder Weitergabe „im kleinen Kreis“
         2. bb) Aufruf von FOSS über einen Browser
         3. cc) Weitergabe bei der Nutzung von Clouddiensten
            1. (1) Weitergabe durch Übermittlung der FOSS an eine Cloud
            2. (2) Weitergabe aufgrund von Zugriffsmöglichkeit durch Dritte
      3. c) Was Cleared Code Base bedeutet und warum sie sinnvoll ist
   3. 3. Bill-of-Material: Was ist drin und woher nehmen
      1. a) Notwendige und optionale Inhalte
      2. b) Was ist wirklich drin: File Lizenzen und Dependencies
         1. aa) File Lizenzen aus den Header Informationen der einzelnen Files
         2. bb) Automatisch eingebundene Abhängigkeiten, sogenannte Dependencies
      3. c) Manuelle Bestandslisten selten vollständig
      4. d) Ziel: Automatisierte Erfassung aus Entwicklungsumgebungen
      5. e) Code Scans als essenzieller Prozessbaustein
         1. aa) „Header“ Scan vs. „Snippet“ Scan vs. „Cloud“ Scan
         2. bb) „Daily“/„Nightly“ Scan vs. Code Audit
         3. cc) Details zu gängigen Scantools aus der Praxis
10. Kapitel VI Rechtliche Bewertung der eingesetzten FOSS
    1. 1. Vorspann: Clustering nach Compliance-Leveln
       1. a) Kategorie A: Panisch
       2. b) Kategorie B: Konservativ
       3. c) Kategorie C: Liberal
       4. d) Kategorie D: Leichtfertig
       5. e) Wenn der CEO das Risiko kalkulieren will
          1. aa) Eintrittswahrscheinlichkeit
          2. bb) Schadenspotenziale
             1. (1) Gesetzliche Ansprüche
             2. (2) Ansprüche aus Vertrag
    2. 2. Shopping list für die rechtliche Bewertung
       1. a) Bill-of-Material (BOM)
       2. b) Schicksal des Endprodukts
       3. c) Sonderproblem: Strukturen und Deadlines in der Projektverwaltung
    3. 3. Whitelist/Blacklist-Ansätze: Begrenzter Nutzen
       1. a) Sortierung nach Gefährlichkeit von FOSS Klauseln naheliegend
       2. b) Listen führen zu pauschalem Verbot von zulässigem Einsatz
    4. 4. Legitime Shortcuts bei der rechtlichen Prüfung
       1. a) Vereinfachtes Prüfungsschema: Grundfrage Weitergabe
       2. b) Warum auch interne Software erfasst werden sollte
       3. c) Schnelle Bewertung von FOSS unter Lizenzen ohne Copyleft
          1. aa) Beifügen von Informationen genügt
          2. bb) Umgehung der Pflichtangaben durch Relizenzierung?
    5. 5. Schutz vor Copyleft Infektion
       1. a) Einhaltung der Vorgaben zum beschränkten Copyleft als „letzte Ausfahrt“
          1. aa) Ausweg Verlinkung für LGPL
          2. bb) Differenzierte Betrachtung für EPL
       2. b) Hinreichende Abgrenzung der Software-Bestandteile
          1. aa) Grundannahme/„Daumenregel“
          2. bb) System Calls/Process Calls zur Verhinderung von Copyleft bei GPL
       3. c) License Exceptions: gut gemeint, nur halb durchdacht?
       4. d) Copyleft detailliert und am Fall
          1. aa) Grundfall: WordPress und „Forking“
             1. (1) Kein Lizenzwechsel erlaubt
             2. (2) Verstoß gegen Copyleft der GPL
          2. bb) Spezielle Anwendungsfälle der Interaktion
             1. (1) Einheitliche Installationsroutine des CMS mit proprietären Software-Komponenten und Vertrieb auf einem Datenträger
             2. (2) Verwendung/Aufruf von proprietären Standardkomponenten über WordPress-eigene Schnittstellen
             3. (3) Hinzufügen eigener proprietärer Funktionskomponenten in WordPress
                1. (a) Ergänzungen/Veränderungen von WordPress-eigenem Code
                2. (b) Änderung durch Austausch von Funktionskomponenten
             4. (4) Verlinkung von proprietären Programmbibliotheken mit WordPress
       5. e) LG Berlin – Irrläufer-Urteil zur Reichweite des Copyleft
          1. aa) Grundsätze der Entscheidung LG Berlin – Surfsitter
          2. bb) Gegenpol: LG Mannheim und OLG Karlsruhe
          3. cc) In Berlin hätte es besser laufen können ...
       6. f) Linux kernel, user space und UAPI: die „Büchse der Pandora“
    6. 6. Gefahr durch Ablauf-/Signaturprüfungen („TiVo“)
       1. a) TiVo-Maßnahmen verhindern Veränderung installierter Software
       2. b) Ausdrückliche Beschränkungen der Tivoisierung in FOSS Lizenzen
          1. aa) GPL/AGPL-3.0
          2. bb) LGPL-3.0
          3. cc) Regelungen zu Tivoisierung in der GPL-2.0
       3. c) Faktische Beschränkungen der Tivoisierung in LGPL
          1. aa) LGPL-2.0
          2. bb) LGPL-2.1
          3. cc) Funktionserhaltende Austauschbarkeit
       4. d) Exceptions als Befreiung von Lizenzvorgaben, auch bzgl. Tivoisierung
       5. e) Wie das Problem mit Tivoisierungsbeschränkungen gelöst werden kann
    7. 7. Oft übersehen: Wenn Lizenzen allergisch aufeinander reagieren
       1. a) Was Lizenzinkompatibilität bedeutet
       2. b) Wie Lizenzinkompatibilität durch Copyleft entstehen kann
       3. c) Welche FOSS Lizenzen konkret allergisch aufeinander reagieren
          1. aa) Apache-2.0 vs GPL
          2. bb) LGPL vs. GPL vs. GPL
          3. cc) Copyleft vs. Copyleft with Exceptions
       4. d) Lizenzkompatibilität: Wie prüfen
    8. 8. Technische Anpassungen zur Rettung des legalen Einsatzes
       1. a) Austausch oft die leichteste Lösung
       2. b) Zwischenschichten als Schutzwall gegen Copyleft?
          1. aa) „Ränder“-Lösung über GPL mit Exception
          2. bb) Legitime Ausgestaltung separierender Zwischenlayer
       3. c) Techniker können die Einhaltung von Exception-Vorgaben bestätigen
       4. d) Innovative Ansätze, LGPL Austauschbarkeit zu erreichen
          1. aa) Verwendung von individuellen Authentifizierungsschlüsseln
          2. bb) Support-Lösung
          3. cc) Docker/Snap-Lösung
          4. dd) Aufteilungslösung
       5. e) Irrelevanter Link bei mitgelieferter Standard Library?
       6. f) Zwei Verlinkungen, kein Copyleft: technisches Argument bei Standard Library
    9. 9. Rechtliche Argumentation als ultima ratio
       1. a) Wo kein Schutz, da kein Problem
       2. b) Bearbeiterurheber: Rechtsverfolgung aussichtslos?
       3. c) Wie viel toxisches Copyleft kann ein Werk schadlos wegstecken?
       4. d) Möglicher Einsatz trotz fehlender File Lizenz
       5. e) Wie man Erschöpfung bei der FOSS Verbreitung nutzen kann
11. Kapitel VII Umsetzung des lizenzgerechten Einsatzes von FOSS in Produkten
    1. 1. Copyright, Lizenzen & Co.: Leicht zu erstellen, aber zeitaufwendig
       1. a) Welche verpflichtenden Angaben FOSS Lizenzen verlangen
       2. b) „Written Offer“ als Arbeitserleichterung
       3. c) Wie diese Pflichtangaben aussehen sollten
       4. d) Und noch wichtiger: Was nicht vergessen werden sollte
       5. e) Wann ein Link auf die Pflichtangaben nicht ausreicht
    2. 2. Source Code Bereitstellung: Was zu tun ist
       1. a) Was genau bereitzustellen ist
       2. b) Es muss nicht immer ein Datenträger sein
       3. c) Das betrifft nicht immer nur Source Code
    3. 3. Verzicht auf Pflichtangaben oder wann man sich den „Kram“ sparen kann
12. Kapitel VIII Herausforderung: Weitergabe des Linux kernel
    1. 1. Pflichtangaben
    2. 2. Verlinkungen auf Kernel Funktionen
    3. 3. Binär-Blobs
    4. 4. Anwendungscode und kurze Textdateien
    5. 5. Dateien ohne Copyrightvermerke
    6. 6. Hardware-Treiber
    7. 7. Lizenzkompatibilität
    8. 8. Bereinigung der Code Base
13. Kapitel IX Anhang: Compliance-Material und Checklisten
    1. 1. Beispiel Chart zur Kategorisierung der Lizenzen
    2. 2. Beispiel One Pager zur Einordnung der Lizenzen und Lizenzvorgaben
    3. 3. Beispiel Whitelist/Blacklist
    4. 4. Beispiel FOSS Compliance-Musterprozess
    5. 5. Beispiel Übersicht zur Information über Vor- und Nachteile des FOSS Einsatzes
    6. 6. Beispiel Darstellung Pflichtangaben
    7. 7. Übersicht der Rechtsprechung und Rechtsverfolgung bei FOSS
    8. 8. Lizenzkompatibilitätsmatrix
    9. 9. Praxisfall: Vertragsverhältnisse und Auswirkungen bei FOSS in Produkten
    10. 10. Pool von FOSS Vertragsklauseln
        1. a) Klauselvorschlag zur Definition von FOSS im Vertrag
        2. b) Ökonomisch effiziente Klausel zur Verwendung von FOSS
        3. c) Umfassende Klausel zur Verpflichtung des Auftragnehmers
14. Glossar
15. Stichwortverzeichnis
16. Zusatzcontent zum Download