Re: DCCP Deprecation

Re: DCCP Deprecation

[Kuniyuki Iwashima]

Hi,

CC maintainers

From: "Maglione, Gregorio" <Gregorio.Maglione@city.ac.uk>
Date: Mon, 10 Jul 2023 12:06:11 +0000
> Hi Kuniyuki,
> 
> I saw the deprecation notice on the DCCP. We are working with a multipath
> extension of the protocol, and this would likely impact us in the
> standardisation effort. Do you know whom I must contact to know how I can
> volunteer to maintain the protocol, and  to get more information about
> the maintenance process?

I think it would be better to review others' patches or post patches before
stepping up as a maintainer.

However, this repo seems to have a license issue that cannot be upstreamed
as is.
https://github.com/telekom/mp-dccp


> 
> Kind Regards,
> Greg

Re: DCCP Deprecation

[Jakub Kicinski]

On Mon, 10 Jul 2023 11:22:53 -0700 Kuniyuki Iwashima wrote:
> From: "Maglione, Gregorio" <Gregorio.Maglione@city.ac.uk>
> Date: Mon, 10 Jul 2023 12:06:11 +0000
> > Hi Kuniyuki,
> > 
> > I saw the deprecation notice on the DCCP. We are working with a multipath
> > extension of the protocol, and this would likely impact us in the
> > standardisation effort. Do you know whom I must contact to know how I can
> > volunteer to maintain the protocol, and  to get more information about
> > the maintenance process?  
> 
> I think it would be better to review others' patches or post patches before
> stepping up as a maintainer.

Yes, I think we should document the expectations more clearly. I asked
on workflows@ if others already have docs.

https://lore.kernel.org/workflows/20230710115239.3f9e2c24@kernel.org/T/#u

For DCCP specifically I think we'd like to see some effort around
improving syzbot testing and addressing the bugs?

> However, this repo seems to have a license issue that cannot be upstreamed
> as is.
> https://github.com/telekom/mp-dccp

Right, in theory maintenance of the code already upstream is orthogonal
to protocol extensions. But if there is no user of the pure upstream
code then it seems hard to justify the effort of keeping it.

Re: DCCP Deprecation

[Stephen Hemminger]

On Mon, 10 Jul 2023 11:22:53 -0700
Kuniyuki Iwashima <kuniyu@amazon.com> wrote:

> I think it would be better to review others' patches or post patches before
> stepping up as a maintainer.
> 
> However, this repo seems to have a license issue that cannot be upstreamed
> as is.
> https://github.com/telekom/mp-dccp

The whole license here is a mess. IMHO it is using existing DCCP code
as base, which makes it a "derived work" under GPL rules.

Re: DCCP Deprecation

[Paolo Abeni]

Hi,

Please send plain text messages, and do proper quoting.

On Tue, 2023-07-11 at 09:31 +0000, Maglione, Gregorio wrote:
> The IETF marks MP-DCCP as EXP and is set to mark is as PS soon.
> Removing DCCP from the kernel would likely impact PS standardisation
> or better. If the reason for removal is the lack of a maintainers,
> then I have sufficient time for bug fixing and syzbot testing.

As Kuniyuki noted, a relevant record of contributions to netdev would
help/be appreciated/customary before proposing stepping-in as
maintainer of some networking components.

> If, as Jakub suggests, DCCP has no users other than MP-DCCP, and as
> such shouldn't be maintained, 

FWIW, I agree that in kernel user would help DCCP "de-deprecation"

> then are you suggesting that we investigate this license concern to
> allow for MP-DCCP to move upstream, or did you have a patch in mind?

IMHO solving the license concerns and move MP-DCCP upstream (in this
order) would be the better solution. That would allow creating the
contributions record mentioned above.

FTR MPTCP is already there, perhaps there is some possible convergence
between the 2 protocols.

Cheers,

Paolo

Re: DCCP Deprecation

[Maglione, Gregorio]

>As Kuniyuki noted, a relevant record of contributions to netdev would
>help/be appreciated/customary before proposing stepping-in as
>maintainer of some networking components.

Admittedly I have minimal netdev experience, I thought helping with an unmaintained protocol with no users would have been good experience. However, if we're looking to upstream MP-DCCP then our project would no longer require a DCCP maintainer.

>IMHO solving the license concerns and move MP-DCCP upstream (in this
>order) would be the better solution. That would allow creating the
>contributions record mentioned above.

MP-DCCP is open source under GPL-2. The scheduling and reordering algorithms are proprietary, however, they are not necessary to MP-DCCP and can be omitted. Is that enough to solve the license concern? 


From: Paolo Abeni <pabeni@redhat.com>
Sent: 11 July 2023 11:06
To: Maglione, Gregorio <Gregorio.Maglione@city.ac.uk>; Kuniyuki Iwashima <kuniyu@amazon.com>; Jakub Kicinski <kuba@kernel.org>
Cc: David S. Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Florian Westphal <fw@strlen.de>; netdev@vger.kernel.org <netdev@vger.kernel.org>; Stephen Hemminger <stephen@networkplumber.org>; Rakocevic, Veselin <Veselin.Rakocevic.1@city.ac.uk>; Markus.Amend@telekom.de <Markus.Amend@telekom.de>; nathalie.romo-moreno@telekom.de <nathalie.romo-moreno@telekom.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.


Hi,

Please send plain text messages, and do proper quoting.

On Tue, 2023-07-11 at 09:31 +0000, Maglione, Gregorio wrote:
> The IETF marks MP-DCCP as EXP and is set to mark is as PS soon.
> Removing DCCP from the kernel would likely impact PS standardisation
> or better. If the reason for removal is the lack of a maintainers,
> then I have sufficient time for bug fixing and syzbot testing.

As Kuniyuki noted, a relevant record of contributions to netdev would
help/be appreciated/customary before proposing stepping-in as
maintainer of some networking components.

> If, as Jakub suggests, DCCP has no users other than MP-DCCP, and as
> such shouldn't be maintained,

FWIW, I agree that in kernel user would help DCCP "de-deprecation"

> then are you suggesting that we investigate this license concern to
> allow for MP-DCCP to move upstream, or did you have a patch in mind?

IMHO solving the license concerns and move MP-DCCP upstream (in this
order) would be the better solution. That would allow creating the
contributions record mentioned above.

FTR MPTCP is already there, perhaps there is some possible convergence
between the 2 protocols.

Cheers,

Paolo

Re: DCCP Deprecation

[Stephen Hemminger]

On Wed, 16 Aug 2023 09:38:21 +0000
"Maglione, Gregorio" <Gregorio.Maglione@city.ac.uk> wrote:

> >As Kuniyuki noted, a relevant record of contributions to netdev would
> >help/be appreciated/customary before proposing stepping-in as
> >maintainer of some networking components.  
> 
> Admittedly I have minimal netdev experience, I thought helping with an unmaintained protocol with no users would have been good experience. However, if we're looking to upstream MP-DCCP then our project would no longer require a DCCP maintainer.
> 
> >IMHO solving the license concerns and move MP-DCCP upstream (in this
> >order) would be the better solution. That would allow creating the
> >contributions record mentioned above.  
> 
> MP-DCCP is open source under GPL-2. The scheduling and reordering algorithms are proprietary, however, they are not necessary to MP-DCCP and can be omitted. Is that enough to solve the license concern? 

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.

Re: DCCP Deprecation

[Maglione, Gregorio]

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


From: Stephen Hemminger <stephen@networkplumber.org>
Sent: 16 August 2023 16:00
To: Maglione, Gregorio <Gregorio.Maglione@city.ac.uk>
Cc: Paolo Abeni <pabeni@redhat.com>; Kuniyuki Iwashima <kuniyu@amazon.com>; Jakub Kicinski <kuba@kernel.org>; David S. Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Florian Westphal <fw@strlen.de>; netdev@vger.kernel.org <netdev@vger.kernel.org>; Rakocevic, Veselin <Veselin.Rakocevic.1@city.ac.uk>; Markus.Amend@telekom.de <Markus.Amend@telekom.de>; nathalie.romo-moreno@telekom.de <nathalie.romo-moreno@telekom.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 09:38:21 +0000
"Maglione, Gregorio" <Gregorio.Maglione@city.ac.uk> wrote:

> >As Kuniyuki noted, a relevant record of contributions to netdev would
> >help/be appreciated/customary before proposing stepping-in as
> >maintainer of some networking components.
>
> Admittedly I have minimal netdev experience, I thought helping with an unmaintained protocol with no users would have been good experience. However, if we're looking to upstream MP-DCCP then our project would no longer require a DCCP maintainer.
>
> >IMHO solving the license concerns and move MP-DCCP upstream (in this
> >order) would be the better solution. That would allow creating the
> >contributions record mentioned above.
>
> MP-DCCP is open source under GPL-2. The scheduling and reordering algorithms are proprietary, however, they are not necessary to MP-DCCP and can be omitted. Is that enough to solve the license concern?

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.

Re: DCCP Deprecation

[Stephen Hemminger]

On Wed, 16 Aug 2023 15:26:07 +0000
"Maglione, Gregorio" <Gregorio.Maglione@city.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.

Re: DCCP Deprecation

[Maglione, Gregorio]

> > > 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@networkplumber.org>
Sent: 16 August 2023 18:15
To: Maglione, Gregorio <Gregorio.Maglione@city.ac.uk>
Cc: Paolo Abeni <pabeni@redhat.com>; Kuniyuki Iwashima <kuniyu@amazon.com>; Jakub Kicinski <kuba@kernel.org>; David S. Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Florian Westphal <fw@strlen.de>; netdev@vger.kernel.org <netdev@vger.kernel.org>; Rakocevic, Veselin <Veselin.Rakocevic.1@city.ac.uk>; Markus.Amend@telekom.de <Markus.Amend@telekom.de>; nathalie.romo-moreno@telekom.de <nathalie.romo-moreno@telekom.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@city.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.

Re: DCCP Deprecation

[Stephen Hemminger]

On Fri, 18 Aug 2023 09:35:02 +0000
"Maglione, Gregorio" <Gregorio.Maglione@city.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.

Re: DCCP Deprecation

[Maglione, Gregorio]

> 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@networkplumber.org>
Sent: 18 August 2023 17:20
To: Maglione, Gregorio <Gregorio.Maglione@city.ac.uk>
Cc: Paolo Abeni <pabeni@redhat.com>; Kuniyuki Iwashima <kuniyu@amazon.com>; Jakub Kicinski <kuba@kernel.org>; David S. Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Florian Westphal <fw@strlen.de>; netdev@vger.kernel.org <netdev@vger.kernel.org>; Rakocevic, Veselin <Veselin.Rakocevic.1@city.ac.uk>; Markus.Amend@telekom.de <Markus.Amend@telekom.de>; nathalie.romo-moreno@telekom.de <nathalie.romo-moreno@telekom.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@city.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.

Re: DCCP Deprecation

[Jakub Kicinski]

On Tue, 29 Aug 2023 15:17:08 +0000 Maglione, Gregorio wrote:
> 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?

Who is going to use it? Your earlier responses gave me the impression
that you just need a number of implementations for the standardization
process - apologies if I'm mistaken - but we suffered thru maintaining
the unused DCCP code for years, we need real users who will care.

Please use a sane email client you're responses are very hard to parse.