Re: [dpdk-dev] [PATCH v3 1/8] net/dpaa: add support for fmlib in dpdk

[Thomas Monjalon <thomas@monjalon.net>]

20/07/2020 06:50, Hemant Agrawal:
> HI Thomas,
> 
> From: Thomas Monjalon <thomas@monjalon.net> 
> 17/07/2020 13:36, Ferruh Yigit:
> > On 7/11/2020 9:17 AM, Hemant Agrawal wrote:
> > > DPAA platorm MAC interface is known as FMAN i.e. Frame Manager.
> > > There are two ways to control it.
> > > 1. Statically configure the queues and classification rules before 
> > > the start of the application using FMC tool.
> > > 2. Dynamically configure it within application by making API calls 
> > > of fmlib.
> > > 
> > > The fmlib or Frame Manager library provides an API on top of the 
> > > Frame Manager driver ioctl calls, that provides a user space 
> > > application with a simple way to configure driver parameters and PCD 
> > > (parse - classify - distribute) rules.
> > > 
> > > This patch integrates the base fmlib so that various queue config, 
> > > RSS and classification related features can be supported on DPAA platform.
> > > 
> > > This base fmlib is shared across multiple project.
> > > - it is not following block comments style for doxygen and other 
> > > comments.
> > > - it usages camel case for naming.
> > > - it is not following the 80 char limits in code
> > > 
> > > Signed-off-by: Sachin Saxena <sachin.saxena@nxp.com>
> > > Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> > Series applied to dpdk-next-net/master, thanks.
> 
> >Sorry, this time I don't agree with Ferruh's decision of merging this series.
> 
> >Checkpatch is sending too many warnings.
> 
> [Hemant] The base codes, which are coming from common area was not originally meant for Linux.
> If we change the original starting code of it, the  the maintenance become very painful otherwise.
> 
> >But most importantly, the licensing has not been agreed in techboard and govboard.
> 
>  [Hemant] you are wrong here. Which license difference are you talking about? Standard licenses do not need techboard and govboard approval.
> /* SPDX-License-Identifier: (BSD-3-Clause OR GPL-2.0) is the approved license. It have been used in DPDK since long. 
> DPDK exception file states:
> Note that following licenses are not exceptions:-
> 	- BSD-3-Clause
> 	- Dual BSD-3-Clause OR GPL-2.0
> 	- Dual BSD-3-Clause OR LGPL-2.1
> 	- GPL-2.0  (*Only for kernel code*)
> Any base code which is shared among kernel and Userspace space - mostly likely will have this kind dual license only.
> Note: you don't add "Dual" word while stating SPDX string - it is implicit.

Indeed you're right it is not marked as an exception in license/exceptions.txt.
This is a discrepancy with the charter:
	https://www.dpdk.org/charter/
In section 6.i.iii:
"
A disjunctive licence choice of BSD-3-Clause OR GPL-2.0 or BSD-3-Clause OR LGPL-2.1 will be used for code that is shared between the kernel and userspace.
"
But we are not building a kernel module with this code,
as it is the case for KNI.

> > Why dropping this codebase in DPDK instead of pulling it as a dependency?
> > I don't like seeing DPDK becoming a pile of code duplicated from somewhere else.
> [Hemant] We are not using the library as it is and making some serious changes in the generic library to suit the DPDK use-case.
> So, it is not possible for us to use the *original* code of fmlib, which is public.

I don't understand.
Either you don't change the code, so you use the original one as a dependency,
or you change the code for DPDK use, so you can adapt it to DPDK.

> > I will drop this series from 20.08, waiting for a clear consensus.
> [Hemant] Why? 
> [Hemant] >Note: I don't remember having heard about such change before, especially not in the roadmap.
> [Hemant] So anyone not publishing a roadmap - you will not accept features?  

This is just a note explaining why I discover it so late.