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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID:
 <CWLP265MB6449B1A1718B6D8CD3EBFB27C91BA@CWLP265MB6449.GBRP265.PROD.OUTLOOK.COM>
Date: Fri, 18 Aug 2023 09:35:02 +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

> > > Is the scheduling in the kernel? If so yes, it will cause a MP-DCCP not to be accepted.
> > > If it is all done in userspace, then it leaves option for someone to reinvent their own open source version.
> >
> > 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? 

From: Stephen Hemminger <stephen@...workplumber.org>
Sent: 16 August 2023 18:15
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 Wed, 16 Aug 2023 15:26:07 +0000
"Maglione, Gregorio" <Gregorio.Maglione@...y.ac.uk> wrote:

> > Is the scheduling in the kernel? If so yes, it will cause a MP-DCCP not to be accepted.
> > If it is all done in userspace, then it leaves option for someone to reinvent their own open source version.
>
> 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.