Leider schwammig
Früh hat man sich auch schon daran ge­macht, diese Freiheit durch ein entspre­chendes Dokument zu sichern, die GNU General Public License (GPL, [1], [2]) - als Zentraldokument der Community berühmt, aber als schwammige Quelle und Gegenstand juristischer Auseinan­dersetzungen berüchtigt. Entworfen von Richard Stallman und Eben Moglen enthält die GPL seit ihrer Verabschiedung im Jahre 1989 eine Reihe von Regeln zu Nutzung und Vertrieb von Open-Source-Produkten. Die Gerichte haben diese Regeln in einzelnen Fällen für verbindlich angesehen. Dennoch bestehen erhebliche Zweifel an der Verbindlichkeit, was die Vereinbar­keit mancher Klauseln mit dem deut­schen Recht angeht. Zum Beispiel ent­hält die GPL in Ziffer 16 einen Haftungs-ausschluss: „In keinem Fall, außer wenn durch geltendes Recht gefordert oder schriftlich zugesichert, ist irgendein Ur­heberrechtsinhaber oder irgendein Drit­ter, der das Programm wie oben erlaubt modifiziert oder übertragen hat, Ihnen gegenüber für irgendwelche Schäden haftbar [...]" Das widerspricht dem deut­schen Gedanken, dass selbst bei Schen­kungen eine Haftung für Vorsatz und grobe Fahrlässigkeit besteht und auch nicht vertraglich beschränkbar ist. Dass die GPL auch für den Käufer von Open-Source-Software verbindlich sein soll, widerspricht dem Grundgedanken, dass eine einmal gekaufte Ware in ih­rer Weiterverbreitung nicht vertraglich reglementiert werden kann. Besondere Schwierigkeiten macht den deutschen Juristen auch die Konstruktion der so genannten Bedingung. Die GPL-Version 2 [1] stellt darauf ab, dass überhaupt nur jemand freie Software nutzen kann, der eine Reihe von Verpflichtungen über­nimmt. Die Rede ist davon, dass die Li­zenz „under the condition", das heißt, unter der Rechtsbedingung der Einhal­tung dieser Verpflichtungen stehe. Diese Bedingungskonstruktionen sind sehr scharf, wie das Landgericht Mün­chen feststellte. Denn entweder sind die Bedingungen der GPL 2 nach deutschem Recht verbindlich, so die Richter, oder sie sind nicht verbindlich - dann würde der Anwender aber gar kein Nutzungs­recht erhalten.
Mit der GPL-Version 3 [3] gibt es in die­ser Hinsicht Neues zu vermelden. Der Begriff „under the condition" findet sich hier nicht mehr. Stattdessen heißt es in der deutschen Version der GPL 3, dass die gewährten Rechte unwiderruflich seien, solange die festgelegten Bedin­gungen erfüllt sind. Insofern führt die Nichteinhaltung der Bedingungen nicht mehr automatisch zum Wegfall der Rechte. Vielmehr kann bei Nichteinhal­tung der GPL ein Widerruf der Rechte erklärt werden.

Lizenz-Automatik
Weggefallen ist auch der frühere Passus, dass der Verkäufer bei Weiterübertra­gung von Nutzungsrechten die GPL ver­bindlich machen müsse. Nunmehr heißt es in Ziffer 10, dass der Empfänger auto­matisch vom ursprünglichen „Lizenzge­ber" eine entsprechende Lizenz erhalte (Abbildung 1). Rätselhaft bleibt aber, wie eine solche „automatische Lizenzierung" nachgeordneter Anwender eigentlich vor sich gehen soll. Die Rechtsordnung kennt automatische Lizenzen nicht. Unklar bleibt auch, wie die GPL 3 ver­bindlich werden soll. Sehr viele Open-Source-Produkte sind unter älteren Ver­sionen der GPL in den Verkehr gebracht worden. Daher stellt sich die Frage, ob die GPL 3 automatisch auch die Alt-Produkte umfasst. In der Lizenz selbst findet sich der Hinweis, dass die Free Software Foundation berechtigt sei, von Zeit zu Zeit überarbeitete und/oder neue Versionen der GPL zu veröffentlichen (Ziffer 14).
Sollte mit diesem Satz allerdings ge­meint sein, dass diese neuen Versionen dann automatisch verbindlich gelten, widerspricht dies dem deutschen Recht. Auch der jetzt in der GPL 3 enthaltene Hinweis, dass Gewährleistungs- und Haftungsausschlüsse nur dann zum Tragen kommen, soweit dies gesetzlich zulässig ist, ist nicht mit hiesigem Recht vereinbar.

Ungeliebte Juristen
Insgesamt finden sich auch in der neuen Version der GPL so viele Rechtsverstöße, dass sich die Frage nach der Sinnhaftig-keit dieses Dokuments stellt. Wer ältere Dokumente von Stallman studiert, stößt darauf, dass Stallman eine Abneigung gegen Juristen hatte und sein Dokument eher als eine Art Code of Conduct (Ver­haltenskodex) verstanden hat. Wenn überhaupt, geriet das Dokument erst durch die Hinzuziehung des Juristen Moglen „juristisch".
Moglen hat die GPL allerdings nur nach Maßgabe amerikanischen Rechts bearbeitet und sich nie Gedanken darüber gemacht, dass es außerhalb der USA Rechtsordnungen gibt, die anders strukturiert sind. Insofern muss man zumindest aus europäischer Perspektive die Frage stellen, wie mit diesem Dokument umzugehen ist. (m.hu)

I. Die GPL nicht ernst nehmen. Egal ob man die GPL für rechtlich verbindlich hält oder nicht: Ein Verstoß gegen die GPL gibt sehr oft Anlass zu Auseinandersetzungen. Setzen Sie sich also mit der GPL auseinander und versu­chen Sie sich bei der Verwendung von Open-Source-Produkten an den dort vorgesehenen Rahmen zu halten.
II. Sich auf die GPL verlassen. Die GPL hat zahlreiche Lücken, rechtliche Fehler und Durchsetzungsprobleme. Wer sich als Programmierer auf die GPL verlässt, zieht oft den Kürzeren.
III. Bei Verletzung der GPL auf Schadens­ ersatz hoffen. Programmierer, die ihre freie Software in GPL-widrigen Zusammenhängen wiederfinden, wünschen oft Schadensersatz. Doch Schadensersatz, so die Rechtsprechung, kann nur die gesamte Entwickler-Community hinter einem Softwareprodukt fordern, nicht der einzelne Entwickler.
IV. Nicht auf die GPL hinweisen. Bislang hat die Rechtsprechung einen Verstoß gegen die GPL rein formal dann angenommen und sank­tioniert, wenn der Entwickler nicht auf die GPL-Lizenzierung des Produkts hingewiesen hat. Wer freie Software nutzt und insbesondere vertreibt, muss auch darauf hinweisen, dass es sich um solche handelt, und den Text der GPL nach Möglichkeit dem Produkt beilegen.
V. Die Grenze zur eigenentwickelten Software falsch einschätzen. Die GPL gilt nicht nur für freie Software, sondern unter bestimmten Voraussetzungen auch für davon abgeleitete, eigenentwickelte Programme. Insofern bedarf jedes Softwareprojekt einer eingehenden Prü­fung, ob darin GPL-lizenzierte Komponenten enthalten sind.
VI. Sich die Open-Source-Freiheit nicht zusichern lassen. Wer sich von externen Programmierern proprietäre Software entwickeln lässt,
sollte sich auf jeden Fall schriftlich bestätigen lassen, dass die gelieferte Software keine Open-Source-Komponenten enthält. Sonst ist er möglicherweise nachträglich in einen furchtbaren Prozess verwickelt und kann sich nicht dadurch entlasten, dass er auf den be­auftragten Software-Entwickler verweist.
VII. Die Haftungsbeschränkung der GPL ernst nehmen. Die GPL schließt die Haftung und Gewährleistung für Open-Source-Produkte gänzlich aus. Dies ist rechtswidrig. Sollten in einem Open-Source-Projekt grobe Schnitzer passieren, ist dies trotz der GPL Anlass für juristische Auseinandersetzungen.
VIII. Die GPL in der USA-Version verwenden. In der Zwischenzeit gibt es die GPL-Version 3 schon in deutscher Sprache. Es empfiehlt sich, das deutsche Dokument zu verwenden, gerade auch wegen der beschriebenen Probleme bei der Anwendung von US-Recht in Europa.