Thema: GPL Copyleft

[Dimension]

Ich würde gerne für alle Peripherie ( (S)ATA, Netzwerk, 3d-beschleuniger) und Bussysteme (PCI, USB, diverse *HCI) die treiber aus dem Linux-Projekt nehmen (/drivers). Um meinen kernel nicht sofort unter GPL zu stellen, möchte ich eine art treiber-proxy dazwischen legen und nur die original linux treiber veröffentlichen, ist das OK ?

Der Proxy steht dabei selbst unter der GPL und wird ordnungsgemäß veröffentlicht. Der kernel kommuniziert über ein Interface mit dem Proxy, so, als ob es ein Dienstprogramm wäre. Für die Architektur fallen mir 3 Wege ein: A: der Proxy importiert den unmodifizierten sourcecode und transformiert ihn, B: der Proxy kompiliert die treiber mit GCC und transformiert den Objektcode, C: der Proxy reproduziert die Linux-Kernel-Umgebung und verlinkt dagegen.

Da auch unter Windows GPL-Programme laufen, der NT-Kernel jedoch nicht unter der GPL veröffentlicht wurde, vermute ich damit keine Probleme. Gibt es hier Lizenz-Spezialisten, bzw. was haltet ihr allgemein von der Idee?

[Jidder]

Ich glaube das ist keine so gute Idee. Du hast ja das Beispiel mit den GPL-Programmen unter Windows genannt, aber da ist die Close Source Software ja nicht vom GPL-Programm abhängig. Bei deinem Kernel wäre das anders. Dein Proxy wäre dann vom Treiber abgeleitet, und dein Kernel vom Proxy abgeleitet. Nur weil du den Proxy selbst geschrieben hast, heißt das nicht, dass du damit die GPL aushebeln kannst.

Das hier könnte vielleicht ganz interessant sein:
http://www.gnu.org/philosophy/udi.html
http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem

[Dimension]

Ich glaube ich werde den Kernel mit der Schnittstelle auf der einen Seite und den Proxy unter GPL auf der anderen Seite jeweils separat anbieten. So kann man genau diesen Proxy nutzen oder jeden beliebigen anderen.

Ich hatte auch versucht mir etwas einfallen zu lassen, um die Schnittstelle so weit zu reduzieren, dass "Funktionsaufrufe und gemeinsame Nutzung komplexer Datenstrukturen" vermieden wird, was sich bei Hardware-Treibern jedoch quasi unmöglich gestaltet. Mein zweiter Versuch war etwas über Dienstprogramme pro Treiber zu konstruieren, welche während des Bootvorgangs im Proxy registriert werden und ihrerseits wiederum unter der GPL stehen. Dieses könnte bspw. ein Dienst sein, der Audiodaten entgegennimmt und and die Soundkarte weiterreicht. Ist mir aber bereits zu schwergewichtig und ändert nichts am Datenpfad.

[kevin]

Ein Proxy, der nur dafür da ist, die GPL auszuhebeln funktioniert nicht. Entweder du hast ein abgeleitetes Werk oder nicht. Wenn du eins hast, bleibt es auch mit Proxy abgeleitet, und wenn nicht, dann ist der Proxy unnötig.

[DerHartmut]

Der Sinn der GPL ist derer, dass man den unter ebendieser Lizenz geschriebenen und verteilten Code nicht einfach in andere Projekte mit Benutzen kann, die nicht im Sinne der GPL agieren und nicht das Paradigma von GNU generell verfolgen; dies schließt halt auch andere freie Lizenzen mit ein, die z.B. eine kommerzielle Nutzung erlauben, nicht viral sind etc..

Der Sinn ist einfach: Ich schreibe etwas für alle, du benutzt das und stellst das, was du geschrieben hast (was ohne mein Geschriebenes so nicht möglich wäre) auch für alle zur Verfügung. Das ist quasi der "GPL-Vertrag". Von daher ist eine Unterwanderung dieser Lizenz wie mit einem "Proxy" nicht nur ethisch fragwürdig sondern halt auch nicht praktikabel.

Für dich scheint eher CDI in Frage zu kommen: CDI ist unter der 4-Klausel-BSD veröffentlicht und hat schon einige vorhandene Treiber.

Und hey, wo bleibt denn auch der Spaß an der Freud', wenn man alles kopiert und nicht selber schreibt

[Svenska]

Da dein Proxy "irgendwie" mit dem GPL-Code und deinem Kernel zusammengelinkt wird, ist es ein abgeleitetes Werk. Die einzige Möglichkeit, die mir einfällt, wäre, die Linuxtreiber im Userspace auszuführen. Die Umgebung, in der das geschieht (Proxy), steht dann unter GPL, der Kernel selbst jedoch nicht - und beide Teile werden nicht fest kombiniert.

Ob es allerdings sinnvoll ist, das Treiberkonzept eines Monolithen im Userspace auszuführen, wage ich zu bezweifeln.

[DerHartmut]

Der Proxy wäre an und für sich nichts anderes als eine nachgebaute Linux-ABI (oder API), die Treiber würden dann als Userprogramme ausgeführt werden...klingt nach einem Konzept für niwohlOS (wir emulieren ja schon erfolgreich die PrettyOS-API).