Proprietary development has penetrated deep into the code of many applications and services. In complex systems, getting rid of them is very difficult. Often, workarounds are used for this, which are rather "crutches". The Linux kernel uses interlayer drivers to work with proprietary drivers, which are designed almost exclusively for translating driver calls to the kernel. The interlayer has open source code, so there are no problems with the GPL license, the formalities have been followed.
But this approach has many opponents. One of them is Christoph Hellwig, a Linux kernel developer. He was previously a member of the Linux Foundation's technical steering committee. He also served as a plaintiff in a lawsuit with VMware. Helwig proposed to significantly tighten the protection against binding proprietary drivers to Linux kernel components.
To do this, he suggests using patches that make it possible to inherit flags associated with the export of GPL symbols. In this case, the TAINT_PROPRIETARY_MODULE flag is inherited in all modules that import symbols from modules with this flag. The essence of the protection is that if the layer driver imports something not from the GPL module, then the GPL module will inherit the TAINT_PROPRIETARY_MODULE label and will not be able to access the kernel components available only for GPL modules.
Source: 3dnews
During the discussion, a reverse blocking was also proposed. So, if a module imports EXPORT_SYMBOL_GPL, then any symbols exported by the module should not be imported by modules that do not claim GPL compatibility. The proposal was not made by Helwig, but by another participant in the discussion. But Helwig agreed with him. Most likely, Linus Torvalds will not skip this proposal, as it will block a number of kernel subsystems for proprietary drivers.
All fuss broke out after the publicationa patch engineer from Facebook with the implementation of the netgpu subsystem. This subsystem makes it possible to organize direct data exchange between the network card and the GPU with the execution of the protocol processing by the CPU. On the basis of the proposal, you can make a general implementation of RDMA for data exchange between GPUs or external CXD. Many developers expressed dissatisfaction with such innovations, since the implementation is available only for proprietary NVIDIA drivers through the layer provided by these drivers. Helvig even called the developer a troll.
In turn, the author of the patch objected that the subsystem is not tied to NVIDIA, so its support can be provided for software interfaces to AMD and Intel GPUs. Ultimately, it was deemed impossible to promote netgpu in the kernel until there was working support based on free drivers such as AMDGPU, Intel i915 or Nouveau.