News for hackers. Stuff that matters.
Re:Standardizing BPF by jmillikin on Friday April 21, 2023 @04:49AM (#35651253)
No such argument is needed (or possible). If you've written an eBPF program that is a derived work of the Linux kernel (for example by copy-pasting Linux code into it), then it's a derived work whether or not it's ever loaded.

Conversely, if your eBPF program is not a derived work of the Linux kernel (because you hand-coded its bytecode in a hex editor via reference to a clean-room eBPF spec) then loading it won't change that.

If you wrote it in C and compiled it with Clang, then whether the compiled eBPF bytecode is a derived work would require (1) looking at the source code and (2) inspecting the compiled output to see if anything unexpected got pulled in via #include.

Re:Standardizing BPF by 112233 on Friday April 21, 2023 @05:19AM (#35651418)
That is not at all what is implied by the "same as kernel modules" text in the bpf manpage. What the manpage says is, essentially, any reference to gpl_only stuff is similar to using EXPORT_SYMBOL_GPL functions in modules, that "cannot be used without the user being a derived work of kernel" according to GKH.

Now, if the userspace program that loads this eBPF is fundamentally coupled to that eBPF program, the argument carries, no?