Nicht-GPL-Kernelmodule mit GPL-Einsen

Question

Die Firma, für die ich arbeite, entwickelt ein Closed-Source-Kernelmodul (.ko-Datei). Dieses Modul muss Funktionen aufrufen, die in einem gpl2-Modul enthalten sind. Im Grunde haben wir eine Situation wie folgt aus:

// GPL 2 kernel module (gpl.c -> gpl.ko) 
void a_function(void) 
{ 
// ... 
} 
EXPORT_SYMBOL(a_function) 


// Closed Source module (closed.c -> closed.ko) 
a_function(); 

diese legal ist? Verletzen wir in diesem Beispiel die GPL2-Lizenz? Bitte beachten Sie, dass closed.c keine gpl2-Header-Datei enthält.

Answer 1

Es gibt GPL_ONLY Flag für Module, die nicht in Nicht-GPL-Module verwendet werden sollten. Wenn das Modul, über das Sie sprechen, nicht GPL_ONLY ist, können Sie es verwenden.

Aber auch diese, die GPL_ONLY sind, können verwendet werden, wenn Sie über user-space drivers, which are possible in 2.6.23 darauf zugreifen. Genau das ist mit dem USB-Subsystem passiert. http://www.linux-magazine.com/online/news/linux_2_6_25_without_closed_source_usb_drivers

Nicht gerade rechtliche Frage Adressierung, sondern gibt Ihnen eine Vorstellung: http://www.cyberciti.biz/tips/linus-rejects-the-idea-of-non-gpl-kernel-modules.html

Answer 2

1 .: Sie müssen mit einem Anwalt darüber sprechen; wahrscheinlich die Rechtsabteilung Ihres Unternehmens.

2.: Die wichtige Frage ist, welches Stück Code von welchem ​​anderen Code abgeleitet wird.

Leider gibt es fast keine Antwort auf diese Frage.

Einige würden halten, dass alle Kernel-Module abgeleitete Werke des Kernels sind, so müssen unabhängig von der Header-Aufnahme GPL sein.

Alternativ ist Ihr geschlossenes Modul vom GPL-Modul abgeleitet, und das GPL-Modul stammt vom Kernel, also muss das geschlossene Modul auch GPL sein.

Answer 3

IANAL so sollten Sie wirklich qualifizierte Rechtsgutachten einholen. Allerdings geht dieser Ansatz sicherlich gegen den Geist der Lizenz und werden Sie keine Freunde im Kernelland gewinnen.

Sie könnten jedoch eine andere Aufteilung betrachten. Ein Ansatz ist, ein vollständig GPL-Modul zu haben und all Ihre "geheime Firma IP" in einem Benutzer Raumfahrer zu setzen. Dies ist eine Herangehensweise, die ich gemacht habe, als die Firma, für die ich arbeitete, nicht darauf erpicht war, die Details unseres FPGA der Welt offen zu legen. Alle Entscheidungen und Registereinstellungen wurden im Userspace entschieden und die Kernel-Seite des Treibers lud nur Werte in IRQs ein. Mit vorsichtiger Design können Sie alle Probleme in Echtzeit verwalten, die Sie haben können und eine nette saubere Trennung zwischen Ihrem geschlossenen Treiber und dem Kernel haben. I glaube, das ist einfacher mit neueren Kernel mit Unterstützung für Benutzerraum Treiber, obwohl ich denke, dass sie DMA noch nicht richtig unterstützen (Ich musste ein Benutzer-Space-DMA-Kernel-Modul zu unterstützen DMA direkt zwischen der Chipsatz und Benutzerraum).

Aber (wieder) würde ich wirklich empfehlen, Sie überlegen, was es ist Ihre versucht zu schützen. Geschlossene Treiber können für eingebettete Anwendungen OK sein, wo Sie die Kernelversion und die Hardware genau kontrollieren können. Aber wenn dieser Treiber für etwas allgemeineres betrachtet wird Verkauf von Hardware-Menschen werden in ihre eigenen Systeme stecken) dann geschlossen Quelle Treiber werden nur beweisen, eine Quelle von ständigen Schmerzen und Wartung Kopfschmerzen.

Answer 4

Es gibt eine Meinung von einigen wichtigen Kernel-Entwicklern (aber nicht von Linus selbst), dass jedes nicht-GPL-Modul eine Verletzung der Kernel-Lizenz darstellt.

Als einige Entwickler den Belkin-Treiber vom Linksys-Router gerissen, umgekehrt manipuliert und das Ergebnis veröffentlicht hatten, konnte Belkin sie wegen der Gegenvorstellung, diese Lizenzinterpretation vor Gericht zur Verteidigung zu bringen, nicht aufhalten.

Answer 5

Unzählige andere Treiber haben eine Open-Source- "Shim" verwendet, um eine Closed-Source-Objektdatei mit dem Open-Source-Kernel zu überbrücken. Dies wird von den meisten Kernel-Entwicklern als Verletzung der GPL angesehen.

Meiner Meinung nach kommt es darauf an, ob Sie die Software vertreiben. Wenn Sie dies ausschließlich auf Software-as-a-Service ausführen, sollte das erlaubt sein. Wenn Sie ein Embedded-Gerät oder ein Boxed-Produkt vertreiben, ist es ein No-No.

Verschieben Sie die Funktionalität, die Sie benötigen, aus dem Kernel, oder öffnen Sie Ihre Kernel-Komponenten. Das ist es, was alle anderen (ehrlich) tun, und es ist im Allgemeinen nicht so schwierig, weil jeder, der beträchtliche Mengen an geistigem Eigentum im Kernel-Space hat, entweder ein schlechtes Geschäftsmodell oder ein inkompetentes Ingenieurteam hat.

* die oben ist meine Meinung *