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

From: Jason Gunthorpe <jgg@nvidia.com>
To: "Orr, Michael" <michael.orr@intel.com>
Cc: "willemb@google.com" <willemb@google.com>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	"decot@google.com" <decot@google.com>,
	"Saleem, Shiraz" <shiraz.saleem@intel.com>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [Intel-wired-lan] [PATCH net-next 00/15] Introduce IDPF driver
Date: Tue, 4 Apr 2023 20:35:40 -0300	[thread overview]
Message-ID: <ZCy0TF7tbgYXZcyy@nvidia.com> (raw)
In-Reply-To: <DM8PR11MB5733892D5D21375332EC6855E9939@DM8PR11MB5733.namprd11.prod.outlook.com>

On Tue, Apr 04, 2023 at 07:19:54PM +0000, Orr, Michael wrote:
> 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.

This series literally said in patch 1 that it is implementing
"virtchnl version 2" and links directly to unapproved OASIS documents
as "the specification for reference".

What you are saying may be the case, but it does not match what was
submitted for review.

Send a v2 with the references to OASIS scrubbed out of the series, and
explain what you explained here in the cover letter - that this Intel
IDPF is not derived from the other OASIS IDPF.

Then you are fine.

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

It is a defined term in the OASIS IPR you linked to:

19. OASIS Standards Draft Deliverable - an OASIS Deliverable
 that has been designated and approved by a Technical Committee as an
 OASIS Standards Draft Deliverable and which is enumerated in and
 developed in accordance with the OASIS Technical Committee Process.

IPR Section 6:

 ... a limited covenant not to assert any Essential Claims required to
     implement such OASIS Standards Draft Deliverable ...

IPR Section 10.3 describes how the "non-assertion mode TC" works, and
that the non-assertion covenant comes into full effect for a "OASIS
Standards Final Deliverable" [defined term #20].

The OASIS document "TC Process" explains what steps a TC must do to
achieve these milestones defined in the IPR.

Achieving the milestones defined in the IPR unambiguously triggers the
non-assertion convents and then we know the IP is safe to incorporate
into Linux.

As I've said a few times now, Linux requires submissions to be
properly licensed and have IP rights compatible with the GPL.

IPR is complicated, the knee jerk reaction should be to reject any
patches implementing in-progress works from standards bodies.

Jason
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan