GPL code mixen mit anderem Code?

[richard42]

Hi,

Ich wuerde gerne eine Eclipse-RCP Application ausliefern (closed source). Ein paar der Plugins die ich gerne mitliefern wuerde stehen unter der GPL. Darf ich diese Plugins dazupacken oder verstoesst das bereits gegen die GPL?

Kann mir jemand in einfachen Worten sagen in wie weit man GPL code mit anderem Code ausliefern darf ohne, dass man nicht gleich alles unter die GPL stellen muss.

Viele Linux distris liefern ja kommerzielle Treiber und Programme mit. Wie ist das moeglich?


Danke,
Ricky

 

[Gast2]

Moin,

man korregiere mich ggf.

solange wie Du in Deinem Teil kein GPL-Code verwendest - kein Problem ... hast Du GPL-Code verwendet als Library und es ist LGPL (statt GPL) - Glück gehabt ... ist es aber GPL musst Du Deine Quellen offen legen ... verwendest Du in Deinem Teil direkt GPL (sprich, direkt Quelltext) - Quellen offen legen

die Plugins müsstest Du eigentlich nur mit Quellcode in die Installation mir reinlegen ... eigentlich sollte es da keine Probleme geben ... außer Du hast da wieder am Quellcode was geändert

hand, mogel

 

[Hilefoks]

Moin,

Kann mir jemand in einfachen Worten sagen in wie weit man GPL code mit anderem Code ausliefern darf ohne, dass man nicht gleich alles unter die GPL stellen muss.

Du darfst selbstverständlich dein Programm und irgendwelche GPL Programme zusammen ausliefern. Dein Programm und die GPL-Programme müssen aber unabhängig sein. D.h. vor allem das du beim programmieren deines Programms in keiner Weise auf Code der GPL Programme zugreifen darfst.

Viele Linux distris liefern ja kommerzielle Treiber und Programme mit. Wie ist das moeglich?

Da auch unter Linux die wichtigsten Bibliotheken, z.B. die glibc, libstdc++ oder gtk+, nicht unter GPL sondern "mindestens" unter LGPL stehen, kann man auch kommerzielle Programme für Linux schreiben. Der Linux-Kernel selbst steht zwar nicht unter LGPL, aber diesen benutzt man als Anwendungsprogrammierer auch nicht (direkt).

Bei Treibern für den Linux-Kernel, wie auch bei Plugins für einige andere Projekte, ist das aber etwas komplexer.

Steht ein Programm unter der GPL, möchte aber ermöglichen das auch kommerzielle Plugins entwickelt werden können (so z.B. KDEs Kontact), so kann folgendes gemacht werden:
Das Programm selbst wird unter GPL veröffentlicht, die Plugin-Schnittstellen jedoch unter LGPL. Nun dürfen sowohl das GPL Programm selbst als auch kommerzielle Anbieter die entsprechenden Schnittstellen verwenden.

Beim Linux-Kernel ist es aber nochmals komplexer. Der Kernel steht unter der GPL und bietet weder stabile Schnittstellen noch Schnittstellen unter der LGPL an. Daher ist es nicht möglich einen Treiber für den Kernel zu schreiben, der nicht unter der GPL steht. Es gibt aber doch einen nicht unumstrittenen Trick, den verschiedene Hersteller gerne nutzen: Sie schreiben einen GPL Treiber der lediglich den Zugriff auf ein bestimmtes Gerät erlaubt (z.B. über das /dev Dateisystem). Der eigentliche Treiber verwendet dann keinen GPL Code mehr, sondern lediglich eine Datei (eben jene die der GPL-Treiber im /dev Dateisystem zur Verfügung stellt).


MfG,
Hilefoks

 

[tuxedo]

>> nicht unter GPL sondern "mindestens" unter LGPL stehen, kann man auch kommerzielle Programme für Linux schreiben.

Kleine Verbesserung/Ergänzung:

GPL schließt kommerzielle Programme nicht per se aus. D.h. du darfst durchaus ein GPL-Lizensiertes Programm verkaufen. NUr ist es eben sehr unbeliebt bei den Herstellern das kommerzielle Produkt auch noch Quelloffen legen zu müssen. Folglich wird im kommerziellen Umfeld (also da, wo für die Anwendung selbst Geld verlangt wird) die GPL nicht wirklich eingesetzt. Wenn doch, dann ist die Anwendung meist kostenlos, und der Support oder das Handbuch etc. kostenpflichtig.

- Alex

 

[maki]

>> NUr ist es eben sehr unbeliebt bei den Herstellern das kommerzielle Produkt auch noch Quelloffen legen zu müssen.

Wir haben bis jetzt jede Software nur mit Quellen ausgeliefert.

 

[tuxedo]

>> Wir haben bis jetzt jede Software nur mit Quellen ausgeliefert.

Na sei doch nicht so engstirnig "unbeliebt" heisst ja nicht, dass 100,00% aller Hersteller Universumsweit das so empfinden.

 

[foobar]

@Hilefolks Wie funktioniert das eigentlich mit proprietären Grakatreibern wie Nvidia? Ist das während der Installation erstellte Kernelinterface so eine Art Gluecode, denn der Treiber steht ja nicht unter der GPL?

 

[Gast2]

@Hilefolks Wie funktioniert das eigentlich mit proprietären Grakatreibern wie Nvidia? Ist das während der Installation erstellte Kernelinterface so eine Art Gluecode, denn der Treiber steht ja nicht unter der GPL?

Beim Linux-Kernel ist es aber nochmals komplexer. Der Kernel steht unter der GPL und bietet weder stabile Schnittstellen noch Schnittstellen unter der LGPL an. Daher ist es nicht möglich einen Treiber für den Kernel zu schreiben, der nicht unter der GPL steht. Es gibt aber doch einen nicht unumstrittenen Trick, den verschiedene Hersteller gerne nutzen: Sie schreiben einen GPL Treiber der lediglich den Zugriff auf ein bestimmtes Gerät erlaubt (z.B. über das /dev Dateisystem). Der eigentliche Treiber verwendet dann keinen GPL Code mehr, sondern lediglich eine Datei (eben jene die der GPL-Treiber im /dev Dateisystem zur Verfügung stellt).

??, mogel