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>] [day] [month] [year] [list]
Date:   Fri, 19 Nov 2021 22:16:38 +0000
From:   Martin Kelly <martin.kelly@...wdstrike.com>
To:     "toke@...hat.com" <toke@...hat.com>,
        "andrii.nakryiko@...il.com" <andrii.nakryiko@...il.com>
CC:     "daniel@...earbox.net" <daniel@...earbox.net>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "kernel-team@...com" <kernel-team@...com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "andrii@...nel.org" <andrii@...nel.org>
Subject: RE: RE: Re: Re: Clarification on bpftool dual licensing

> From: Toke Høiland-Jørgensen <toke@...hat.com>
> Sent: Friday, November 19, 2021 4:54 AM
> To: Martin Kelly <martin.kelly@...wdstrike.com>; andrii.nakryiko@...il.com
> Cc: daniel@...earbox.net; bpf@...r.kernel.org; ast@...nel.org;
> netdev@...r.kernel.org; kernel-team@...com; davem@...emloft.net;
> andrii@...nel.org
> Subject: [External] RE: Re: Re: Clarification on bpftool dual licensing
> 
> Martin Kelly <martin.kelly@...wdstrike.com> writes:
> 
> >> > One other, related question: vmlinux.h (generated by "bpftool btf dump
> file
> >> /sys/kernel/btf/vmlinux format c"), does not currently contain a license
> >> declaration. I assume this would have to be a GPL header, since vmlinux.h
> >> references many GPL'd Linux kernel structs and similar, though again I'm not
> a
> >> lawyer and therefore am not certain. Would you all agree with this? If so,
> any
> >> objection to a patch adding an SPDX line to the generated vmlinux.h?
> >>
> >> Is vmlinux DWARF data GPL'ed? I certainly hope not. So vmlinux.h
> >> shouldn't be licensed under GPL.
> >
> > I have no idea; I had assumed that a struct definition coming from a
> > GPL-licensed header would have to be GPL, but again, not a lawyer, and
> > I could totally be wrong. If not GPL though, what would the license
> > be? Is it just "output of a program" and therefore license-less, even
> > though the output happens to be code?
> 
> Totally not a lawyer either, but:
> 
> There's (generally, in many jurisdictions, etc), a minimum bar for when
> something is considered a "creative work" and thus copyrightable. Debug
> output *could* fall short of this (and thus not be copyrightable at
> all). It could also fall under the same "API" umbrella as that famous
> Google v Oracle case. Or it could fall under the "syscall exception" of
> the kernel source.
> 
> I guess it would take a court decision to know either way. IMO it would
> make sense if vmlinux.h is not copyrightable for whatever reason, but,
> again, IANAL :)
> 
> Anyway, while we obviously can't resolve legal matters on the mailing,
> we can express the *intention* of the community, which is what the
> licensing document is trying to do. So it totally makes sense to mention
> vmlinux.h here; the question is what should such a text say?
> 

Yep, I completely agree with your assessment; trying to decide this definitively is probably hard even for lawyers, considering the number of contributors involved, and various differences in copyright law around the world, so I'm hoping we can at least agree on intention.

Based on what I've heard so far, it sounds like:
- There is good consensus that that the generated skeleton file is dual-licensed BSD/GPL regardless of the licensing status of the embedded eBPF code; in other words, the eBPF code has no bearing on the license of the skeleton header itself.

- Toke, it sounds like you believe vmlinux.h should be "license-less" such that someone generating it could relicense it as anything they want. This seems reasonable to me, but I welcome others' thoughts as well.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ