Ein Problem, auf das Copyleft-Juristen immer wieder angesprochen werden, betrifft die Bibliotheken für Open-Source- Software. Diese werfen spezielle Fragen auf, von denen die wichtigsten im Folgenden angesprochen werden.

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.

Weniger GPL – mehr Schutz für die Freiheit der Bibliothek

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 diese veränderte Version verbreiten. Das gilt gemäß Paragraph 2a LGPL allerdings nur dann, wenn auch das Derivat wieder eine Bibliothek ist.

Auch weitere lange Passagen entsprechen der GPL, das gilt für Paragraph 4 LGPL (Paragraph 3 GPL) und die Paragraphen 8 bis 14 LGPL (§§ 4 bis 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 Absatz 1 besagt, dass ein Programm, das für den Zugriff auf eine Bibliothek geschrieben ist, als solches (“in isolation”) nicht von der Lizenz erfasst wird.

Auch dynamisch verlinkte Programme sind Derivate

Nach der Gesetzeslage ist dies auch nicht möglich. Das Programm kann also ohne Restriktionen proprietär vertrieben werden, solange dies in isolierter Form geschieht. Spannend sind in Paragraph 5 LGPL die Absätze 2 und 3: Hier definiert die LGPL, was eine “Work that uses the library” ist. Sie geht in Paragraph 5 Absatz 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 zuvor beschrieben 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.

Nicht jede Nutzung erzeugtein Derivat

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 Absatz 2 LGPL jedenfalls durch eine vertraglich verbindliche Festlegung, dass auch dynamisch verlinkte Programme wie Derivate zu behandeln sind. Paragraph 5 Absatz 2 LGPL ist für die weitere Auslegung der LGPL entscheidend. Paragraph 2c LGPL ist also durch die vertragliche Festlegung des Paragraphen 5 auch auf dynamisch mit der Bibliothek verlinkte Programme anzuwenden.

Paragraph 5 Absatz 4 LGPL nimmt kleinste Programmteile von den Verpflichtungen der LGPL aus. Greift man mit einem proprietären Programm auf numerische Parameter, kleine Makros von weniger als zehn Zeilen oder Ähnliches zurück, entsteht dadurch kein Derivat der Bibliothek. Das entspricht der Gesetzeslage.

Paragraph 6 LGPL mindert die Verpflichtung des Paragraphen 2c LGPL für “Work that uses the library”. Für die durch Verlinkung mit der Bibliothek entstehenden Derivate greift Paragraph 2c nicht in seiner ganzen Schärfe.

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; wenn ihm “Reverse engineering for debugging” gestattet ist; wenn jede Kopie einen auffälligen Hinweis auf die Nutzung der OSS-Bibliothek und die LGPL enthält; wenn eine Kopie der LGPL beigefügt ist und wenn eine der folgenden Bedingungen erfüllt ist:

n Paragraph 6a LGPL: Beifügung des gesamten Source-Codes des Executables, also der OSS-Bibliothek und des zugreifenden Programms. Es genügt jedoch gemäß Paragraph 6c LGPL auch das schriftliche Angebot hierzu.

n Paragraph 6b 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. Das ermöglicht jedenfalls auch eine Kombination von OSS-Bibliothek mit “geschlossener” Software.

Was ist ein “Work that uses the library”?

Die umfangreiche Regelung des Paragraph 6 LGPL hat ihr das Prädikat eingebracht, “lesser” gegenüber der GPL zu sein, also weniger zu fordern. Das 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 “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 “Works” 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. ( uwo)n