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


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



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.)



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



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)



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


1



AGENDA





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)




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




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



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



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“)



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


1



AGENDA





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.



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.



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


1



AGENDA





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.


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)


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


1



AGENDA





Till Kreutzer, i.e.


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?


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.


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


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


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


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


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



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



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.


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.


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.



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.


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)


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


1



AGENDA





Till Kreutzer, i.e.


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)


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.


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.


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.


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.


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.


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.

Open Source Lizenzmanagement

Business

Transcript of Open Source Lizenzmanagement