Modules de noyau non-GPL utilisant GPL

Question

La société pour laquelle je travaille développe un module de noyau de source fermée (fichier .ko). Ce module doit effectuer des appels aux fonctions contenues dans un module gpl2. En fait, nous avons une situation comme celle-ci:

// 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(); 

Est-ce légal? Violons-nous la licence GPL2 dans cet exemple? Veuillez noter que closed.c n'inclut aucun fichier d'en-tête gpl2.

Answer 1

Il y a GPL_ONLY indicateur pour les modules, qui ne doit pas être utilisé dans des modules non-GPL. Donc, si le module dont vous parlez n'est pas GPL_ONLY, vous pouvez l'utiliser.

Mais même ceux qui sont GPL_ONLY peuvent être utilisés si vous y accédez via user-space drivers, which are possible in 2.6.23. C'est exactement ce qui est arrivé au sous-système USB. http://www.linux-magazine.com/online/news/linux_2_6_25_without_closed_source_usb_drivers

Pas exactement d'adressage problème juridique, mais vous donne une idée: http://www.cyberciti.biz/tips/linus-rejects-the-idea-of-non-gpl-kernel-modules.html

Answer 2

1er: Vous devez parler à un avocat à ce sujet; probablement le service juridique de votre entreprise. 2ème: La question importante est quel morceau de code est dérivé de quel autre code.

Malheureusement, il y a presque n'importe quel nombre de réponses pour cette question. Certains diraient que tous les modules du noyau sont des travaux dérivés du noyau, ils doivent donc être GPL indépendamment de l'inclusion de l'en-tête.

Alternativement votre module fermé dérive du module GPL, et le module GPL dérive du noyau, ainsi le module fermé doit également être GPL.

Answer 3

IANAL donc vous devriez vraiment demander un avis juridique qualifié. Cependant cette approche va certainement à l'encontre de l'esprit de la licence et ne vous gagnera pas d'amis dans les terres des noyaux.

Cependant, vous pourriez envisager une division différente. Une approche consiste à avoir un module entièrement GPL'ed et mettre toute votre "IP de société secrète" dans un pilote d'espace utilisateur . C'est une approche que j'ai prise lorsque la société pour laquelle j'ai travaillé pour ne tenait pas à exposer les détails de notre FPGA au monde. Toutes les décisions et les paramètres de registre où décidé dans l'espace utilisateur et le côté noyau du pilote vient de charger des valeurs dans IRQ. Avec un design soigné , vous pouvez gérer tous les problèmes en temps réel que vous pourriez avoir et une bonne séparation entre votre pilote fermé et le noyau. I crois que c'est plus facile avec les nouveaux noyaux avec support pour l'espace utilisateur drivers bien que je ne pense pas qu'ils supportent DMA correctement (je devais coder un module de noyau DMA espace utilisateur pour supporter DMA directement entre le chipset et l'espace utilisateur).

Cependant (encore) je vous recommande vraiment de considérer ce que c'est votre en essayant de protéger. Les pilotes fermés peuvent convenir aux applications intégrées où vous avez un contrôle strict sur la version du noyau et le matériel. Mais si ce pilote est envisagé pour quelque chose de plus générique (c.-à-d. personnes vendant du matériel se connecteront à leurs propres systèmes) puis fermé les pilotes de source ne se révélera être une source de douleur constante et maux de tête de maintenance.

Answer 4

Certains développeurs clés du noyau (mais pas Linus lui-même) sont d'avis que tout module non-GPL est une violation de la licence du noyau. Lorsque certains développeurs ont arraché le pilote Belkin du routeur Linksys, l'ont inversé et publié le résultat, Belkin n'a pas pu les arrêter à cause de la contre-attaque consistant à apporter cette interprétation de la licence devant le tribunal en guise de défense.

Answer 5

D'innombrables autres pilotes ont utilisé un «shim» open-source pour faire le pont entre un fichier objet de source fermée et le noyau open-source. Ceci est considéré par la plupart des développeurs du noyau comme une violation, au moins dans l'esprit, de la GPL. Selon moi, cela dépend si vous distribuez le logiciel. Si vous utilisez uniquement le logiciel en tant que service, cela devrait être autorisé. Si vous distribuez un périphérique intégré ou un produit en boîte, c'est un non-non.

Déplacez toutes les fonctionnalités dont vous avez besoin du noyau, ou ouvrez les composants de votre noyau. C'est ce que tout le monde (honnête) fait, et ce n'est généralement pas aussi compliqué, car quiconque possède une quantité importante de «propriété intellectuelle» du noyau a un mauvais modèle d'affaires ou une équipe d'ingénieurs incompétente.

* ci-dessus est mon opinion *