From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752804AbaF1PVS (ORCPT ); Sat, 28 Jun 2014 11:21:18 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:52082 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751058AbaF1PVR (ORCPT ); Sat, 28 Jun 2014 11:21:17 -0400 Date: Sat, 28 Jun 2014 11:21:04 -0400 From: Greg KH To: Alexei Starovoitov Cc: Andy Lutomirski , "David S. Miller" , Ingo Molnar , Linus Torvalds , Steven Rostedt , Daniel Borkmann , Chema Gonzalez , Eric Dumazet , Peter Zijlstra , Arnaldo Carvalho de Melo , Jiri Olsa , Thomas Gleixner , "H. Peter Anvin" , Andrew Morton , Kees Cook , Linux API , Network Development , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH RFC net-next 07/14] bpf: expand BPF syscall with program load/unload Message-ID: <20140628152104.GB29548@kroah.com> References: <1403913966-4927-1-git-send-email-ast@plumgrid.com> <1403913966-4927-8-git-send-email-ast@plumgrid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 28, 2014 at 12:26:14AM -0700, Alexei Starovoitov wrote: > On Fri, Jun 27, 2014 at 11:28 PM, Andy Lutomirski wrote: > > On Fri, Jun 27, 2014 at 11:12 PM, Alexei Starovoitov 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. greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: [PATCH RFC net-next 07/14] bpf: expand BPF syscall with program load/unload Date: Sat, 28 Jun 2014 11:21:04 -0400 Message-ID: <20140628152104.GB29548@kroah.com> References: <1403913966-4927-1-git-send-email-ast@plumgrid.com> <1403913966-4927-8-git-send-email-ast@plumgrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andy Lutomirski , "David S. Miller" , Ingo Molnar , Linus Torvalds , Steven Rostedt , Daniel Borkmann , Chema Gonzalez , Eric Dumazet , Peter Zijlstra , Arnaldo Carvalho de Melo , Jiri Olsa , Thomas Gleixner , "H. Peter Anvin" , Andrew Morton , Kees Cook , Linux API , Network Development , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" To: Alexei Starovoitov Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org On Sat, Jun 28, 2014 at 12:26:14AM -0700, Alexei Starovoitov wrote: > On Fri, Jun 27, 2014 at 11:28 PM, Andy Lutomirski wrote: > > On Fri, Jun 27, 2014 at 11:12 PM, Alexei Starovoitov 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. greg k-h