Message-ID: <0C0B6439-B3D0-46F3-8CD2-6AACD0DDE923@oracle.com>
Date:   Sat, 4 Mar 2023 20:19:06 +0000
From:   Chuck Lever III <chuck.lever@...cle.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Chuck Lever <cel@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        "kernel-tls-handshake@...ts.linux.dev" 
        <kernel-tls-handshake@...ts.linux.dev>,
        John Haxby <john.haxby@...cle.com>
Subject: Re: [PATCH v6 1/2] net/handshake: Create a NETLINK service for
 handling handshake requests



> On Mar 4, 2023, at 3:01 PM, Jakub Kicinski <kuba@...nel.org> wrote:
> 
> On Sat, 4 Mar 2023 19:48:51 +0000 Chuck Lever III wrote:
>>>>> 2. The SPDX tags in the generated source files is "BSD
>>>>> 3-clause", but the tag in my spec is "GPL-2.0 with
>>>>> syscall note". Oddly, the generated uapi header still
>>>>> has the latter (correct) tag.  
>>> 
>>> I was trying to go with least restrictive licenses for the generated
>>> code. Would BSD-3-clause everywhere be okay with you?  
>> 
>> IIUC we cannot generate source code from a GPL-encumbered
>> specification and label that code with a less-restrictive
>> license. Isn't generated source code a "derived" artifact?
>> 
>> The spec lives in the kernel tree, therefore it's covered.
>> Plus, my employer requires that all of my contributions
>> to the Linux kernel are under GPL v2.
>> 
>> I'd prefer to see all my generated files get a license
>> that matches the spec's license.
>> 
>> You could add an spdx object in the YAML schema, and output
>> the value of that object as part of code generation.
>> 
>> To be safe, I'd also find a suitably informed lawyer who
>> can give us an opinion about how this needs to work. I've
>> had a similar discussion about the license status of a
>> spec derived from source code, so I'm skeptical that we
>> can simply replace the license when going to code from
>> spec.
>> 
>> If you need to require BSD-3-clause in this area, I can
>> request an exception from my employer for the YAML that
>> is contributed as part of the handshake mechanism.
> 
> The choice of BSD was to make the specs as easy to use as possible.
> Some companies may still be iffy about GPL, and it's all basically
> an API, not "real code".
> 
> If your lawyers agree we should require BSD an all Netlink specs,
> document that and make the uAPI also BSD.
> 
>> Sorry to make trouble -- hopefully this discussion is also
>> keeping you out of trouble too.
> 
> I was hoping choice of BSD would keep me out of trouble :)
> My second choice was to make them public domain.. but lawyers should
> like BSD-3-clause more because of the warranty statement.

The issue is that the GPL forces our hand. Derived code
is under GPL if the spec is under GPL. The 3 existing
specs in Documentation/netlink/specs are unlabeled, and
therefore I think would be subsumed under the blanket
license that other kernel source falls under.

I don't think you can simply choose a license for
the derived code. The only way to fix this so that the
generated code is under BSD-3-clause is to explicitly
re-license the specs under Documentation/netlink/specs/
as BSD-3-clause. (which is as easy as asking the authors
for permission to do that - I assume this stuff is new
enough that it won't be difficult to track them down).

Again, it would be convenient for contributors in this
area to specify the spec and code license in the YAML
spec. Anyone can contribute under BSD-3-clause or GPL,
but the code and spec licenses have to match, IMO.

I can start with the LF first to see if we actually have
a problem.


--
Chuck Lever

Powered by blists - more mailing lists