netdev - Clarification on bpftool dual licensing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 15 Nov 2021 18:20:59 +0000
From:   Martin Kelly <martin.kelly@...wdstrike.com>
To:     "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "kernel-team@...com" <kernel-team@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        "David S. Miller" <davem@...emloft.net>,
        Andrii Nakryiko <andrii@...nel.org>
Subject: Clarification on bpftool dual licensing

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