[linux-l] GPL wirklich strenger als LGPL?

olafBuddenhagen at gmx.net olafBuddenhagen at gmx.net
Mo Jul 16 22:57:17 CEST 2007


Hallo,

On Fri, Jul 13, 2007 at 08:30:34PM +0200, Volker Grabsch wrote:

> Inzwischen sehe ich den Unterschied gar nicht mehr als so gravierend
> an. Ist GPL wirklich stärker als LGPL?
> 
> Es geht bei GPL <-> LGPL doch eher um die grundsätzliche Frage, wann
> der Aufruf von fremdem Programmcode eine "Nutzung" ist, und ab wann es
> sich um ein Derivat handelt. Der fremde Code kann durch einen
> separaten Prozess aufgerufen werden, als dynmische Bibliothek oder als
> statische Bibliothek. Obwohl dies lediglich technische Unterschiede
> sind, machen GPL und LGPL da Unterschiede.

Das stimmt nicht ganz. IIRC erwähnt GPLv2 linken an keiner Stelle. v3
erwähnt es lediglich im Zusammenhang mit System-Libraries, und auch da
nur als Beispiel.

LGPL 2.1 sagt ausdrücklich dass sowohl statisches als auch dynamisches
Linken unter bestimmten Bedingungen zulässig ist; bei LGPL 2 hatte das
zu viel Verwirrung verursacht.

An sonsten legen GPL und LGPL fest, unter welchen Bedingungen
abgeleitete Werke weitergegeben werden können; machen aber keine Aussage
darüber, wann genau ein abgeleitetes Werk vorliegt. Das ist nämlich
keine Frage der Lizenz, sondern der Copyright-Gesetzgebung.

Linken ist deshalb ein Sonderfall, weil das Ergebnis durch den Vorgang
des Linkens -- zumindest nach dem Rechtsverständnis der FSF -- auf jeden
Fall ein Gesamtwerk darastellt, selbst wenn die Teile im Quellcode als
unabhängig angesehen werden können. Bei anderen Formen der Verknüpfung,
die auf Programmaufrufen und IPC basieren, gibt es dagegen keinen
Unterschied zwischen ausführbarer Version und Quellcode.

Bei der ausfuehrbaren Version kann Linken also tatsaechlich Auswirkung
auf den Lizenzstatus haben; waehrend beim Quellcode die Art der
Verknuepfung keine Rolle spielt. Entscheidend sind hier andere Faktoren:
Wie eng sind die Komponenten miteinander verbunden? Wurden sie speziell
aneinander angepasst, oder kann man sie auch unabhaengig nutzen?
Natuerlich spielen die Deteils der nationalen Rechtslage auch eine
Rolle. Und wenn es zu einem Prozess kommt, sicher auch die Einstellung
der zustaendigen Richter -- in vielen Faellen ist es leider
Ermessenssache.

Wenn also die Komponenten in Quellcode-Form als unabaengige Programme
gelten, nutzt es was, statt Linking auf eine andere Form der
Verknuepfung auszuweichen, um zu verhindern, dass das ausfuehrbare
Programm unter GPL faellt.

(NVidia ueberlaesst bei seinen proprietaeren Kernel-Treibern das Linken
dem Nutzer, und fuehlt sich so relativ sicher -- auch wenn *einige*
Linux-Entwickler der Ansicht sind, dass bereits der ungelinkte Treiber
ein abgeleitetes Werk und damit eine Lizenzverletzung ist...)

Wenn die Komponenten hingegen schon im Quellcode als Teile eines
einzelnen Prgramms gesehen werden, spielt der Verknuepfungsmechanismus
keine Rolle.

> Kann man daher wirklich sagen, dass die GPL stärker als die LGPL ist?

Ja. Die LGPL verlangt nur, dass der urspruengliche LGPL-Code, und
direkte Aenderungen daran freigegeben werden muessen. Wenn Code dagegen
getrennt ist -- ob durch Linken oder durch Prozessgrenzen -- unterliegt
er (fast) keinen Bedingungen mehr. Auf diese Weise koennen nicht nur
LGPL-Bibliotheken in proprietaeren Programmen verwendet werden, sondern
es koennen auch LGPL-Bibliotheken oder -Programme mit relativ geringem
Aufwand um praktisch beliebige Faehigkeiten erweitert werden, ohne diese
Erweiterungen freizugeben. Man kann also proprietaere Varianten
veroeffentlichen, bei denen man die Erweiterungen des urspruenglichen
LGPL-Codes vorenthaelt. Kein starkes Copyleft.

Die GPL bezieht sich hingegen auf das Gesamtprogramm. Sobald Codeteile
nicht als unabhaengig gelten, fallen sie unter GPL. Dabei spielt es
keine Rolle, ob sie gelinkt werden oder, in getrennten Prozessen laufen
-- sobald die Schnittstelle wesentlich komplexer ist als system() oder
popen(), kann man in den meisten Faellen nicht mehr von getrennten
Programmen reden.

-Olaf-



Mehr Informationen über die Mailingliste linux-l