Software korrekt lizenzieren Open-Source-Lizenzen rechtskonform einsetzen

Open Source Software wird von Unternehmen gerne als günstige und anpassbare Lösung eingesetzt. Wie aber lassen sich die Lizenzbestimmungen einhalten, wenn es darum geht, sie als Basis für eigene Produkte zu verwenden?

Anbieter zum Thema

Insider Research

OutSystems

Open-Source-Applikationen kennt und nutzt nahezu jeder – dieser Text wurde mit solcher Software geschrieben, wird von ihr gehostet und vermutlich auch mit einem quelloffenen Browser wie Firefox angezeigt. Weniger bekannt sind die dahinterstehenden Lizenzen – aber erst die machen aus einer Ansammlung von Code wirklich Open Source Software. Um diese Lizenzen richtig einsetzen zu können, muss erst einmal klar sein, wie sie definiert sind.

Eine kurze Definition

Die Open Source Initiative (OSI) führt eine Liste anerkannter Open-Source-Lizenzen und definiert OS-Lizenzen als solche, die der Open-Source-Definition entsprechen. In Kürze heißt das: Die Lizenz erlaubt die freie Nutzung, Bearbeitung und Weitergabe (unter bestimmten Bedingungen) des Codes. Daneben beinhalten die Lizenzen unterschiedlichste Obligationen, Definitionen und teils Absätze zu Patenten, Gerichtsständen und so weiter.

Die Lizenzen lassen sich grob in zwei Lager einteilen: Freigiebige und nicht-freigiebige Lizenzen, in der Praxis tauchen eher die Begriffe Permissive und Non-Permissive auf. Dabei geht es um den einst von Steve Ballmer als „Krebsgeschwür“ bezeichneten Copyleft-Effekt. Copyleft heißt, dass die durch die Lizenz gewährten Rechte weitergegeben werden müssen, wenn der so lizenzierte Code für ein neues Produkt verwendet wird.

Völlig gleich, ob nun eigener Code hinzukommt oder mit weiterer Software kombiniert wird, das Endresultat stünde wieder unter der GPL. Dieser virale Aspekt gewährleistet, dass vom Urheber frei lizenziertes Material nicht ohne Weiteres in proprietäre Produkte einfließen kann. Das populärste Beispiel für solche eine nicht-freigiebige Lizenz ist die General Public License (GPL).

Das beste Beispiel für eine freigiebige Lizenz ohne Copyleft-Effekt ist die 2-clause-BSD, die allgemein mit BSD-Lizenz gemeint ist. Diese stellt nur zwei Forderungen: Wird der Quellcode weitergegeben, muss die Lizenz samt Copyright-Hinweis und dem Disclaimer erhalten bleiben. Und im zweiten Satz wird dasselbe für Binaries gefordert. BSD-lizenzierte Software kann also durchaus für proprietäre Produkte genutzt werden. Und genau hier scheiden sich die Geister: Die OSI unterstützt derlei Lizenzen, die Free Software Foundation (FSF) nicht – zu den praktischen Auswirkungen dieses Zwists später mehr.

Neue Projekte lizenzieren

Neue, komplett selbst geschriebene Software als Open Source zu lizenzieren, ist im Grunde sehr einfach. Bei der BSD-Lizenz würde es zum Beispiel genügen, den Urheber in die Lizenz einzufügen und die Lizenz mitsamt der Quelltext-Dateien zu veröffentlichen. Andere Lizenzen machen weitere Auflagen, beispielsweise Copyright-Hinweise in jeder einzelnen Quelltext-Datei oder die Dokumentation jeder Änderung. Häufig wird verlangt, dass der Quellcode auch bei Veröffentlichung als Binary zugänglich gemacht wird.

Das eigentlich Schwierige ist die Auswahl der Lizenz – die Frage, wer mit der Software was und unter welchen Auflagen machen darf, bestimmt letztlich auch ihre Zukunft. Eine gute Übersicht über gewährte Rechte, Auflagen und Limits der wichtigsten Lizenzen gibt es bei Choosingalicense.com.

Modifikationen und neue Werke lizenzieren

Gänzlich neu geschriebene Projekte sind allerdings die Ausnahme, in der Regel geht es eher darum, bestehende Open Source Software zu modifizieren oder mit fremder Software zu kombinieren. Soll also zum Beispiel ein Open-Source-Tool für eigene Kunden angepasst und vertrieben werden, muss zunächst geklärt werden, ob Modifikationen unter einer anderen Lizenz veröffentlicht werden dürfen oder nicht.

Dazu finden sich im Netz reichlich Matrizen, kurz gesagt erlauben es die freigiebigen Lizenzen wie BSD und die Copyleft-Fraktion um die GPL erlaubt es nicht. Anschließend müssen wieder die Obligationen der finalen Lizenz befolgt werden. Auch dafür gibt es ein gutes Tool: Der Open Source Compliance Advisor listet detailliert auf, was bei Verwendung welcher Lizenz in welchem Szenario getan werden muss.

Werden hingegen mehrere Open-Source-Produkte miteinander zu einem neuen Produkt kombiniert, steht die Kompatibilität der Lizenzen in Frage. Im Prinzip ist es recht simpel: Code kann grundsätzlich weniger-freigiebig lizenziert werden – BSD-Code könnte also in ein Projekt unter GPL überführt werden. Die beste Übersicht dazu stammt von David A. Wheeler und zeigt mögliche Neu-Lizenzierungen auf einen Blick (links im Bild).

GPL – Lizenz mit Tücken

Die mit Abstand wichtigste Lizenz ist die GPL, vor allem in der Version GPLv2. Die GPLv2 verfolgt ein strenges Copyleft, weil sich GPLv2-Code nur unter der Bedinung mit anderem Code kombinieren lässt, dass auch dieser Code wieder unter der GPLv2 steht. Das ist für kommerzielle Projekte, aber auch technisch schwierig – man denke nur an Bibliotheken. Damit solche Libraries, beispielsweise der MP3-Encoder Lame, auch für Nicht-GPL-Projekte nutzbar sind, gibt es die LGPL.

Das vorangestellte L steht für Lesser und verheißt ein weniger strenges Copyleft: LGPL-Code darf folgenlos von beliebig lizenzierter Software verlinkt werden. Lame findet sich zum Beispiel in vielen proprietären Kauf-Produkten. Dieses schwache Copyleft räumt dem Lizenznehmer die GPL-üblichen Rechte bezüglich der LGPL-Bestandteile ein, weitet diese aber nicht auf sonstigen Code aus.

Bislang ist die Lage ziemlich klar, nun aber bringt ein technisches Detail etwas Unklarheit: Entsteht aus GPLv2- und weiterem Code ein neues Werk, steht dieses wieder unter der GPL. Bei statischer Verlinkung in einem gemeinsamen Binary ist das unfraglich. Was aber, wenn eine kompilierte Dritt-Software schlicht dynamisch auf GPL-Software verlinkt, also beispielsweise eine DLL-Datei unter Windows?

Jetzt kommen wie angekündigt FSF und OSI ins Spiel: Die OSI ist ein pragmatischer Verein, der Open Source schlicht als das beste Entwicklungskonzept ansieht und die Software möglichst zugänglich machen möchte. Dynamische Verlinkung erzeugt nach OSI-Ansicht kein Derivat. Bei der FSF herrscht ein deutlich idealistischer Tonfall, man spricht von Freiheiten statt Rechten und Free statt Open Source Software. Und entsprechend interpretiert man die Situation genau andersherum. Und die FSF hat die GPL immerhin geschrieben.

In der Praxis ist es eine Frage des Einzelfalls, wie Linus Torvalds diesen „grauen Bereich“ einmal für seinen Linux-Kernel kommentierte. Nicht-GPL-Kernel-Module wie Treiber werden hier durchaus dynamisch gegen den GPLv2-Kernel verlinkt, von Copyright-Inhaber Torvalds aber nicht als GPL-Verstoß gewertet. Im Zweifelsfall muss sich jeder Entwickler gut überlegen, ob er es auf einen Streit mit der FSF-Community ankommen lassen möchte.

Noch einmal in Kürze

In der praktischen Umsetzung müsste man sich nun den Details einzelner Lizenzen widmen – wie muss eine Änderung in welcher Datei und welcher Form dokumentiert werden und so weiter. Auch die Feinheiten zwischen GPLv2, GPLv2+, GPLv3 und AGPL bieten noch einigen Spielraum. Die gute Nachricht: Abgesehen von der GPL sind die meisten anderen Lizenzen wunderbar einfach und kurz gehalten und auch für Nicht-Juristen verständlich.

Das Grundsätzliche sollte klar sein: In den meisten Fällen müssen die Beitragenden attributiert sowie Lizenz und Quellcode verfügbar gemacht werden. Nutzungsbeschränkungen darf es nicht geben. Handelt es sich um Lizenzen mit Copyleft, gelten diese auch für Derivate. Und all diese Obligationen greifen natürlich erst, wenn die Software verteilt wird.

Übrigens: Wer es anderen Entwicklern einfach machen will, kann auch dual lizenzieren – dann kann der Lizenznehmer selbst entscheiden, ob etwa GPL oder BSD besser passt.

(ID:44667531)