Software-Bibliotheken

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 meist um Standardbefehle, die von mehreren Programmen unter einem Betriebssystem benötigt werden, also beispielsweise den Befehl Fenster öffnen für ein Betriebssystem, das mit Fenstern arbeitet.

Die Vorteile dieses Verfahrens sind offensichtlich: Bibliotheken erlauben einen sparsamen Umgang mit Speicherkapazität, sie sind zudem eine Arbeitserleichterung für Programmierer. Im Quelltext eines Programms bedarf es für diese kleinen Befehle mitunter mehrerer Tausend Zeilen, sie können außerdem 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, also des Objectcodes in der für den Computer ausführbaren Form.

Bibliotheken unter der GPL

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, das Teile der Bibliothek enthält. Das Executable erscheint dadurch als Derivat der Bibliothek, es fällt unter Paragraph 2b GPL und muss also auch freigegeben werden, wenn die Bibliothek unter der GPL steht.

Dynamisches Verlinken

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, also an unterschiedlichen Stellen des Speichers. Das aufrufende Programm und die Bibliotheksroutine werden erst zur Laufzeit von einer gemeinsamen Adresse aus abrufbar, während sie zuvor nur in unterschiedlichen Adressräumen kontrollierbar sind.

Man könnte daher 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, die unabhängig voneinander besteht, grundsätzlich gestattet.

Möglich erscheint es aber ebenfalls, schon bei der Frage nach der Zulässigkeit von Vervielfältigung und Vertrieb den Gesichtspunkt der Laufzeit in den Vordergrund zu stellen. Der Urheberschutz setzt schließlich nicht erst dann an, wenn das Werk auf ein Medium gebannt beziehungsweise unter eine gemeinsame Adresse zusammengeführt wurde, sondern bereits dann, wenn es als immaterielles Gut existiert. Das Programm kann damit schon 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 zugrunde gelegt. Der Vertrieb einer freien Bibliothek neben einem proprietären Programm, das die Programmroutinen der Bibliothek dynamisch einbindet, wäre demnach gemäß Paragraph 2b 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.