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:
 <CWLP265MB64494218BFFF89EFB445543EC9E7A@CWLP265MB6449.GBRP265.PROD.OUTLOOK.COM>
Date: Tue, 29 Aug 2023 15:17:08 +0000
From: "Maglione, Gregorio" <Gregorio.Maglione@...y.ac.uk>
To: Stephen Hemminger <stephen@...workplumber.org>
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

> 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.

For the purpose of upstreaming, the repository was forked [https://github.com/GREGORIO-M/mp-dccp] to remove non-GPL components and to update the license to show GPL-2.0. Is this enough to solve the license issue? If so, is it still agreeable for us to upstream and maintain MP-DCCP, so that, once DCCP deprecates, MP-DCCP becomes the sole DCCP enabler in the kernel? What steps would the upstreaming involve? Do you require any information about the MP?

From: Stephen Hemminger <stephen@...workplumber.org>
Sent: 18 August 2023 17:20
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 

CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and believe the content to be safe.

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.