Christoph Hellwig, a prominent Linux kernel developer who was once a member of the Linux Foundation's technical steering committee and sued in a GPL litigation against VMware.
He has proposed tightening the protections against tying proprietary drivers to exported Linux kernel components only for modules licensed under the GPL.
To avoid restriction to export GPL symbols, proprietary controller manufacturers use a layer module, whose code is open source and is distributed under the GPLv2 license, but the functions boil down to passing the owner controller access to the APIs kernel files, the use of which is prohibited directly from the proprietary code.
To block such a maneuver, Christoph Helwig prepared patches for the Linux kernel that ensure inheritance of the flags associated with the export of GPL symbols.
We have had an error in our _GPL module resolution since day one,
that is, a module can claim to be GPL licensed and use _GPL exports, while also relying on non-GPL module symbols. This is used as a circumvention of _GPL exports by using a small shim module that uses _GPL exports and other functionality.
The proposal boils down to inheriting the indicator TAINT_PROPRIETARY_MODULE in all modules that import module symbols with this flag.
Therefore, if a GPL middle layer module tries to import symbols from a non-GPL module, the GPL module will inherit the TAINT_PROPRIETARY_MODULE tag and will not be able to access the kernel components available only to GPL licensed modules, even if the module previously imported symbols from "gplonly".
Hellwig's patch is now trying to make this difficult. Modules that import proprietary symbols are marked proprietary and do not have access to GPL symbols.
The change was proposed in response to a series of patches released by a Facebook engineer with the implementation of a new netgpu subsystem, which allows direct data exchange (zero copy DMA) between the network card and the GPU, while performing the protocol processing by the CPU.
This would avoid the method originally planned by Jonathan Lemon for your patches and would make the development of the interlayers to omit the GPL symbol be much more difficult, even if there is still a small gap, as indicated.
In the discussion they are currently having various Linux kernel developers as well reverse blocking suggested: If a module imports EXPORT_SYMBOL_GPL symbols, the symbols exported by that module should not be imported by modules that do not explicitly claim GPL compatibility.
Those without a module imports EXPORT_SYMBOL_GPL symbols, all their exported symbols should be treated as EXPORT_SYMBOL_GPL.
Christoph Helwig wrote that he agrees 100% with this proposal, but Linus Torvalds won't miss out on that change as it will make most of the kernel subsystems unavailable to proprietary drivers, due to the fact that when developing drivers the base symbols are exported under the GPL
The developers were not satisfied with the availability of the implementation only for the proprietary NVIDIA drivers through the GPL layer provided by these drivers.
In response to criticism, the author of the patch indicated that the subsystem is not linked to NVIDIA and its support can be provided, among other things, for software interfaces for AMD and Intel GPUs.
As a result, the promotion of netgpu in the kernel was deemed impossible until the availability of working support based on free drivers such as AMDGPU, Intel i915 or Nouveau.
You have to remember that in the past, the Linux kernel community has implemented a variety of changes that knowingly or as a side effect, have hindered the development of proprietary modules or not compatible with licenses.
Finally if you want to know more about it, you can check the details by going to the following link.
Source: https://lkml.org/
Maybe it would be better to put the article in English instead of using a translator. There are many parts that are unintelligible to me.