KRSI and proprietary BPF programs

Posted Jan 19, 2020 9:42 UTC (Sun) by mfuzzey (subscriber, #57966)
Parent article: KRSI and proprietary BPF programs

While I understand , and agree with, the desire to prevent proprietary security modules I'm not quite sure how this works legally.

INAL but I thought the legal basis for the GPL applying to modified kernels or kernel modules is that they are considered derived works of the original GPL kernel.
For modules it is even a bit murkier than that I think, which allows Nvidia to get away with their GPL shim loading a propriety binary driver (which was not originally designed solely for Linux).

But does derived work apply to independently developped BPF code just using hooks that the GPL kernel provides?

KRSI and proprietary BPF programs

Posted Jan 20, 2020 8:52 UTC (Mon) by rvolgers (guest, #63218) [Link] (5 responses)

The idea behind marking interfaces as GPL or not GPL is that marking something GPL-only means that the kernel developers consider it to be so intimately tied to the internals of the kernel that using it necessarily means your product is a derived work of the kernel as defined by the GPL.

Of course I don't think that precise interpretation has ever been tested in court. But it's easy to see how that extends to BPF security hooks. They get passed a structure full of data that is very much full of kernel implementation details and not intended as a public interface to "other projects". So it seems reasonable to say that if you write a BPF program that receives that as an argument, it's a derived work of the Linux kernel, and so must be released under a GPL compatible license.

KRSI and proprietary BPF programs

Posted Jan 20, 2020 16:53 UTC (Mon) by admalledd (subscriber, #95347) [Link] (3 responses)

Not legal advice, not a lawyer myself, etc etc.

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.

KRSI and proprietary BPF programs

Posted Jan 21, 2020 2:43 UTC (Tue) by zlynx (guest, #2285) [Link] (2 responses)

IMO the nvidia binary module definitely violates the GPL. Once it is compiled. That's the key.

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.

KRSI and proprietary BPF programs

Posted Jan 21, 2020 23:50 UTC (Tue) by gray_-_wolf (subscriber, #131074) [Link]

https://www.archlinux.org/packages/extra/x86_64/nvidia/ Based on the package content this looks like distributing compiled nvidia module. I have no idea if it is legal or not just pointing out that at least archlinux does distribute it in compiled form.

KRSI and proprietary BPF programs

Posted Jan 23, 2020 23:22 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

So, basically, the same loophole that ZFS-on-Linux has been using for ages? IIRC various people were upset about Canonical's semi-recent decision to cut out the middleman and provide full ZFS support on the install disk, but I've heard nothing about actual lawsuits.

KRSI and proprietary BPF programs

Posted Jan 30, 2020 22:38 UTC (Thu) by Wol (subscriber, #4433) [Link]

> So it seems reasonable to say that if you write a BPF program that receives that as an argument, it's a derived work of the Linux kernel, and so must be released under a GPL compatible license.

Except that one of the freedoms the GPL is - explicitly - designed to enforce is the freedom NOT to release your work.

So no, it is NOT a reasonable argument to say it must be released under a GPL-compatible licence ...

Cheers,
Wol