Message-ID: <9E2B3905-08AF-4C18-BE1B-3F55B917276B@oracle.com>
Date:   Mon, 6 Mar 2023 19:34:31 +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:45 PM, Jakub Kicinski <kuba@...nel.org> wrote:
> 
> On Sat, 4 Mar 2023 20:19:06 +0000 Chuck Lever III wrote:
>>>> 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.
> 
> Understood.
> 
>> 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).
> 
> Fair point. I'll relicense, they are all written by me.
> The two other people who touched them should be easy to
> get hold of.
> 
>> 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.
> 
> Yes, I'll clean the existing specs up. The only outstanding
> question AFAICT is whether we really need the GPL or you can 
> get an exception for yourself and use BSD?

I'm told that without even getting an exception, I am permitted
to contribute the handshake spec as GPL-2.0 OR BSD-2-Clause.

I don't yet have a resolution on whether the code generated
by ynl-gen-c.py is considered a derivative work.


> I care more about the downstream users than kernel devs on this,
> I'd really prefer for the users not to have to worry about 
> licensing. There may be a codegen for some funky new language 
> which requires a specific license which may not be compatible
> with GPL.
> 
> For normal C this is covered by the "uAPI note" but I doubt
> that will cover generated code. And frankly would prefer not 
> to have to ask :( So let's try BSD?
> 
> FWIW I always thought that companies which have an explicit
> "can contribute to the kernel in GPL" policy do it because
> one needs an exception _for_GPL_, not for the kernel.
> Logically the answer to BSD-3-Clause to be "oh, yea, we 
> don't care"... I said "logically", you can make the obvious
> joke yourself :)

So I'm wondering why not dual-license all the specs? That is
the usual way to provide a permissive license that can be
used outside of Linux environments. The output files might
then carry a dual license as well.


--
Chuck Lever

Powered by blists - more mailing lists