Bibliotheken (Libraries) stellen den unter einem Betriebssystem laufenden Programmen die von allen gemeinsam benötigten Programmroutinen zur Verfügung. Bei diesen in der Bibliothek abgelegten Programmteilen handelt es sich zumeist um Standardbefehle, welche von mehreren Programmen unter einem Betriebssystem benötigt werden, also beispielsweise der Befehl "Fenster öffnen" für ein Betriebssystem, welches mit Fenstern arbeitet. Die Vorteile der Verwendung von Bibliotheken liegen auf der Hand: Bibliotheken erlauben einen sparsamen Umgang mit Speicherkapazität, sie stellen zudem eine Arbeitserleichterung für Programmierer dar. Im Quelltext bedarf es für diese "kleinen" Befehle mitunter mehrerer tausend Zeilen, sie können also durchaus Urheberrechtsschutz genießen. Natürlich kann man auch eine solche Bibliothek "copyleften", also unter die GPL stellen. Daneben hat die FSF eine spezielle, früher "Library GPL", heute "Lesser GPL" genannte Lizenz für Bibliotheken herausgegeben. Die wichtigste OSS-Library, die GNU C Library (glibc), steht beispielsweise unter der LGPL. Warum sollte man eine Bibliothek unter die GPL stellen, wenn es dafür auch die speziellere LGPL gibt? Zur Beantwortung dieser Frage bietet es sich an, zunächst die Technik der Einbindung von Code aus der OSS-Bibliothek in das Anwendungsprogramme etwas näher zu beleuchten. Das zugreifende Programm und die Programmroutine aus der Bibliothek können statisch verbunden werden. Die Programmroutine aus der Bibliothek wird dann ständiger Bestandteil des Executables, das heißt des Objectcodes in der für den Computer ausführbaren Form. Eine andere Möglichkeit besteht darin, die beiden Programme dynamisch zu verlinken. Bei der dynamischen Einbindung von Bibliotheks-Routinen werden diese nur zur Laufzeit des Executables Teil des Objectcodes. In beiden Fällen wird die Programmroutine - jedenfalls zur Laufzeit - integraler Bestandteil des Executables in der Form des Objectcodes. Bei der statischen Verlinkung entsteht aus dem zugreifenden Programm und der Bibliothek dauerhaft ein verbundenes "neues" Programm, welches Teile der Bibliothek enthält. Das Executable erscheint dadurch als Derivat der Bibliothek, es fällt unter Paragraph 2 b GPL und muss also auch freigegeben werden, wenn die Bibliothek unter der GPL steht. Im Fall der dynamischen Verlinkung ist die Abgrenzung schwieriger: Hier werden die Programmroutinen aus der Bibliothek erst zum Moment der Laufzeit in den Objectcode eingelesen. Bis zu diesem Zeitpunkt stehen die Programme "nebeneinander", das heißt an unterschiedlichen Stellen des Speichers. Das aufrufende Programm und die Bibliotheksroutine werden erst zur Laufzeit von einer gemeinsamen Adresse aus abrufbar, während sie vorher nur in unterschiedlichen Adressräumen kontrollierbar sind. Man könnte dadurch mit guten Argumenten die Ansicht vertreten, dass der Vertrieb einer freien Bibliothek und eines proprietären, dynamisch zugreifenden Programms in einer Distribution möglich ist, da zum Zeitpunkt der Vervielfältigung und Verbreitung noch kein Derivat besteht. Dem liegt zugrunde, dass die GPL den Vertrieb von "freier" und "proprietärer" Software, welche unabhängig voneinander besteht, grundsätzlich gestattet. Möglich erscheint aber ebenfalls, auch schon für die Frage nach der Zulässigkeit von Vervielfältigung und Vertrieb auf den Moment der Laufzeit abzustellen. Der Urheberschutz setzt schließlich nicht erst dann an, wenn das Werk auf ein Medium gebannt bzw. unter eine gemeinsame Adresse zusammengeführt ist, sondern bereits dann, wenn es als immaterielles Gut existiert. Das Programm kann so bereits eine konkrete Formgestaltung gefunden haben. Auch wenn also erst beim User die "Verschmelzung" von Programmroutine und zugreifendem Programm im Objectcode des Executables stattfindet, kann bereits der gemeinsame Vertrieb als Verbreitung eines Derivats angesehen werden. Bei dieser Sicht bietet es sich an, statische und dynamische Verlinkung gleich zu behandeln. Diese Auffassung scheint auch die Lesser GPL in ihrer Präambel zu teilen, sie wird im Folgenden zugrundegelegt. Der Vertrieb einer freien Bibliothek neben einem proprietären Programm, welches die Programmroutinen der Bibliothek dynamisch einbindet, wäre demnach gem.äß Paragraph 2 b GPL ausgeschlossen. Es sei aber nochmals darauf hingewiesen, dass diese Rechtsauffassung nicht zwingend ist. Der Hinweis in der Präambel der LGPL, man solle stets auch für Software-Bibliotheken zuerst die GPL in Betracht ziehen, ist wegen der unklaren Rechtslage deshalb mit Vorsicht zu genießen. Was aber nun, wenn die Bibliothek unter der LGPL steht? Die Paragraphen 1 und 2 LGPL sind im Wesentlichen identisch mit den Regelungen der GPL. Auch für die Bibliothek unter der LGPL gilt also "Study, Copy, Modify, Redistribute". Man darf eine unter der LGPL stehende Bibliothek unverändert vervielfältigen und verbreiten, man darf sie seinen persönlichen Bedürfnissen entsprechend verändern und auch die veränderte Version wiederum verbreiten. Dies gilt gem.äß Paragraph 2 a LGPL allerdings nur, wenn auch das Derivat eine Bibliothek darstellt. Auch weitere lange Passagen entsprechen der GPL, das gilt für Paragraph 4 LGPL (Paragraph 3 GPL), Paragraphen 8-14 LGPL (§§ 4-10 GPL). Paragraph 3 LGPL regelt den Umstieg von der LGPL auf die GPL. Von besonderem Interesse sind aber die Paragraphen 5 und, 6 LGPL: Paragraph 5 Abs. 1 besagt, dass ein Programm, welches für den Zugriff auf eine Bibliothek geschrieben ist, als solches ("in isolation") nicht von der Lizenz erfasst wird. Dies kann es auch nicht nach der Gesetzeslage. Das Programm kann also ohne Restriktionen "proprietär" vertrieben werden, solange dies in isolierter Form geschieht. Spannend sind Paragraph 5 Abs. 2 und 3 LGPL: Hier definiert die LGPL, was eine "work that uses the library" darstellt. Die LGPL geht in Paragraph 5 Abs. 2 davon aus, dass auch bei dynamischer Verlinkung bereits bei der gemeinsamen Vervielfältigung und Verbreitung von Bibliothek und zugreifendem Programm ein Derivat entsteht. Dies aus den gesetzlichen Vorschriften des Urheberrechts ableiten zu wollen ist - wie bereits zu zeigen versucht wurde - zwar nicht zweifelsfrei möglich. Andererseits steht es dem Lizenzgeber natürlich frei, das eingeräumte Nutzungsrecht inhaltlich insoweit einzuschränken, dass auch dynamisch verlinkte Programme nach den vertraglichen Bestimmungen über Derivate zu behandeln sind. Auch wenn man also davon ausgeht, dass durch den gemeinsamen Vertrieb einer GPL-Bibliothek mit einem zugreifenden Programm sich noch nicht die Verpflichtung ergibt, auch das zugreifende Programm zu "copyleften", so unterstellt Paragraph 5 Abs. 2 LGPL jedenfalls durch eine vertraglich verbindliche Festlegung, dass auch dynamisch verlinkte Programme wie Derivate zu behandeln sind. Paragraph 5 Abs. 2 LGPL ist für die weitere Auslegung der LGPL entscheidend. Der Paragraph 2 c LGPL ist also jedenfalls durch die vertragliche Festlegung des Paragraphen 5 LGPL - auch auf Programme anzuwenden, welche dynamisch mit der Bibliothek verlinkt sind. Paragraph 5 Abs. 4 LGPL nimmt kleinste Programmteile von den Verpflichtungen der LGPL aus. Greift man mit einem proprietären Programm auf numerische Parameter, kleine Makros von unter 10 Zeilen oder ähnliches zurück, so entsteht dadurch kein Derivat der Bibliothek. Dies entspricht der Gesetzeslage. Paragraph 6 LGPL schließlich mindert die Verpflichtung des Paragraphen 2 c LGPL für "work that uses the library" ab. Für die durch Verlinkung mit der Bibliothek entstehenden Derivate greift Paragraph 2 c LGPL nicht in seiner ganzen Schärfe zu. Die OSS-Bibliothek und das zugreifende Programm dürfen danach auch dann zusammen verbreitet werden, wenn dem User Veränderungen für die eigenen Bedürfnisse gestattet sind; dem User "reverse engineering for debugging" gestattet ist; jede Kopie einen auffälligen Hinweis auf die Nutzung der OSS-Bibliothek und die LGPL enthält; eine Kopie der LGPL beigefügt ist; und eine der folgenden Bedingungen erfüllt ist: * Paragraph 6 a LGPL: Beifügung des gesamten Source Codes des Executables, das heißt die OSS-Bibliothek und das zugreifende Programm. Es genügt jedoch gemäß Paragraph 6 c LGPL auch das schriftliche Angebot hierzu. * oder Paragraph 6 b LGPL: Es muss ein hinreichend verbreiteter Linking-Mechanismus gewählt werden. Dieser muss zudem "suitable" (geeignet) sein. Das zugreifende Programm muss auch mit einer veränderten Version der Bibliothek arbeiten können, soweit die neue Bibliothek Schnittstellen-kompatibel mit der alten Bibliothek ist. Dies ermöglicht jedenfalls auch eine Kombination von OSS-Bibliothek mit "geschlossener" Software. Die umfangreiche Regelung des Paragraph 6 LGPL hat ihr das Prädikat eingebracht, "lesser" gegenüber der GPL zu sein, also weniger zu fordern. Dies trifft auf den ersten Blick natürlich zu. Nach den Vorschriften der GPL muss jedes Derivat "freigegeben" werden, also seinerseits quelloffen sein und dem User die vier Grundfreiheiten <\#227>Study, Copy, Modify, Redistribute" einräumen. Die LGPL unterstellt zwar "works that uses the library" qua vertraglicher Definition der Regelung für Derivate, sie korrigiert die Verpflichtungen aber zugleich auch für diese "work that uses the library" in Paragraph 6 erheblich nach unten. Gleichwohl erscheint der Schutz, den die LGPL gegen eine proprietäre Ausnutzung freier Bibliotheken bietet, sicherer als derjenige der GPL. Denn die Verpflichtungen der LGPL greifen in jedem Fall, unabhängig davon, welche Auffassung man im Hinblick auf die ungeklärte juristische Frage zum Durchgreifen der GPL bei dynamischem Verlinken auch vertreten mag. Um es auf eine Formel zu bringen: Die LGPL garantiert den Bibliotheken zwar ein Weniger an Freiheit, dafür aber ein Mehr an Rechtssicherheit.
| Der Autor |
|
Axel Metzger 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. |