O desenvolvimento proprietário penetrou profundamente no código de muitos aplicativos e serviços. Em sistemas complexos, é muito difícil livrar-se deles. Freqüentemente, soluções alternativas são usadas para isso, que são mais como "muletas". O kernel Linux usa drivers intercamadas para trabalhar com drivers proprietários, que são projetados quase exclusivamente para traduzir chamadas de driver para o kernel. O interlayer possui código-fonte aberto, portanto não há problemas com a licença GPL, as formalidades foram seguidas.
Mas essa abordagem tem muitos oponentes. Um deles é Christoph Hellwig, desenvolvedor do kernel Linux. Anteriormente, ele foi membro do comitê técnico da Linux Foundation. Ele também atuou como demandante em uma ação judicial com a VMware. Helwig propôs aumentar significativamente a proteção contra a vinculação de drivers proprietários aos componentes do kernel do Linux.
Para fazer isso, ele sugere o uso de patches que tornam possível herdar sinalizadores associados à exportação de símbolos GPL. Nesse caso, o sinalizador TAINT_PROPRIETARY_MODULE é herdado em todos os módulos que importam símbolos de módulos com este sinalizador. A essência da proteção é que se o driver interlayer importar algo que não seja do módulo GPL, o módulo GPL herdará o rótulo TAINT_PROPRIETARY_MODULE e não será capaz de acessar os componentes do kernel disponíveis apenas para módulos GPL.
Fonte: 3dnews
Durante a discussão, um bloqueio reverso também foi proposto. Por exemplo, se um módulo importa EXPORT_SYMBOL_GPL, quaisquer símbolos exportados pelo módulo não devem ser importados por módulos que não alegam compatibilidade GPL. A proposta não foi feita por Helwig, mas por outro participante da discussão. Mas Helwig concordou com ele. Muito provavelmente, Linus Torvalds não irá ignorar esta proposta, já que irá bloquear vários subsistemas do kernel para drivers proprietários.
Todo o rebuliço começou após a publicaçãoum engenheiro de patch do Facebook com a implementação do subsistema netgpu. Este subsistema permite organizar a troca direta de dados entre a placa de rede e a GPU com a execução do processamento do protocolo pela CPU. Com base na proposta, você pode fazer uma implementação geral de RDMA para troca de dados entre GPUs ou CXD externo. Muitos desenvolvedores expressaram insatisfação com essas inovações, uma vez que a implementação está disponível apenas para drivers NVIDIA proprietários por meio da camada fornecida por esses drivers. Helvig até chamou o desenvolvedor de troll.
Por sua vez, o autor do patch objetou que o subsistema não está vinculado à NVIDIA, de modo que seu suporte pode ser fornecido para interfaces de software para GPUs AMD e Intel. No final das contas, foi considerado impossível promover o netgpu no kernel até que houvesse suporte de trabalho baseado em drivers gratuitos como AMDGPU, Intel i915 ou Nouveau.