3 ms·

> eBPF was linux-only in such a way that loading eBPF program into > kernel made your userspace program a derived work of linux kernel > and forced GPL-2 on

> eBPF was linux-only in such a way that loading eBPF program into > kernel made your userspace program a derived work of linux kernel > and forced GPL-2 on the userspace. Copyright doesn't work like that: 1. If some particular eBPF program is a derived work of the kernel, then whether it's loaded or not doesn't matter. Distributing that program (such as embedded into an ELF binary) would still require being accompanied by its source code (/ a written offer, etc). 2. If some eBPF program is not a derived work, then loading it into the kernel doesn't cause the userspace program to become a derived work. Programs distributed as interpreted bytecode are not automatically derived works of their interpreter. 3. Even if a program depends on GPL'd code in such a way as to be a derived work when compiled, its own license only needs to be compatible with the GPL, it doesn't need to be GPL'd itself. For example, it's legal to write and distribute a Linux kernel module licensed under various permissive licenses (MIT, 3-clause BSD, etc).

112233 4y ago
Thanks, but it did't help ... :) Suppose a person is writing software that works on linux as part of dayjob/hobby/large project/tutorial or something. And, wanting to use some eBPF produced by clang, that person comes to this "license" member in the manpage. What to do? Call lawyer? Call police? Call reddit? [edit, a ramble]: next logical step after putting license in API is putting Code of Conduct in api. Half expecting vegan-only syscalls any time soon.
- jmillikin 4y ago
  > And, wanting to use some eBPF produced by clang, that person comes > to this "license" member in the manpage. What to do? Call lawyer? > Call police? Call reddit? They could try reading, which is effective in this situation given that the quoted portion of the manpage is a concise and easily-understood description of the rules.
Denvercoder9 4y 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 4y ago
  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.
  - 112233 4y ago
    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?

112233 4y ago

Thanks, but it did't help ... :) Suppose a person is writing software that works on linux as part of dayjob/hobby/large project/tutorial or something. And, wanting to use some eBPF produced by clang, that person comes to this "license" member in the manpage. What to do? Call lawyer? Call police? Call reddit? [edit, a ramble]: next logical step after putting license in API is putting Code of Conduct in api. Half expecting vegan-only syscalls any time soon.

jmillikin 4y ago
> And, wanting to use some eBPF produced by clang, that person comes > to this "license" member in the manpage. What to do? Call lawyer? > Call police? Call reddit? They could try reading, which is effective in this situation given that the quoted portion of the manpage is a concise and easily-understood description of the rules.

Denvercoder9 4y 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 4y ago
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.
- 112233 4y ago
  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?