3.3. Nicht vergessen: Auswahl einer geeigneten Lizenz

Bei der Software-Entwicklung werden rechtliche Fragen gern verdrängt oder übersehen. Dabei hat die Lizenzform der Software entscheidende Bedeutung für die Nutzung und Weiterverbreitung derselben.

Es ist daher unerlässlich, sich mit der Frage auseinander zu setzen, welche Lizenz die geeignete für die Software ist und welche Spielräume überhaupt bleiben, baut man die eigene Entwicklung beispielsweise auf bestehendem Linux-Code auf.

Die Anzahl der in der Open-Source-Gemeinschaft beheimateten Lizenzen ist beträchtlich. Einige von ihnen unterscheiden sich in der Sache allerdings nur in Nuancen.

Nahezu allen Open-Source-Lizenzen ist zunächst gemeinsam, dass

3.3.1. GPL und LGPL

An einer grundsätzlichen Frage scheiden sich die Geister: Muss modifizierter Open-Source-Code ebenfalls freigegeben werden und unter die gleiche Lizenz gestellt werden wie das Ursprungsprogramm? Oder dürfen Änderungen wie Weiterentwicklungen mit proprietärem Code kombiniert und unter proprietäre Lizenzen gestellt werden?

Die populärste Open-Source-Lizenzform, die »GNU General Public License« (GPL), gibt darauf eine strikte, eindeutige Antwort. Sie verlangt, dass jedes Programm, welches ganz oder nur in Teilen von einer GPL-lizenzierten Software abgeleitet wird, ebenfalls komplett unter die Bedingungen der GPL fällt und lizenzfrei offen gelegt werden muss. Nur die Programme, die in keiner Weise vom GPL-Ursprungsprogramm abgeleitet werden und somit als unabhängige, eigenständige Software gelten, können unter einer anderen Lizenz getrennt weiterverbreitet werden.

Linus Torvalds stellt klar, dass bereits »ein für Linux geschriebenes Modul, das Kernel-Infrastruktur benötigt, um zu laufen« von vornherein als ein solch abgeleitetes Werk betrachtet wird, »selbst wenn dazu kein existierender Linux-Code kopiert wird.« Linux selbst ist der bekannteste Vertreter einer GPL-lizenzierten Software – der Linux-Kernel unterliegt der GPL in seiner aktuellen Version 2.0. Während GPL-Software die vollständige Palette der Linux-Funktionen zur Verfügung steht, bietet der Linux-Kernel für die Entwickler proprietärer Treiber nur eine eingeschränkte Funktionalität an.

Die GPL verfolgt das Ziel »freie Software«. Indem die umfangreichen Nutzungsrechte jeglicher GPL-Software nur eingeräumt werden, wenn der Nutzer sich seinerseits zu gleichem Tun verpflichtet, werden die Restriktionen, die mit proprietären Lizenzen verbunden sind, außer Kraft gesetzt.

In der Praxis werden diese juristisch eindeutigen und strikten Vorgaben der GPL teilweise umgangen. So existieren für Linux dynamisch gelinkte Treiber (Binärtreiber), deren Sourcecode vom Hersteller geheim gehalten wird. Zwar werden solche Treiber vom Linux-Kernel als »verdorben« (tainted) markiert, doch wird ein Zusammenspiel nicht verweigert – sehr zum Unmut vieler Open-Source-Entwickler. Während Befürworter von Binärtreibern appellieren, jeder, der seinen Treiber auf Linux portieren möchte, ohne zur GPL zu wechseln, solle dies tun dürfen, würden die Verfechter freier Software auf Verletzungen der GPL am liebsten mit der Blockade solcher Software reagieren. De facto wird jedoch bislang keiner gezwungen, das Copyright zu wechseln – geschweige denn mit juristischen Sanktionen belangt.

Speziell für einige Bibliotheken hat die »Free Software Foundation« die so genannte »Lesser General Public License« (LGPL) kreiert. Wie der Lizenz-Name andeutet, sind die beschriebenen Vorgaben nicht so streng wie bei der GPL. Zwar müssen Änderungen an der Bibliothek ebenfalls unter den Bedingungen der LGPL oder der GPL offen gelegt werden. Programme aber, die die Bibliothek nur nutzen, können diese Bibliothek zu ihrem Programm linken, ohne das Programm unter eine Open-Source-Lizenz stellen zu müssen. Von diesem Schritt erhofft sich die Freie-Software-Bewegung, dass so bekannte Bibliotheken wie die »GNU C Library« neben proprietären Bibliotheken bestehen oder gar zum De-facto-Standard werden können.

3.3.2. MPL und BSD

Die »Mozilla Public License« (MPL) ist ebenfalls sehr verbreitet. Ihr Unterschied zur GPL: Wird der unter der Open-Source-Lizenz stehende Code mit proprietären Bestandteilen kombiniert, müssen nur die ursprünglichen Open-Source-Teile als solche bewahrt bleiben und lizenzfrei offen gelegt werden, nicht aber das neu geschaffene Werk als Ganzes.

Einen anderen Ansatz verfolgen die Vertreter von Lizenzen wie BSD oder Apache. Ihrer Ansicht zufolge kann proprietärer Code sehr wohl mit Open Source koexistieren – wobei Modifikationen am Open-Source-Quelltext nicht als Open Source deklariert werden müssen. Hier hat der Entwickler also die Möglichkeit, Open-Source-Software zu verwenden, um sie unter einer proprietären Lizenz weiter zu verbreiten.

Stellt der Treiberentwickler seinen Code unter die LGPL, die MPL oder die BSD-Lizenz, erhält er eine hundertprozentige Unterstützung durch den Linux-Kernel und durch die Entwicklergemeinde. Sobald dieser Code mit Linux läuft, ist die GPL-Lizenz die dominante – der Entwickler verpflichtet sich daher, das gesamte Paket unter den Bedingungen der GPL freizugeben. Nichts hindert den Entwickler allerdings daran, seinen ursprünglichen BSD-Code auch mit proprietärer Software zusammenzuführen.

Generell gilt: Die Entscheidung eines Entwicklers für eine Open-Source-Lizenz bringt die Unterstützung der Community mit sich. Bei Problemen stößt man auf viele offene Ohren und bereitwillige Helfer. Das haben vor allem diejenigen Unternehmen erkannt, die primär mit Services und Support rund um Hardware handeln.

Inzwischen wankt bei vielen Firmen das einstige Dogma, geistiges Kapital der Mitarbeiter unter Verschluss zu halten. Zunehmend lassen sich kommerzielle Anbieter bei Softwarelösungen in die Karten schauen. Bei diesen setzt sich die Erkenntnis durch, dass durch Veröffentlichung des Codes keine Kernkompetenz abgegeben wird, die zum Einbruch des Umsatzes führt. Zum einen liegt das Kapital – wie Eric Raymond es bezeichnete – weniger in der Software als vielmehr in der Kompetenz der Entwickler. Zum anderen bringt die GPL Vorteile mit sich. Schließlich beteiligen sich durch die Offenlegung des Quellcodes viele Programmierer an der Weiterentwicklung. Diese wiederum sind durch die Lizenz dazu verpflichtet, ihre Arbeit allen – und damit auch dem Hersteller – wieder zur Verfügung zu stellen.


Lizenz