Christoph Hellwig, en framstående Linux-kärnutvecklare som en gång var medlem i Linux Foundations tekniska styrkommitté och stämde i en GPL-process mot VMware.
Han har föreslagit att stärka skydden mot länkning proprietära drivrutiner till exporterade Linux-kärnkomponenter endast för moduler licensierade under GPL.
För att undvika begränsningen för att exportera GPL-symboler, proprietära drivrutinstillverkare använder en lagermodul, vars kod är öppen källkod och distribueras under GPLv2-licensen, men funktionerna reduceras till att ge ägarkontrollantens åtkomst till API:erna nödvändiga kärnfiler, vars användning är förbjuden direkt från proprietär kod.
För att blockera en sådan manöver, Christoph Helwig förberedde patchar för Linux-kärnan som säkerställer arv av flaggorna som är kopplade till exporten av GPL-symboler.
Vi har haft en bugg i vår _GPL-modulupplösning sedan dag ett,
det vill säga en modul kan göra anspråk på att vara GPL-licensierad och använda _GPL-exporter, samtidigt som den förlitar sig på symboler från icke-GPL-moduler. Detta används som ett kringgående av _GPL-exporterna genom att använda en liten shim-modul som använder _GPL-exporterna och andra funktioner.
Förslaget går ut på att ärva flaggan TAINT_PROPRIETARY_MODULE i alla moduler som importerar modulsymboler med denna flagga.
Därför, om en GPL-mellanlagermodul försöker importera symboler från en icke-GPL-modul, kommer GPL-modulen att ärva TAINT_PROPRIETARY_MODULE-taggen och kommer inte att kunna komma åt kärnkomponenter som bara är tillgängliga för GPL-licensierade moduler, även om modulen tidigare importerats symboler från "gponly".
Hellwigs patch försöker nu göra detta svårt. Moduler som importerar proprietära symboler är markerade som proprietära och har inte tillgång till GPL-symbolerna.
Ändringen föreslogs som svar på en serie släppta patchar av en Facebook-ingenjör med implementeringen av ett nytt netgpu-undersystem, som tillåter direkt datautbyte (DMA noll kopia) mellan nätverkskortet och GPU:n, samtidigt som protokollbearbetningen utförs av CPU:n.
Detta skulle undvika metoden som ursprungligen planerades av Jonathan Lemon för dina patchar och skulle få utvecklingen av de mellanliggande lagren att utelämna GPL-symbolen vara mycket svårare, även om det fortfarande finns en liten lucka, som du anger.
I den diskussion som de för just nu olika Linux-kärnutvecklare också Omvänd lås föreslås: om en modul importerar EXPORT_SYMBOL_GPL-symboler, får symboler som exporteras av den modulen inte importeras av moduler som inte uttryckligen hävdar GPL-kompatibilitet.
De utan en modul importerar EXPORT_SYMBOL_GPL-symboler, alla dina exporterade symboler ska behandlas som EXPORT_SYMBOL_GPL.
Christoph Helwig skrev att han instämmer till 100% i detta förslag, men Linus Torvalds kommer inte att missa den förändringen, eftersom den kommer att göra de flesta av kärnundersystemen otillgängliga för proprietära drivrutiner, på grund av det faktum att när man utvecklar drivrutiner exporteras bassymbolerna under GPL
Utvecklarna var inte nöjda med tillgängligheten av implementeringen endast för proprietära NVIDIA-drivrutiner genom GPL-lagret som tillhandahålls av dessa drivrutiner.
Som svar på kritik, författaren till patchen angav att delsystemet inte är kopplat till NVIDIA och dess stöd kan tillhandahållas bland annat för mjukvarugränssnitt till AMD och Intel GPU:er.
Som ett resultat ansågs marknadsföringen av netgpu i kärnan vara omöjlig förrän tillgången till gratis drivrutinsbaserat arbetsstöd som AMDGPU, Intel i915 eller Nouveau.
Du måste komma ihåg det förr, Linux-kärngemenskapen har genomfört en mängd olika förändringar som, medvetet eller som en bieffekt, har hindrat utvecklingen av proprietära moduler eller inte är kompatibel med licenser.
Slutligen om du vill veta mer om detkan du kontrollera detaljerna genom att gå till följande länk.
Fuente: https://lkml.org/
Kanske vore det bättre att lägga artikeln på engelska istället för att använda en översättare. Det finns många delar som är obegripliga för mig.