Re: DCCP Deprecation

[Stephen Hemminger <stephen@networkplumber.org>]

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.