All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Martin Kelly <martin.kelly@crowdstrike.com>,
	"andrii.nakryiko@gmail.com" <andrii.nakryiko@gmail.com>
Cc: "daniel@iogearbox.net" <daniel@iogearbox.net>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"ast@kernel.org" <ast@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"kernel-team@fb.com" <kernel-team@fb.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"andrii@kernel.org" <andrii@kernel.org>
Subject: RE: Re: Re: Clarification on bpftool dual licensing
Date: Fri, 19 Nov 2021 13:54:19 +0100	[thread overview]
Message-ID: <87czmwe26c.fsf@toke.dk> (raw)
In-Reply-To: <cb8074f8c8554ca480d6bb57f79535fc@crowdstrike.com>

Martin Kelly <martin.kelly@crowdstrike.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?

-Toke


      reply	other threads:[~2021-11-19 12:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-18 16:37 Re: Re: Clarification on bpftool dual licensing Martin Kelly
2021-11-19 12:54 ` Toke Høiland-Jørgensen [this message]

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=87czmwe26c.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=andrii.nakryiko@gmail.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=martin.kelly@crowdstrike.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.