On Mon, Apr 15, 2024 at 4:07 PM Martin Kelly <martin.kelly@xxxxxxxxxxxxxxx> wrote: > > Add an explicit statement clarifying that generated BPF code bundled > inside a libbpf skeleton header may have a license distinct from the > skeleton header (in other words, the bundled code does not alter the > skeleton header license). This is a follow-up from a previous thread > discussing licensing terms: > https://lore.kernel.org/bpf/54d3cb9669644995b6ae787b4d532b73@xxxxxxxxxxxxxxx/#r > > Signed-off-by: Martin Kelly <martin.kelly@xxxxxxxxxxxxxxx> > --- > Documentation/bpf/bpf_licensing.rst | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/Documentation/bpf/bpf_licensing.rst b/Documentation/bpf/bpf_licensing.rst > index b19c433f41d2..05bc1b845e64 100644 > --- a/Documentation/bpf/bpf_licensing.rst > +++ b/Documentation/bpf/bpf_licensing.rst > @@ -89,4 +89,8 @@ 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. > +separate executable processes. In particular, BPF code bundled inside a libbpf > +skeleton header may have a different license than that of its surrounding > +skeleton. In other words, the license of the bundled BPF code does not alter the > +license of the skeleton header nor of a program including the header. This > +paragraph applies to both cBPF and eBPF programs. The doc is clear enough. This is unnecessary. Otherwise we'll start listing every project that bundles bpf prog in some form.
