Das Copyleft-Prinzip – Inhalt und Auswirkung auf die ... · Der Ausgangspunkt: das „Copyleft“...
23
Das Copyleft-Prinzip – Inhalt und Auswirkung auf die Lizenzierung von Software DGRI Fachausschuss für Vertragsrecht, München, 25. November 2011 Dr. Till Jaeger Fachanwalt für Urheber- und Medienrecht www.jbb.de
Transcript of Das Copyleft-Prinzip – Inhalt und Auswirkung auf die ... · Der Ausgangspunkt: das „Copyleft“...
Das Copyleft-Prinzip – Inhalt und Auswirkung auf die Lizenzierung von Software
DGRI Fachausschuss für Vertragsrecht, München, 25. November 2011
Dr. Till Jaeger
Fachanwalt für Urheber- und Medienrecht
www.jbb.de
● Der Ausgangspunkt: das „Copyleft“
● Reichweite des Copyleft
● Kompatibilität von Open Source Lizenzen
● Freigabe von Eigenentwicklungen
www.jbb.de
Agenda
● “Copyleft”: Die Pflicht, Weiterentwicklungen unter der Ursprungslizenz freizugeben (meist nur bei der Weitergabe der Software)
● Beispiel GPLv2:
“You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.“
● Ziel: Perpetuierung der freien Nutzbarkeit einer Software für jedermann
● „Viraler Effekt“ - kein Lizenzautomatismus, sondern Wahlmöglichkeit im
Verletzungsfall: Freigabe eigenen Codes oder Änderung des Produktes
www.jbb.de
Der Ausgangspunkt – das „Copyleft“
● Copyleft-Lizenzen
- GNU General Public License (GPL) – Versionen 2 und 3
- GNU Lesser General Public License (LGPL)
- Eclipse Public License (EPL)
● Non-Copyleft-Lizenzen
- BSD-License
- Apache License
www.jbb.de
Der Ausgangspunkt – das „Copyleft“
● Bedeutung für:
- Lizenzierung von Eigenentwicklungen
- Kompatibilität mit anderen OSS-Komponenten
● Aktuell noch keine Urteile oder Rechtsstreitigkeiten zur Auslegung der GPL oder zu dem, was als Bearbeitung einer Software anzusehen ist
● Zumeist urheberrechtliche Frage: Wie sind Bearbeitungen zu lizenzieren?
● Sammelwerke und verbundene Werke?
www.jbb.de
Der Ausgangspunkt – das „Copyleft“
● Ausgangspunkt: Computerprogrammrichtlinie von 1991
● Art. 6 RL setzt Kombinierbarkeit von Programmen voraus
● „interoperability of an independently created computer program with other
programs“
● Eg 12: „interoperability can be defined as the ability to exchange information
and mutually to use the information which has been exchanged“
www.jbb.de
Der Bearbeitungsbegriff im Softwareurheberrecht
● Kommunikation über Schnittstellen führt im Regelfall zu keiner Bearbeitung
bzw. „derivative work“
● Problemfälle:
- Ausgliederung einer Programmänderung in ein „eigenes Programm“
- Änderungen auf beiden Seiten einer Schnittstelle, die über das zur
Nutzung der Schnittstelle Erfoderliche hinausgehen
- Verlinkungen/Bibliotheken
www.jbb.de
Der Bearbeitungsbegriff im Softwareurheberrecht
● Copyleft der GPLv2
● Ziffer 2, Abs.2 GPLv2:
“If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.”
● GPLv2 geht offnbar über gesetzlichen Bearbeitungsbegriff hinaus
www.jbb.de
Reichweite des „Copyleft“
● Auslegung gem. Ziffer 2: inhaltliche und formale Bewertungskriterien
● Voraussetzungen für unabhängige Module:
- abgrenzbarer, funktional eigenständiger Softwarebestandteil (inhaltliches Erfordernis)
- Vertrieb in getrennten Dateien (formales Erfordernis)
● Technische Verbindung nur Indiz
www.jbb.de
Reichweite des „Copyleft“
● GPLv2: Auslegung gem. Ziffer 2
- Einfügen von Sourcecode-Bestandteilen in bestehenden Code – Copyleft-Effekt greift
● Bloße Systemaufrufe an den Linux-Kernel – kein Copyleft-Effekt, Präambel von Linus Torvalds:
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".
- Bei Userlandprogrammen in der Regel kein Copyleft
● Ziffer 2, Abs. 4 GPL: „mere aggregetion“, also Speicherung auf einem Datenträger löst kein Copyleft aus
www.jbb.de
Reichweite des „Copyleft“
● GPLv2: Auslegung gem. Ziffer 2 (Technik nur Indiz für rechtliche Einordnung!)
- Kommunikation über klassische Schnittstellen (Pipes, Sockets) – regelmäßig kein Copyleft
- Header Files mit Inline-Code – umstritten, abhängig von Art und Umfang des Inline-Codes
- Verwendung von Tools, wenn kein Code einkopiert wird – regelmäßig kein Copyleft
- Verwendung von Tools, wenn Code einkopiert wird (Bison, gcc) – regelmäßig Copyleft, aber meist Ausnahmeregelungen
www.jbb.de
Reichweite des „Copyleft“
● GPLv2: Auslegung gem. Ziffer 2
- Fraglich: Kernelmodule, Plugins, Programmbibliotheken (v.a. dynamisch verlinkt)
- Kernelmodule für aktuelle Kernelversion – Copyleft anzunehmen wg enger Verbindung zum Kernel (Binary only modules allenfalls geduldet)
- Bei Programmbibliotheken zu differenzieren: statische Verlinkung führt zu Copyleft, dynamische nach Einzelfall zu prüfen (Problem: Entwickler-community und FSF gehen davon aus, dass bei Verlinkung immer „derivative work“ entsteht)
- Plugins: abhängig von konkreter Technik, meist mit dynamischem Linken vergleichbar
www.jbb.de
Reichweite des „Copyleft“
● GPLv3: bei jeder Bearbeitung i.S.d. UrheberR
● LGPLv2.1:
- bei Änderungen der Bibliothek selbst
- nicht: das auf die Bibliothek zugreifende Programm
- aber: Erlaubnis zum Reengineering, Mechanismus, der Änderung der Bibliothek ermöglicht
● LGPLv3: wie LGPLv2.1
www.jbb.de
Reichweite des „Copyleft“
● Eclipse Public License (EPL):
„Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program.“
● Vom Wortlaut her so streng wie GPL,aber andere Auslegung
● Eclipse Plugins
„For clarity, merely interfacing or interoperating with Eclipse plug-in APIs (without modification) does not make an Eclipse plug-in a derivative work, http://www.eclipse.org/legal/eplfaq.php#EXAMPLE”
www.jbb.de
Reichweite des „Copyleft“
● Relevant für die Frage, ob Open Source-Komponenten unter verschieden-
en Lizenzen zu einem gemeinsamen Werk verbunden werden dürfen
● Gestattet Lizenz der einen Komponente die Lizenzierung unter der Lizenz
einer anderen Komponente?
● Enthält die Lizenz der einen Komponente Lizenzpflichten, die die Copyleft-
Lizenz der anderen Komponente nicht besitzt? (vgl. auch „no further
restriction“-Klausel in Ziffer 6 GPLv2)
www.jbb.de
Lizenzkompatibilität
● Prüfung:
- Sind zwei oder mehr Komponenten voneinander abgeleitet (i.S.d.
betroffenen OSS-Lizenzen)
- Sind mehrere Copyleft-Lizenzen betroffen?
- Ja: Kompatibilitätsklausel?
- Nein: Enthält die Non-Copyleft-Lizenz Pflichten, die die Copyleft-Lizenz
nicht zulässt?
www.jbb.de
Lizenzkompatibilität
● Kein Einsatz von Copyleft-Lizenzen – keine Kompatibilitätsprüfung
● Kompatibilitätsklauseln:
„Wenn der Lizenznehmer Bearbeitungen, die auf dem Originalwerk und einem
anderen Werk, das unter einer kompatiblen Lizenz lizenziert wurde, basieren, oder
die Kopien dieser Bearbeitungen verbreitet oder zugänglich macht, kann dies unter
den Bedingungen dieser kompatiblen Lizenz erfolgen. Unter „kompatibler Lizenz“ ist
eine im Anhang dieser Lizenz angeführte Lizenz zu verstehen. Sollten die
Verpflichtungen des Lizenznehmers aus der kompatiblen Lizenz mit denjenigen aus
der vorliegenden Lizenz (EUPL) in Konflikt stehen, werden die Verpflichtungen aus
der kompatiblen Lizenz Vorrang haben.“
www.jbb.de
Lizenzkompatibilität
● Inkompatibilität zwischen GPLv2 und Apache License 2.0
● Ziffer 9 Apache License 2.0 zur Freistellung von Lizenzgebern
● Unterschiedliche Auffassungen zwischen FSF und Apache Foundation
● Lösung in der Ziffer 7 f) GPLv3
www.jbb.de
Lizenzkompatibilität
● Copyleft greift regelmäßig nur bei Vertrieb der Software ein – ein
private/interne Bearbeitung muss nicht freigegeben werden
● Wann liegt eine interne Nutzung vor?
- Weitergabe zwischen Entwicklungsabteilungen?
- Konzerninterne Weitergabe?
- Bearbeitung durch Dienstleister?
- Vorstellung der Software beim Kunden oder auf einer Messe?
● Umgehung durch Vertrieb von Diffs vermutlich nicht möglich
www.jbb.de
Freigabe von Eigenentwicklungen
● Strategie bei der Freigabe von Eigenentwicklungen
● Mögliche Vorteile einer Freigabe:
- Externe Unterstützung der Weiterentwicklung (v.a. Softwareinfrastruktur)
- Reduzierung Pflegeaufwand für neue Versionen (z.B. Kernelpatches)
● Mögliche Nachteile einer Freigabe:
- Einsicht von Konkurrenten, Aufgabe Wettbewerbsvorteil
● Abwägung im konkreten Fall
www.jbb.de
Freigabe von Eigenentwicklungen
● ifrOSS: www.ifross.org (Kommentierung zu Ziffer 2 GPLv2)
● Free Software Foundation: www.fsf.org
● Lizenzkompatibilität: www.gnu.org/licenses/license-list.html#
SoftwareLicenses
● T. Jaeger, Kommerzielle Applikationen für Open Source Software und
deutsches Urheberrecht, in: Hoffmann, Mathis/ Leible, Stefan (Hrsg.),
Vernetztes Rechnen - Softwarepatente - Web 2.0, Stuttgart 2008, Boorberg
Verlag, S. 61
www.jbb.de
Weitergehende Informationen
● ifrOSS: www.ifross.org (Kommentierung zu Ziffer 2 GPLv2)
● Free Software Foundation: www.fsf.org
● Lizenzkompatibilität: www.gnu.org/licenses/license-list.html#
SoftwareLicenses
● T. Jaeger, Kommerzielle Applikationen für Open Source Software und
deutsches Urheberrecht, in: Hoffmann, Mathis/ Leible, Stefan (Hrsg.),
Vernetztes Rechnen - Softwarepatente - Web 2.0, Stuttgart 2008, Boorberg
Verlag, S. 61
www.jbb.de
Weitergehende Informationen
JBB Rechtsanwälte
Dr. Till Jaeger
Christinenstraße 18/19
10119 Berlin
www.jbb.de
www.jbb.de
Herzlichen Dank für Ihre Aufmerksamkeit!
