Praxishandbuch Open Source

Name: Praxishandbuch Open Source | Technische und rechtliche Rahmenbedingungen für einen lizenzkonformen Einsatz von FOSS im Unternehmen
Brand: Fachmedien Recht und Wirtschaft
Price: 97.99 EUR
Availability: OnlineOnly

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

Christian Galetzka Chan-jo Jun Yvonne Roßmann(Author)

Christian Galetzka Chan-jo Jun Yvonne Roßmann(Editor)

Fachmedien Recht und Wirtschaft (Publisher)

1st Edition

Published on 14. October 2021

XXXVI, 415 pages

E-Book

PDF with digital watermarking

System requirements

978-3-8005-9383-5 (ISBN)

€97.99incl. 7% vat

System requirements

for PDF with digital watermarking

E-Book Single Licence

Available for download

Description

More details

Other editions

Persons

Content

Cover
Titel
Impressum
Vorwort
Inhaltsübersicht
Inhaltsverzeichnis
Abkürzungsverzeichnis
Literaturverzeichnis
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
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?
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 rechtverstehen
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
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
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
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
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-Vorgabenbestä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
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
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
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
Glossar
Stichwortverzeichnis
Zusatzcontent zum Download

System requirements

Save as PDF Copy link into clipboard

Schweitzer Fachinformationen

Praxishandbuch Open Source

Description

More details

Other editions

Additional editions

Persons

Content

System requirements