Clarification on bpftool dual licensing

Clarification on bpftool dual licensing

[Martin Kelly]

Hi,

I have a question regarding the dual licensing provision of bpftool. I 
understand that bpftool can be distributed as either GPL 2.0 or BSD 2-clause. 
That said, bpftool can also auto-generate BPF code that gets specified inline 
in the skeleton header file, and it's possible that the BPF code generated is 
GPL. What I'm wondering is what happens if bpftool generates GPL-licensed BPF 
code inside the skeleton header, so that you get a header like this:

something.skel.h:
/* this file is BSD 2-clause, by nature of dual licensing */

/* THIS FILE IS AUTOGENERATED! */

/* standard skeleton definitions */

...

s->data_sz = XXX;
s->data = (void *)"\
<eBPF bytecode, produced by GPL 2.0 sources, specified in binary>
";

My guess is that, based on the choice to dual-license bpftool, the header is 
meant to still be BSD 2-clause, and the s->data inline code's GPL license is 
not meant to change the licensing of the header itself, but I wanted to 
double-check, especially as I am not a lawyer. If this is indeed the intent, 
is there any opposition to a patch clarifying this more explicitly in 
Documentation/bpf/bpf_licensing.rst?

Thanks,
Martin

Re: Clarification on bpftool dual licensing

[Daniel Borkmann]

On 11/15/21 7:20 PM, Martin Kelly wrote:
> Hi,
> 
> I have a question regarding the dual licensing provision of bpftool. I
> understand that bpftool can be distributed as either GPL 2.0 or BSD 2-clause.
> That said, bpftool can also auto-generate BPF code that gets specified inline
> in the skeleton header file, and it's possible that the BPF code generated is
> GPL. What I'm wondering is what happens if bpftool generates GPL-licensed BPF
> code inside the skeleton header, so that you get a header like this:
> 
> something.skel.h:
> /* this file is BSD 2-clause, by nature of dual licensing */

Fwiw, the generated header contains an SPDX identifier:

  /* SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) */
  /* THIS FILE IS AUTOGENERATED! */

> /* THIS FILE IS AUTOGENERATED! */
> 
> /* standard skeleton definitions */
> 
> ...
> 
> s->data_sz = XXX;
> s->data = (void *)"\
> <eBPF bytecode, produced by GPL 2.0 sources, specified in binary>
> ";
> 
> My guess is that, based on the choice to dual-license bpftool, the header is
> meant to still be BSD 2-clause, and the s->data inline code's GPL license is
> not meant to change the licensing of the header itself, but I wanted to
> double-check, especially as I am not a lawyer. If this is indeed the intent,
> is there any opposition to a patch clarifying this more explicitly in
> Documentation/bpf/bpf_licensing.rst?

Not a lawyer either, but my interpretation is that this point related to "packaging"
of BPF programs from the bpf_licensing.rst would apply here (given this is what it
does after all):

   Packaging BPF programs with user space applications
   ===================================================

   Generally, proprietary-licensed applications and GPL licensed BPF programs
   written for the Linux kernel in the same package can co-exist because they are
   separate executable processes. This applies to both cBPF and eBPF programs.

Re: Clarification on bpftool dual licensing

[Andrii Nakryiko]

On Tue, Nov 16, 2021 at 2:16 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 11/15/21 7:20 PM, Martin Kelly wrote:
> > Hi,
> >
> > I have a question regarding the dual licensing provision of bpftool. I
> > understand that bpftool can be distributed as either GPL 2.0 or BSD 2-clause.
> > That said, bpftool can also auto-generate BPF code that gets specified inline
> > in the skeleton header file, and it's possible that the BPF code generated is
> > GPL. What I'm wondering is what happens if bpftool generates GPL-licensed BPF
> > code inside the skeleton header, so that you get a header like this:
> >
> > something.skel.h:
> > /* this file is BSD 2-clause, by nature of dual licensing */
>
> Fwiw, the generated header contains an SPDX identifier:
>
>   /* SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) */
>   /* THIS FILE IS AUTOGENERATED! */
>
> > /* THIS FILE IS AUTOGENERATED! */
> >
> > /* standard skeleton definitions */
> >
> > ...
> >
> > s->data_sz = XXX;
> > s->data = (void *)"\
> > <eBPF bytecode, produced by GPL 2.0 sources, specified in binary>
> > ";
> >
> > My guess is that, based on the choice to dual-license bpftool, the header is
> > meant to still be BSD 2-clause, and the s->data inline code's GPL license is
> > not meant to change the licensing of the header itself, but I wanted to

Yes, definitely that is the intent (but not a lawyer either).


> > double-check, especially as I am not a lawyer. If this is indeed the intent,
> > is there any opposition to a patch clarifying this more explicitly in
> > Documentation/bpf/bpf_licensing.rst?
>
> Not a lawyer either, but my interpretation is that this point related to "packaging"
> of BPF programs from the bpf_licensing.rst would apply here (given this is what it
> does after all):
>
>    Packaging BPF programs with user space applications
>    ===================================================
>
>    Generally, proprietary-licensed applications and GPL licensed BPF programs
>    written for the Linux kernel in the same package can co-exist because they are
>    separate executable processes. This applies to both cBPF and eBPF programs.

Yep. If someone packages proprietary BPF ELF into a skeleton, that
doesn't make the BPF ELF suddenly GPL or BSD, I'd imagine.