Praxishandbuch Open Source E-Book

Christian Galetzka

• Herausgeber: Fachmedien Recht und Wirtschaft
• Kategorie: Fachliteratur
• Serie: Kommunikation & Recht
• Sprache: Deutsch
• Veröffentlichungsjahr: 2021

Seitenzahl: 597

Beschreibung

Dieses Praxishandbuch erläutert die legalen Voraussetzugen für einen Einsatz von "Free and Open Source Software" (FOSS) in der Unternehmenspraxis, sei es bei der Entwicklung eigener wie beim Einkauf fremder Software, sei es auch bei intelligenten Geräten. Bedingungen aus Lizenztexten der 90er Jahre für Programmiersprachen der 80er Jahre in Steuergeräten der Zukunft gefährden die Timelines aktueller Projekte; die Lösung damit verbundener Probleme erfordert gleichzeitig technisches wie rechtliches Verständnis. Das Praxishandbuch Open Source stellt alle notwendigen Materialien für einen lizenzkonformen Einsatz von Open-Source-Software zusammen, bietet praktische Lösungen an und hilft, einen Compliance-Prozess zu etablieren und den lizenzkonformen Einsatz von FOSS zu meistern.

Leseprobe

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 [email protected]) oder einer Folgeauflage.

Würzburg, im September 2021

Christian Galetzka, LL. M.

Chan-jo Jun

Yvonne Roßmann

Inhaltsübersicht

Vorwort

Inhaltsverzeichnis

Abkürzungsverzeichnis

Literaturverzeichnis

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

Kapitel II Technische Grundlagen: Coding und Kompilierung

Kapitel III Rechtliche Grundlagen: insbesondere Lizenzvorgaben und Copyleft

Kapitel IV Die elementaren Prozessschritte: Ermittlung – Bewertung – Umsetzung

Kapitel V Ermittlung der eingesetzten FOSS

Kapitel VI Rechtliche Bewertung der eingesetzten FOSS

Kapitel VII Umsetzung des lizenzgerechten Einsatzes von FOSS in Produkten

Kapitel VIII Herausforderung: Weitergabe des Linux kernel

Kapitel IX Anhang: Compliance-Material und Checklisten

Glossar

Stichwortverzeichnis

Zusatzcontent zum Download

Abkürzungsverzeichnis

a.A.

anderer Ansicht

ABl.

Amtsblatt

ABl. EG

Amtsblatt der Europäischen Gemeinschaft

ABl. EU

Amtsblatt der Europäischen Union

Abs.

Absatz

AcP

Archiv für die civilistische Praxis (Zeitschrift)

a.E.

am Ende

AG

Aktiengesellschaft

AGB

Allgemeine Geschäftsbedingungen

AGPL

GNU Affero General Public License (FOSS Lizenz)

AktG

Aktiengesetz

allg.

allgemein/allgemeine/allgemeiner/allgemeines

Anm.

Anmerkung

ANTLR

ANother Tool for Language Recognition

API

Application Programming Interface (= Schnittstelle)

Art.

Artikel

ASF

Apache Software Foundation – (FOSS Organisation und Urheber der Apache Lizenzen)

ASP

Application Service Providing

Aufl.

Auflage

AWS

Amazon Web Services

BeckOK

Beck’scher Onlinekommentar

BeckRS

beck-online.RECHTSPRECHUNG

Bekl.

Beklagte/r

BGB

Bürgerliches Gesetzbuch

BGH

Bundesgerichtshof

BGHZ

Entscheidungen des Bundesgerichtshofs in Zivilsachen (Entscheidungssammlung)

Bit

binary digit

BOM

Bill-of-Material

BSD

BSD License (FOSS Lizenz, entwickelt und herausgegeben von der Berkeley Software Distribution)

Buchst.

Buchstabe

bzgl.

bezüglich

bzw.

beziehungsweise

CC

Creative Commons

CC-NC

Creative Commons-non commercial

CCPL

Creative Commons Public License

CD-ROM

Compact Disc Read-Only Memory

CDDL

Common Development and Distribution License (FOSS Lizenz)

CEO

Chief Executive Officer

CMS

Content Management System

CPL

Common Public License (FOSS Lizenz)

CR

Computer und Recht

CRi

Computer und Recht International

csv

Comma-separated values

CTO

Chief Technology Officer

DS-GVO

Datenschutz-Grundverordnung

d.h.

das heißt

DIMM

Dual Inline Memory Module

DMCA

Digital Millennium Copyright Act

DRM

Digital Rights Management

DSRITB

DSRI-Tagungsband

EG

Europäische Gemeinschaft

EL

Ergänzungslieferung

EPL

Eclipse Public License (FOSS Lizenz)

etc.

et cetera

EuGH

Europäischer Gerichtshof

EuGVVO

Verordnung über die gerichtliche Zuständigkeit und die Anerkennung und Vollstreckung von Entscheidungen in Zivil- und Handelssachen

EULA

End User License Agreement

EV

Einstweilige Verfügung

EU

Europäische Union

EWR

Europäischer Wirtschaftsraum

FAQ

Frequently Asked Questions

f.

folgende

ff.

fortfolgende

Fn.

Fußnote

FOSS

Free and Open Source Software

FS

Festschrift

FSF

Free Software Foundation (Organisation und Urheber der GNU Lizenzen)

GCC

GNU Compiler Collection

gem.

gemäß

ggf.

gegebenenfalls

GmbH

Gesellschaft mit beschränkter Haftung

GMV

Gemeinschaftsmarkenverordnung

GNU

GNU’s Not Unix

GPL

GNU General Public License (FOSS Lizenz)

GRUR

Gewerblicher Rechtsschutz und Urheberrecht (Zeitschrift)

GRUR Int.

Gewerblicher Rechtsschutz und Urheberrecht – International (Zeitschrift)

GRUR-Prax

Gewerblicher Rechtsschutz und Urheberrecht – Praxis im Immaterialgüter- und Wettbewerbsrecht (Zeitschrift)

GRUR-RD

Gewerblicher Rechtsschutz und Urheberrecht – Rechtsprechungsdienst (Online)

GRUR-RR

Gewerblicher Rechtsschutz und Urheberrecht – Rechtsprechungs-Report (Zeitschrift)

GRUR-RS

Gewerblicher Rechtsschutz und Urheberrecht – RECHTSPRECHUNG (Online)

h.L.

herrschende Lehre

h.M.

herrschende Meinung

Hdb.

Handbuch

Hrsg.

Herausgeber

HTML

Hypertext Markup Language

IDE

Integrierte Entwicklungsumgebung

i.d.R.

in der Regel

ifrOSS

Institut für Rechtsfragen der Freien und Open Source Software

INAL

I’m not a lawyer

Inc.

Incorporated

IPR

Internationales Privatrecht

i.S.d.

im Sinne des

i.S.v.

im Sinne von

i.V.m.

in Verbindung mit

IT

Informationstechnologie

JAR

Java Archive

JavaCC

Java Compiler Compiler

JDK

Java Development Kit

JDT

Java Development Tools

JSON

JavaScript Object Notation

jurisPK

Juris Praxiskommentar

JurPC

Internet-Zeitschrift für Rechtsinformatik und Informationsrecht, www.jurpc.de

JZ

Juristenzeitung (Zeitschrift)

Kap.

Kapitel

KG

Kammergericht Berlin

Kl.

Kläger/in

krit.

kritisch

KUG

Kunsturheberrechtsgesetz

K&R

Kommunikation und Recht (Zeitschrift)

LG

Landgericht

LGPL

GNU Lesser General Public License (FOSS Lizenz)

LLC

Limited Liability Company

Ls.

Leitsatz

Ltd.

Limited

MarkenG

Gesetz über den Schutz von Marken und sonstigen Kennzeichen (Markengesetz)

MIT

MIT License (FOSS Lizenz, entwickelt und herausgegeben vom Massachusetts Institute of Technology)

Mitt.

Mitteilung

MMR

Multimedia und Recht (Zeitschrift)

MPL

Mozilla Public License (FOSS Lizenz)

MüKo

Münchener Kommentar

m.

mit

m.w.N.

mit weiteren Nachweisen

NJW

Neue Juristische Wochenschrift (Zeitschrift)

NJW-RR

NJW-Rechtsprechungsreport (Zeitschrift)

npm

Node Package Manager

Nr.

Nummer

o.ä.

oder ähnliches

OLG

Oberlandesgericht

Open-LIMS

Open-Laboratory Information Management System

OS/2

Operating System/2

OSADL

Open Source Automation Development Lab

OSI

Open Source Initiative

OWiG

Gesetz über Ordnungswidrigkeiten

PC

Personal Computer

PDF

Portable Document Format

RAM

Random-Access Memory

RiStBV

Richtlinien für das Strafverfahren und das Bußgeldverfahren

RL

Richtlinie

Rn.

Randnummer

Rspr.

Rechtsprechung

S.

Seite

SaaS

Software as a Service

SCA

Software Code Analysis

SDK

Software Development Kits

sog.

sogenannt/e

SPDX

Software Package Data Exchange

SSL

Secure Sockets Layer

SSPL

Server Side Public License (FOSS Lizenz)

StGB

Strafgesetzbuch

str.

strittig

techn.

technisch

TiVo

Tivoisierung

TPM

Technical Protection Measures

TXT

Textdateiformat

UAPI

Universal Application Programming Interface

Unterziff.

Unterziffer

UrhG

Gesetz über Urheberrecht und verwandte Schutzrechte (Urheberrechtsgesetz)

URL

Uniform Resource Locator

USA

United States of America

U. S.

United States

USB

Universal Serial Bus

u.

und

usw.

und so weiter

UTF

Unicode Transformation Format

u.a.

unter anderem

u.U.

unter Umständen

UWG

Gesetz gegen den unlauteren Wettbewerb

v/V

version/Version

v.a.

vor allem

vgl.

vergleiche

VM

Virtual Machine

VO

Verordnung

VoIP

Voice over IP

vsl.

voraussichtlich

WCT

WIPO copyright treaty

WIPO

World Intellectual Property Organisation

WLAN

Wireless Local Area Network

z.B.

zum Beispiel

Ziff.

Ziffer

zit.

zitiert

ZPO

Zivilprozessordnung

ZR

Revisionen, Beschwerden gegen die Nichtzulassung der Revision, Anträge auf Zulassung der Sprungrevision, Berufungen in Patentsachen beim Bundesgerichtshof

ZUM

Zeitschrift für Urheber- und Medienrecht

ZUM-RD

Zeitschrift für Urheber- und Medienrecht – Rechtsprechungs-Dienst

©

Copyright

Literaturverzeichnis

Ahlberg, Hartwig/Götting, Horst-Peter (Hrsg.)

Beck’scher Onlinekommentar zum Urheberrecht, 30. Edition, 2021 (zit. Bearbeiter, in: BeckOK UrhR, § Rn.)

Allmann, Ivonne

Open Source Compliance, 2019 (zit. Allmann, S.)

Arlt, Christian

Digital Rights Management – Der Einsatz technischer Maßnahmen zum Schutz digitaler Inhalte, 2006 (zit. Arlt, Digital Rights Management, S.)

Augsten, Stephan

Was ist eine Software-Paketverwaltung?, abrufbar unter https://www.dev-insider.de/wasist-eine-software-paketverwaltung-a-847919/

Augsten, Stephan

Der Unterschied von Compiler und Interpreter, abrufbar unter https://www.dev-insider.de/der-unterschied-von-compiler-und-interpreter-a-742282/

Augsten, Stephan

Was ist ein Parser?, abrufbar unter https://www.dev-insider.de/was-ist-ein-parser-a-756662/

Augsten, Stephan

Was ist ein SDK?, abrufbar unter https://www.dev-insider.de/was-ist-ein-sdk-a-730921/

Baader, Hans-Joachim

Patrick McHardy: GPL-Durchsetzung zur persönlichen Bereicherung, abrufbar unter https://www.pro-linux.de/news/1/25090/patrick-mchardy-gpl-durchsetzung-zur-persoenlichen-bereicherung.html

Beckendorf, Ingo

USA: Oracle gewinnt gegen Google wegen Java-Copyright, MMR-Aktuell 2018, 405405

Chiusi, Tiziana/Martinek, Michael (Hrsg.)

J. von Staudingers Kommentar zum Bürgerlichen Gesetzbuch mit Einführungsgesetz und Nebengesetzen. Buch 2, Recht der Schuldverhältnisse, Schenkungsrecht, 15. Aufl. 2013 (zit. Bearbeiter, in: Staudinger, BGB, § Rn.)

Czychowski, Christian

Der „Urheberrechts-Troll“ – Wichtige Rechtsfragen von Open Source-Lizenzen?, GRUR-RR 2018, 1–5

Determann, Lothar

Softwarekombinationen unter der GPL, GRUR Int. 2006, 645–653.

Dietrich, Nils

ASP – öffentliche Zugänglichmachung oder unbenannte Nutzungsart?, ZUM 2010, 567–572

Dreier, Thomas/Schulze, Gernot (Hrsg.)

Urheberrechtsgesetz – Kommentar, 6. Aufl. 2018 (zit. Bearbeiter, in: Dreier/Schulze, UrhG, § Rn.)

Eckert, Hans-Werner (Redaktor)

Hans-Theodor Soergel, Bürgerliches Gesetzbuch mit Einführungsgesetz und Nebengesetzen, Band 7, Schuldrecht 5: §§ 481–534 BGB, 13. Aufl. 2014 (zit. Bearbeiter, in: Soergel, BGB, § Rn.)

Ellmer, Bernhard/Schaaf, Alexander/Lüchinger, Florian

Open Source-Software, 2013 (zit. Bearbeiter, in: Ellmer/Schaaf/Lüchinger, S.)

Fischer, Thomas (Hrsg.)

Strafgesetzbuch: StGB – Kommentar, 66. Aufl. 2019 (zit. Bearbeiter, in: Fischer, StGB, § Rn.)

Fitzner, Julia

CAFC: Urteil zur Durchsetzbarkeit von Open-Source-Lizenzen, MMR-Nachrichtenarchiv 12/2018, S. XV

Galetzka, Christian

Der strenge Copyleft-Effekt der GNU General Public License bei Interaktion von proprietärer Software mit Standard-CMS wie Joomla, Typo3 oder Wordpress, DSRITB 2015, 647–663

Galetzka, Christian/Otto, Sabrina

Darlegungslast bei Bearbeiterurheberrechten an Software – Anmerkung zu LG Hamburg, Urteil vom 8.7.2016 – 310 O 89/15, MMR 2016, 740, 742–743

Galetzka, Christian/Hackel, Florian

Darlegungslast bei Bearbeiterurheberrechten an Software – Anmerkung zu OLG Hamburg, Urteil vom 28.2.2019 – 5 U 146/16, MMR 2019, 452, 455–458

Galetzka, Christian/Stamer, Erik

Streaming – aktuelle Entwicklungen in Recht und Praxis, Redtube, kinox.to & Co., MMR 2014, 292–298

Grüner, Sebastian

Tesla beginnt Versuch der GPL-Einhaltung, Golem Newsticker v. 22.5.2018, abrufbar unter https://www.golem.de/news/linux-teslabeginnt-versuch-der-gpl-einhaltung-1805-134501.html

Herberger, Maximilian/Martinek, Michael/Rüßmann, Helmut/Weth, Stephan/Würdinger, Markus (Hrsg.)

juris Praxiskommentar BGB, Band 2 Schuldrecht, 9. Aufl. 2020 (zit. Bearbeiter, in: jurisPK-BGB, § Rn.)

Hildebrandt, Ulrich

Die Strafvorschriften des Urheberrechts (Schriften zum Strafrecht; SR 125), 2001 (zit. Hildebrandt, S.)

Hoeren, Thomas/Sieber, Ulrich/Holznagel, Bernd

Multimedia-Recht, Loseblatt, 54. Ergänzungslieferung, 2020 (zit. Bearbeiter, in: Hoeren/Sieber/Holznagel, Hdb. MultimediaR, Teil Rn.)

Hoeren, Thomas

Open Source und das Schenkungsrecht – eine durchdachte Liaison?, in: Bork, Reinhard u.a., Recht und Risiko, FS für Helmut Kollhosser, 2004, Band 2, S. 229–240

Institut für Rechtsfragen der Freien und Open Source Software – ifrOSS (Hrsg.)

Die GPL kommentiert und erklärt, abrufbar unter https://web.archive.org/web/20160303174211/www.ifross.org/ifross_html/Druckfassung/Die_GPL_kommentiert_und_erklaert.pdf, 2005 (zit. Bearbeiter, in: ifrOSS, Die GPL kommentiert und erklärt, Ziff. Rn.)

Jaeger, Till/Metzger, Axel

Open Source Software – Rechtliche Rahmenbedingungen der Freien Software, 5. Aufl. 2020 (zit. Jaeger/Metzger, Open Source Software, Rn.)

Jaeger, Till/Metzger, Axel

Die neue Version 3 der GNU General Public License, GRUR 2008, 130–137

Jani, Ole

Kein digitaler Flohmarkt – Der Erschöpfungsgrundsatz gilt nicht beim Online-Vertrieb urheberrechtlich geschützter Werke, K&R 2020, 101–103

Kilian, Wolfgang/Heussen, Benno (Hrsg.: Taeger, Jürgen/Pohle, Jan)

Computerrechts-Handbuch, 35. EL Juni 2020, 32.6 Open Source Software (zit. Bearbeiter, in: Computerrechts-Handbuch, 35. EL Juni 2020, 32.6 Open Source Software, Rn.)

Kreutzer, Till

Firmware, Urheberrecht und GPL – Zu den Folgen einer Verwendung von GPL-lizenzierten Open-Source-Software-Komponenten auf die Durchsetzung von Urheberrechten an Firmware, CR 2012, 146–152

Kumar, Sapna/Koglin, Olaf

GPL Version 3’s DRM and Patent Clauses under German and U. S. Law, CRi 2008, 33–38

Lagodny, Otto/Miesbach, Klaus (Band-Redakteure)

Münchener Kommentar zum StGB, Band 7, 3. Aufl. 2018 (zit. Bearbeiter, in: MüKo-StGB, § Rn.)

Lettl, Tobias

Urheberrecht, 3. Aufl. 2018 (zit. Lettl, Urheberrecht, § Rn.)

Lucas, Ina

Zur „Wirksamkeit“ technischer Maßnahmen gemäß § 95a UrhG nach Maßgabe der Richtlinie 2001/29/EG – zugleich eine Darstellung deutscher und finnischer Rechtsprechung, GRUR Int. 2017, 114–119

Mantz, Reto

Creative Commons-Lizenzen im Spiegel internationaler Gerichtsverfahren, MMR 2008, 20–24

Meeker, Heather J.

The Open Source Alternative – Understanding Risks and Leveraging Opportunities, New Jersey 2008 (zit. Meeker, The Open Source Alternative, S.)

Metzger, Axel/Jaeger, Till

Open Source Software und deutsches Urheberrecht, GRUR Int. 1999, 839–848

Möhring, Philipp/Nicolini, Käte (Hrsg. Ahlberg, Hartwig/Götting, Horst-Peter)

Urheberrecht, 4. Aufl. 2018 (zit. Bearbeiter, in: Möhring/Nicolini, UrhG, § Rn.)

Peukert, Alexander

USA: Ende der Expansion des Copyright, GRUR Int. 2002, 1012–1021

Raape, Leo

Die Beweislast bei positiver Vertragsverletzung, AcP 147 (1941), 217–289

Redeker, Helmut

IT-Recht, 7. Aufl. 2020 (zit. Redeker, IT-Recht, Rn.)

Schäfer, Fabian

Anmerkung zum Urteil des LG Berlin (GRUR-RR 2012, 107 – Surfsitter), K&R 2012, 127–129

Schönke, Adolf/Schröder, Horst (Hrsg.)

Strafgesetzbuch: StGB – Kommentar, 30. Aufl. 2019 (zit. Bearbeiter, in: Schönke/Schröder, StGB, § Rn.)

Schöttle, Hendrik

Wie umgehen mit der Umgehung von Open-Source-Lizenzpflichten – Von GPL-Kondomen und anderen Verhütungsmitteln, DSRITB 2019, 625–638

Schöttle, Hendrik

Nutzung von Open-Source-Software in Form von ASP/SaaS – kompatibel?, MMR 2020, 801–805

Schricker, Gerhard/Loewenheim, Ulrich (Hrsg.)

Urheberrecht – Kommentar, 6. Aufl. 2020 (zit. Bearbeiter, in: Schricker/Loewenheim, UrhG, § Rn.)

Schreibauer, Markus/Mantz, Reto

Anmerkung zum Urteil des LG Berlin (GRUR-RR 2012, 107 – Surfsitter), GRUR-RR 2012, 111–112.

Shuttleworth, Mark/Moglen, Eben

Automotive Software Governance and Copyleft, Online-Artikel v. 12.10.2018, abrufbar unter https://www.softwarefreedom.org/resources/2018/automotive-software-governance.pdf

Siebers, Bernd

Urheberrechte am Linux kernel – Anmerkung zu LG Köln, Urteil vom 20.10.2017 – 14 O 188/17, MMR 2018, 415–417

Spindler, Gerald (Hrsg.)

Rechtsfragen bei open source, Göttingen 2004 (zit. Bearbeiter, in: Spindler, Rechtsfragen bei open source, Kap. Rn.)

Spindler, Gerald/Schuster, Fabian (Hrsg.)

Recht der elektronischen Medien – Kommentar, 4. Aufl. 2019 (zit. Bearbeiter, in: Spindler/Schuster, § Rn.)

Spindler, Gerald

Grenzen des Softwareschutzes, Das Urteil des EuGH in Sachen SAS Institute, CR 2012, 417–422

Stallman, Richard

What is Free Software? – The Free Software Definition, abrufbar unter https://www.gnu.org/philosophy/free-sw.html.en

Stallman, Richard

Why „Free Software” is better than „Open Source”, abrufbar unter https://www.gnu.org/philosophy/free-software-for-freedom.de.html

Stallman, Richard

Why Open Source misses the point of Free Software, abrufbar unter https://www.gnu.org/philosophy/open-source-misses-the-point.de.html

Stallman, Richard

Why Upgrade to GPL Version 3, abrufbar unter https://www.gnu.org/licenses/rms-why-gplv3.html

Steinlechner, Peter

Linux-Abmahnungen verunsichern Elektronikbranche, Golem Newsticker v. 5.3.2018, abrufbar unter https://www.golem.de/news/lizenzbestimmungen-linux-abmahnungenverunsichern-elektronikbranche-1803-133139.html

Stiebert, Julius

Linus Torvalds hat die FSF satt, Golem Newsticker v. 28.9.2006, abrufbar unter https://www.golem.de/0609/48078.html

Stiebert, Julius

Video-Interview: „DRM ist unverschämt“, Golem Newsticker v. 5.6.2007, abrufbar unter https://www.golem.de/0706/52635.html

Strobel, Tobias

So content with Open Content – Zufriedenheit dank Open-Content-Lizenz?, MMR 2003, 778–782

Stürner, Rolf (Hrsg.)

Jauernig, Bürgerliches Gesetzbuch – Kommentar, 18. Aufl. 2021

Sujecki, Bartosz

Vertrags- und urheberrechtliche Aspekte von Open Source Software im deutschen Recht, JurPC Web-Dok. 145/2005, Abs. 1–52

Teupen, Christian

„Copyleft“ im deutschen Urheberrecht – Implikationen von Open Source Software (OSS) im Urhebergesetz, Berlin 2011 (zit. Teupen, S.)

Thiele, Wolfgang

Leistungsstörung und Schutzpflichtverletzung, JZ 1967, 649–657

Thoma, Jörg

Linux 4.14 rüstet sich gegen Copyright-Trolle, Golem Newsticker v. 13.11.2017, abrufbar unter https://www.golem.de/news/betriebssysteme-linux-4-14-ruestet-sich-gegen-copyrighttrolle-1711-131108.html

Torwalds, Linus

Dual-Licensing Linux kernel with GPL V2 and GPL V3, Mitt. v. 13.6.2007, abrufbar unter https://lkml.org/lkml/2007/6/13/289

Turner, David

The LGPL and Java, abrufbar unter https://www.gnu.org/licenses/lgpl-java.en.html

Ullenboom, Christian

Java ist auch eine Insel, Rheinwerk Openbook, abrufbar unter http://openbook.rheinwerk-verlag.de/javainsel (zit. Ullenboom, http://openbook.rheinwerk-verlag.de/javainsel, Kap.)

Van den Brande, Ywein/Coughlan, Shane/Jaeger, Till (Hrsg.)

The International Free and Open Source Software Law Book, 2. Aufl. 2014 (zit. Van den Brande/Coughlan/Jaeger, S.)

Villa, Luis

MPL 2.0, copyleft, and license compatibility, abrufbar unter https://opensource.com/law/11/9/mpl-20-copyleft-and-license-compatibility.

v. Welser, Marcus

Kampf um Linux: Ist die Freiheit der Open-Source-Software bedroht?, GRUR-Prax 2018, 164–166

Wagner, Kristina

Streaming aus der Sicht des Endnutzers – noch Graubereich oder bereits tiefschwarz?, GRUR 2016, 874–882

Wandtke, Artur-Axel/Bullinger, Winfried (Hrsg.)

Praxiskommentar zum Urheberrecht, 5. Aufl. 2019 (zit. Bearbeiter, in: Wandtke/Bullinger, UrhG, § Rn.)

Westermann, Harm-Peter (Band-Redakteur)

Münchener Kommentar zum BGB, Band 4, Schuldrecht – Besonderer Teil I, §§ 433 bis 534, 8. Aufl. 2019 (zit. Bearbeiter, in: MüKo-BGB, § Rn.)

Hinweis zu im Literaturverzeichnis und ansonsten in diesem Buch genannten Online-Fundstellen: In den Online-Fundstellen referenzierte URLs wurden zuletzt abgerufen am 12.3.2021.

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

1

Der technische Einsatz von Free and Open Source Software (FOSS) ist weit verbreitet, das gilt jedoch nicht im gleichen Umfang für die rechtliche Einhaltung der Lizenzvorgaben. Hier treffen zwei Welten aufeinander, die allen Beteuerungen zum Trotz lieber nebeneinander koexistieren möchten, als sich allzu weit zu überschneiden. Software-Entwickler möchten die langen Lizenztexte am liebsten auf eine einzeilige If-then-else-Formel reduzieren und Juristen wollen für die Lizenzbedingungen keine Software-Architektur analysieren.

2

Basic: Free and Open Source Software (FOSS) (siehe Rn. 63ff.)

Die wesentlichen Merkmale von FOSS sind, dass die Software von jedermann frei und ohne Zahlung von Lizenzgebühren verwendet werden kann, der Source Code der Software zugänglich ist und der Nutzer die Software selbst verändern und an Dritte weitergeben darf. Freeware, Shareware und auch Public Domain Software sind keine FOSS im klassischen Sinne; letztere kann jedoch nach denselben Maßstäben beurteilt werden.

FOSS Komponenten stehen regelmäßig unter klassischen FOSS Lizenzen, die von der FSF1 oder der OSI2 nach deren Kriterien anerkannt wurden (zu diesen Organisationen siehe Rn. 50ff.). Sie lassen sich meist der bei der Organisation SDPX verfügbaren Lizenzliste entnehmen.3 Wir verwenden in diesem Buch für alle FOSS Lizenzen als Bezeichnungen die in dieser Liste vorgesehenen SPDX Identifier, also die vereinheitlichten Kurzbezeichnungen. SPDX ist ein Projekt, das sich die einheitliche Bezeichnung und Übermittlung von FOSS nach einheitlichen Standards auf die Fahne geschrieben hat.4

3

Man kann sich damit begnügen, alle GPL-artigen Lizenzen auf eine rote Liste zu setzen und schlicht nach passenden Komponenten unter liberalen Lizenzen zu suchen. Dabei werden die Entwickler jedoch schnell feststellen, dass gerade die häufig benötigten, gewollten oder schlicht am besten geeigneten Komponenten unter „gefährlicheren“ Lizenzen stehen. Diese können häufig nur eingesetzt werden, wenn bei der Verwendung genaue technische Vorgaben eingehalten werden. Insofern ist es für eine vertiefte Auseinandersetzung unerlässlich, entsprechendes Technikwissen zu haben. Damit lässt sich ein Einsatz oft lizenzkonform gestalten, auch wenn die erste rechtliche Bewertung zunächst ein höheres Risiko ausgibt. Um solche Fälle zu beurteilen, braucht man technische und rechtliche Grundlagen, die ein wenig über das Allgemeinwissen hinausgehen.

4

Die Schnittstelle zwischen den Juristen und Entwicklern ist dabei oft die Sollbruchstelle. Fähige Entwickler können den Code für Lizenzkonformität anpassen, wenn sie wissen, welche Software-Architektur den Lizenzvorgaben gerecht wird. Gute Juristen können Lösungen für technisch nicht anders umsetzbare Architekturen finden, wenn sie die dahinter liegenden Code Mechanismen, beispielsweise zur Interaktion verschiedener Komponenten miteinander, verstanden haben. In den folgenden Kapiteln dieses Buches finden beide Parteien die entsprechenden Grundlagen aus dem rechtlichen und technischen Bereich praxisnah aufbereitet. Ziel ist, das Zusammenspiel von Technik und Recht zu optimieren und so den lizenzgerechten Einsatz von FOSS zu gestalten.

1

https://www.gnu.org/licenses/license-list.html.en.

2

https://opensource.org/licenses.

3

https://spdx.org/licenses/.

4

https://spdx.dev/.

1. Wie naiver Einsatz kostenloser Software Ihr Unternehmen bedrohen kann

5

– Die FOSS Idealisten wollten die Software-Entwicklung von den Beschränkungen des Urheberrechts befreien, knüpften die Freiheit aber an Bedingungen.

– Alternativlosigkeit von FOSS wird schnell behauptet, sollte aber kritisch hinterfragt werden.

– Vor- und Nachteile sollten bei einem Einsatz von FOSS gut abgewogen werden, insbesondere wenn es kommerziell lizenzierte Alternativen gibt.

– Neben Rufschäden drohen auch gerichtliche Verfahren bei FOSS Lizenzverletzungen.

6

Welche Motivation steckt hinter dem FOSS Konzept? Die urheber- und patentrechtlichen Beschränkungen von kommerzieller Software stellen sich als Hinderungsgrund für die kreative Entfaltung dar. Hätten nicht alle mehr davon, wenn jeder auf die bestehende Software aufsetzen könnte und dann seine eigenen Ergebnisse ebenfalls wieder im Source Code bereitstellt? Die Grundidee war einfach und altruistisch. Der Idealismus stößt jedoch an Grenzen, wenn sich zwar alle bedienen wollen, wichtige Fortentwicklungen dann jedoch unter kommerziellen Lizenzen verwertet wurden. So wurde die gegenseitige Freizügigkeit zur einklagbaren Bedingung.

a)Am Anfang stand die Idee: Freiheit von Copyrightzwängen

7

Der Entwickler Richard Stallman war einer der ersten, der die Idee von FOSS prägte. Zur Erläuterung verwies er darauf, dass das Konzept „frei“ i.S.v. Freiheiten, nicht i.S.v. nur kostenfrei bedeuten soll.

„To understand the concept, you should think of ‚free‘ as in ‚free speech‘, not as in ‚free beer‘.“

ist das wesentliche, von Stallman entwickelte Leitmotiv der FOSS Community.5 Mit verfügbarem Source Code könnten alle Entwickler an der Lösung aller Probleme und für alle benötigten Funktionen weltweit zusammenarbeiten, ohne dass jemand Wissen für sich behält.

aa) Wie sich FOSS verbreitet hat

8

Von diesem Ideal ist die heutige Realität jedoch deutlich entfernt. Der Gedanke, Geld für Software-Entwicklung auszugeben und die Ergebnisse dann an die Konkurrenz zu verschenken, erscheint in vielen Branchen noch immer einigermaßen abwegig. Hinzu kommt die Sorge vor der Aufdeckung von Sicherheitslücken, wenn Code offengelegt wird. Zwar wird viel FOSS eingesetzt, häufig aber eingebettet in kommerziellen Code.

9

Zur Jahrtausendwende war FOSS Software schon weit verbreitet, für manche seriösen Anwender aber gleichwohl anrüchig. Software-Anwender wollten einen Lizenzgeber haben, den sie in Haftung nehmen können, wenn etwas an der Software nicht funktioniert. Nur Freaks, die sich von Pizza und Cola ernährten, betrieben Linux Server zuhause, während seriöse Unternehmen mit viel Mühe Windows NT-Server am Laufen hielten. Die Entscheidung für FOSS Anwendungen war nicht alternativlos, erfolgte häufig aus einer bewussten Entscheidung zugunsten der Quelloffenheit und im Konsens mit dem Grundprinzip, dass man im Gegenzug zur kostenlosen Zurverfügungstellung der Software auch seine Bearbeitungen an die Community zurückspielen werde. In den folgenden Dekaden entstanden eine Kommerzialisierung von FOSS und eine Entkopplung von diesem altruistischen Grundverständnis.

10

Heutige Software-Entwickler beginnen ihren Beruf mit der Überzeugung, dass die Mehrheit aller Entwicklungsaufgaben unter Einbindung einer FOSS Komponente gelöst werden könne. Der Gedanke, auf FOSS zu verzichten und stattdessen alles von Hand zu programmieren, erscheint so absurd wie der Vorschlag an den Bäcker, sein eigenes Mehl zu mahlen. Während die Open Source Communities zwar gewachsen sind, wuchs aber auch der Anteil der kommerziellen Anwender, die unter keinen Umständen ihre eigenen Software-Quellen offen bereitstellen würden. Diese unterschiedlichen Einstellungen spielen eine Rolle bei der Auslegung der Lizenzen, wenn der Wortlaut nicht ausreicht und auf den mutmaßlichen Willen des Lizenzgebers abgestellt werden soll. Hier wird in beide Richtungen leidenschaftlich argumentiert, dass die FOSS Lizenz entweder jegliche kommerzielle Nutzung ohne unüberwindbare Hindernisse zulassen wollte oder anderseits der vollständige Support für einen Austausch gewährleistet sein muss.

bb) Wo FOSS verzichtbar ist und wo nicht

11

Software-Entwickler haben gelegentlich Mühe, ihren Inhouse-Juristen zu erklären, dass ein kompletter Verzicht von FOSS genauso wenig denkbar ist wie der Vorschlag, auf sämtliche Copyleft Lizenzen zu verzichten. Wer sich auf ein Linux Ökosystem eingelassen hat, kann den Einsatz von GPL nicht kategorisch ausschließen. Das einfache Modell, Lizenzen in Gut und Böse einzuteilen, hält dem Realitätscheck nicht lange stand. Wohl dem, der bei Entwicklung seiner Lizenzrichtlinien rechtzeitig mit seinen Entwicklern gesprochen hat.

12

Basic: Copyleft (siehe Rn. 225ff.)

Das ist das zentrale Prinzip des FOSS Ideals. Hat die Lizenz ein Copyleft, so muss ein von der FOSS Komponente „abgeleitetes Werk“ ebenfalls unter den Bedingungen der FOSS Lizenz verfügbar gemacht werden. Es gibt Lizenzen mit strengem Copyleft, die dieses Prinzip voll umsetzen, andere mit beschränktem Copyleft, die teils Ausnahmen vorsehen, sowie Lizenzen ohne Copyleft, die nur die Einhaltung anderer Bedingungen vorsehen. In der Regel wollen Unternehmen Copyleft vermeiden, um eigenen bzw. proprietären Code nicht im Source Code unter einer FOSS Lizenz freigeben zu müssen, damit sie die Lizenzvorgaben einhalten.

13

Auf der anderen Seite wird das Argument der technischen Notwendigkeit und Alternativlosigkeit viel zu häufig hingenommen. Wer sich dann im nächsten Schritt auch sagen lässt, dass die Einhaltung der theoretischen Bedingungen praktisch oder wirtschaftlich unmöglich ist, findet sich im Dilemma, zwischen Lizenzverstoß und Lästigkeit entscheiden zu müssen. Man solle doch pragmatisch sein, statt Probleme zu schaffen, wettert der CTO gegenüber der Rechtsabteilung und diese antwortet dann mit einer Strafbarkeitswarnung an den CEO. Diese Eskalation ist am Ende peinlich, wenn sich später herausstellt, dass eine legale Lösung nur aus Unfähigkeit übersehen wurde.

14

Zugegeben, an FOSS kommt man kaum vorbei, sobald ein Stromverbraucher mehr macht, als einen Wolfram-Draht zu erwärmen. Früher konnte man die typischen Einsatzfelder von FOSS noch mit Linux Servern beschreiben, während eingebettete Software häufiger individuell programmierte Software enthielt. Mit dem Internet der Dinge ist kaum noch eine Anwendung zu primitiv, um nicht mit FOSS umgesetzt zu werden. Eine Glühbirne kommt heute mit WLAN-Empfang auf FOSS Basis und synchronisiert das Programm mit Heizung, Kamera und Lautsprecher, ebenso das ferngesteuerte Sexspielzeug. Was kommuniziert, enthält vermutlich auch FOSS.

15

Kommerzielle Betriebssysteme wie iOS oder Windows enthalten bereits selbst FOSS und die dafür geschriebenen Anwendungsprogramme erst recht. Selbst die Steuerung einer Sieben-Segment-Anzeige wird gelegentlich mit FOSS realisiert. Wenn man FOSS freie Systeme sucht, müsste man daher schon auf die analoge Ebene des Operationsverstärkers zurückgehen – der enthält garantiert keine FOSS.

16

Es gibt jedoch auch leistungsfähige Realtime Betriebssysteme, die ohne Copyleft Lizenzen auskommen, dafür aber Lizenzgebühren kosten. Teilweise geben Rechtsinhaber die gleiche Anwendung unter FOSS Lizenz oder unter kommerzieller Lizenz heraus, so dass der Verzicht auf Copyleft Effekt gegen Gebühr gekauft werden kann. Bei vielen Libraries gibt es alternative Komponenten unter liberalen Lizenzen, was manchmal erst spät im Entwicklungsprozess bemerkt wird. Juristen sind daher gut beraten, bei behaupteter Alternativlosigkeit genauer hinzuschauen.

17

Basic: Begriffsklärung Software/Komponente/Produkt/Projekt/Library/File

Im Bereich FOSS werden viele Begriffe unterschiedlich eingesetzt. Wir verwenden als zentrale Bezeichnung FOSS Komponente für das einzelne urheberrechtlich geschützte Werk, das abgrenzbar für die Software-Entwicklung eingesetzt wird. Parallel werden auch die Begriffe FOSS, Produkt oder Projekt verwendet. Gerade die Internetauftritte von FOSS Komponenten werden häufig als Projekthomepages bezeichnet und bei entsprechender Community die Gemeinschaft/Komponente oft als Projekt. Ist die Komponente unselbstständig, wird sie häufig als Library bezeichnet (typisches Format ist eine .dll-Datei).

Eine FOSS Komponente besteht aus einer Vielzahl einzelner Files, die Zeilen von Header Informationen und Code beinhalten. Sie enthält ggf. weitere Komponenten oder Komponentenbestandteile, sogenannte Abhängigkeiten oder Dependencies. Teils sind diese nicht direkt in den Code einbezogen, sondern werden erst beim Kompilierungsvorgang, also der Umwandlung des Source Code in ein Kompilat, hinzugezogen.

Wir setzen den Begriff Produkt nicht für die einzelne Komponente ein, sondern wenn wir das Ergebnis der Zusammenstellung der Komponenten ggf. auch mit proprietärem Code bezeichnen wollen. Also ist damit quasi das Endergebnis der Programmiervorgänge gemeint. Alternativ wird das auch als Projekt bezeichnet. Projekt nutzen wir jedoch als Referenz für den gesamten Entwicklungsvorgang, insbesondere mit Bezug auf die Zeitschienen.

b)In welchen Fällen kostenlose Software teuer werden kann

18

FOSS gewinnt nicht nur Territorium in Wegwerf-Hardware, sondern auch in hochspezialisierten und hochpreisigen Steuergeräten für Maschinen oder Fahrzeuge. Ein Entscheidungsträger, der für die nächste Gerätegeneration einen Wechsel von vorwiegend proprietär lizenzierten Systemen zu FOSS beschließt, kennt die technischen Vorzüge und die ersparten Lizenzkosten sehr genau. Die rechtlichen Kosten treffen einige Hersteller aber trotzdem unvorbereitet und verdienen eine frühere Betrachtung.

19

Viele FOSS Entwickler verkennen zum Zeitpunkt der Systementscheidungen den Entwicklungsaufwand, der für eine lizenzkonforme Umsetzung erforderlich ist. Gerade bei der tiefen Einbindung von Copyleft Komponenten ist die Freigabe von eigenem Source Code manchmal nicht zu verhindern. Wer diese Software nicht freigeben will oder kann, weil sie ihm gar nicht selbst gehört, findet sich in einer Sackgasse und nimmt entweder Rechtsverletzungen in Kauf oder revidiert seine Software-Auswahl.

20

Wenn die gleiche Software unter Dual License gegen Lizenzgebühr oder unter Copyleft Lizenz angeboten wird, entfällt einerseits das Argument der Alternativlosigkeit, andererseits erhöht sich das Risiko der Rechtsverfolgung, da der Rechtsinhaber eher geneigt ist, Verletzungen der FOSS Variante zu verfolgen und Schadensersatz auf Grundlage der Lizenzanalogie einzufordern.

21

Auf der Seite der Schadenspotenziale sollte kalkuliert werden, welche Auswirkungen ein erfolgreich geltend gemachter Unterlassungsanspruch hätte. Ein solcher Anspruch sorgt bis zum Austausch der Software mindestens zu einem Auslieferungsstopp, u.U. auch zu einem Produktrückruf. Eine solche Rückrufpflicht ergibt sich für bereits veräußerte Gegenstände nicht automatisch aus dem Unterlassungsanspruch, mittelbar jedoch aus den Gewährleistungsansprüchen, wenn das nunmehr illegale Werk vom Käufer nicht mehr weitergegeben werden kann. Der Importeur einer Webcam mag dieses Risiko niedriger einschätzen als ein Automobilhersteller, dem die Stilllegung seiner Flotte droht. Im Business-to-Business-Bereich wiederum können Nachbesserungsaufwände im Rahmen von Wartungsverträgen zu verschmerzen sein.

22

Bei Umsetzung der künftig vorgeschriebenen Over-the-Air-Updates ergeben sich leichtere Korrekturmöglichkeiten für heilbare Lizenzverletzungen wie beispielsweise fehlende Pflichtangaben. Soweit jedoch die Lizenzkonformität nur durch Freigabe von eigenem Source Code erreicht werden kann, kann dies schon alleine daran scheitern, dass der Lizenzverletzer gar nicht über die notwendigen Rechte verfügt, um den entsprechenden Code unter einer FOSS Lizenz freizugeben.

23

Basic: Pflichtangaben und Source Code Freigabe (siehe Rn. 765ff.)

Die FOSS Lizenzen unterscheiden sich teils deutlich im Regelungsgehalt und Umfang der Regelungen, insbesondere bzgl. des Copyleft. So gut wie alle FOSS Lizenzen fordern jedoch für Verwertungshandlungen eine Auflistung von bestimmten Angaben, wir nennen sie Pflichtangaben. Es handelt sich meist um Copyright Hinweise, Lizenztexte und teils weitere Angaben wie z.B. Informationen zur Veränderung.

Copyleft Lizenzen fordern in der Regel die Mitlieferung oder dasAngebot der Mitlieferung des Source Code der FOSS Komponente unter der entsprechenden Lizenz, auch wenn das Copyleft für verbundene oder veränderte Software nicht greift. Greift Copyleft, muss entsprechend auch der veränderte oder verbundene Code bereitgestellt werden.

24

Wer selbst innerhalb einer Zulieferkette FOSS einsetzt, muss in seiner Kalkulation berücksichtigen, dass er für die Schäden seines Kunden haftet, soweit es ihm nicht gelingt, diese Haftungen vertraglich zuverlässig auszuschließen, worauf wir in diesem Buch noch eingehen werden. Natürlich sind die Zeiten vorbei, in denen Rechtsabteilungen apodiktisch jeglichen Einsatz von FOSS verboten haben. Andererseits verbietet sich der kritiklose ungeprüfte Einsatz.

c)Was schlimmstenfalls passieren kann

25

Die Rechtsabteilungen haben selbstverständlich im Blick, wie wahrscheinlich und groß die drohenden Schadensszenarien sind. Eines ist meist eindeutig klar: Eigener proprietärer Code soll nicht in großem Umfang unter einer FOSS Lizenz freigegeben werden. Die Vorgabe, Copyrightvermerke zusammen mit der jeweiligen Lizenz bei Weitergabe beizufügen, nehmen die Verwender meist schon deutlich weniger ernst. In der Praxis kommt häufig die Frage, ob das denn überhaupt jemand merkt und dann tatsächlich auch noch verfolgt.

aa) Häufiger Irrtum: Copyleft führt automatisch zur Freigabe als FOSS

26

Die Geschichte ist so dramatisch, dass sie in fast jedem FOSS Vortrag vorkommt. Sie ist trotzdem falsch. Es wird behauptet, dass die Auslösung des Copyleft Effekts dazu führt, dass die eigene Software – infiziert von einer winzigen Dosis Copyleft – auch zum Copyleft Zombie wird. Auf dieser Grundlage wird dann die Freigabe des kompletten kommerziellen Produkts gefordert, das entsprechend infiziert ist. Richtig ist, dass Werke, die von Copyleft lizenzierten Werken abgeleitet werden, ebenfalls unter Copyleft Lizenz gestellt werden müssen, um die Lizenzbedingung zu erfüllen (siehe hierzu Rn. 225ff.). Es gibt jedoch keinen Automatismus.

27

Der Rechtsinhaber hat die Wahl, die Copyleft Lizenz dadurch zu erfüllen, dass er seine eigene Software auch unter gleiche Lizenz stellt oder auf die Vorzüge der FOSS Lizenz, insbesondere auf das gewährte Nutzungsrecht zu verzichten. Das mag sich nach einem Dilemma anhören, da die Verletzung der Lizenz Rechtsnachteile bedeuten kann; es ist aber gleichwohl die Entscheidung des Rechtsinhabers, ob er die Freigabe seines Code und der FOSS Lizenz vornehmen will oder nicht. Dass kein Automatismus bestehen kann, ergibt sich schon alleine aus dem Umstand, dass der Verwerter möglicherweise gar nicht in der Lage ist, eine Lizenzierung unter einer FOSS Lizenz vorzunehmen. Wäre es anders, könnte man eine fremde kommerzielle Software mal eben mit GPL infizieren, so dass sie dann für jedermann frei nutzbar wäre.

28

Der Gedanke hält sich gleichwohl hartnäckig und liegt sogar der Entscheidung des LG Berlin im Fall AVM ./. Cybits (Surfsitter)6 zugrunde. Das an mehreren Stellen angreifbare Urteil (siehe ausführlich Rn. 605ff.) geht davon aus, dass der Hersteller der Fritzbox keine Unterlassungsansprüche gegen Cybits geltend machen darf, wenn das linux-basierte FritzOS verändert wird. Die Richter statuierten, dass mit Copyleft Effekt infizierte Software quasi „vogelfrei“ wird und der Rechtsinhaber seine Ansprüche aus dem Urheberrecht verlieren soll. Anders ausgedrückt sollen Sammelwerke, die aus FOSS bestehen, als Ganzes den Bedingungen der FOSS mit Copyleft Effekt unterliegen. Spätere Rechtsprechung hat diesen Fehler erkannt und auch unter dem Gesichtspunkt der Verwirkung und dem Unclean-Hands-Einwand Einwendungen gegen das Verwertungsrecht zurückgewiesen.7

29

Die Möglichkeiten für Lizenznehmer, wegen FOSS Verstößen Kostenfreiheit zu erlangen, sind etwas kleiner als angenommen. FOSS Lizenzen können nur die Instrumente des Urheberrechts einsetzen. Das Sanktionsarsenal beschränkt sich daher darauf, das kostenlos gewährte Nutzungsrecht an der FOSS entfallen zu lassen. Die Lizenz kann keine zusätzlichen Nutzungsrechte für jedermann an proprietärer Software erzeugen.

bb) Ungenutztes Schädigungspotenzial der Rechtsinhaber

30

Die „offene“ Verbreitung von FOSS bietet Vorteile, aber zugleich nicht zu unterschätzende Risiken, weniger für den Anwender als vielmehr für denjenigen, der FOSS für die eigene Entwicklung einsetzen und auch an Endkunden vertreiben will.

(1) Rechtlicher Fokus

31

Die Lizenzbedingungen der jeweiligen FOSS legen die urheberrechtlichen Rahmenbedingungen fest, unter denen der Entwickler der Software bzw. deren Rechtsinhaber anderen Nutzungsrechte an der FOSS einräumen will. Da die FOSS Lizenzbedingungen auf diese Weise die Ausübung des Urheberrechts konkretisieren, stellt jede Verletzung der Lizenzbedingungen eine Urheberrechtsverletzung dar, die urheberrechtliche Ansprüche der §§ 69f, 69a Abs. 4 i.V.m. §§ 97ff. UrhG auslöst, sofern die jeweiligen Anspruchsvoraussetzungen gegeben sind (siehe auch Rn. 499ff.).8

32

Automatischer Rechtsfortfall oder inhaltliche Beschränkung?

Die Geltendmachung von urheberrechtlichen Ansprüchen durch den Urheber wegen lizenzwidriger FOSS Nutzung hängt im Wesentlichen davon ab, ob das lizenzwidrige Verhalten zu einem Wegfall der durch die FOSS Lizenz eingeräumten Nutzungsrechte führt ober ob eine bloße Verletzung vertraglicher Pflichten vorliegt, was den Rechtsinhaber auf die bloße Durchsetzung von schuldrechtrechtlichen Ansprüchen gegen den Verletzer beschränken würde. Beispielsweise regelt die GPL-2.0 in Ziff. 4 einen automatischen Rechtsfortfall bei lizenzwidriger Nutzung, stellt aber lediglich eine vertragliche Regelung dar. Daher wird in der Literatur diskutiert, welche rechtlichen Folgen sich aus dieser Klausel ergeben.

Während einige Autoren von einer inhaltlichen Beschränkung der Nutzungsrechte i.S.d. § 31 Abs. 1 Satz 2 UrhG ausgehen,9 nimmt die h.M. eine auflösend bedingte Rechtseinräumung nach § 158 Abs. 2 BGB an.10 Im Ergebnis kann der GPL-2.0 nicht nur eine schuldrechtliche Verpflichtung zur Einhaltung der Lizenzbedingungen entnommen werden, so dass die h.M. zutreffend davon ausgeht, dass dem Lizenznehmer die Nutzungsrechte unter der auflösenden Bedingungen eingeräumt werden, dass dieser sich an die Lizenzbedingungen hält (siehe Rn. 152f.). Wird gegen die Pflichten verstoßen, fallen die Nutzungsrechte automatisch ex nunc weg und der Lizenznehmer begeht eine Urheberrechtsverletzung, wenn er die Software entgegen den Lizenzbedingungen vertreibt.11

(2) Realitätsfokus

33

Eine „Massenabmahnwelle“ der FOSS Entwickler ist bisher nicht losgebrochen, aber in Anbetracht des doch weitreichenden FOSS Einsatzes in Produkten aller Art künftig nicht per se ausgeschlossen. Die Konsequenzen aus der auch gerichtlichen Verfolgung der bei lizenzwidrigem FOSS Einsatz entstehenden Ansprüche können recht weitreichend sein. So ist u.U. der Rückruf ganzer Produktserien, in denen FOSS Komponenten ohne Einhaltung der Lizenzbedingungen implementiert sind, nicht undenkbar. Dies kann nicht zuletzt immense wirtschaftliche Schäden und Reputationsverluste für die in Anspruch genommenen Unternehmen nach sich ziehen.

34

Die entstehenden rechtlichen Risiken sind abhängig von der Strenge der jeweiligen FOSS Lizenz und von dem Pflichtenprogramm, das von den Lizenzbedingungen vorgeschriebenen ist und durch eine Weitergabe der jeweiligen FOSS z.B. in einem Endprodukt ausgelöst wird. Dies betrifft v.a. den Vertrieb der FOSS an Endkunden. Das rechtliche Risiko wird zusätzlich erhöht, wenn FOSS Komponenten mit proprietären Programmkomponenten z.B. verbunden im Rahmen von sogenannten Value added Produkten12 vertrieben werden. Handelt es sich bei der verbundenen oder auch nur bei Installation und Ausführung interagierenden FOSS um eine solche mit angeordnetem strengem Copyleft (wie z.B. bei der GPL-2.0 oder GPL-3.0 der Fall), so ist u.U. der Vertrieb nur gestattet, wenn alle Programme, die von der GPL Software abgeleitet sind, ebenfalls unter die GPL gestellt werden (siehe weiterführend Rn. 234ff.).

35

Die deutsche Rechtsprechung hat noch immer keinen gemeinsamen Nenner gefunden; v.a. zur Reichweite des Copyleft Effekts der GPL fehlen Entscheidungen, soweit ersichtlich, bisher völlig.13 Jedoch ist ein Großteil der Entscheidungen der letzten Jahre (siehe Rn. 36ff. und ausführlich Anhang Rn. 837.)14 zugunsten der Rechtsinhaber von FOSS ergangen, die von den jeweiligen Prozess-Kontrahenten ohne Beachtung der jeweiligen FOSS Lizenzbedingungen und damit urheberrechtswidrig eingesetzt worden ist. Die bisherigen FOSS Urteile schärfen daher den Fokus hinsichtlich der sich tatsächlich auch in der Praxis realisierenden Rechtsrisiken und fördern immer mehr das Bedürfnis von Unternehmen unterschiedlichster Wirtschaftszweige nach FOSS Compliance. Diese verfolgt das Ziel, einen kontrollierten Einsatz von FOSS und deren rechtskonformen Vertrieb v.a. in Verbindung mit Value added Produkten oder in eingebetteten Systemen zu ermöglichen.

d)Was bisher geschah...

36

In den letzten Jahren sind einige Vertreter aus der Open Source Community (siehe auch Rn. 48ff.) aufgetreten, die das Bild ergangener Gerichtsentscheidungen bzgl. der Verfolgung von Rechtsverstößen im FOSS Bereich geprägt haben. Außerdem wurden einige interessante Verfahren in Übersee im FOSS Bereich ausgetragen.

aa) Harald Welte: Pionier der deutschen FOSS Rechtsprechung

37

Allen voran und gleichsam als Initiator einiger richtungsweisender FOSS Urteile in Deutschland zu nennen ist Harald Welte, der Miturheber und -entwickler des Linux kernel. Welte betreibt unter der URL gpl-violations.org eine zentrale Informations- und Community-Webseite zu FOSS und katalogisiert dort zahlreiche Fälle, in denen die GPL (insbesondere die GPL-2.0) in der Praxis verletzt wurde. Ein Überblick der von ihm auch gerichtlich verfolgten FOSS Verletzungsfälle und weitere FOSS News findet sich ebenfalls auf der genannten Community-Webseite.15

38

Die Klärung von einigen wesentlichen Grundsatzfragen im FOSS Bereich für das deutsche (Urheber-)Recht vor den deutschen Gerichten geht auf von Welte angestrengte gerichtliche Verfahren zurück.

39

Die wesentlichen Grundsatzfragen:

– FOSS Lizenzbedingungen als AGB (siehe Rn. 141ff.);

– Wirksamkeit von FOSS Lizenzbedingungen in Deutschland (siehe Rn. 149ff.);

– Rechtsfortfallklausel gem. Ziff. 4 GPL-2.0 als auflösend bedingte Rechtseinräumung (siehe Rn. 150ff.);

– Verstoß gegen FOSS Lizenzbedingungen als Urheberrechtsverstoß, der Ansprüche nach den §§ 97ff. UrhG auslöst.

bb) Patrick McHardy: Kommerzialisierung der Rechtsverfolgung

40

Jedenfalls von der Open Source Community eher kritisch betrachtet wird die Rechtsverfolgung von Patrick McHardy, der u.a. auch Verfahren vor den deutschen Gerichten mit gleichwohl bisher mäßigem Erfolg angestrengt hat.16

41

Bereits seit 2013 geht McHardy im größeren Stil zunächst außergerichtlich gegen angebliche Urheberrechtsverletzungen der GPL-2.0 mit der Behauptung vor, er sei Miturheber bzw. Bearbeiterurheber des Linux kernel, und Unternehmen, die Linux beispielsweise im Zusammenhang mit von ihnen vertriebener Hardware nutzen, hätten die FOSS Lizenzbedingungen bzgl. der von McHardy zumindest mitentwickelten Linux Komponenten urheberrechtswidrig nicht eingehalten. Im Wege anwaltlicher Abmahnungen werden vor allem urheberrechtliche Ansprüche auf Unterlassung und Erstattung von Abmahnkosten geltend gemacht.

42

In den Fällen, die wir bisher gesehen haben, wirkte McHardy darauf hin, auf Abmahnungen möglichst weit gefasste Unterlassungserklärungen zu erhalten, und beobachtete sodann die weitere Betätigung der abgemahnten mittelständischen Unternehmen am Markt. In einem nächsten Schritt wurde ein Verstoß gegen abgegebene Unterlassungserklärungen und damit eine Vertragsstrafe geltend gemacht. Ähnliche Berichte gibt es von weiteren Fällen, wobei viele Auseinandersetzungen nicht in gerichtlichen Klageverfahren mündeten, sondern in außergerichtlichen Vergleichen endeten, deren Vergleichssummen McHardy zuflossen.17

43

Das Vorgehen von McHardy gerade im größeren Stil18 ist zumindest in Deutschland ein Novum im FOSS Bereich und rief erhebliche Kritik in der Open Source Community hervor. Der im Grunde nicht Community konforme Alleingang McHardys führte daher bereits im Sommer 2016 zu dessen Ausschluss aus dem sog. Core Team des Linux kernel für den Bereich Netfilter.19

cc) Schlaglichter FOSS relevanter Verfahren im Ausland

44

Auch ein kurzer Blick auf FOSS Verfahren im Ausland soll an dieser Stelle nicht fehlen. Zu den relevanten Auseinandersetzungen in den USA20 gehören die von der Software Freedom Conservancy21 angestoßenen Gerichtsverfahren insbesondere im Zusammenhang mit der Rechtsverfolgung von Verstößen gegen die GPL Lizenzbedingungen rund um BusyBox (siehe auch Rn. 62). Bei dem Verfahren BusyBox v. Westinghouse ging es im Jahr 2010 um die erste Rechtsdurchsetzung der GPL-2.0 in einem gerichtlichen Verfahren vor dem United States District Court, Southern District of New York, das zu einer Verurteilung der Beklagten zu Schadensersatz nach dem U. S. Copyright Act wegen Nichteinhaltung der Lizenzbestimmungen führte.22 Weitere Verfahren mit FOSS Bezug wurden vor U.S.-Gerichten u.a. in den Rechtssachen Jacobsen v. Katzer23, XimpleWare v. Versata24 sowie Artifex v. Hancom25 geführt. In allen Verfahren ging es thematisch um die Verletzung von FOSS Lizenzen durch Bestandteile der in den Verfahren streitgegenständlichen Software-Produkte. Das Verfahren Jacobsen v. Katzer ist insofern hervorzuheben, als es sich um das erste Verfahren handelte, in dem ein U. S.-Gericht zur Wirksamkeit von FOSS Lizenzbedingungen (im Verfahren: Artistic-1.026) entscheiden musste und deren Wirksamkeit bestätigte.27

45

Ein weiteres Verfahren mit insbes. vertragsrechtlichen Bezügen zu FOSS wurde vor dem französischem Cour d’appel de Paris in der Rechtssache AFPA/Edu4 ausgetragen.28 Neben der Bestätigung der Wirksamkeit der GPL-2.0 im Verhältnis zwischen Unternehmen hat die französische Entscheidung insofern Gewicht, als sie einen direkten Anspruch auf Herausgabe des Source Code und weiterer Informationen ausurteilte. Der Anspruch wurde dem Erwerber einer unter GPL lizenzierten Software gegen den Distributor der Software zugesprochen (siehe hierzu auch Rn. 162),29 dieser basierte aber, soweit aus den Gründen des Urteils ersichtlich, auf Ansprüchen aus dem zwischen AFPA und Edu4 bestehenden Vertragsverhältnissen, nicht aus unmittelbarer Anwendbarkeit der GPL-2.0.

46

Streng genommen keine FOSS Verfahren, aber dennoch besondere Schlaglichter von Software-Prozessen in den USA sind die vor U. S.-Gerichten ausgetragenen Verfahren zwischen Oracle und Google.30 Zentraler Vorwurf von Oracle an Google war die Verletzung von Patenten und Urheberrechten wegen der Verwendung der Programmiersprache Java in Googles Betriebssystem Android. Die gerichtlichen Bemühungen von Oracle reichen bis in das Jahr 2010 zurück und mündeten in mehreren Gerichtsverfahren ganz unterschiedlichen Ausgangs. Zuletzt wurde Google die Verwendung der Programmiersprache Java in seinem Betriebssystem unter dem Gesichtspunkt des Fair Use abgesprochen, was in die Geltendmachung von Schadensersatzforderungen in Milliardenhöhe durch Oracle mündete.31

47

FOSS in Java und Android

Interessanter Randaspekt ist, dass das von Oracle vertriebene Open-JDK als wesentlicher Teil des Oracle Programmpakets Java unter GPL-2.0 mit Classpath Exception32 lizenziert ist33 und insofern FOSS Relevanz hat. Außerdem ist das Google Betriebssystem Android vollständig quelloffen, was die notwendigen Recherchen für die patent- und urheberrechtliche Inanspruchnahme von Google durch Oracle sicherlich erleichtert haben dürfte. Software-Komponenten des Android Open Source Project (AOSP) sind überwiegend unter Apache-2.0 lizenziert; der ebenfalls im Projekt enthaltene Linux kernel bekanntlich unter GPL-2.0 mit teilweisen Exceptions.34 Die FOSS Komponenten von Java und von Android waren (soweit ersichtlich) in den U. S.-Verfahren allerdings nicht streitgegenständlich.

e)Das Who’s Who der Open Source Community

48

Hört oder liest man von FOSS, ist immer wieder die Rede von einer Community. Diese Community entwickelt gemeinschaftlich Software, nimmt dankbar Änderungen entgegen, entscheidet über Lizenzverstöße und Rechtsverfolgungen. Man könnte sich diese Community als supranationale, allwissende und übermächtige Instanz vorstellen, die zentral in der Blockchain lebt und am Ende von einer künstlichen Intelligenz gesteuert wird. Grund genug, dass wir diese ominöse FOSS Community genauer betrachten, wenigstens dort, wo sie durch Organisationen zutage tritt.

49

Da es eine Vielzahl von Organisationen mit sehr unterschiedlichen Ausrichtungen gibt, macht es Sinn, ihre Motive zu erforschen, um ihre Position besser einordnen zu können. Einfach wäre es natürlich, man könnte die Organisationen antagonistisch in Rechtsinhaber und potenzielle Rechtsverletzer aufteilen, allerdings kommen wir damit nicht weit, da jeder Software-Entwickler und Produkthersteller sowohl Täter als auch Verletzter einer Lizenzverletzung sein kann. Entsprechend sind die Organisationen inzwischen oft mit unterschiedlichen Interessenvertretern unterwandert. Einfacher ist die Zuordnung bei reinen Industrieverbänden, die sich beispielsweise zusammengeschlossen haben, um die Verwertung von FOSS in ihren häufig proprietären Projekten und Produkten zu vereinfachen.

aa) Free Software Foundation (FSF)

50

Zu den älteren, man könnte schon fast sagen traditionellen, Organisationen gehören jene, die schon im letzten Jahrtausend Lizenzen und Software herausgegeben haben, wie etwa die Free Software Foundation (FSF)35 als Urheber und Herausgeber der GNU GPL Lizenzfamilie. Die Aktivisten der FSF haben mit dem Copyleft Effekt in der GPL die vorherige Gratiskultur eingeschränkt. Das originelle Wortspiel Copyleft als Ergänzung oder Widerspruch zum Copyright wird dem FSF-Gründer Richard Stallman zugeschrieben. Aus seiner Tastatur sollen auch Äußerungen zur Reichweite der GPL Verpflichtungen stammen, wonach GPL betriebene Geräte ohne Display den Lizenztext vorlesen sollen und dass der Copyleft Effekt schon dann eintrete, wenn man an Linux beim Programmieren gedacht habe.

51

Die Position zur Interpretation der GPL von der FSF sollte man ernst nehmen, allerdings steht sie gelegentlich auch in Widerspruch zu nationalem Recht. Gerade wenn es um Lizenzkompatibilität und Copyleft Effekt geht, vertritt die FSF häufig die strengste anzunehmende, also panische Auslegungsart (siehe Rn. 490) Man könnte aber konstruktiv konzedieren, dass derjenige, der sich an die Vorgaben der FSF hält, und seine Software-Architektur entsprechend einschränkt, weitgehend auf rechtlich sicherer Seite operiert. Man muss dann aber auch in Konsequenz hinnehmen, dass man die beliebte OpenSSL Library mangels Lizenzkompatibilität nicht mehr auf GPL-2.0 Linux Systemen einsetzen kann.

52

Interessant sind die Äußerungen der FSF dort, wo Widersprüche im eigenen Lizenzwerk angesprochen werden, etwa bei der Wirkungsweise der GPL Exceptions, die nach ihrem Wortlaut geeignet sind, Zweck und Inhalt der Grundlizenz komplett auszuhebeln. Hier verweisen Organisationen und sogar Lizenztexte auf den INAL Disclaimer (I’m not a Laywer). Die Antwort auf die Frage ist natürlich wenig befriedigend, wenn man selbst Anwalt auf Suche nach Erleuchtung ist.

bb) Open Source Initiative (OSI)

53

Die Open Source Initiative (OSI)36 leistet einen wichtigen Dienst, indem sie FOSS Lizenzen nach einer allgemein anerkannten Definition zertifiziert. OSI