Wer versteht Section 5 der LGPL 2.1?

[MarderFahrer]

Ich kann es einfach nicht verstehen. Section 5 besteht aus zwei Sätzen, die sich meiner Meinung nach komplett! widersprechen. Gibt es irgendjemanden, der hier drin einen Sinn erkennt?

5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License.

Im ersten Teil wird explizit erwähnt, dass ein Programm, welches keinen Code der lib beinhaltet, sondern nur damit compiled oder "verlinkt!" wird nicht unter die LGPL fällt. Es ist dann ein "work that uses the Library"

Gerade der Verwendung des Wortes "verlinkt" fällt mir hier auf, denn im zweiten Teil wird gerade das komplett widersprüchlich zum ersten Teil wiederverwendet. Dort heißt es, verlinkt man dieses Programm mit der lib, wäre das ein executable welches ein derivative der lib ist und somit unter die LGPL fällt.

Wo ist hier der Sinn? Ich habe meinen Code, compile/verlinke ihn mit der LGPL lib und bekomme ein Kompilat "work that uses the Library". Warum zur Hölle sollte dieses Kompilat erneut mit der lib verlinkt werden und warum sollte das dann ein derriverat sein???

Im ersten Teil wird erwähnt das ein Programm, welches mit einer LGPL lib kompiliert wird, Ncht! unter die LGLP fällt und im nächsten Satz heißt es, wird es verlinkt, fällt es unter die LGPL.

 

[maki]

Stell dir vor, es gäbe eine Standard API die nur aus interfaces besteht, wie JDBC.
Jetzt gibt es viele Implementierungen dieser API, eine davon von MySQL welche (u.a.) unter der GPL steht, also der MySQL JDBC Treiber.

Nutzt du die JDBC API in deinem Code und konfigurierst du die Implementierung zur Laufzeit, zB. durch einen Container/Framework (Spring, Hibernate, JNDI DataSources, etc. pp.), nutzt du den GPL Implementierung von MySQL nicht direkt in deinem Code.
Nutzt du dagegen den MySQL Treiber direkt ist das etwas anderes (import com.mysql.....)

 

[Marco13]

Ich glaube, dass das eher C-Programmen geschuldet ist - da kann man ja eine DLL erstellen, die zusammen mit der fraglichen DLL zu einem Programm zusammengebaut werden kann, ODER ein Programm erstellen, das direkt die fagliche DLL verwendet. Inwieweit dann statisches oder dynamtisches Linken noch einen Unterschied macht, weiß ich nicht.

Für Java und JARs sollte man sich aber auch GPL linking exception ? Wikipedia ansehen.

Ich hatte auch eine Zeitlang die LGPL verwendet, aber hab' dann auf die MIT/X11 umgestellt. Genau wegen dieses verklausulierten, ZIG-seitigen Juristenhickhack in der LGPL version 2.1.5.alpha, das erstens fast niemand liest, und zweitens derjenige, der es liest, nicht versteht. Beim MIT/X11 ist's klar: "Mach' was du willst, lass' das Copyright drin, und wenn's nicht funktioniert ist das dein Problem". Die Möglichkeit zur kommerziellen/closed source Nutzung finde ich eigentlich auch nicht schön, aber ... besser als irgendeine Lizenz, die weder man selbst noch irgendjemand anderes wirklich nachvollziehen kann, und wo man "blind" drauf vertrauen muss, dass das, was da drin steht, Sinn macht...

 

[jDennis79_nli]

Ich stehe ja total auf die WTFPL.