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 Till Kreutzer, i.e. Seite 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

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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

Seite Till Kreutzer, i.e. Seite 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.

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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

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 Seite Till Kreutzer Seite Till Kreutzer, i.e.

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 Seite Till Kreutzer Seite Till Kreutzer, i.e.

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). Seite Till Kreutzer Seite Till Kreutzer, i.e.

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 Till Kreutzer, i.e. Seite

Open Source Lizenztypologie Im wesentlichen drei Typen: 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) 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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

Beispielsfall zur Lizenzkompatibilität Die Antwort hängt entscheidend von zwei Aspekten ab, die eng miteinander verzahnt sind: 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. 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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

Lizenzkompatibilität und GPL v.2 Frage 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 Till Kreutzer, i.e. Seite

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: „ modificatio n “ i.S.d. GPL ≠ „ Bearbeitun g“ 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 Till Kreutzer, i.e. Seite

Lizenzkompatibilität und GPL v.2 Modification/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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

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?) Seite Till Kreutzer Seite Till Kreutzer, i.e.

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 „ modificati ons “. „ 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 Till Kreutzer, i.e. Seite

Lizenzkompatibilität und LGPL v.2 Frage 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 Till Kreutzer, i.e. Seite

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)! Seite Till Kreutzer Seite Till Kreutzer, i.e.

Lizenzkompatibilität bei Lizenzen ohne Copyleft Frage 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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

Praxistipps für das Open-Source-Lizenzmanagement Lizenzstrategie 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 Till Kreutzer, i.e. Seite

Praxistipps für das Open-Source-Lizenzmanagement Dokumentation 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 Seite Till Kreutzer Seite Till Kreutzer, i.e.

Praxistipps für das Open-Source-Lizenzmanagement Auslieferung 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 Till Kreutzer, i.e. Seite

Praxistipps für das Open-Source-Lizenzmanagement Dokumentation 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 Till Kreutzer, i.e. Seite

Praxistipps für das Open-Source-Lizenzmanagement Umlizenzierung: 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. Seite Till Kreutzer Seite Till Kreutzer, i.e.

Praxistipps für das Open-Source-Lizenzmanagement Lizenzierung 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 Till Kreutzer, i.e. Seite

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 Till Kreutzer, i.e. Seite

Vielen Dank für Ihre Aufmerksamkeit! Seite Seite Till Kreutzer, i.e.

Open Source Lizenzmanagement

Weitere ähnliche Inhalte

Empfohlen

Open Source Lizenzmanagement

Hinweis der Redaktion