Verwendung GPL-lizenzierter Komponenten in kommerziellen Projekten

Software, die unter der GNU General Public License lizenziert ist, ist freie Software, und alle Software, die auf GPL-lizenzierten Komponenten aufbaut, ist ebenso frei und muss ebenso unter der GPL lizenziert werden. Daher wird häufig angenommen, dass GPL-lizenzierte Software für kommerzielle Projekte ungeeignet ist. Die beiden meist genannten Mythen sind dabei:

• Man darf keine Lizenzgebühren verlangen.
• Der Quellcode des Projekts muss veröffentlicht werden.

Wenn diese Behauptungen wahr wären, wäre GPL-lizenzierte Software in der Tat ungeeignet für kommerzielle Projekte. Aber sie sind es nicht. Also, sehen wir uns die Lage genauer an.

Die Familie der GNU Lizenzen

Die Free Software Foundation hat eine Familie von Lizenzen publiziert. Die wichtigste davon ist die GNU General Public License . Aber es gibt auch die GNU Lesser General Public License und die GNU Affero General Public License . In diesem Blogbeitrag werden wir uns nur mit Version 3 der Lizenzen, der aktuellen Version also, beschäftigen. Die Links für die Lizenzen verweisen auf die englischsprachigen Originallizenztexte, weil es keine offiziellen Übersetzungen der Lizenztexte ins Deutsche gibt.

Die GNU General Public License

Die GPL gewährt dem Lizenznehmer eine Reihe von Rechten. Das einfachste ist das Recht, die Software zu benutzen. Der Lizenznehmer kann die Software aber auch analysieren. Dazu ist der Lizenzgeber verpflichtet, den Quellcode zur Verfügung zu stellen. Dies kann auf verschiedene Weisen geschehen. Zum Beispiel kann die Software zusammen mit dem Quelltext auf CD oder DVD übergeben werden. Oder der Quellcode kann auf einem öffentlich zugänglichen Webserver veröffentlicht werden.

Der Lizenznehmer hat das Recht, die Software weiter zu verteilen, ohne dass der Lizenzgeber dafür Gebühren verlangen darf. Weiter darf der Lizenznehmer die Software modifizieren oder in seinen eigenen Projekten einsetzen. Wenn er Software verteilt, die GPL-lizenzierte, unveränderte oder veränderte Komponenten beinhaltet, unterliegt auch sein eigenes Produkt der GPL. Daher hat auch jeder weitere Lizenznehmer alle Rechte, die die GPL gewährt, wie den Zugang zum Quellcode oder die Freiheit, das Produkt zu modifizieren oder zu verteilen.

Die GPL enthält keine Passage, die aussagte, dass keine Lizenzgebühren verlangt werden dürften. Vielmehr findet sich in der GPL FAQ Liste die explizite Aussage, dass das Verlangen von Lizenzgebühren zulässig ist (z.B. hier ).

Die GPL enthält auch keine Aussage, dass der Quellcode öffentlich zu machen sei. Es sind die Lizenznehmer und nur sie, die einen Zugang zum Quellcode erhalten müssen. Und der Lizenzgeber bestimmt selbst, wer seine Lizenznehmer sind. Die Tatsache, dass eine GPL-lizenzierte Komponente öffentlich, z.B. über das Internet, verfügbar ist, bedeutet keineswegs, dass auch ein Projekt, das diese Komponente verwendet, öffentlich gemacht werden muss.

Die GNU Lesser General Public License

Die LGPL ist als Lizenz für Software-Bibliotheken vorgesehen. Die Grundidee hierbei ist, dass die Bibliothek freie Software bleibt. Sie kann aber in kommerziellen Applikationen verwendet werden, ohne dass die Applikationen deshalb nun ebenfalls freie Software werden. Eine Applikation, die gegen eine LGLP-lizenzierte Bibliothek linkt oder diese verwendet, kann unter jeder beliebigen Lizenz verbreitet werden, solange diese Lizenz nicht die Lizenznehmer in der Verwendung der LGPL-lizenzierten Bibliothek einschränkt. Der Quelltext der LGPL-lizenzierten Bibliothek muss den Lizenznehmern zur Verfügung gestellt werden.

Die Situation ist ein wenig komplizierter, wenn die Bibliothek modifiziert wird. Die Bibliothek und ihre Änderung unterliegen immer noch der LGPL. Daher ist es erforderlich, jedem Lizenznehmer eine Kopie des modifizierten Quellcodes zugänglich zu machen und ihm auch sonst alle Rechte zu gewähren, die mit der ursprünglichen Lizenz verbunden sind. Daraus folgt aber noch immer nicht die Notwendigkeit, auch die ganze Applikation unter der LGPL zu verbreiten.

Die GNU Affero General Public License

Die AGPL kann als Erweiterung der GPL betrachtet werden. Sie ist für für die Lizenzierung von Software vorgesehen, die nicht an Benutzer verteilt wird, sondern über ein Netzwerk wie das Internet verwendet wird. Die Benutzer erhalten dabei dieselben Rechte wie sonst Lizenznehmer. Insbesondere erhalten die Benutzer das Recht auf Zugang zum Quellcode der Software.

Kompatibilität der Lizenzen

In ihrer aktuellen Version, der Version 3, sind alle drei Lizenzen miteinander kompatibel. Man kann Komponenten oder Bibliotheken unter jede der Lizenzen in einem gemeinsamen Projekt einsetzen, wobei die Bedingungen der jeweiligen Lizenzen gültig bleiben. Wenn zum Beispiel ein Projekt eine LGPL-lizenzierte und eine GPL-lizenzierte Bibliothek einsetzt, unterliegt das Projekt beiden Lizenzen. Im Effekt ist es dann die stärkere GPL, die vorschreibt, welche Rechte die Lizenznehmer des Projekts haben. Eine Applikation, die GPL-lizenzierte und AGPL-lizenzierte Komponenten verwendet, muss sowohl die unter der GPL als auch die unter der AGPL vorgeschriebenen Rechte gewähren. Das heißt unter anderem, allen Benutzern, nicht nur den Lizenznehmern, die eine Kopie der Applikation erhalten, muss ein Zugang zum Quelltext gewährt werden.

Mögliche Verwendungen

LGPL-lizenzierte Software

Bibliotheken und Komponenten, die unter der LGPL freigegeben sind, können problemlos in kommerziellen Projekten verwendet werden. Die Bibliotheken und Komponenten unterliegen dann immer noch der LGPL. Ihre Verwendung oder freie Verteilung durch den Kunden kann in keiner Weise eingeschränkt werden. Aber die Applikation selbst, die LGPL-lizenzierte Bibliotheken oder Komponenten verwendet, kann unter beliebiger Lizenz freigegeben werden.

Interessant ist, dass die Bildung von Unterklassen einer LGPL-lizenzierten Java (oder anderen OO) Klasse als Benutzung einer Schnittstelle einer Bibliothek analog dem Funktionsaufruf einer Bibliothek gesehen wird. Sie wird nicht als Modifikation der ursprünglichen Klasse betrachtet. Daher unterliegen die so gebildeten Unterklassen nicht den Verpflichtungen, die die LGPL Lizenzgebern auferlegt.

Interne Verwendungen

Solange man GPL- oder AGPL-lizenzierte Komponenten oder eigene Software, die auf solche Komponenten aufbaut, nicht verbreitet, sondern nur hausintern verwendet, ist man nicht verpflichtet, irgendwelche Rechte zu gewähren. Folglich sind alle internen Verwendungen unbeschränkt und harmlos. Ein typischer Fall etwa ist das Aufsetzen eines Linux Servers. Der Linux-Kern ist unter der GPL lizenziert. Trotzdem ist die Verwendung von Linux als Betriebssystem für die Benutzer mit keinen weiteren Verpflichtungen verbunden. Dasselbe gilt für alle internen Verwendungen von GPL-lizenzierter Software.

Mehr noch, auch die Installation eines Linux-Servers beim Kunden ist absolut unproblematisch. Und zwar auch dann, wenn man für die Installation und den Service Gebühren verlangt. Das Verlangen von Gebühren für Services rund um GPL-lizenzierte Software ist unter allen Umständen unproblematisch. Selbst das Verlangen von Gebühren für die Software selbst ist nach GPL durchaus zulässig. Es stellt sich nur die Frage, in wie weit Kunden bereit sind, für solche Lizenzen Geld auszugeben, wenn sie die Lizenzen aus anderen Quellen umsonst erhalten können.

Tatsächlich ist das Bereitstellen von Dienstleistungen um Linux-Server, ja sogar das Verlangen von Gebühren für Linux-Lizenzen ein erfolgreiches Geschäftsmodell für Firmen wie Debian, Red Hat und SuSE seit fast zwei Jahrzehnten. Sie zeigen, dass erfolgreiche Geschäftsmodelle im Umfeld freier Software etabliert werden können.

Cloud Dienste

Viele Applikationen werden heute nicht mehr lizenziert und verteilt als gebündelte Software wie z.B. Microsoft Office. Statt dessen laufen die Applikationen nur noch auf einem Cluster von Servern und werden von Benutzern über das Internet verwendet. Beispiele dafür sind Webmail-Systeme oder Dienste zum Teilen von Fotos. Diese Applikationen sind bekannt unter dem Begriff Software as a Service .

Die GPL ist eine Lizenz, die für die klassische Verteilung von Software entworfen wurde. Wenn Software nicht verteilt wird, greifen die Rechte der GPL gar nicht. Als Konsequenz kann man GPL-lizenzierte Komponenten in SaaS-Projekten benutzen, ohne den Quellcode der Projekte irgend jemandem außerhalb des eigenen Unternehmens zugänglich machen zu müssen. Dies ist eine bekannte Schwachstelle der GPL, und der Grund dafür, weshalb die AGPL existiert.

„Normale“ Kundenprojekte

Ein „normales“ Kundenprojekt ist ein Projekt, in dem eine Softwarefirma für einen Kunden oder einen kleinen Kreis von Kunden eine Anwendung entwickelt, meist auf Anforderung des Kunden. Selbst in solchen Projekten kann der Einsatz von GPL-lizenzierten Komponenten sinnvoll sein. Tatsächlich stellt die Bedingung, den Quelcode des Projektes an den Kunden auszuliefern, in solche einem Fall nicht wirklich eine ernste Beschränkung dar, weil Verträge für solche Projekte ohnehin regelmäßig Klauseln beinhalten, die die Übergabe des Quelltextes vorsehen. Da der Kunde für die Entwicklung zahlt, hat er das Recht, alle bei der Entwicklung entstehenden Artefakte einschließlich des Quelltextes zu erhalten.

Ein Punkt, der hier sehr viel wichtiger ist, ist der, dass der Kunde ebenso nach GPL das Recht erhält, die Software weiter zu verteilen einschließlich der Option, dafür Lizenzgebühren zu verlangen. Es ist also in diesem Fall eine wichtige Frage, ob der Kunde ein Interesse haben könnte, die Software weiter zu verteilen. Schauen wir uns dazu zwei Beispiele an. Angenommen die Softwarefirma entwickelt eine Anwendung, die nicht nur für den Kunden selbst, sondern für weitere Firmen aus der Branche des Kunden nützlich ist. Ein Beispiel dafür kann eine Verwaltung von Adressen und Zahlungsverfahren für Endkunden sein. Solch ein System ist in der Regel nicht spezifisch für den Kunden ausgelegt. Damit kann der Kunde schon ein Interesse haben, die Software an seine Konkurrenten zu verkaufen. Die GPL gibt ihm die Freiheit, das zu tun.

Angenommen, die Anwendung, die für den Kunden entwickelt wird, ist ein Softwaremodell des Kernprozesses des Geschäftsmodells des Kunden. Die Anwendung modelliert Schlüsseleigenschaften, die dem Kunden entscheidende Wettbewerbsvorteile gegenüber der Konkurrenz sichert. In der Automobilindustrie etwa, um ein Beispiel zu geben, könnte das ein Fahrzeugkonfigurator sein, der direkt mit dem Auftragssystem und den Produktionsanlagen interagiert. Die Anwendung wäre dann essentiell für den ökonomischen Erfolg des Kunden und Teil seiner Kernwerte. In solch einer Situation hätte ein Kunde vermutlich fast keine Gründe, die Anwendung an Konkurrenten weiter zu geben. Obwohl also die GPL dem Kunden gewisse Recht gewährt, kann man sich ziemlich sicher sein, dass der Kunde kein Interesse hat, diese Rechte jemals auch zu nutzen. In solch einem Fall kann die Verwendung von GPL-lizenzierten Komponenten durchaus eine sinnvolle Option sein.

Übersicht

Obwohl die Verwendung von GPL-lizenzierten Komponenten in kommerziellen Projekten einen ziemlich schlechten Ruf hat, ist die Situation nicht ganz so schlecht, wie man vielleicht denken könnte. Die folgenden Fälle können als unproblematisch erachtet werden.

• Die Verwendung von LGPL-lizenzierten Bibliotheken oder Komponenten.
• Die interne Verwendung von GPL-lizenzierten Komponenten.
• Die externe Verwendung von GPL-lizenzierten Applikationen, wenn das Geschäftsmodell in der Bereitstellung von Dienstleistungen rund um die Applikationen besteht.
• Die Verwendung von GPL-lizenzierten Komponenten in SaaS-Projekten.

In normalen kommerziellen Projekten ist zu überlegen, ob der Kunde ein Interesse haben könnte, das ihm von der GPL gewährte Recht wahr zu nehmen, die Applikation an seine Konkurrenten weiter zu reichen. Wenn das nicht der Fall ist, kann auch in solchen Projekten der Einsatz von GPL-lizenzierten Komponenten sinnvoll sein.

Hinweis

Dieser Text stellt keine Rechtsberatung im Sinne des Rechtsdienstleistungsgesetzes dar, sondern gibt lediglich die Meinung des Autors wieder.