Download - Open Source Lizenzmanagement
Open Source Lizenzmanagement- Vortrag bei den Kölner Tagen Informationsrecht am 11.3.2010
Rechtsanwalt Dr. Till Kreutzer, i.e. - Büro für informationsrechtliche Expertise und Institut für Rechtsfragen der Freien und Open Source Software (ifrOSS)
http://creativecommons.org/licenses/by-nc-nd/3.0/de/
Seite 2
Till Kreutzer, i.e. Seite 2
1
4 Open Source Lizenztypologie
Einführung: Open Source Compliance in Softwareprojekten
AGENDA
2 Grundlagen Open Source Software und Recht
3 Lizenzkompatibilität als Kernproblem des Open Source Lizenzmanagements
5 Lizenzkompatibilität bei verschiedenen Lizenztypen
6 Praxistipps für das Open Source Lizenzmanagement
Seite 3Till Kreutzer, i.e. Seite 3
Einführung: Open Source Compliance in Softwareprojekten
Nutzen von Open Source
Open Source Software hat viele Vorteile
Nicht nur für (End-)Anwender, sondern auch und v. a. für Entwickler und Softwareunternehmen
Seite 4Till Kreutzer, i.e. Seite 4
Einführung: Open Source Compliance in Softwareprojekten
Nutzen von Open Source
Open Source Software als ideale Basis/Ergänzung von Eigenentwicklungen: OSS ist häufig sehr ausgereift OSS ist frei verfügbar OSS steht im Sourcecode bereit – kein „Vendor-Lock-In“, da Weiterentwicklung, Support,
Customizing unabhängig von einem best. Hersteller OSS darf ohne Lizenzgebühren genutzt und in Eigenentwicklung implementiert werden –
spart Zeit und Kosten Open-Source-Lizenzen verschaffen weit gehende Nutzungsfreiheiten (Vervielfältigungs-,
Anpassungs- und Weiterentwicklungsrechte, Online-Rechte usw.)
Seite 5Till Kreutzer, i.e. Seite 5
Einführung: Open Source Compliance in Softwareprojekten
Open Source Einsatz in kommerziellen Softwareprodukten
Verwendung von OSS in kommerziellen Softwareprodukten ist heute weit verbreitet und üblich
Beispiele: Einbindung in Firmware von Endgeräten (z. B. embedded) Verwendung von (zumeist Java-)Bibliotheken in Frameworks u. a. Unterschiedlichste Ergänzungen kommerzieller Applikationen
Seite 6Till Kreutzer, i.e. Seite 6
Einführung: Open Source Compliance in Softwareprojekten
Open Source Compliance
Problemstellung: Soll eine Eigenentwicklung mit OS-Bestandteilen kombiniert und zusammen vertrieben werden, sind Lizenzpflichten für alle im Produkt verwendeten OS-Komponenten zu beachten!
Komponenten werden meist unter unterschiedlichen Lizenzen stehen
Nicht alle Softwarekombinationen sind zulässig, nicht jede Kombination lässt die freie Wahl bei der Lizenzierung des Gesamtprodukts (Copyleft, Problem der Lizenzinkompatibilität)
Seite 7Till Kreutzer, i.e. Seite 7
Einführung: Open Source Compliance in Softwareprojekten
Open Source Compliance
Aspekt der Open-Source-Compliance sollte gerade bei komplexen Softwareprojekten, bei denen eine Vielzahl Fremdkomponenten verwendet werden, von vornherein bedacht werden
Nachträgliche Aufarbeitung, Prüfung und Auflösung von Lizenzinkompatibilitäten ist meist sehr zeitaufwändig, mitunter unmöglich
Open Source Compliance Management bedarf sorgfältiger Dokumentation und Kenntnissen von zumindest bestimmten Grundregeln
Seite 8
Till Kreutzer, i.e. Seite 8
1
4 Open Source Lizenztypologie
Einführung: Open Source Compliance in Softwareprojekten
AGENDA
2 Grundlagen Open Source Software und Recht
3 Lizenzkompatibilität als Kernproblem des Open Source Lizenzmanagements
5 Lizenzkompatibilität bei verschiedenen Lizenztypen
6 Praxistipps für das Open Source Lizenzmanagement
Till Kreutzer, i.e.
Seite 9Till Kreutzer, i.e. Seite 9
Grundlagen OSS und Recht
Rechtliche Funktionsweise des Open Source Modells
Open Source Software ist nicht frei von Urheberrechten!
Lizenz ≠ Verzicht auf Rechte
Einfaches Nutzungsrecht an jedermann (Vertriebs- und Entwicklungsrechte)
Seite 10Till Kreutzer, i.e. Seite 10
Grundlagen OSS und Recht
Rechtliche Funktionsweise des Open Source Modells
Rechte werden lizenzgebührenfrei eingeräumt
Das heißt nicht, dass mit Open Source Software kein Geld verdient werden darf!
Alternative Geschäftsmodelle für Gewinnerzielung, z.B. Software-Support, Materialien (Handbücher), Verkauf von Datenträgern, Customizing, Dual Licensing (Bsp: MySQL, Open Office - Star Office) – ohne weiteres zulässig
Seite 11Till Kreutzer, i.e. Seite 11
Grundlagen OSS und Recht
Rechtliche Funktionsweise des Open Source Modells
Lizenzen sind rechtlich wirksam, Einbeziehung als AGB möglich
Bei Lizenzverletzung automatischer Rechtsverlust (jedenfalls bei Copyleft-Lizenzen, etwa GPL, MPL, CPL). Folge: Nutzer wird zum Urheberrechtsverletzer und kann rechtlich (nicht nur wegen Vertragsverletzung) belangt werden
Seite 12Till Kreutzer, i.e. Seite 12
Grundlagen OSS und Recht
Zustandekommen der Lizenz und Entstehung von Rechten und Pflichten
Durch Vornahme lizenzpflichtiger Nutzungen kommt automatisch ein verbindlicher Lizenzvertrag zwischen Rechteinhabern und Nutzer zustande
Rein private/interne Nutzung ≠ Verbreitung ≠ öffentliche Zugänglichmachung Ob lizenzpflichtige Nutzung vorliegt, muss durch Auslegung ermittelt werden:
Bei US-Lizenzen (das sind fast alle) Orientierung am US Copyright Act (z. B. Definition der publication in Art. 101 CA oder distribution in Art. 106 CA)
Hiernach: Keine Lizenzpflichten bei Weitergaben oder Intranetnutzungen innerhalb eines einzelnen Unternehmens oder einer Behörde
Anders bei Überlassung an andere Rechtsträger, z. B. Weitergabe an andere Gesellschaften eines Konzerns
Seite 13Till Kreutzer, i.e. Seite 13
Grundlagen OSS und Recht
In a nutshell: verbreitete Irrtümer über OS-Lizenzpflichten
1. Irrtum: Bearbeitete Versionen von OSS müssen nicht veröffentlicht werden!
Denn: Lizenzpflichten (z.B. Quellcode offenlegen, Copyleft, Lizenzhinweise) entstehen erst, wenn OSS veröffentlicht, verbreitet oder öff. zugänglich gemacht wird („Vertriebspflichten“)
Seite 14Till Kreutzer, i.e. Seite 14
Grundlagen OSS und Recht
In a nutshell: verbreitete Irrtümer über OS-Lizenzpflichten
2. Irrtum: Es besteht keine Pflicht, (geänderte Versionen von) OSS jedermann zugänglich zu machen!
Rein interne Nutzung, Zugänglichmachung an eingeschränkte Öffentlichkeit zulässig (z. B. nur an einzelne Kunden, registrierte Mitglieder eines Online-Dienstes) ist nach allen Lizenzen zulässig
Aber: Keine Möglichkeit, Dritten die Weiterverbreitung zu untersagen („You may not impose any further restrictions“) – daher kann „leaking“ (außer bei non copyleft Software) nicht verhindert werden (auch nicht durch schuldrechtliche Auflagen).
Seite 15
Till Kreutzer, i.e. Seite 15
1
4 Open Source Lizenztypologie
Einführung: Open Source Compliance in Softwareprojekten
AGENDA
2 Grundlagen Open Source Software und Recht
3 Lizenzkompatibilität als Kernproblem des Open Source Lizenzmanagements
5 Lizenzkompatibilität bei verschiedenen Lizenztypen
6 Praxistipps für das Open Source Lizenzmanagement
Till Kreutzer, i.e.
Seite 16Till Kreutzer Seite 16
Lizenzkompatibilität als Kernproblem des Open Source Lizenzmanagements
Problemstellung: Kommerzielle Softwareprodukte, die unter Verwendung von Open Source Komponenten entwickelt wurden, dürfen nur vertrieben werden, wenn die Lizenzpflichten aller implementierten OS-Komponenten eingehalten werden
Inkompatibel = Lizenzen, die unvereinbare Lizenzpflichten enthalten, mit der Folge, dass man bei Kombinationen von Software, die unter unterschiedlichen Lizenzen steht, durch Einhaltung der Pflichten aus der einen Lizenz unweigerlich gegen die Pflichten aus der anderen Lizenz verstößt
Till Kreutzer, i.e.
Seite 17Till Kreutzer Seite 17
Lizenzkompatibilität als Kernproblem des Open Source Lizenzmanagements
Mögliche Folgen von Lizenzinkompatibilitäten
Bestehen Lizenzinkompatibilitäten kann das Gesamtprodukt: Nicht mehr rechtssicher vertrieben werden Im Zweifel nicht mehr unter einer beliebigen Lizenz, v. a. nicht „proprietär“
verbreitet werden
Werden die Lizenzinkompatibilitäten selbst und noch vor der Markteinführung entdeckt, sind mögliche Folgen :
Nachträgliche, nicht eingeplante Neuentwicklungen
Verzögerungen bei der Markteinführung Im schlimmsten Fall Verwertungsunfähigkeit des entwickelten Produkts
Till Kreutzer, i.e.
Seite 18Till Kreutzer Seite 18
Lizenzkompatibilität als Kernproblem des Open Source Lizenzmanagements
Werden die Lizenzinkompatibilitäten nicht entdeckt:
Drohen rechtliche Schritte (tatsächlich werden gerade GPL-Verletzungen immer häufiger verfolgt, gravierender noch ist die Gewährleistung und Haftung im schuldrechtlichen Verhältnis gegenüber dem Kunden – er hat vertragliche Ansprüche, weil das Produkt mit Rechtsmängeln behaftet ist),
die bei strategischen Fehlern zu Rufschädigungen und PR-Desastern führen können
und die gravierende wirtschaftliche Auswirkungen haben können (v. a. Unterlassungsansprüche).
Till Kreutzer, i.e.
Seite 19
Till Kreutzer, i.e. Seite 19
1
4 Open Source Lizenztypologie
Einführung: Open Source Compliance in Softwareprojekten
AGENDA
2 Grundlagen Open Source Software und Recht
3 Lizenzkompatibilität als Kernproblem des Open Source Lizenzmanagements
5 Lizenzkompatibilität bei verschiedenen Lizenztypen
6 Praxistipps für das Open Source Lizenzmanagement
Till Kreutzer, i.e.
Seite 20Till Kreutzer, i.e. Seite 20
Open Source Lizenztypologie Wahrscheinlichkeit von Lizenzinkompatibilitäten hängt stark von der Art der
involvierten Lizenzen ab
Große Zahl unterschiedlicher Open-Source-Lizenzen im Umlauf (ifrOSS-Lizenzcenter zählt weit über 100 Lizenzen, siehe http://www.ifross.org/lizenz-center).
Eine Kompatibilitätsprüfung (einschließlich aller Wechselwirkungen) aller (in großen Projekten mitunter mehr als fünfzig) Lizenzen ist sehr aufwändig.
Lizenzen können typologisiert werden. Innerhalb der Gattungen lassen sich z. T. generalisierbare Erkenntnisse herausarbeiten, die generell zu beachten sind.
Seite 21Till Kreutzer, i.e. Seite 21
Open Source LizenztypologieIm wesentlichen drei Typen:1. Lizenzen ohne Copyleft-Effekt: Generell sehr kurze Lizenztexte, durch die gestattet wird,
dass Weiterentwicklungen unter abweichenden Lizenzbedingungen veröffentlicht werden. Sie enthalten keine Einschränkungen hinsichtlich des gemeinsamen Vertriebs mit anders lizenzierten Programmen.
BSDartige Lizenzen (Bsp: BSD-License, Apache-License) Sonstige Lizenzen ohne Copyleft-Effekt (meist an bestimmte Projekte angepasste
Apache- und BSD-Derivate)
2. Lizenzen mit strengem Copyleft-Effekt: Meist sehr komplizierte Lizenzen, die verlangen, dass sämtliche Weiterentwicklungen (zumeist definiert als „abgeleitete Werke“ bzw. „derivative works“), nur unter der Ursprungslizenz vertrieben werden dürfen. Als „abgeleitete Werke“ werden mitunter auch Kombinationen von Software-Komponenten verstanden.
GPLartige Lizenzen (GPL v.2, v.3; AGPL) Sonstige Lizenzen mit strengem Copyleft-Effekt (CPL, EPL)
Seite 22Till Kreutzer, i.e. Seite 22
Open Source Lizenztypologie
3. Lizenzen mit beschränktem Copyleft-Effekt: Komplexe Lizenzen, die grundsätzlich auch verlangen, dass Weiterentwicklungen nur unter der Ursprungslizenz vertrieben werden dürfen. Das Copyleft erstreckt sich auf Code-Kombinationen und u. U. sogar „Bearbeitungen“ jedoch nur eingeschränkt.
MPLartige Lizenzen (MPL, Nokia Open-Source-License, Sun Public License) Sonstige Lizenzen mit beschränktem Copyleft-Effekt (LGPL, Yahoo! Public License)
Seite 23
Till Kreutzer, i.e. Seite 23
1
4 Open Source Lizenztypologie
Einführung: Open Source Compliance in Softwareprojekten
AGENDA
2 Grundlagen Open Source Software und Recht
3 Lizenzkompatibilität als Kernproblem des Open Source Lizenzmanagements
5 Lizenzkompatibilität bei verschiedenen Lizenztypen
6 Praxistipps für das Open Source Lizenzmanagement
Till Kreutzer, i.e.
Seite 24Till Kreutzer, i.e. Seite 24
Beispielsfall zur Lizenzkompatibilität
Beispielsfall: Sie entwickeln ein Framework, in das Sie eine Vielzahl Open-Source-Komponenten implementieren wollen. Hierunter sind insbesondere verschiedene (u. a. Java-) Bibliotheken, die teilweise unter Apache- und BSD-Lizenzen und teilweise unter der LGPL v.2.1 stehen. Zudem verwenden Sie Module, die unter der MPL und der GPL v.2 stehen. Die Open-Source-Komponenten werden dabei selbst nicht verändert. Sie sollen aber zusammen mit den selbst entwickelten Basiskomponenten des Frameworks ausgeliefert werden, wobei zumindest die Eigenentwicklungen nicht unter eine Open-Source-Lizenz gestellt werden sollen.
Frage: Ist es zulässig, den Code der unter den verschiedenen Open Source Lizenzen stehenden Programmen miteinander bzw. mit der eigenen Software zu kombinieren und die Kombination zu vermarkten, ohne dass die Eigenentwicklungen als Open Source vertrieben werden müssen?
Seite 25Till Kreutzer, i.e. Seite 25
Beispielsfall zur Lizenzkompatibilität
Die Antwort hängt entscheidend von zwei Aspekten ab, die eng miteinander verzahnt sind:
1. Eingreifen von Copyleft-Effekten: Greift der Copyleft-Effekt einer der Lizenzen, muss das Gesamtprodukt wieder unter dieser Lizenz veröffentlicht werden. Eine closed source Publikation der Eigenentwicklungen ist dann (so) nicht möglich.
2. Kompatibilität der Open-Source-Lizenzen: Greift der Copyleft-Effekt einer der Lizenzen und enthalten die anderen Lizenzen Pflichten, die in der Copyleft-Lizenz nicht enthalten sind, ist die Kombination (so) nicht möglich. Die Kombination mit Modulen, die unter einer Copyleft-Lizenz stehen, ist nur möglich, wenn die für die kombinierten Module geltenden Lizenzen keine Pflichten enthalten, die die Copyleft-Lizenz nicht enthält.
Seite 26Till Kreutzer, i.e. Seite 26
Lizenzkompatibilität bei Lizenzen mit strengem Copyleft-Effekt
Copyleft: Veränderte Versionen der Software („derivatives“) dürfen nur unter den gleichen Lizenzbestimmungen vertrieben werden. Zusätzlich beschränkende Bedingungen dürfen dem Nutzer nicht auferlegt werden („You may not impose further restrictions“, z. B. Ziff. GPL v.2, Ziff. 10 GPL v.3).
Ob ein Lizenzkompatibilitätsproblem entsteht, hängt also von der Frage ab, ob das Copyleft greift, m. a. W., ob die angestrebte Kombination ein derivative work des Ursprungsprogramms darstellt
Seite 27Till Kreutzer, i.e. Seite 27
Lizenzkompatibilität und GPL v.2Frage aus dem Beispielsfall: Implementierung der GPL v.2-Module
Grundsatz: GPL schreibt strenges Copyleft vor, d. h. modifizierte Versionen (siehe Ziff. 2 GPL) dürfen stets nur unter der GPL vertrieben werden.
Die Kombination ist nur möglich, wenn die andere Lizenz uneingeschränkt erlaubt, die Software unter der GPL zu vertreiben und dabei keine über die GPL hinausgehenden Pflichten beachtet werden müssen (dann wäre sie inkompatibel)
GPL v.2 kompatible Lizenzen (siehe Übersicht der FSF unter http://www.fsf.org/licensing/licenses/index_html#CommonPublicLicense10):
LGPL 2.0, BSD-Lizenz ohne Werbeklausel, Public Domain Nicht kompatibel: GPLv3 (nur bei any later version); MPL; CPL Streitig: Apache-Lizenzen (FSF: inkompatibel) – kompatibel nach v.3 EUPL: Kompatibel nur mit GPLv2, nicht mit GPLv3
Seite 28Till Kreutzer, i.e. Seite 28
Lizenzkompatibilität und GPL v.2 Frage: Handelt es sich bei dem Gesamtprodukt um eine „modification“ bzw. ein
„derivative work“ der GPL-Module? Wenn (+), greift Copyleft und das Gesamtprodukt darf nur unter GPL vertrieben werden.
Problem: „modification“ i.S.d. GPL ≠ „Bearbeitung“ i.S.d. Urheberrechts, Begriff geht deutlich weiter
Eine modification kann auch vorliegen, wenn der unveränderte GPL-Code mit anderen Software-Bestandteilen kombiniert, z. B. gelinkt wird (hier: Kombination mit anderen Open-Source-Komponenten bzw. eigenen, proprietär zu lizenzierenden Bestandteilen)
Eine „modification“ liegt nicht vor bei: „mere aggregation on a volume of a storage or distribution medium“ (Ziff. 2, Abs. 4 GPL)
Abgrenzung zur modification schwierig
Seite 29Till Kreutzer, i.e. Seite 29
Lizenzkompatibilität und GPL v.2Modification/Derivative Works i.S.d. GPL
Stets bei Erweiterungen, Kürzungen und Abänderungen des GPL-Codes (= urheberrechtliche „Bearbeitung“)
Nie wenn eigenständiges Programm, in dem kein GPL-Code enthalten ist, isoliert vertrieben wird, selbst wenn beim linking mit GPL-Code während des Ablaufs ein derivative entstehen würde
Bei Kombinationen von eigenem mit GPL-Code: Unterscheidung eigenständiges vers. abgeleitetes Programm nötig
Abgrenzung hängt von inhaltlichen und formalen Aspekten ab, also sowohl davon, wie die Bestandteile der Kombination inhaltlich zusammenhängen als auch in welcher Form technischer Verbindung der gemeinsame Vertrieb erfolgt
Idee dahinter: GPL-Code soll stets eigenständig nutzbar und identifizierbar sein
Seite 30Till Kreutzer, i.e. Seite 30
Lizenzkompatibilität und GPL v.2
Derivative Works i.S.d. GPL
Inhaltliches Abgrenzungskriterium: Je mehr GPL-Code und eigene Bestandteile voneinander abhängen, desto eher „abgeleitetes“ Werk
Indiz für inhaltliche Abhängigkeit: Software-Bestandteil ist nur mit GPL-Programm lauffähig. Dagegen: Modul ist nicht auf das Zusammenwirken mit GPL-Software zugeschnitten
Formales Abgrenzungskriterium: Code-Bestandteile werden in deutlich abgegrenzter Form verbreitet.
Indiz für Abhängigkeit: Bestandteile im Objekt- oder Sourcecode „vermischt“, werden statisch gelinkt in einer Datei (z. B. in einem einzigen Executable) vertrieben. Dagegen: Bestandteile sind in eigenständigen Files gespeichert
Einordnung hängt stets von den Umständen des Einzelfalls ab
Seite 31Till Kreutzer, i.e. Seite 31
Lizenzkompatibilität und GPL v.2
Derivative Works i.S.d. GPL
Faustformel: Copyleft greift nicht, wenn Programme oder Softwarebestandteile inhaltlich nicht voneinander abgeleitet sind und sie voneinander formal getrennt vertrieben werden
Allgemeine Regeln:
Programme oder Softwarebestandteile, die (inhaltlich) nicht voneinander abgeleitet sind, können unter unterschiedlichen Lizenzen verbreitet werden, wenn sie auch formal getrennt vertrieben werden (v. a. in verschiedenen Dateien gespeichert sind)
Programme oder Softwarebestandteile, die (inhaltlich) nicht voneinander abgeleitet sind, müssen insgesamt unter GPL verbreitet werden, wenn sie ein „Ganzes“ bilden, also keine formale Trennung vorliegt
Programme oder Softwarebestandteile, die (inhaltlich) voneinander abgeleitet sind, dürfen stets nur unter der GPL gemeinsam verbreitet werden
Seite 32Till Kreutzer Seite 32
Lizenzkompatibilität und GPL v.2
Ergebnis im Beispielsfall
Der gemeinsame Vertrieb der GPL-Komponenten mit den anderen Bestandteilen darf jedenfalls nicht in Form eines einzigen Executables erfolgen. Hier wäre der Vertrieb nur zulässig, wenn man das Gesamtprodukt unter der GPL vertreiben würde, was u. a. erfordern würde, den Code offen zu legen.
Möglich wäre es beispielsweise, die Apache-Bibliotheken in eigenen Dateien zu speichern und dynamisch (runtime) miteinander zu linken
Erforderlich ist zudem die inhaltliche Unabhängigkeit von GPL- und anders lizenzierten Komponenten (Einzelfallfrage, wichtigstes Indiz: Wurden die anderen Bestandteile speziell für die Verwendung mit den GPL-Modulen entwickelt oder handelt es sich jeweils um unangepasste Standardkomponenten?)
Till Kreutzer, i.e.
Seite 33Till Kreutzer, i.e. Seite 33
Lizenzkompatibilität und Lizenzen mit beschränktem Copyleft-Effekt
Frage aus dem Beispielsfall: Implementierung der Mozilla-Module
Es gilt Mozilla Public Licence Ziff. 2.2:
Copyleft gilt für „modifications“. „modifications“ definiert Ziff. 1.9: Änderungen des Codes (Streichungen, Hinzufügungen, Kürzungen)
Aber: Wenn Ergänzungen, Zusätze oder auf die MPL-Software zugreifende Programme in neuen, eigenständigen Files (ohne Ursprungs-Code) gespeichert sind, kein Copyleft (rein formale Kriterien zur Abgrenzung von „derivatives“ und eigenständigen Programmen)
Ergebnis im Beispielsfall: Ein gemeinsamer Vertrieb der MPL-Module mit beispielsweise den Apache-Bibliotheken wäre zulässig, wenn sie in unterschiedlichen Dateien gespeichert sind. Aus Sicht der GPL wäre ein gemeinsamer Vertrieb jedoch nur zulässig, wenn die MPL-Software zusätzlich von der GPL-Software inhaltlich unabhängig wäre.
Seite 34Till Kreutzer, i.e. Seite 34
Lizenzkompatibilität und LGPL v.2Frage aus dem Beispielsfall: Implementierung der LGPL-Bibliotheken Lizenz ist bestimmt für den Einsatz für Bibliotheken und soll (auch)
ermöglichen, dass diese mit proprietären Programmen gelinkt und in einem Executable vertrieben werden, ohne dass der Copyleft-Effekt das proprietäre Programm erfasst.
Programme, die für Zugriff auf LGPL-Bibliotheken geschrieben sind und gemeinsam vertrieben werden, unterfallen daher nicht immer dem Copyleft
Copyleft greift zwar grundsätzlich, wenn Programm und Bibliothek verlinkt (auch dynamisch) sind und gemeinsam vertrieben (als ein Executable) werden, Ausnahmen sind aber möglich.
Ausnahmen vom Copyleft-Effekt der LGPL: Ziff. 6b) LGPL Kein Copyleft, soweit hinreichend verbreiteter Linking-Mechanismus verwendet wird, und Befugnisse zur Änderung & Dekompilierung des Programms eingeräumt werden, und Hinweis auf LGPL-Bibliothek sowie Kopie LGPL mitgeliefert wird.
Seite 35Till Kreutzer Seite 35
Lizenzkompatibilität und GPL v.2
Ergebnis im Beispielsfall
Der gemeinsame Vertrieb der LGPL-Komponenten mit den anders lizenzierten Softwarebestandteilen kann – auch gelinkt in einem Executable – zulässig sein!
Dies würde jedoch zumindest erfordern, dass zumindest die selbst entwickelten Applikationen nach deren Lizenzbestimmungen vom Nutzer dekompiliert werden dürfen. Im Zweifel müsste ein Dekompilierungsrecht für das ganze Executable gewährt werden
Ob dergleichen akzeptabel ist, hängt stark vom Einzelfall (v. a. von der Bedeutung der LGPL-Bibliothek für das Gesamtprodukt) ab. LGPL ist von Bedeutung, da z. B. GLib als eine der wichtigsten Linux-Bibliotheken hierunter steht)!
Till Kreutzer, i.e.
Seite 36Till Kreutzer, i.e. Seite 36
Lizenzkompatibilität bei Lizenzen ohne CopyleftFrage aus dem Beispielsfall: Implementierung der BSD- und Apache-Bibliotheken Da kein Copyleft, können die Komponenten ohne Einschränkungen mit anders
lizenzierten Programmen kombiniert und vertrieben werden Aber: Die Vertriebspflichten der Lizenzen sind dennoch zu befolgen. Das sind (am
Beispiel Apache Licence 1.1): Copyright-Angaben, Lizenztext und Haftungs-Disclaimer müssen beibehalten bzw. – bei der
Verbreitung als Binary – in einer Dokumentation oder sonstigen Materialien (wie einer Datei) reproduziert werden
Hinweis "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)." muss in der Endnutzer-Dokumentation, der Software selbst oder an sonstigen Orten (z.B. anderen, auch elektronischen, Begleitmaterialien), an denen üblicherweise Hinweise auf Drittsoftware zu finden sind, gegeben werden.
Geänderte Versionen der Software dürfen die Marke Apache nicht mehr enthalten. Eine Pflicht, den Sourcecode verfügbar zu machen, enthält die APL 1.1 nicht.
Aber: Aus Sicht der GPL sind Kombinationen mit Apache-Software nur möglich, wenn Copyleft der GPL nicht greift (da Lizenzen inkompatibel)
Seite 37Till Kreutzer, i.e. Seite 37
Fazit zur Lizenzkompatibilität
Kombinationen von Open-Source-Komponenten, die unter unterschiedlichen Copyleft-Lizenzen stehen, können nicht in Form eines einzigen Executables (eine Datei) vertrieben werden.
Copyleft-Lizenzen sind in aller Regel im Verhältnis zueinander (und häufig auch zu non copyleft Lizenzen) inkompatibel. Software kann nur gemeinsam vertrieben werden, wenn Copyleft nicht greift
Greift der Copyleft-Effekt aufgrund der Verbindung unterschiedlich lizenzierter Programme in einem einzigen Executable, schreibt jede der Lizenzen vor, dass die hierbei entstehende Datei nur unter den eigenen Lizenzbestimmungen vertrieben werden darf.
Da man jeweils nur einer Copyleft-Verpflichtung nachkommen kann, sind solche Distributionen nicht möglich.
Generell wird die Verwendung von Komponenten mit starken Copyleft-Lizenzen in closed source Endprodukten daher soweit möglich zu vermeiden sein!
Seite 38
Till Kreutzer, i.e. Seite 38
1
4 Open Source Lizenztypologie
Einführung: Open Source Compliance in Softwareprojekten
AGENDA
2 Grundlagen Open Source Software und Recht
3 Lizenzkompatibilität als Kernproblem des Open Source Lizenzmanagements
5 Lizenzkompatibilität bei verschiedenen Lizenztypen
6 Praxistipps für das Open Source Lizenzmanagement
Till Kreutzer, i.e.
Seite 39Till Kreutzer, i.e. Seite 39
Praxistipps für das Open-Source-LizenzmanagementLizenzstrategie für die Vermarktung des Produkts
Vor Beginn der Entwicklung sollte eine Lizenzstrategie für die Vermarktung des Endprodukts entwickelt werden
Denkbar sind u. U. nicht nur single licensing Modelle (z. B. nur proprietär), sondern auch dual licensing Strategien - abhängig vom Geschäftsmodell
Dual licensing (z. B. in Form des Vertriebs einer Open-Source- und einer proprietären Variante der Software) ist in der Regel nicht möglich, wenn Copyleft-Software implementiert wird (da aufgrund des Copylefts ein Vertrieb jedenfalls dieser Komponenten, ggf. auch der gesamten Kombination, unter einer anderen, v. a. proprietären, Lizenz nicht zulässig ist)
Sollte dual licensing des Gesamtprodukts angestrebt werden, ist daher darauf zu achten, dass die Lizenzen aller Komponenten einen gemeinsamen Vertrieb unterschiedlich lizenzierter Komponenten uneingeschränkt gestatten (unproblematisch nur, wenn OS-Software unter non copyleft Lizenzen steht)
Seite 40Till Kreutzer Seite 40
Praxistipps für das Open-Source-LizenzmanagementDokumentation von Fremdkomponenten und Lizenzen
Bei Projekten, in denen es um die Verwendung einer Vielzahl von Open-Source-Komponenten geht, sollte unbedingt ein Quellenverzeichnis angelegt werden. Dies sollte zumindest die Namen der Fremdsoftware, deren Fundort (Links) und die hierfür geltende Lizenz enthalten. Zudem erscheint es sinnvoll, die Lizenztexte abzuspeichern.
Geschieht dies nicht, ist eine nachträgliche Compliance-Prüfung nur noch mit sehr großem Aufwand möglich
Bei Verwendung von Copyleft-Software sollte zudem dokumentiert werden, in welcher Form sie ausgeliefert werden soll, wie sie technisch mit den anderen Modulen des Gesamtprodukts interagieren und ob und wenn, inwiefern sie verändert wurde
Till Kreutzer, i.e.
Seite 41Till Kreutzer, i.e. Seite 41
Praxistipps für das Open-Source-LizenzmanagementAuslieferung der Sourcecodes
Bei einem Vertrieb von komplexen Kombinationen von eigenen und fremden Open-Source-Software-Komponenten ist es generell sinnvoll, die Sourcecodes der Open-Source-Komponenten mit auszuliefern.
Grund: In den Source-Dateien sind – sofern von den Entwicklern die Pflichten aus den Lizenzen korrekt eingehalten wurden – in der Regel alle Lizenzhinweise, Copyright- und Urhebervermerke sowie Lizenztexte bereits enthalten.
Zudem erspart man sich so, die teils sehr unterschiedlichen Anforderungen in Bezug auf die Bereitstellung des Sourcecodes im Einzelnen bedenken und beachten zu müssen. Allerdings sind nach manchen Lizenzen weitere, besondere Pflichten zu beachten, wenn die Open Source Software im Objektcode vertrieben wird.
Seite 42Till Kreutzer, i.e. Seite 42
Praxistipps für das Open-Source-LizenzmanagementDokumentation der Fremdkomponenten im Endprodukt
Eine Aufstellung der Fremdkomponenten sollte jeder Distribution des Gesamtprodukts beigefügt werden (digital oder in Papierform), in der auch die Lizenztexte enthalten sind
Beispielsformulierung: „Dieses Produkt enthält Fremdsoftware, die nach der jeweils hierfür geltenden Open-Source-Lizenz von jedem genutzt werden kann. Die Bestandteile xxx und yyy stehen unter der xx-Lizenz (Einfügung des Lizenztexts)...“.
Zu bedenken ist, dass eine solche Aufstellung bei Änderungen der Konfiguration (z. B. Austausch einzelner Komponenten) angepasst werden muss.
Seite 43Till Kreutzer Seite 43
Praxistipps für das Open-Source-LizenzmanagementUmlizenzierung: Sollte/darf man non copyleft Komponenten zwecks
Lizenzeinheitlichkeit unter die (z. B. proprietäre) Lizenz des Gesamtprodukts stellen?
Da kein Copyleft, darf non copyleft Software grundsätzlich umlizenziert und unter einer beliebigen anderen Lizenz veröffentlicht werden
Aber: Da die Vertriebspflichten der Lizenzen dennoch zu befolgen sind, sollte das vermieden werden.
Daher ist ratsam, auch solche Komponenten wieder unter der Ursprungslizenz zu vertreiben und sie in einem Lizenzdokument (z. B. license.txt) zu benennen und die notwendigen Hinweise (Copyright-Angaben, Disclaimer, Lizenztext usw.) zu geben.
Till Kreutzer, i.e.
Seite 44Till Kreutzer, i.e. Seite 44
Praxistipps für das Open-Source-LizenzmanagementLizenzierung des Gesamtprodukts
Bei der Konzeption der Lizenzverträge für das Gesamtprodukt ist die Verwendung der Open-Source-Komponenten zu berücksichtigen.
U. a. sollte deutlich darauf hingewiesen werden, dass die Lizenz die Open-
Source-Komponenten nicht erfasst (schon aus Haftungsgründen) und dass diese nach den Bedingungen aus der jeweiligen Open-Source-Lizenz ohne Lizenzgebühren genutzt werden können.
Seite 45Till Kreutzer, i.e. Seite 45
Literatur und Weblinks Über uns: www.ie-online.de www.ifross.de www.fsf.org www.irights.info Spindler, Gerald – Rechtsfragen bei Open Source Jaeger, Till/Metzger, Axel – Open Source Software – Rechtliche
Rahmenbedingungen der Freien Software, 2. Auflage 2006 ifrOSS (Hrsg.) - Die GPL kommentiert und erklärt (Download:
http://www.ifross.org/Druckfassung/Die_GPL_kommentiert_und_erklaert.pdf)
Seite 46Seite 46
Vielen Dank für Ihre Aufmerksamkeit!
Till Kreutzer, i.e.