GNU Lesser General Public License

[xaromz]

Hallo,

ich habe mir jetzt das Hin und Her in diesem Thread durchgelesen und habe jetzt ein paar Fragen:
Sollte die LGPL fordern, dass jedes Programm, das LPGL-Code eincompiliert hat, wieder unter der LGPL steht, wo ist dann der Unterschied zur GPL?
Ich habe hier eine Unit, die unter der LGPL steht. Die kann ich natürlich nicht dynamisch linken, also warum steht sie dann überhaupt unter der LGPL? Und wie steht es mit kommerzieller Linux-Software, die muss ja auch manche Systembibliotheken dynamisch linken, obwohl diese unter GPL stehen (insbesondere der Kernel)? Wo also ist der Unterschied?

Fragend
xaromz

[Mystic]

Zitat von xaromz:

Hallo,

ich habe mir jetzt das Hin und Her in diesem Thread durchgelesen und habe jetzt ein paar Fragen:
Sollte die LGPL fordern, dass jedes Programm, das LPGL-Code eincompiliert hat, wieder unter der LGPL steht, wo ist dann der Unterschied zur GPL?

In diesem Punkt gibt es keinen Unterschied. Wenn du den Code der Bibliothek in deinem Programm statisch verlinkst, musst du das Programm ebenfalls unter die LGPL/GPL stellen.

Zitat von xaromz:

Ich habe hier eine Unit, die unter der LGPL steht. Die kann ich natürlich nicht dynamisch linken, also warum steht sie dann überhaupt unter der LGPL?

Weil der Autor wahrscheinlich die LGPL fehlinterpretiert hat.

Vielleicht könntest du die Unit in eine BPL-Datei packen, die du dann in deinem Programm benutzt. Dann wäre sie doch theoretisch dynamisch verlinkt?

[tommie-lie]

Zitat von xaromz:

Sollte die LGPL fordern, dass jedes Programm, das LPGL-Code eincompiliert hat, wieder unter der LGPL steht, wo ist dann der Unterschied zur GPL?

Die FSF schrieb in der LGPL:

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.

und

Die FSF schrieb in der LGPL:

As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

Kurz und auf Deutsch: Bibliotheken, die unter die GPL fallen, erzwingen in jedem erdenklichen Fall, daß Programme die diese Bibliotheken benutzen, ebenfalls unter der GPL veröffentlicht werden müssen (Ausnahme: die Bibliotheken sind standalone lauffähig und werden als solche behandelt). Die LGPL erlaubt late binding von Bibliotheken in ein Programm.

Zitat von xaromz:

Ich habe hier eine Unit, die unter der LGPL steht. Die kann ich natürlich nicht dynamisch linken, also warum steht sie dann überhaupt unter der LGPL?

Wieso kannst du sie nicht dynamisch linken? Du hast durch die LGPL die Freiheit, den Code zu verändern, also schaffe ein portables Interface und kompiliere es in eine dynamische Bibliothek (SO, DLL, BPL, whatever). Das Interface musst du offenlegen da er vom Originalcode abgeleitet ist, dein Programm kann aber unter den Bedingungen von Section 5 und 6 der LGPL die Bibliothek laden und benutzen.

Zitat von xaromz:

Und wie steht es mit kommerzieller Linux-Software, die muss ja auch manche Systembibliotheken dynamisch linken, obwohl diese unter GPL stehen (insbesondere der Kernel)?

Nicht alle Systembibliotheken fallen unter die GPL. Besonders die libc von GNU ist unter der LGPL und macht wenig Probleme. Direkte Kernel-Calls sind eher selten (und ich gestehe, daß ich gar nicht weiß, unter welcher Lizenz der Kernel steht).

Edit: Quote-Tags korrigiert.

[xaromz]

Hallo,

Zitat von tommie-lie:

Wieso kannst du sie nicht dynamisch linken? Du hast durch die LGPL die Freiheit, den Code zu verändern, also schaffe ein portables Interface und kompiliere es in eine dynamische Bibliothek (SO, DLL, BPL, whatever). Das Interface musst du offenlegen da er vom Originalcode abgeleitet ist, dein Programm kann aber unter den Bedingungen von Section 5 und 6 der LGPL die Bibliothek laden und benutzen.

Das ist mir klar, aber die Unit ist ein Interface für eine DLL, und es macht wohl wenig Sinn, ein DLL-Interface in eine DLL zu packen. Das hat der Autor wohl Sch**** gebaut.

Zitat von tommie-lie:

Direkte Kernel-Calls sind eher selten

Müssen nicht alle Dateioperationen über den Kernel laufen ?

Zitat von tommie-lie:

(und ich gestehe, daß ich gar nicht weiß, unter welcher Lizenz der Kernel steht).

Das ist einfach, natürlich die GPL.

Gruß
xaromz

[tommie-lie]

Zitat von xaromz:

Das ist mir klar, aber die Unit ist ein Interface für eine DLL, und es macht wohl wenig Sinn, ein DLL-Interface in eine DLL zu packen. Das hat der Autor wohl Sch**** gebaut.

Kommt drauf an, was der Autor im Sinn hatte. Wollte er es ermöglichen, seine DLL in closed-source-Programmen zu benutzen, war es ziemlich schwachsinnig. Will er die Verbreitung von freier Software fördern, hat er es richtig gemacht. Allerdings ist ersterer Fall wahrscheinlicher, denn wollte er die Verbreitung freier Software fördern, hätte er es unter die GPL gestellt und nicht die Schlupflöcher der LGPL zur Verfügung gestellt.

Zitat von xaromz:

Müssen nicht alle Dateioperationen über den Kernel laufen ?

Indrekt müssen *alle* I/Os über den Kernel laufen. Die libc abstrahiert aber hinreichend (File-I/O beispielsweise über die f*()-Funktionen aus dem stdio.h-Header).

Zitat von xaromz:

Das ist einfach, natürlich die GPL.

So einfach finde ich es nicht, Linux ist nicht Teil von GNU und wird es auch niemals sein. Aber ich habe nachgeschaut, es ist tatsächlich der Fall. Darüber hinaus:

in /usr/src/*/COPYING ist zu finden:

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.

Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.

Linus Torvalds

Torvalds räumt also explizit Sonderrechte für POSIX- und linux-spezifische Calls aus gewöhnlichen Programmen heraus ein, zusätzlich zu den Möglichkeiten, die LGPL-Bibliotheken aus GNU bieten. Frag' mich nicht, wie es bei den Binary-Treibern von nVidia oder den vmWare-Treibern aussieht, ich kenne das Treiberinterface für diese Treiber nicht, kann also auch nicht entscheiden, ob die jeweiligen binary-only-Teile dann zum Kernel gehören, oder nicht, und inwiefern Torvalds die Benutzung des Treiberinterfaces unter Ausnahmen gestellt hat.

[xaromz]

Hallo,

Zitat von tommie-lie:

Kommt drauf an, was der Autor im Sinn hatte. Wollte er es ermöglichen, seine DLL in closed-source-Programmen zu benutzen, war es ziemlich schwachsinnig. Will er die Verbreitung von freier Software fördern, hat er es richtig gemacht. Allerdings ist ersterer Fall wahrscheinlicher, denn wollte er die Verbreitung freier Software fördern, hätte er es unter die GPL gestellt und nicht die Schlupflöcher der LGPL zur Verfügung gestellt.

Das ist ein Interface für eine fremde Bibliothek unter der LGPL (ASpell). Also glaube ich auch eher an Möglichkeit eins.

Zitat von tommie-lie:

Frag' mich nicht, wie es bei den Binary-Treibern von nVidia oder den vmWare-Treibern aussieht, ich kenne das Treiberinterface für diese Treiber nicht, kann also auch nicht entscheiden, ob die jeweiligen binary-only-Teile dann zum Kernel gehören, oder nicht, und inwiefern Torvalds die Benutzung des Treiberinterfaces unter Ausnahmen gestellt hat.

Da gab's in letzter Zeit viel Streit auf der Kernel Mailing List. Eigentlich sind Closed Source-Treiber im Linux-Kernel ein Verstoß gegen die GPL. Torvalds toleriert das momentan (er hat extra Symbole wieder umbenannt, die GPL im Namen hatten), aber die meisten Kernel-Hacker nicht.

Gruß
xaromz

[tommie-lie]

Zitat von xaromz:

Das ist ein Interface für eine fremde Bibliothek unter der LGPL (ASpell). Also glaube ich auch eher an Möglichkeit eins.

Bei aspell könnte ich mir durchaus auch die zweite Variante vorstellen.

Zitat von xaromz:

Da gab's in letzter Zeit viel Streit auf der Kernel Mailing List. Eigentlich sind Closed Source-Treiber im Linux-Kernel ein Verstoß gegen die GPL. Torvalds toleriert das momentan (er hat extra Symbole wieder umbenannt, die GPL im Namen hatten), aber die meisten Kernel-Hacker nicht.

Ich weiß, daß es Streit über closed source Treiber gibt, aber das Argument, daß es gegen die GPL verstößt, ist mir wohl entfallen.

[phXql]

Eine frage: Wo is der unterschied zwischen dynamischen Linken und statischem Linken?
Das sind nur andere Wörter für late-bindung und das.. ähm.. andere (hat das nen namen? ^^), oder?

[Mystic]

Zitat von phXql:

Eine frage: Wo is der unterschied zwischen dynamischen Linken und statischem Linken?
Das sind nur andere Wörter für late-bindung und das.. ähm.. andere (hat das nen namen? ^^), oder?

Statisches Linken ist, wenn du den Bibliothekscode in die Programmdatei mit hineinkompilierst. Dynamisches Linken ist, wenn der Bibliothekscode extern z.B. in einer DLL ist, und das Programm nur Funktionen dieser aufruft.

[steph-7]

Man man... hier geht's ja jetzt richtig zur Sache!

Zitat von Mystic:

Zitat von phXql:

Eine frage: Wo is der unterschied zwischen dynamischen Linken und statischem Linken?
Das sind nur andere Wörter für late-bindung und das.. ähm.. andere (hat das nen namen? ^^), oder?

Statisches Linken ist, wenn du den Bibliothekscode in die Programmdatei mit hineinkompilierst. Dynamisches Linken ist, wenn der Bibliothekscode extern z.B. in einer DLL ist, und das Programm nur Funktionen dieser aufruft.

Joa, kannst du sonst auch hier nachlesen: Wikipedia


Hier noch ein kleiner Hinweis am Rande:
Leute, die sich für die GPL und LGPL interessieren, interessieren sich vielleicht auch für die MPL (Mozilla Public License). Infos darüber lassen sich z.B. hier finden: mozilla.org, Wikipedia und Delphi Source