netdev - Re: [PATCH v6 1/2] net/handshake: Create a NETLINK service for handling handshake requests

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230304124517.394695e8@kernel.org>
Date:   Sat, 4 Mar 2023 12:45:17 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Chuck Lever III <chuck.lever@...cle.com>
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 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 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 :)

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