RE: RE: Re: Re: Clarification on bpftool dual licensing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>
> Sent: Friday, November 19, 2021 4:54 AM
> To: Martin Kelly <martin.kelly@xxxxxxxxxxxxxxx>; andrii.nakryiko@xxxxxxxxx
> Cc: daniel@xxxxxxxxxxxxx; bpf@xxxxxxxxxxxxxxx; ast@xxxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx; kernel-team@xxxxxx; davem@xxxxxxxxxxxxx;
> andrii@xxxxxxxxxx
> Subject: [External] RE: Re: Re: Clarification on bpftool dual licensing
> 
> Martin Kelly <martin.kelly@xxxxxxxxxxxxxxx> 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.




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux