KRSI and proprietary BPF programs
KRSI and proprietary BPF programs
Posted Jan 20, 2020 16:53 UTC (Mon) by admalledd (subscriber, #95347)In reply to: KRSI and proprietary BPF programs by rvolgers
Parent article: KRSI and proprietary BPF programs
At my work we have some brief workshops on various topics that are related to our work. One of the ones that they require us developers partake in is a bit about licensing and GPL/MIT/AGPL/etc that we might encounter for either plugins/packages/modules or platforms we might develop with/for. Mostly so that we remember to go and check in with legal on specifics whenever we use something new.
The big thing that was stated about "interfaces, API layers and poison licenses" (Sorry, corporates words...) is that if something does have to go to court (or arbitration and remediation, the corporate preference) the intent of initial developers placing code under the license in question, including even commented code or notes questioning if it should be, can have significant weight on "is this a derivative work". Courts are imperfect and imprecise, so they use things like "tests" that can be used to answer questions outside of their scope. These tests and questions would fall upon that there were marked "we, the kernel developers think using these things means you are so tied to us that you must be derivative" and that is a powerful argument to deconstruct from the other side. We ourselves use AGPL3 or MIT in a defensive fashion for any code we own outright and have to (by client contract/ask/funding) open source it. Applying comments, exports, etc flagging "you might be a derivative" is something we actually took from the Kernel. Of course in general corporate don't want to have to ever see a court room to enforce (or be enforced by) any of these, so mostly are just legal ammo to bring people to arbitration/remediation where corporate legal can say "it is so much easier if we all play nice hrm?".
As much to say: even if the BPF *didn't* see the internal structures, but the helpers were marked GPL (or the entire hook point, whatever) would certainly have me pushing that any BPF we wrote as also being GPL. Only way I would stand down is with a lot of CYA paperwork from both parties.
IMO the Nvidia shim (and some others) possibly violate the GPL as intended, but that too many people are locked in to requiring the module to use the hardware means no one really wants to take that close a legal look and risk having worthless hardware. Again, I am not a lawyer, my opinion is my own, etc.
Posted Jan 21, 2020 2:43 UTC (Tue)
by zlynx (guest, #2285)
[Link] (2 responses)
As far as I know no one distributes a fully compiled Nvidia driver module. The end user always does it. The end user cannot violate the GPL. The trick is the dual licensing of the Nvidia glue shim which is licensed both to link to the Nvidia proprietary .o driver and is licensed as GPL2 to link to the kernel.
The result of linking it all is a violation of all licenses and cannot be legally distributed. But no one cares because no one is distributing the result, just the individual pieces.
Posted Jan 21, 2020 23:50 UTC (Tue)
by gray_-_wolf (subscriber, #131074)
[Link]
Posted Jan 23, 2020 23:22 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
KRSI and proprietary BPF programs
KRSI and proprietary BPF programs
KRSI and proprietary BPF programs