staging.inyokaproject.org

Hi!

Ich hoffe ich bin hier halbwegs richtig. Besserer Titel ist mir leider nicht eingefallen.

Meine Fragen drehen sich darum, was die GPL bewirkt. So viel ist klar: Kernelpatches und Anwendungen, die gegen GPL linken oder GPL/LGPL einbetten, müssen ebenfalls als GPL/LGPL veröffentlicht werden. Anwendungen, die nur gegen LGPL linken, nicht.

Nun meine Frage Nr1: Wenn ich die serielle Schnittstelle verwende, dann linke ich doch gegen Teile von Linux? Linux ist GPL - welche konkrete Ausname erlaubt es mir, die Anwendung als ClosedSource zu veröffentlichen? Und die 2. Frage: Logitech verwendet in der G19 ein embedded Linux und behaupten, dass ihr Linux ClosedSource sei, was natürlich absoluter Stuss ist... angenommen, dass sie sich auf die Ausnahme von Frage Nr.1 berufen - den Linux-Kernel, den sie verwendet haben, müssen sie dennoch veröffentlichen (oder sagen, welcher es war), oder?

Hoffe, dass hier ein paar GPL-Spezialisten an Board sind. Rechtliche Fragen stell ich nur ungerne in einer Nicht-Muttersprache :S

mfG Andy

Black Sliver schrieb:

Hi!

Ich hoffe ich bin hier halbwegs richtig. Besserer Titel ist mir leider nicht eingefallen.

Meine Fragen drehen sich darum, was die GPL bewirkt. So viel ist klar: Kernelpatches und Anwendungen, die gegen GPL linken oder GPL/LGPL einbetten, müssen ebenfalls als GPL/LGPL veröffentlicht werden. Anwendungen, die nur gegen LGPL linken, nicht.

Nun meine Frage Nr1: Wenn ich die serielle Schnittstelle verwende, dann linke ich doch gegen Teile von Linux? Linux ist GPL - welche konkrete Ausname erlaubt es mir, die Anwendung als ClosedSource zu veröffentlichen?

In der Regel wirst du dazu eine lib verwenden (die dann in aller Regel unter der LGPL steht) oder einfach direkt den device auslesen bzw darauf schreiben (unter *ix-Systemen ist alles "nur" eine Datei) und nicht direkt gegen Linux linken

Und die 2. Frage: Logitech verwendet in der G19 ein embedded Linux und behaupten, dass ihr Linux ClosedSource sei, was natürlich absoluter Stuss ist... angenommen, dass sie sich auf die Ausnahme von Frage Nr.1 berufen - den Linux-Kernel, den sie verwendet haben, müssen sie dennoch veröffentlichen (oder sagen, welcher es war), oder?

Linux ist und bleibt GPL. Dies müssen Sie ihren Kunden mitteilen und entweder den Quellcode direkt mitliefern oder ein schriftliches Angebot nachdem man den Quellcode nachträglich bestellen kann. Was sie drum herum alles proprietäres programmiert haben und ob es so gegen GPL Code linkt damit es im juristischen Sinn ein abgeleitetes Werk ergibt kann ich nicht sagen, ich kenne das Produkt nicht.

In der Regel wirst du dazu eine lib verwenden (die dann in aller Regel unter der LGPL steht) oder einfach direkt den device auslesen bzw darauf schreiben (unter *ix-Systemen ist alles "nur" eine Datei) und nicht direkt gegen Linux linken

Wir reden von Funktionen, die in den sys/*.h dateien deklariert werden, somit vermutlich POSIX-Standard, richtig? Somit linkt man doch sehrwohl dynamisch gegen das OS!? Oder sind diese Methoden dann letztendlich nicht im Kernel, sondern in LGPL'ed Libs?

Und die 2. Frage: Logitech verwendet in der G19 ein embedded Linux und behaupten, dass ihr Linux ClosedSource sei, was natürlich absoluter Stuss ist... angenommen, dass sie sich auf die Ausnahme von Frage Nr.1 berufen - den Linux-Kernel, den sie verwendet haben, müssen sie dennoch veröffentlichen (oder sagen, welcher es war), oder?

Linux ist und bleibt GPL. Dies müssen Sie ihren Kunden mitteilen und entweder den Quellcode direkt mitliefern oder ein schriftliches Angebot nachdem man den Quellcode nachträglich bestellen kann. Was sie drum herum alles proprietäres programmiert haben und ob es so gegen GPL Code linkt damit es im juristischen Sinn ein abgeleitetes Werk ergibt kann ich nicht sagen, ich kenne das Produkt nicht.

Ob sie ihr gesamtes Werk als GPL lizenzieren müssen, wage ich ebenfalls nicht zu beurteilen. Aber zu behaubten, dass daran nichts OpenSource sei ist falsch. Somit handelt es sich wohl eindeutig um einen GPL-Verstoß, wie ich mir dachte:

Ruben Mookerjee | August 31st, 2009 at 11:16 am

Jayden,

The OS for the LCD unit is Linux, but it is not open-source nor can it be edited as write access to it is not possible.

Cheers, Ruben

Quelle: http://blog.logitech.com/2009/01/20/new-logitech-pc-gaming-products-unveiled-at-ces-2009/

Die 2 Fragen haben eigentlich denkbar wenig miteinander zu tun. 1. handelt von einer Stand-Alone-Anwendung, die (leider) closed Source sein muss, ich wollte eben den tatsächlichen, rechtlichen Teil dazu wissen. Die restlichen benutzten Libs sind alle LGPL oder noch freier. 2. ist mir auf der Suche nach G19-Treibern so nebenbei aufgefallen 😉

@Black Silver: Diese "Funktionen" liegen nicht in Bibliotheken [1]. Sie sind nicht mal Funktionen im eigentlichen Sinne, man spricht von Systemaufrufen. Sie werden nicht zur Übersetzungszeit in das Programm gelinkt, sondern zur Laufzeit über Nummern nachgeschlagen. Daher fallen solche Aufrufe nicht unter "derived work" im Sinne der GPL.

Um das herauszufinden, hätte es im Übrigen gereicht, die Lizenz des Kernels auch tatsächlich mal zu lesen, denn gleich der erste Absatz stellt die Grenzen der Lizenz klar:

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". […]

• 1: Sie sind im Übrigen auch nicht alle Teil von POSIX

Argh.. auf die Idee die erste Zeile zu lesen, bin ich natürlich nicht gekommen :S Dachte das wär eine sinnlose Präambel. Danke, die Frage wäre damit geklärt, denke ich.

sondern zur Laufzeit über Nummern nachgeschlagen.

Das ist doch dynamisches Linken? 😉 Ob Nummern, Namen oder Pfade ist ja nicht wirklich von Bedeutung. Und genau das (dynamisches Linken) beinhaltet die GPL ebenfalls - darum gibt's die LGPL.

Sie sind im Übrigen auch nicht alle Teil von POSIX

Ja schon klar. Gibt ja mehrere Standards, jedoch wollte ich damit nur sagen, dass man sehrwohl (mehr oder minder) "direkt" zum Kernel kommt.

@Black Silver: Nein, das ist kein dynamisches Linken. Dynamisches Linken ist ein kleines bisschen komplizierter als ein Systemaufruf. Wie das genau funktioniert, kannst Du nachlesen, aber es gibt zwei wichtige Unterschiede:

• Systemaufrufe sind eine Art IPC. Bei einem Systemaufruf wird ein Kontextwechsel durchgeführt, und anschließend führt ein separater Prozess den Code des Systemaufrufs selbst aus. Diese Trennung ist essentiell, um die Privilegien des Kernels sicherzustellen. Dynamische Bibliotheken dagegen werden in den Adressraum des ausführenden Prozesses geladen, und laufen daher im selben Prozess wie das Programm.

• Daraus folgt, dass ein dynamisch gelinktes Programm ohne die gelinkten Bibliotheken nicht ausgeführt werden kann. Es fehlen dann substantielle Teile des Codes, und Symbolnamen können nicht auf Speicheradressen umgesetzt werden. Ein Programm, welches nur Systemaufrufe nutzt, kann allerdings ohne den Kernel ausgeführt werden. Technisch hängt ein Systemaufruf nur vom Registerzugriff, vom Speicherzugriff und von der Interruptverwaltung ab, und ist daher nur architekturabhängig, nicht aber systemabhängig. Natürlich funktioniert das in der Praxis nicht, aber de facto ist ein Programm technisch gesehen unabhängig vom Kernel, nicht aber unabhängig von dynamischen Bibliotheken.

Man kommt im Übrigen aus dem Userspace nie direkt zum Kernel, sondern kann auf dessen Funktionalität einzig und allein über Systemaufrufe zugreifen. Das ist die oberste Schnittstelle des Kernels, direkter Zugriff auf darunter liegende Funktionen ist aus dem Userspace heraus unmöglich.