On Sat, Jun 28, 2014 at 8:21 AM, Greg KH [off-list ref] wrote:

On Sat, Jun 28, 2014 at 12:26:14AM -0700, Alexei Starovoitov wrote:

quoted

On Fri, Jun 27, 2014 at 11:28 PM, Andy Lutomirski [off-list ref] wrote:

quoted

On Fri, Jun 27, 2014 at 11:12 PM, Alexei Starovoitov [off-list ref] wrote:
If you want to add GPL-only functions in the future, that would be one
thing.  But if someone writes a nice eBPF compiler, and someone else
writes a little program that filters on network packets, I see no
reason to claim that the little program is a derivative work of the
kernel and therefore must be GPL.

I think we have to draw a line somewhere. Say, tomorrow I want
to modify libpcap to emit eBPF based on existing tcpdump syntax.
Would it mean that tcpdump filter strings are GPLed? Definitely not,
since they existed before and can function without new libpcap.
But if I write a new packet filtering program in C, compile it
using LLVM->eBPF and call into in-kernel helper functions
(like bpf_map_lookup_elem()),  I think it's exactly the derivative work.
It's analogous to kernel modules. If module wants to call
export_symbol_gpl() functions, it needs to be GPLed. Here all helper
functions are GPL. So we just have a blank check for eBPF program.

I agree, these eBFP programs should be GPL-compatible licensed as well.

I think I'd be happy with an export_symbol_gpl analogue.  I might
argue that bpf_map_lookup_elem shouldn't be gpl-only, though.
Something like "look up the uid that opened a port," on the other
hand, maybe should be.

--Andy