Christophe Hellwig, un éminent développeur de noyau Linux qui était autrefois membre du comité de pilotage technique de la Linux Foundation et qui a intenté une action en justice GPL contre VMware.
Il a proposé de resserrer les protections contre l'attachement pilotes propriétaires aux composants du noyau Linux exportés uniquement pour les modules sous licence GPL.
Pour éviter les restrictions pour exporter des symboles GPL, les fabricants de contrôleurs propriétaires utilisent un module de couche, dont le code est open source et distribué sous licence GPLv2, mais les fonctions se résument à transmettre l'accès du contrôleur propriétaire aux API les fichiers du noyau dont l'utilisation est interdite directement à partir du code propriétaire.
Pour bloquer une telle manœuvre, Christoph Helwig a préparé des correctifs pour le noyau Linux qui garantissent l'héritage des drapeaux associés à l'exportation des symboles GPL.
Nous avons eu une erreur dans la résolution de notre module _GPL depuis le premier jour,
c'est-à-dire qu'un module peut prétendre être sous licence GPL et utiliser des exportations _GPL, tout en s'appuyant également sur des symboles de module non GPL. Ceci est utilisé comme un contournement des exportations _GPL en utilisant un petit module de shim qui utilise les exportations _GPL et d'autres fonctionnalités.
La proposition se résume à hériter de l'indicateur TAINT_PROPRIETARY_MODULE dans tous les modules qui importent des symboles de module avec cet indicateur.
Par conséquent, si un module de couche intermédiaire GPL tente d'importer des symboles à partir d'un module non GPL, le module GPL héritera de la balise TAINT_PROPRIETARY_MODULE et ne pourra pas accéder aux composants du noyau disponibles uniquement pour les modules sous licence GPL, même si le module précédemment importé symboles de "gplonly".
Le patch de Hellwig essaie maintenant de rendre cela difficile. Les modules qui importent des symboles propriétaires sont marqués propriétaires et n'ont pas accès aux symboles GPL.
Le changement a été proposé en réponse à une série de correctifs publiés par un ingénieur Facebook avec l'implémentation d'un nouveau sous-système netgpu, qui permet un échange direct de données (zero copy DMA) entre la carte réseau et le GPU, tout en effectuant le traitement du protocole par le CPU.
Cela éviterait la méthode initialement prévue par Jonathan Lemon pour vos correctifs et entraînerait le développement des intercalaires pour omettre le symbole GPL être beaucoup plus difficile, même s'il y a encore un petit écart, comme indiqué.
Dans la discussion qu'ils ont actuellement divers développeurs de noyau Linux également un blocage inverse a été suggéré: Si un module importe des symboles EXPORT_SYMBOL_GPL, les symboles exportés par ce module ne doivent pas être importés par des modules qui ne revendiquent pas explicitement la compatibilité GPL.
Ceux qui n'ont pas de module importent des symboles EXPORT_SYMBOL_GPL, tous leurs symboles exportés doivent être traités comme EXPORT_SYMBOL_GPL.
Christoph Helwig a écrit qu'il était d'accord à 100% avec cette proposition, mais Linus Torvalds ne manquera pas ce changement car il rendra la plupart des sous-systèmes du noyau indisponibles pour les pilotes propriétaires, en raison du fait que lors du développement des pilotes, les symboles de base sont exportés sous la GPL
Les développeurs n'étaient pas satisfaits de la disponibilité de l'implémentation uniquement pour les pilotes propriétaires NVIDIA via la couche GPL fournie par ces pilotes.
En réponse aux critiques, l'auteur du correctif a indiqué que le sous-système n'est pas lié à NVIDIA et son support peut être fourni, entre autres, pour les interfaces logicielles pour les GPU AMD et Intel.
En conséquence, la promotion de netgpu dans le noyau a été jugée impossible jusqu'à la disponibilité d'un support fonctionnel basé sur des pilotes gratuits tels que AMDGPU, Intel i915 ou Nouveau.
Tu dois te souvenir que dans le passé, la communauté du noyau Linux a mis en œuvre une variété de changements que sciemment ou comme effet secondaire, ont entravé le développement de modules propriétaires ou non compatible avec les licences.
Enfin si vous voulez en savoir plus, vous pouvez vérifier les détails en allant vers le lien suivant.
source: https://lkml.org/
Il serait peut-être préférable de mettre l'article en anglais plutôt que d'utiliser un traducteur. Il y a de nombreuses parties qui me sont incompréhensibles.