Diskussion:GNU Lesser General Public License

Library GPL oder Lesser GPL?

Was denn jetzt? "Lesser General Public License" oder "Library General Public License" ??

Beides. Die Lizenz wurde als "Library GPL" eingeführt und später in "Lesser GPL" umbenannt: »The GNU Lesser General Public License is used by a few (but not all) GNU libraries. This license was formerly called the Library GPL, but we changed the name, because the old name encouraged people to use this license more often than it really ought to be used.« [1] --Tkarcher 09:50, 25. Mai 2005 (CEST)

Grenzfälle: Scriptsprachen

Ich darf also Software, die unter der LGPL steht in eine Software einbauen, die nicht unter der (L)GPL steht, wenn ich die entsprechenden Teile dynamisch linke. Dynamisch linken bedeutet, dass die codeteile nicht fest in mein Programm eingebunden sind, sondern nachgeladen werden.

wie ist das denn nun bei html, PHP ?

Wenn ich in einer PHP Datei per include etwas einbinde, was unter der LGPL steht, ist das ja wohl dynamisch. Es wird schliesslich erst eingebunden, wenn der Benutzer das entsprechende script aufruft. Allerdings würde ich das bei PHP kein "linken" nennen. Aber wenn die LGPL überhaupt Sinn bei Webanwendungen macht, dann ja wohl, wenn man sie einfach nur per include() einbindet, oder in einem eigenen Fenster öffnet.

Somit Dürfte dann meine PHP Datei unter einer anderen Lizenz stehen, oder ?

(Vorstehender nicht signierter Beitrag stammt von 84.57.255.249 (Diskussion • Beiträge) )

• Wenn man in einem proprietären Programm Icons/Grafiken anzeigen möchte, die unter der LGPL stehen, müssen diese dann aus dem Dateisystem eingebunden werden oder ist eine embedded Resource auch möglich? Wäre eine DLL mit den Icons/Grafiken, die unter der LGPL steht, ausreichend? -- Fleasoft 18:24, 28. Apr 2006 (CEST)

• Hallo,
  selbstverständlich ist Linken bei den meisten Scriptsprachen (wie PHP, Perl, Python, Ruby) fehl am Platz. Oft muss man von spezifischen Grenzfällen sprechen, z.B. gibt es ja kompilierte Laufzeitmodule für PHP, und Perl-Module verhalten spich prinzipiell wie ein require-Aufruf, daher ist die linken-Definition nicht ganz passend. Vielleicht wird es klarer, wenn man die These so umformuliert, dass linken nur nachträgliches Laden des Sourcecodes bedeutet, was wohl mit allen Scriptsprachen möglich ist. Ob das dann, im Fall PHP, über "andere Fenster" oder ähnliches läuft, spielt eh keine Rolle (ganz generell ist dieser Ausdruck fehl am Platz, in PHP gibt es keine Fenster).
  Grüße, --84.178.12.15 21:40, 26. Nov. 2006 (CET) Benutzer:Benji

Unterschiede zur GPL

Im Artikel steht z.Zt. dass „eine unter LGPL lizenzierte Software nur mit ihrem Quelltext vertrieben werden oder mit der Zusage, den Quelltext auf Anfrage nachzureichen.“ Ich halte den hervorgehobenen Teil schlicht für falsch, jedenfalls konnte ich keinen entsprechenden Passus in der LGPL finden.
Dort steht in §4: „Sie können die Bibliothek … kopieren und weitergeben, sofern Sie den vollständigen entsprechenden maschinenlesbaren Quelltext beifügen …“ und im 2. Absatz (zu Downloads) „… erfüllt das Angebot eines gleichwertigen Zugangs zum Kopieren des Quelltextes von demselben Ort die Anforderung, auch den Quelltext weiterzugeben …“ D.h. nach der LGPL muss immer der Quelltext mit auf die CD/DVD bzw. mit in die Distribution und bei Downloads muss der Quelltext auf dem selben Server zur Verfügung stehen.
Nur in der GPL findet sich hingegen der Passus (§3) „liefern Sie das Programm zusammen mit einem mindestens drei Jahre lang gültigen schriftlichen Angebot aus, jedem Dritten eine vollständige maschinenlesbare Kopie des Quelltextes zur Verfügung zu stellen …“
-- 84.191.37.140 00:15, 1. Mai 2007 (CEST)

Bedingungen

Super wäre es auch wenn man die einzelnen Bedingungen der LGPL aufführen würde. Wie z.B. Nennung der Autoren, Weitergabe unter der gleichen Lizenz etc pp. ← Körnerbrötchen - ✉ 14:24, 12. Jun. 2007 (CEST)

Wirklich nur dynamisches Linken?

Stimmt es wirklich, dass das Programm, das eine LGPL-Biblothek benutzt, nur dynamisch gelinkt werden darf, damit es seine Lizenz behalten darf. In der LGPL steht nur etwas von einer "kombinierten Arbeit", was meiner Meinung nach, nicht ausschließt, dass auch statisches Linken oder gar includen von Sourcecode-Teilen mögich ist. --Moon2005 17:05, 16. Apr. 2008 (CEST)

Ja klar! Dies ist ein Fehler der seit November 2005 (also jetzt mehr als 6 Jahre) existiert.

Statisches Linken ist erlaubt. Dann muss proprietärer Code als Objektdateien (oder opensource, manchmal auch gezwungenermaßen opensource, z.B. bei inline Funktionen unter LGPL - siehe Kommentar zu C++ unten) zur Verfügung gestellt werden.

Ein Programm welches LGPL Code zusammen mit eigenem (z.B. proprietärem) Code verwendet, muss so aufgebaut sein, dass jeder Endnutzer den LGPL Code (oder modifizierte Versionen dessen) in das endgültige Programm reinlinken kann. Dies kann entweder durch dynamisches linken geschehen (wo der LGPL Code in einer Dynamische Bibliothek verwendet wird); dann kann der Endnutzer eine eigene Dynamische Bibliothek 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 Objektdatein des proprietärem Codes, und die Sourcen des LGPL Codes und kann diese zusammenlinken.

Referenzen:

„Also, you must do one of these things:
a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
etc.“

– GNU Lesser General Public License, version 2.1

„d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.“

– GNU Lesser General Public License, Version 3.0

Für eine C++ Bibliothek die stark inline Funktionen und Templates verwendet, wird meist eine (dem Entwickler gegenüber) offenere 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 der Bibliothek usw. bereits im Quelltext inkludieren, und daher können dem Endnutzer keine Objektdatein des proprietärem Codes gegeben werden, da etwaige Modifizierungen von inline Funktionen (der Bibliothek) schon im Quelltext inkludiert werden müssen. Ref

--Sonderzeichen lgpl (Diskussion) 20:03, 7. Mär. 2012 (CET)

LGPL ist immer kompatibel zu GPL

Der Satz, dass die Option zur wahlweisen Veröffentlichung LGPL/GPL der Kompatibilität dient, ist falsch. Die LGPL ist immer kompatibel, auch ohne diese Option. Es geht nur um die Freiheit des Programmierers, seine Aenderungen an den LGPL Sourcen komplett der GPL zu unterstellen. --Peter Walt A. 20:06, 25. Mär. 2010 (CET)

Bedeutung des Wortes "Lesser"

...sollte unbedingt erklärt werden. Ist das ein Eigenname, kommt es vom englischen Wort "less" (= "weniger", "gering") in seiner Steigeungsform oder ganz was anderes? --Carbenium 13:25, 14. Mär. 2011 (CET)

Kompatiblität zur Software Märkten

Sowohl Apples als auch MSs Markt schränken die Weitergabe der Binaries ein und setzen DRM oben drauf. Inwieweit ist das in Einklang zu bringen mit der GPL bzw. LGPL? Erstere verbietet diese Art von Exklusivität. Zweiter Punkt mit dem Linken. Die LGPL unterscheidet hier zwischen dyn. Linken und stat. Linken. Nun existieren Compiler/Sprachen die zur Optimierung den Code miteinbinden(C++ include). Danach wäre dann diese Programm ebenfalls LGPL, richtig?--Darktrym (Diskussion) 10:15, 16. Mär. 2012 (CET)