From: Martin Kelly <martin.kelly@crowdstrike.com>
To: "bpf@vger.kernel.org" <bpf@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"kernel-team@fb.com" <kernel-team@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
"David S. Miller" <davem@davemloft.net>,
Andrii Nakryiko <andrii@kernel.org>
Subject: Clarification on bpftool dual licensing
Date: Mon, 15 Nov 2021 18:20:59 +0000 [thread overview]
Message-ID: <54d3cb9669644995b6ae787b4d532b73@crowdstrike.com> (raw)
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
next reply other threads:[~2021-11-15 20:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-15 18:20 Martin Kelly [this message]
2021-11-16 10:16 ` Clarification on bpftool dual licensing Daniel Borkmann
2021-11-16 22:00 ` Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54d3cb9669644995b6ae787b4d532b73@crowdstrike.com \
--to=martin.kelly@crowdstrike.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.