3 ms·
> If some particular eBPF program is a derived work of the kernel, then whether it's loaded or not doesn't matter. IANAL, but as eBPF programs are distributed
by Denvercoder9 3y ago
> If some particular eBPF program is a derived work of the kernel, then whether it's loaded or not doesn't matter.
IANAL, but as eBPF programs are distributed as bytecode and only JIT-compiled and linked when they are loaded into the kernel, I think there's an argument to be made that it doesn't become a derivative work until it's loaded.
- jmillikin 3y agoNo 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.
- 112233 3y agoThat 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?