Freie Software ist nicht mehr nur das besondere Programmiermodell einer kleinen und einigermaßen einheitlich agierenden Community für den eigenen Bedarf, sondern entwickelt sich immer weiter zu einem Geschäftsfeld, das für neue, ganz heterogene Interessentenkreise von Bedeutung ist. Damit tauchen auch neue Vertriebssysteme auf, die neue Rechtsfragen aufwerfen, vor allem im Hinblick auf das Lizenzmodell. Das zeigte sich deutlich beim 2. ifrOSS-Seminar, das am 3. November in der Hamburger Handelskammer veranstaltet wurde [1]. Dort fanden sich Vertreter von Distributoren, Softwarefirmen und freien Projekten zusammen und konnten aus ihrem praktischen Tätigkeitsfeld Probleme schildern, die bei der täglichen Arbeit auftreten. Einige dieser Probleme, die das Nebeneinander von unterschiedlichen Lizenztypen betreffen, sollen hier herausgegriffen werden. Zunächst einmal kann man die grundlegende Frage aufwerfen, ob ein Programmierer seine selbst geschriebene Software unter mehreren Lizenzen verbreiten kann, sei es gleichzeitig oder zeitlich versetzt. Hält man sich vor Augen, dass eine Lizenz nichts anderes als ein Vertrag ist, wird schnell deutlich, dass nichts dagegen spricht, dem einen das Programm unter den Bedingungen der GPL zur Nutzung zu überlassen, dem anderen unter den Bedingungen einer anderen Lizenz, mag sie auch proprietär sein. Dass es solche Lizenzmodelle in der Praxis gibt, zeigen etwa die Beispiele der Kryptographiesoftware PKCS#11 von RSA Data Security, Inc., die als gpkcs11 unter der LGPL/GPL frei erhältlich ist [2] und des Datenbanksystems MySQL [3]. Ghostscript gibt es sogar unter drei Lizenzen: Man kann zwischen der GPL, der Aladdin License und der proprietären Artifex License wählen [4]. Ein Beweggrund für dieses Vorgehen mag der Wunsch sein, seinem Programm eine möglichst weite Verbreitung zu verschaffen, schließlich wird es zunehmend zu einem Wettbewerbsvorteil, auch auf freien Plattformen vertreten zu sein. Natürlich wird es auch Fälle geben, bei denen der Kunde nur solchen Programmen vertraut, für die er auch teuer bezahlt hat, speziell im Gebiet der Kryptographie. Aber auch so verbreitete Pakete wie StarOffice und der Netscape Communicator sind oder waren unter verschiedenen Lizenzen erhältlich. In dem Versuch, die vermeintlichen Vorteile von freier und proprietärer Software zu kombinieren, entsteht ein ziemliches Lizenzchaos, bei dem offenbar die Firmen manchmal selbst den Überblick verloren haben. Durchaus sinnvoll kann eine Doppellizenzierung aber dann sein, wenn Software durch dieses Lizenzmodell einem breiteren Kreis zur Verfügung gestellt werden kann. Ein Beispiel bietet hier das Toolkit Qt von Troll Tech, das für viele freie Projekte von Interesse ist. Würde man solche Programme nur unter die GPL stellen, wären sie für Projekte nicht mehr einsetzbar, die eine andere Lizenz verwenden und verhindern wollen, dass sie ihre Software insgesamt unter die GPL stellen müssen, weil die Lizenzbedingungen der GPL verlangen, dass modifizierter GPL-Code ebenfalls wieder unter die GPL gestellt wird. Interessant werden gesplittete Lizenzmodelle vor allem bei Fortentwicklungen. Wie sieht also die Lage aus, wenn man eine neue, weiterentwickelte Version seines Programms, das man unter die GPL gestellt hatte, nun proprietär vertreiben möchte, etwa weil man inzwischen spezielle Anwendungen für einen kleinen Kundenkreis entwickelt hat? Zunächst ist zu berücksichtigen, dass eine Lizenzierung in aller Regel nicht rückgängig gemacht werden kann. Wer einmal ein Programm unter eine freie Lizenz gestellt hat, kann nicht mehr verhindern, dass der davon betroffene Source- Code weiterverbreitet wird. Eine Kündigung oder Ähnliches gibt es bei der Einräumung von Nutzungsrechten nicht. Insoweit gilt tatsächlich: "Einmal GPL, immer GPL". Wenn so auch das Modell "proprietäre anstatt freier Software" ausgeschlossen ist, bleibt doch eine Doppellizenzierung nach dem Motto "proprietäre und freie Software" möglich. In dieser Konstellation ist danach zu unterscheiden, ob Dritte inzwischen Änderungen an dem Programm vorgenommen haben, die man weiterverwenden möchte: Ist dies nicht der Fall, greift man also bloß auf eigenen Source -Code zurück, verletzt man die GPL nicht, wenn man das Programm proprietär vertreibt. Dafür sind zwei Gründe ausschlaggebend: Die GPL enthält - wie auch die anderen Open- Source-Lizenzen - keine Selbstverpflichtung oder Verzicht auf seine urheberrechtlichen Befugnisse. Durch die GPL werden lediglich einfache Nutzungsrechte an jedermann eingeräumt. Durch den dabei geschlossenen Vertrag entsteht keine Bindung des Programmautors dahingehend, dass er seine Software nicht anderweitig nutzen dürfte. Umgekehrt darf der Lizenznehmer, also derjenige, der das von einem anderen erstellte Programm nutzt, dieses Programm nicht unter anderen Bedingungen weiterverbreiten. Der Programmautor darf als Urheber - wie bereits erwähnt - seine Software unterschiedlich lizenzieren und verletzt dabei keinen (Lizenz-)Vertrag, wenn er das eigene Programm frei und proprietär verwertet. Anders wäre die Lage nur, wenn man seinem Vertragspartner ein so genanntes ausschließliches Nutzungsrecht einräumt, das diesem die alleinigen Verwertungsbefugnis gewährt - dann ist es dem Programmautor selbst verboten, die Software noch entsprechend zu verwerten. Nichts Anderes passiert, wenn man in einem proprietär arbeitenden Softwarehaus angestellt ist. Den dabei erstellten Source -Code darf man in aller Regel selbst nicht weitergeben oder unter eine freie Lizenz stellen. Daher ist eine Doppellizenzierung nur möglich, wenn man jeweils so genannte einfache Nutzungsrechte einräumt, wie dies bei der GPL oder den anderen Open -Source-Lizenzen der Fall ist. Anders sieht die Lage aus, wenn ein Dritter aufgrund der Rechte, die er durch eine Open -Source-Lizenz erworben hat, das betreffende Programm weiterentwickelt hat. Hier würde man gegen die GPL - also gegen den mit diesem Programmautor geschlossenen Lizenzvertrag - verstoßen, wenn man die so abgeänderte Software proprietär vertreiben würde. Denn nun benötigt der ursprüngliche Programmautor die Lizenz (GPL) desjenigen, der sein Programm verändert hat, um diese Modifikationen dann weiterverbreiten zu können. Anders ist die Situation dagegen bei BSD-artigen Lizenzen: Da diese nicht copylefted sind, also nicht verlangen, dass derjenige, der das Programm unter einer freien Lizenz erhalten hat, es selbst oder seine Weiterentwicklungen auch wieder unter diese Lizenzbedingungen stellt, kann jeder solche Software - verändert oder nicht - unter beliebigen Bedingungen verbreiten. Auf die Vor- und Nachteile, die damit verbunden sind, will ich hier nicht näher eingehen, die Diskussion darüber ist hinlänglich bekannt. Wenden wir uns in diesem Zusammenhang einer weiteren Frage zu, die insbesondere für proprietäre Anbieter von Interesse ist. Kann man eine Vorversion freigeben, den Quelltext für die aktuelle Version aber unter Verschluss halten und diese gegen Lizenzgebühren veräußern? Auch hier gilt: Solange kein Quelltext Dritter enthalten ist, spricht urheberrechtlich nichts gegen ein solches "gestuftes Vertriebssystem". Allerdings sollte das Konfliktpotential nicht unterschätzt werden, das dadurch entstehen kann, dass im freien Zweig Verbesserungen durchgeführt werden, die der Anbieter nicht mehr in seinen proprietären Zweig einfügen kann. Er muss befürchten, dass ihm misstraut wird, wenn sein geheimgehaltener Sourcecode insoweit nicht überprüft werden kann. Einige Softwareunternehmen versuchen, dieses Problem dadurch zu umgehen, dass sie ihre Programme unter eine eigene "offene" Lizenz stellen, die ihnen das Recht sichert, Änderungen Dritter auch in ihre proprietären Programme einzubauen. Dies ist etwa bei der SCSL (Sun Community Source License) der Fall [5], die deswegen auch keine Open -Source-Lizenz im Sinne der OSI ist [6]. Denn sie gewährt diese besonderen Rechte nur der Firma Sun, nicht aber den anderen Programmautoren, die einen Beitrag geleistet haben. Ob man damit aber die kreative Kraft freier Entwicklergruppen für sich gewinnen kann, erscheint aber eher fraglich.
| Infos |
|
[1] Ein Seminarbericht findet sich bei: http://www.ifross.de/ifross_html/seminarbericht1.html http://www.ifross.de/ifross_html/seminarbericht1.html |
| Der Autor |
|
Till Jaeger ist Doktorand am Max-Planck-Institut für ausländisches und internationales Patent-, Urheber- und Wettbewerbsrecht in München. Im von ihm mitgegründeten ifrOSS beschäftigt er sich mit Rechtsfragen der Open Source Software. |