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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 4 Apr 2023 20:35:40 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     "Orr, Michael" <michael.orr@...el.com>
Cc:     "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "Linga, Pavan Kumar" <pavan.kumar.linga@...el.com>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Saleem, Shiraz" <shiraz.saleem@...el.com>,
        "Tantilov, Emil S" <emil.s.tantilov@...el.com>,
        "willemb@...gle.com" <willemb@...gle.com>,
        "decot@...gle.com" <decot@...gle.com>,
        "Hay, Joshua A" <joshua.a.hay@...el.com>,
        Christoph Hellwig <hch@....de>,
        "Singhai, Anjali" <anjali.singhai@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH net-next 00/15] Introduce IDPF driver

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