Die GNU Lesser General Public License oder LGPL (ehemals GNU Library General Public License) ist eine von der Free Software Foundation (FSF) entwickelte Lizenz für freie Software. Die LGPL erlaubt den Entwicklern und Firmen das Verwenden und Einbinden von LGPL-Software in eigene (sogar proprietäre) Software, ohne durch ein starkes Copyleft gezwungen zu sein, den Quellcode der eigenen Software-Teile offenzulegen. Lediglich das Ändern der LGPL-Software-Teile muss Endnutzern ermöglicht werden: Deshalb werden im Falle von proprietärer Software die LGPL-Teile meist in Form einer dynamischen Programmbibliothek (z. B. DLL) verwendet, um so die notwendige Trennung zwischen proprietären und quelloffenen LGPL-Teilen zu ermöglichen.
Die LGPL wurde somit als Kompromiss zwischen dem starken Copyleft der GNU General Public License (GPL) und freizügigerer Lizenzen wie der BSD-Lizenzen und der MIT-Lizenz entwickelt. Das Wort Lesser (im Sinne von „weniger“) im Namen der Lizenz soll zum Ausdruck bringen, dass LGPL den Endnutzern nicht vollkommene Freiheit in der Verwendung von Software garantieren kann, da nur die LGPL-Teile, nicht aber etwaige proprietäre Software-Teile den Endnutzern die Freiheit auf Modifizierung gewähren.
Die LGPL wurde im Jahr 1991 veröffentlicht und nahm gleich die Versionsnummer 2 an, um zahlenmäßig mit der GPL-Version 2 übereinzustimmen. Im Jahre 1999 wurde die LGPL geringfügig verändert und mit 2.1 versioniert, außerdem wurde der Name in GNU Lesser General Public License umbenannt, um dem Standpunkt der FSF Ausdruck zu verleihen, dass nicht alle Bibliotheken die LGPL nutzen sollen. Version 3 der LGPL wurde im Jahr 2007 veröffentlicht, um mit zusätzlichen Berechtigungen der GPL-Version 3 übereinzustimmen.
Die LGPL wird hauptsächlich für Software-Bibliotheken, aber auch mit eigenständiger Software eingesetzt.
Bedingungen/technische Einhaltung Bearbeiten
Im Gegensatz zur GPL darf bei der LGPL auch geschlossener (d. h. proprietärer) Code mit dem LGPL-Code kombiniert werden, allerdings nur, wenn folgende Bedingung eingehalten wird: Ein Programm, das LGPL-Code zusammen mit eigenem proprietärem Code verwendet, muss so aufgebaut sein, dass jeder Endnutzer den quelloffenen LGPL-Code (oder modifizierte Versionen davon) in das endgültige Programm (selbständig) linken kann. Dies kann entweder durch dynamisches Linken geschehen (wo der LGPL-Code in einer dynamischen Bibliothek verwendet wird); dann kann der Endnutzer eine eigene dynamische Bibliothek (Linux-Jargon: Shared Object) des LGPL-Teils erstellen (beispielsweise aus einer modifizierten Version des LGPL-Codes) und nutzen. Oder es kann durch statisches Linken geschehen – dann bekommt ein Endnutzer typischerweise die Objektdateien (oder Quelltext) des proprietären Codes und die Quelltexte des LGPL-Codes und kann diese zusammenlinken.
Diese Bedingung ist derart, dass der Nutzer den LGPL-Teil ändern und neu einbinden können muss und darin nicht eingeschränkt werden darf; somit müssen dem Nutzer Installationsinformationen zur Verfügung gestellt werden, um eine modifizierte Version des LGPL-Teils in das kombinierte Werk installieren und ausführen zu können; ferner darf dem Nutzer zum Debuggen von Änderungen des LGPL-Teils auch Reverse Engineering nicht untersagt werden.
Normalerweise linkt der Hersteller proprietärer Software sein Programm einfach dynamisch gegen die fragliche LGPL-Bibliothek. Dadurch enthält die Software eine klare Trennung zwischen LGPL-Code und dem proprietären Teil.
Beispiele für Bibliotheken unter LGPL sind die Standardbibliotheken der einzelnen Programmiersprachen, wie beispielsweise die glibc (Implementierung der Standard C Library der Free Software Foundation) oder auch die GnuMP-Bibliothek.
Für eine C++-Bibliothek, die viele inline-Funktionen und Klassenvorlagen („templates“) verwendet, wird meist eine (etwaigen dritten Entwicklern gegenüber) weniger restriktive Lizenz als LGPL gewählt, sofern eine Verwendung der Bibliothek zusammen mit verschlossenem (proprietärem) Code erlaubt sein soll. Denn der proprietäre Code muss in dem Fall die inline-Funktionen und den Template-Code der Bibliothek usw. bereits im Quelltext enthalten, und daher können dem Endnutzer keine Objektdateien des proprietärem Codes gegeben werden, da etwaige Modifizierungen von inline-Funktionen (der Bibliothek) schon im Quelltext eingebunden werden müssen. Als Beispiel ist libstdc++ (GNU C++ Library) zu nennen, welche zahlreiche inline-Funktionen und Templates nutzt: Hier haben sich die Entwickler von libstdc++ für eine GPL-Lizenz mit speziellem Zusatz entschieden, die dem Entwickler erlaubt, libstdc++ mit eigenem Code zu mischen, wobei der eigene Code weder unter GPL noch LGPL zu stehen braucht (aber es natürlich darf). Insbesondere entfällt in diesem Fall die Forderung, dass ein Endnutzer die libstdc++-Bibliothek in geänderter Form (statisch oder dynamisch) linken können muss, und ist somit gegenüber proprietären Entwicklern, die die Bibliothek nutzen, weniger restriktiv als die LGPL.
Es gilt aber der Grundsatz, dass etwaige Änderungen an LGPL-Teilen selbst (sofern die Änderungen nicht einzig und allein für den eigenen Gebrauch gemacht wurden, sondern als Programm verkauft oder wie auch immer weitergegeben werden) immer den Endnutzern zugängig gemacht werden müssen. Eine Offenlegung von eigenem Code, der unabhängig vom LGPL-Code ist, ist nur dann notwendig, wenn sich in der Gesamtsoftware Quellcode-Teile befinden (oder auf solchen aufgebaut wird), welche unter der GPL-Lizenz stehen und somit dem Copyleft-Prinzip unterliegen.
Die LGPL beinhaltet eine Option, eine veränderte Version einer Software unter der GPL zu veröffentlichen. Das gibt Programmierern freier Software die Möglichkeit, ihre Erweiterungen nach Wunsch unter einer Copyleft-Lizenz zu veröffentlichen.
Siehe auch Bearbeiten
Weblinks Bearbeiten
Einzelnachweise Bearbeiten
- GNU Lesser General Public License, Version 3.0 (inoffizielle deutsche Übersetzung)
- GCC FAQ
- libstdc++ Runtime Library Exception