23.10.2012, 10:31 Uhr

Durchblick bei Open Source

Viele Entwickler nutzen für eigene Softwareprojekte Open Source Softwaremodule unter der GNU General Public License (GPL) oder der GNU Lesser General Public License (LGPL). Dabei werden die rechtlichen Konsequenzen oft zu wenig bedacht.
Wer Software öffentlich zugänglich machen will, muss einige rechtliche Aspekte beachten.
*Der Autor ist Rechtsanwalt bei Rentsch Partner AG in Zrich und Spezialist für IT-Recht.

Hintergrund von GPL und LGPL 

Die GPLv1 (erste Version) wurde im Januar 1989 von Richard Stallman, dem Gründer des GNU-Projekts, für die Free Software Foundation, Inc. verfasst und umfasste rund 4 A4-Seiten. Wenige Jahre später (1991) wurde eine zweite Version der GPL (GPLv2) publiziert, die bereits etwas länger war. Erheblicher waren aber die Änderungen in der dritten Version (GPLv3), welche 2007 veröffentlicht wurde und rund zehn A4-Seiten umfasst.
Die LGPL wurde 1991 von der Free Software Foundation, Inc. in einer ersten Version (damals noch als GNU Library Public License) zeitgleich mit der GPLv2 veröffentlicht und speziell für die Verwendung mit Softwarebibliotheken verfasst, für welche sich die Bestimmungen der GPL oftmals als zu streng erwiesen. Die LGPL wurde 1999 in einer Version 2.1 überarbeitet (LGPLv2.1). Die aktuelle Version 3 (LGPLv3) wurde gleichzeitig mit der GPLv3 veröffentlicht (hat aber immer noch auf 3 A4-Seiten Platz).
Richard Stallman hatte das Ziel, eine Open Source Lizenz mit strengem Copyleft (als Kontrapunkt zum Copyright) zu entwickeln, die man bei jedem Projekt verwenden kann. Mit der LGPL sollte eine von der GPL abgeleitet, aber weniger strenge Version der GPL geschaffen werden (beschränktes Copyleft).

Die Bewegung der Free Software Foundation

Die GNU Lizenzen sind Produkte der Free Software Foundation, einer Stiftung, die 1985 von Richard Stallman als gemeinnützige Organisation mit dem ideellen Zweck gegründet wurde, freie (beziehungsweise Open Source) Software zu fördern und für diese Arbeit Spenden zu sammeln.
Die wesentlichen Prinzipien oder Freiheitenhttp://www.gnu.org/philosophy/free-sw.html, welche von der Free Software Foundation verfochten werden, sind (1) die Freiheit, Software für jeden Zweck auszuführen beziehungsweise zu nutzen, (2) die Freiheit, die Funktionsweise der Software zu untersuchen und eigenen Bedürfnissen anzupassen (der Zugang zum Quellcode ist dafür Voraussetzung), (3) die Freiheit, die Software weiterzuverbreiten, und (4) die Freiheit, die Software zu verbessern und diese Verbesserungen der Öffentlichkeit freizugeben (der Zugang zum Quellcode ist auch dafür Voraussetzung). Damit diese Freiheiten durchsetzbar sind, müssen sie grundsätzlich dauerhaft und unwiderruflich gelten.
Freie Software darf grundsätzlich auch kommerziell verwertet werden, solange gleichzeitig die Lizenzbedingungen eingehalten werden. Allerdings sehen sowohl die GPL als auch die LGPL vor, dass eine Lizenzgebühr nur für die Kosten der Kopie und der Verbreitung, oder für eigene Garantieleistungen verlangt werden darf. Selbstredend darf auch für die Beratung im Zusammenhang mit Open Source Software ein Entgelt verlangt werden.
Lesen Sie auf der nächsten Seite: Die wesentlichen Pflichten bei der Verbreitung unveränderter Software

Die wesentlichen Pflichten bei der Verbreitung unveränderter Software

Vor dem Hintergrund dieser Prinzipien sind die Bestimmungen der GPL und LGPL zu sehen. Eine erste wesentliche Verpflichtung bei der Verbreitung ist, dass der Lizenztext zusammen mit der Software verbreitet wird. Dies ist wesentlich, um sicherzustellen, dass auch weitere Nutzer der Software sich den Regeln der entsprechenden Lizenz unterwerfen. Vor demselben Hintergrund wird verlangt, dass bei jeder Verbreitung auf das Copyright und die anwendbare Lizenz hingewiesen wird. Der Copyrightvermerk soll auch den Ausschluss von Haftung und Gewährleistung umfassen. Weil Haftung und Gewährleistung erhebliche Risiken mit sich bringen und der Verbreitung damit entgegenwirken können, ist der vertragliche Ausschluss von Haftung und Gewährleistung essentiell. Bestehende Vermerke und Hinweise dürfen bei der Weiterverbreitung nicht verändert werden.
Verschiedene Prinzipien oder Freiheiten möchten sicherstellen, dass der Nutzer die Software modifizieren kann, sei es, um sie seinen eigenen Bedürfnissen anzupassen, oder um sie zu verbessern und weiterzuentwickeln. Für beide Nutzungen ist der Nutzer letztlich auf den Quellcode angewiesen. Die Lizenzbestimmungen enthalten daher die zentrale Verpflichtung, den Quellcode bei der Verbreitung mitzuliefern (oder ? je nach Art der Verbreitung ? zumindest verfügbar zu machen).

Die wesentlichen Pflichten bei der Verbreitung veränderter Software

Etwas komplexer wird es, wenn Software vor der Verbreitung verändert (in der Regel verbessert beziehungsweise weiterentwickelt wird). Dies bringt verschiedene zusätzliche Verpflichtungen mit sich. Vorab muss der Copyrightvermerk der veränderten Software mit einem Hinweis auf die vorgenommenen Änderungen und das Datum der Änderungen ergänzt werden. Es soll für die weiteren Nutzer klar erkennbar sein, dass die Software geändert wurde.
Wesentlich einschneidender ist die Verpflichtung, die veränderte Software wiederum unter der GPL beziehungsweise LGPL zu verbreiten. Diese Verpflichtung umfasst indirekt auch sämtliche oben erwähnten Pflichten, insbesondere die Pflicht, den Quellcode der veränderten Software zu verbreiten. Allerdings ist ein Entwickler nicht verpflichtet, veränderte Open Source Software weiterzuverbreiten. Wird zum Beispiel Software unter GPL für die Bedürfnisse eines Unternehmens angepasst und anschliessend nur in diesem Unternehmen genutzt, besteht keine Pflicht, die angepasste Software unter GPL weiter zu verbreiten.
In der Praxis stellt sich sehr häufig die Frage, ob eine veränderte Software vorliegt, wenn eigene (proprietäre) Software mit (an sich unveränderter) Software unter GPL oder LGPL lediglich kombiniert wird. Entscheidend für diese Frage ist letztlich die Art und Weise der Verbindung zwischen eigener Software und Open Source Software. Den Prinzipien der Free Software Foundation folgend, muss sichergestellt werden, dass im Rahmen der weiteren Verbreitung der Nutzer trotz der Kombination weiterhin in der Lage ist, die Software unter GPL oder LGPL eigenständig zu nutzen und zu bearbeiten.
Lesen Sie auf der nächsten Seite: Probleme bei der Kombination von Software unter GPL/LGPL mit eigener Software

Probleme bei der Kombination von Software unter GPL/LGPL mit eigener Software

Für die Beurteilung der Problematik der Kombination von Open Source mit proprietärer Software gibt es erstens eine formale Sichtweise (Sind die unterschiedlichen Softwarebestandteile getrennt, auch wenn sie auf einem Datenträger verbreitet werden?) und eine inhaltlich-funktionelle Sichtweise (Werden die Softwarebestandteile auch funktionell als eigenständig wahrgenommen oder als Funktionen ein und desselben Programms?). Die Beurteilung unter der neuen GPLv3 ist dabei wesentlich komplizierter als unter GPLv2, weil mit der GPLv3 neue, teilweise nur im Verhältnis zum nationalen Urheberrecht auslegbare Begriffe eingeführt worden sind.

Klar ist der Grundsatz, dass Softwarebestandteile durchaus auf einem (gemeinsamen) Datenträger verbreitet werden dürfen; die Verbreitung auf einem Datenträger an sich stellt also noch kein Problem dar. Entsprechend dürfen Softwarebestandteile, die nicht voneinander abgeleitet sind, auch auf einem gemeinsamen Datenträger, unter unterschiedlichen Lizenzen, verbreitet werden. Softwarebestandteile, die zwar nicht voneinander abgeleitet sind, aber funktionell eine «Ganzes» bilden, müssen dagegen in der Regel insgesamt unter GPL oder LGPL verbreitet werden. Softwarebestandteile, die gemeinsam in einem Executable (ausführbare exe-Datei) vertrieben werden, müssen immer insgesamt unter GPL oder LGPL verbreitet werden, weil der Nutzer ansonsten die im Executable integrierte Open Source Software nicht mehr lizenzgemäss nutzen und bearbeiten kann.
Die Beurteilung, ob eine Verbreitung von Softwarebestandteilen unter unterschiedlichen Lizenzen zulässig ist, kann im Einzelfall rechtlich komplex und schwierig sein, so dass man auf die Unterstützung eines spezialisierten Rechtsanwalts oder einer spezialisierten Rechtsanwältin angewiesen ist. Einige Praxisfälle haben sich immerhin inzwischen ausgebildet. So gelten statische Verlinkungen von GPL oder LGPL Software mit eigener (proprietärer) Software in der Regel als Einheit, so dass ein Vertrieb nur unter GPL oder LGPL in Frage kommt. Beim dynamischen Verlinken kommt es wesentlich auf die funktionalen Kriterien an. Wenn GPL oder LGPL Software (insbesondere eine Softwarebibliothek) verlinkt wird, um der eigenen Software «nur» zusätzliche (aber nicht die wesentlichen) Funktionen zu verleihen, so kann oftmals von separaten Softwarebestandteilen ausgegangen werden, womit ein Vertrieb unter unterschiedlicher Lizenz zulässig ist. Klar ist in der Regel auch, dass die Nutzung von Entwicklungsumgebungen unter GPL nicht dazu führt, dass die damit entwickelte Software auch unter GPL weitervertrieben werden müsste, es sei denn, die entwickelte Software enthalte Softwarebestandteile unter GPL.
Unabhängig davon muss man sich jedoch immer bewusst sein, dass zumindest der Softwarebestandteil unter GPL oder LGPL immer unter diesen Lizenzen weiterverbreitet werden muss.
Lesen Sie auf der nächsten Seite: Verbreitung unter eigener Lizenz?

Verbreitung unter eigener Lizenz?

Gibt es Fälle, in welchen es zulässig ist, Software und GPL oder LGPL mit proprietärer Software zu kombinieren und dann insgesamt unter den eigenen (proprietären) Lizenzbedingungen zu verbreiten? Unter GPL ist ein solches Szenario nicht vorgesehen. Die LGPL gestattet ausnahmsweise, dass eine Softwarebibliothek, welche von eigener Software genutzt wird, insgesamt unter eigenen (proprietären) Lizenzbedingungen vertrieben werden darf; diese Erlaubnis ist jedoch an Bedingungen geknüpft.
So muss in den eigenen Lizenzbedingungen zugelassen werden, dass der Nutzer auch auf die eigene Software zugreifen darf, um Fehler zu beheben. Dazu muss auch Reverse Engineering erlaubt werden. Zudem muss deutlich darauf hingewiesen werden, dass die eigene Software auf eine Bibliothek unter LGPL zugreift und diese Bibliothek unter LGPL genutzt werden darf. (Aus diesem Grund muss auch der Lizenztext mitgeliefert werden.) Zu alledem muss sichergestellt werden, dass der Nutzer zumindest auf den Quellcode der Bibliothek zugreifen kann, um seine Rechte wahrzunehmen.
Daneben erlaubt die neueste Version der GPL (GPLv3), dass für eigene Entwicklungen, welche unter GPLv3 vertrieben werden, gewisse eigene (insbesondere einschränkende) Bestimmungen in die Lizenzbedingungen eingefügt werden dürfen. Dies betrifft etwa Bestimmungen zu Gewährleistung und Haftung, zur Nutzung von Markenzeichen oder zur Freistellung des Lizenzgebers durch Lizenznehmer, welche in den Verträgen mit den Endnutzern weitergehende Verpflichtungen eingehen.
Wer sich komplexe rechtliche Fragen ersparen will, vertreibt eigene Software und Softwarebestandteile unter GPL oder LGPL mit Vorteil getrennt. Soweit technisch machbar, kann auch nur die eigene (proprietäre) Software vertrieben, und es im Übrigen dem Nutzer überlassen werden, sich die erforderliche Software unter GPL oder LGPL zu beschaffen. Weil dies aber nicht benutzerfreundlich ist, entscheiden sich viele Entwickler für einen Vertrieb der unterschiedlichen Bestandteile als unabhängige (separate) Dateien auf einem einzigen Datenträger, wobei dann ein Installer sämtliche erforderlichen Softwarebestandteile installiert. Auch in diesem Fall ist darauf zu achten, dass die Verpflichtungen für den Vertrieb der Bestandteile unter GPL und LGPL erfüllt werden. Bei einem interaktiven Installer empfiehlt es sich dazu unter anderem, Copyrightvermerke (einschliesslich Gewährleistungs- und Haftungsausschluss) vor der Installation anzuzeigen und auf die jeweils anwendbare Lizenz hinzuweisen.
 



Das könnte Sie auch interessieren