[Intel-wired-lan] [PATCH net-next 00/15] Introduce IDPF driver

[Orr, Michael]

Jason -

The Driver being published now is an Intel driver, under Intel directory, 
and using the Intel Device ID - because it is NOT the IDPF standard.  It is a Vendor driver. 

Therefore all the discussion about any IPR policy applying to the OASIS TC work 
is simply irrelevant here. 

The reason OASIS is referenced is that since this Intel driver is the basis/starting point for an Eventual OASIS IDPF 
standard,  anyone who has an interest in OASIS IDPF will have an interest in this driver even If they have no interest 
in Intel's Products. I (we) assume that there are many people in the mailing list who might be interested in at least 
keeping up with OASIS IDPF TC work, hence the OASIS references.  Anyone who is not interested in OASIS IDPF
can simply ignore this referencing. 

If you have additional questions, please reach out to me directly - I'll gladly discuss any concerns, but I think 
This should happen apart from this forum. My contact is below. 

P2P answers below 


--
Michael Orr  NCNG Strategy & Roadmap Office    WW Cell:     (669)265-5995
Note:  Dyslexic @Work. Please excuse my typos.   (Remember, Dyslexics are teople, poo)



-----Original Message-----
From: Jason Gunthorpe <jgg at nvidia.com> 
Sent: Tuesday, April 4, 2023 7:42 PM
To: Samudrala, Sridhar <sridhar.samudrala at intel.com>
Cc: Jakub Kicinski <kuba at kernel.org>; Linga, Pavan Kumar <pavan.kumar.linga at intel.com>; intel-wired-lan at lists.osuosl.org; netdev at vger.kernel.org; Saleem, Shiraz <shiraz.saleem at intel.com>; Tantilov, Emil S <emil.s.tantilov at intel.com>; willemb at google.com; decot at google.com; Hay, Joshua A <joshua.a.hay at intel.com>; Christoph Hellwig <hch at lst.de>; Orr, Michael <michael.orr at intel.com>; Singhai, Anjali <anjali.singhai at intel.com>
Subject: Re: [Intel-wired-lan] [PATCH net-next 00/15] Introduce IDPF driver

On Mon, Apr 03, 2023 at 04:36:56PM -0500, Samudrala, Sridhar wrote:

> > > Further OASIS has a legal IPR policy that basically means Intel 
> > > needs to publicly justify that their Signed-off-by is consisent with 
> > > the kernel rules of the DCO. ie that they have a legal right to 
> > > submit this IP to the kernel.
> > 
> > OASIS does NOT have such a legal IPR policy. The only IPR policy that 
> > applies to the IDPF TC members is the “Non-assert” IPR policy as 
> > stated in the Charter.

> Non-assert is relevant to inclusion in Linux and is part of what the DCO considers. According to the OASIS IPR non-assert doesn't automatically trigger just because information has been shared within a TC.

The TC charter states that *All*  TC work is under Non-Assert. Any materials/documents/code submitted to the TC do not change ownership, but they are covered by a "non-assert" license.
this applies to Everything, not just final or draft deliverables. I have not seen any OASIS statement that says what you quote above, and the TC member companies have not agreed to any such.
There is nothing needed to "trigger" non-assert and any information Shared in the TC *IS* under non-assert. When you sing up to the OASIS TC mailing list you agree to these terms. 

But more importantly: whatever OASIS's Policies/IPR are, they do not apply here. This driver upload is NOT part of the TC work, and OASIS has nothing to do with it. 



> As the submitter you need to explain that all IP and license issues are accounted for because *in general* taking work-in-progress out of a industry workgroup with an IPR is a problematic thing to include in Linux.

I frankly do not understand what the above means, and how this would make "all IP and license issues are accounted for".
 Again - the driver published by intel here is not " taking work-in-progress out of a industry workgroup".
On the contrary - this is an Intel Driver, that will be Donated INTO the OASIS TC Industry work-group. Even then, it will NOT be "THE" standard. It is just a way to speed up the TC work by having it not start from scratch. 


> eg you can say that the 0.9 document this series linked to has properly reached "OASIS Standards Draft Deliverable" and is thus covered by the IPR, 
> or you can explain that all Intel has confirmed outside OASIS that all parties that contribued to the document clear the IP release, or perhaps even that Intel is the > only IP owner.

I am not planning to say any of these. 
1. This driver has not reached "OASIS Standards Draft Deliverable" - in fact, I have no idea what this term means - it is not in the TC's milestones, and if this term 
     has any legal/IPR significance, I do not know it.
2. This driver is an Intel driver, published as such, and has nothing to do with OASIS, and any and all OASIS Policies and IPR terms do not apply. When the IDPF TC will 
     Publish an industry-standard IDPF driver - THAT driver, like all TC materials, will be under Non-Assert IPR policy - and nothing else.  


> This abnormal thing just needs to be explained, maintainer's can't be left to guess if IP issues are correct.


>  Jason