Die proprietäre Entwicklung ist tief in den Code vieler Anwendungen und Dienste eingedrungen. In komplexen Systemen ist es sehr schwierig, sie loszuwerden. Oft werden hierfür Problemumgehungen verwendet, die eher "Krücken" ähneln. Der Linux-Kernel verwendet Interlayer-Treiber, um mit proprietären Treibern zu arbeiten, die fast ausschließlich für die Übersetzung von Treiberaufrufen in den Kernel entwickelt wurden. Der Interlayer verfügt über Open Source Code, sodass es keine Probleme mit der GPL-Lizenz gibt. Die Formalitäten wurden eingehalten.
Aber dieser Ansatz hat viele Gegner. Einer von ihnen ist Christoph Hellwig, ein Linux-Kernel-Entwickler. Zuvor war er Mitglied des technischen Lenkungsausschusses der Linux Foundation. Er war auch Kläger in einer Klage bei VMware. Helwig schlug vor, den Schutz gegen das Binden proprietärer Treiber an Linux-Kernel-Komponenten erheblich zu verschärfen.
Zu diesem Zweck schlägt er die Verwendung von Patches vor , die es ermöglichen, Flags zu erben, die mit dem Export von GPL-Symbolen verbunden sind. In diesem Fall wird das Flag TAINT_PROPRIETARY_MODULE von allen Modulen geerbt, die Symbole von Modulen mit diesem Flag importieren. Der Kern des Schutzes besteht darin, dass das GPL-Modul das Label TAINT_PROPRIETARY_MODULE erbt und nicht auf die Kernelkomponenten zugreifen kann, die nur für GPL-Module verfügbar sind, wenn der Layer-Treiber etwas importiert, das nicht aus dem GPL-Modul stammt.
Quelle: 3dnews
Während der Diskussion wurde auch eine umgekehrte Blockierung vorgeschlagen. Wenn ein Modul EXPORT_SYMBOL_GPL importiert, sollten vom Modul exportierte Symbole nicht von Modulen importiert werden, die keine GPL-Kompatibilität beanspruchen. Der Vorschlag wurde nicht von Helwig, sondern von einem anderen Diskussionsteilnehmer gemacht. Aber Helwig stimmte ihm zu. Höchstwahrscheinlich wird Linus Torvalds diesen Vorschlag nicht überspringen, da er eine Reihe von Kernel-Subsystemen für proprietäre Treiber blockiert. Nach der Veröffentlichung brach
alles Aufhebens ausein Patch-Ingenieur von Facebook mit der Implementierung des NetGPU-Subsystems. Dieses Subsystem ermöglicht es, den direkten Datenaustausch zwischen der Netzwerkkarte und der GPU mit der Ausführung der Protokollverarbeitung durch die CPU zu organisieren. Auf der Grundlage des Vorschlags können Sie eine allgemeine Implementierung von RDMA für den Datenaustausch zwischen GPUs oder externem CXD vornehmen. Viele Entwickler äußerten sich unzufrieden mit solchen Innovationen, da die Implementierung nur für proprietäre NVIDIA-Treiber über die von diesen Treibern bereitgestellte Schicht verfügbar ist. Helvig nannte den Entwickler sogar einen Troll.
Der Autor des Patches beanstandete wiederum, dass das Subsystem nicht an NVIDIA gebunden ist, sodass Software-Schnittstellen zu AMD- und Intel-GPUs unterstützt werden können. Letztendlich wurde es als unmöglich erachtet, netgpu im Kernel zu bewerben, bis es eine funktionierende Unterstützung gab, die auf kostenlosen Treibern wie AMDGPU, Intel i915 oder Nouveau basierte.