netdev - Re: DCCP Deprecation

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230818092027.1542c503@hermes.local>
Date: Fri, 18 Aug 2023 09:20:27 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: "Maglione, Gregorio" <Gregorio.Maglione@...y.ac.uk>
Cc: Paolo Abeni <pabeni@...hat.com>, Kuniyuki Iwashima <kuniyu@...zon.com>,
 Jakub Kicinski <kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Florian Westphal <fw@...len.de>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Rakocevic, Veselin"
 <Veselin.Rakocevic.1@...y.ac.uk>, "Markus.Amend@...ekom.de"
 <Markus.Amend@...ekom.de>, "nathalie.romo-moreno@...ekom.de"
 <nathalie.romo-moreno@...ekom.de>
Subject: Re: DCCP Deprecation

On Fri, 18 Aug 2023 09:35:02 +0000
"Maglione, Gregorio" <Gregorio.Maglione@...y.ac.uk> wrote:

> > > The protocol works at the kernel level, and has a GPL scheduler and reordering which are the default algorithms. The GitHub implementation includes some non-GPL schedulers and reordering algorithms used for testing, which can be removed if upstreaming.  
> >IANAL
> >
> >The implementation I looked at on github was in IMHO a GPL violation because it linked GPL  
> and non GPL code into a single module. That makes it a derived work.
> >
> >If you put non-GPL scheduler into userspace, not a problem.
> >
> >If you put non-GPL scheduler into a different kernel module, according to precedent  
> set by filesystems and other drivers; then it would be allowed.  BUT you would need
> to only use exported API's not marked GPL.  And adding new EXPORT_SYMBOL() only
> used by non-GPL code would get rejected. Kernel developers are openly hostile to non-GPL
> code and would want any export symbols to be EXPORT_SYMBOL_GPL.
> 
> I see, the problem centres around the implementation rather than the protocol, as the protocol itself does not need these non-GPL components. So, would another option to the ones you've already suggested be that of creating a repository without the non-GPL components, and consider only that for purposes of upstreaming? 

Yes, the implementation needs to be aligned with the legal license requirements.
It might not be the ideal solution but any mix of GPL and non-GPL components needs
to stay with in the legal constraints.