| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Earl, dear all, I agree with Earl’s bottom line: “how IEEE wants to deal with OSS”. To that point, I note that IEEE has a RAND-based patent policy, not RF or RE. Therefore, introducing CLAs that require RF commitments with no opt-out seems to clash with
that policy, or could be viewed as an attempt to circumvent it. As some commentators (including myself) have already pointed out, in order to use and publish OSS, IEEE only needs the copyright, for example through a copyright-only license or an assignment. Best regards, -Matteo From: Nied, Earl <earl.nied@xxxxxxxxx> Guys – I believe this distills down to whether IEEE should have an issue with Open Source projects. Unfortunately the references to ANSI in these threads entail ANSI responses to unique situations. ANSI does not have a prohibition on
Open Source. My personal experience in the API days (I chaired the ANSI IPRPC at that time) was that people were concern that FOR AMERICAN NATIONAL STANDARDS the ANSI Essential Requirements try to establish that licenses for SEPs are available for negotiation
under FRAND or RE-RAND terms (or waived). The ERs want to highlight the potential for a SEP that would not be licensed. If such
SEP truly exists, it should not be used in the standard and if the standard is already published steps need to be taken. This all revolves around trying to avoid a blocked ANS. ANSI has no control over (and does not care about) SDOs that diverge from the ANSI ERs for non-ANS standards. So, ANSI has no position on stand alone Open Source projects. API does have a royalty free requirement and ANSI’s interest was
to assure that API ANSs still followed the rules regarding truly blocking SEPs. Having a RE-RAND commitment still falls under the ANSI ERs. A SDO having only RF-RAND rules that receives a RAND notice must deal with that under its own rules (in my mind it
still meets the ANS requirements just not the SDO rules). If someone has a truly blocking patent that they refuse to license (will not do RAND, RF-RAND or waiver per the ERs), that becomes a problem. Per my personal logic that means that SDOs that deal only with contributions (as you might
find in software created in an Apache OSS project – which software may or may not be part of a standard) could still be fine so long as there are no
truly standards blocking patents. Note there is a lot of complexity and subtility here and any SDO not dealing with an ANS is still free to do anything they want. Also, note that I keep emphasizing
truly because SDOs must be able to deal with false claims attempting to disrupt their work. So, my bottom line is that the real question at IEEE is how IEEE wants to deal with Open Source. ANSI rules should be discuss at ANSI. From: Kolakowski, John (Nokia - US) <john.kolakowski@xxxxxxxxx>
Gil, I’m not personally particularly familiar with the recent accreditation challenges and I’m not the person to mount a full-throated argument for or against that ANSI decision – I was just noting that your specific point made about API
didn’t seem correct. That’s because I understand a point of distinction being raised here (as compared to, for example, API) is that one has to agree in the present situation to RF licensing terms before even participating in the standards development process,
and that doesn’t seem to be the case with API. And of course the debate is whether that complies with ANSI Essential Requirements of, for example, openness and balance for due process. As to the “Understanding ANSI’s Patent Policy” document, given it’s a document that’s not officially set forth by or approved by ANSI, I question how much stock we should put into it for present purposes. While it is written by ANSI’s
GC (as some here may not realize), it is also true that the very first footnote after the very first sentence of that document emphasizes that the document “represents the views of the author. It does not purport to represent the position of any particular
committee, group or member of ANSI.” --John From: Gil Ohana (gilohana) <gilohana@xxxxxxxxx>
Thanks John. Can you point to anything in the “Understanding ANSI’s Patent Policy” document that conditions ANSI’s willingness to accredit a standards developer that adopts a mandatory royalty-free patent policy on the ability of a patentee
to participate in standards development but subsequently refuse to license essential patent claims? Can you point me to any support for the position that if a standards development organization had an RF policy that permitted it to finalize a standard despite
a participant reneging on its commitment to grant royalty-free licenses that such a policy would cause ANSI to refuse to accredit the SDO?
There are other ANSI-accredited SDOs (OASIS Open is one) that permit technical committees to choose RF licensing (the options are described in Section 4 of the OASIS Open IPR Policy). I do not see any text in the policy that would cause
OASIS Open to withdraw a standard if a patentee breached the commitment it made to license on RF terms if that was the licensing option that the relevant OASIS Open Technical Committee selected, yet OASIS Open is accredited by ANSI. Best regards, Gil From: Kolakowski, John (Nokia - US) <john.kolakowski@xxxxxxxxx>
Gil, If API is, as you wrote, (a) in a “situation[] in which the creation of standards the implementation of which would necessarily infringe patents will be unavoidable,” and (b) API then “require[s] a royalty-free patent license or a release,”
what happens if API doesn’t receive the RF license or release from the patent holder? Presumably from the language of the patent policy, API then wouldn’t include the patented tech in the standard, right? Doesn’t that effectively provide an opt-out for the patent holder as Michael argued? What are we missing?
The sentence you highlighted in yellow notes that “any patent holder may participate in API standards activities,” so it doesn’t appear that anyone is frozen out up front. --John From: Gil Ohana (gilohana) <00000b67ee67ba19-dmarc-request@xxxxxxxx>
Thanks Michael. I think you are reading the text selectively, because reading it otherwise undercuts your argument. Let’s look at the text: 6.4.2 Patents It is API’s intent to fully comply with the 2019 edition of the ANSI
Essential Requirements: Due Process Requirements for American National Standards
and sets forth the following additional policy statements that are also compliant with the 2019 edition. As a general rule, API standards are developed using performance-based language.
In accordance with 5.2,
Due Process,
any patent holder may participate in API standards activities, but patents which would be required for compliance with that standard should not be included in API standards. These types of patents may, in exceptional circumstances, be included in API standards provided that: (i) there are significant technical reasons why the standard cannot be drafted without the use of terms covered by patent rights, and (ii) where the patent holder,
and any successors or assigns, are bound by an agreement in written or electronic form to a letter of assurance approved by the API Office of General Counsel granting either: a) a royalty free license under reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to utilize the license for the purpose of implementing the standard, or b) a release to API and all users of the document from any claims of patent infringement based on the publication or use of the standard. In the sentence highlighted in yellow API is announcing a preference that API standards not require the implementer to license patents. In the next sentence (see text highlighted in blue), API recognizes that may not always be possible,
and that there may be situations in which the creation of standards the implementation of which would necessarily infringe patents will be unavoidable. In those situations, API will require a royalty-free patent license or a release. BTW, my recollection is that there was a discussion of the API IPR policy in the ANSI Patent Committee (as it was known then) in which Qualcomm representatives participated. The concerns they expressed at the time (along with other companies
with business models based on SEP licensing) suggested that they read the API patent policy to require royalty-free licensing. Best regards, Gil From: Michael Atlass <matlass@xxxxxxxxxxxx>
In case anyone has the wrong impression, the American Petroleum Institute (API) paragraph cited in Gil’s email excludes the possibility of the API issuing a standard if someone doesn’t license or promise not to exercise (release) their
exclusive patent rights. As commonly defined, that is an opt-out. Thus, the conclusion that API does not permit someone opt-out from licensing their patents for free (or see
highlighted text in email below) is factually the opposite from being correct.
Here’s the text again. “…,
any patent holder may participate in API standards activities, but patents which would be required for compliance with that standard
should not be included in API standards.” – Then the language goes on to say (what Gil highlighted) that if patents are included they must (if and only then) be licensed royalty free or released (free).
I have seen this language misinterpreted this way before, and I hope that API can clarify its language so it doesn’t continue to happen, but I don’t participate in that
organization. To recap, if an API member identifies a SEP that covers a standard, by virtue of notice to API and refusal to promise a royalty free license or accept a release obligation, this API paragraph says that it will not issue the standard. API
could find that patent is somehow determined to be non-essential, or the standard written to exclude claim coverage by that patent. That seems like a pretty convincing opt-out.
From:
Gil Ohana (gilohana) <00000b67ee67ba19-dmarc-request@xxxxxxxx> CAUTION: This email originated from outside of
the organization. Though further comment may not be necessary given the result of the ProCom meeting, I would also note that a number of ANSI accredited standards development organizations have patent policies that
provide for mandatory royalty-free licensing without the possibility of opt-out. The example I am most familiar with is the American Petroleum Institute, a leading trade association and developer
of standards in the US oil and gas industry. The API patent policy is in Section 6.4.2 of the attached document, available on API’s website. For convenience, I am pasting the text of Section 6.4.2 below, with the operative text describing what the licensing
commitment API requires highlighted: 6.4.2 Patents It is API’s intent to fully comply with the 2019 edition of the ANSI
Essential Requirements: Due Process Requirements for American National Standards
and sets forth the following additional policy statements that are also compliant with the 2019 edition. As a general rule, API standards are developed using performance-based language. In accordance with 5.2,
Due Process,
any patent holder may participate in API standards activities, but patents which would be required for compliance with that standard should not be included in API standards. These types of patents may, in exceptional circumstances, be included in API standards provided that: (i) there are significant technical reasons why the standard cannot be drafted without the use of terms covered by patent rights, and (ii) where the patent holder, and any successors or assigns, are bound by an agreement in written or electronic form to a letter of assurance approved by the API Office of General Counsel granting either: a) a royalty free license under reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to utilize the license for the purpose of implementing the standard,
or b) a release to API and all users of the document from any claims of patent infringement based on the publication or use of the standard. My dim recollection is that when API adopted this policy around a decade ago, some of the same companies that have (repeatedly) tried to cause ANSI to dis-accredit IEEE-SA sought to challenge ANSI’s re-accreditation of the American Petroleum
Institute. I will try to find additional information about the API reaccreditation dispute and provide it as soon as possible. Thankfully, the companies that sought to cause ANSI to dis-accredit API were no more successful in that effort than they have been
in their (repeated) efforts to dis-accredit the IEEE Standards Association. Best regards, Gil Ohana From: Gil Ohana (gilohana) <00000b67ee67ba19-dmarc-request@xxxxxxxx>
Dear Stephanie, Thank you for your intervention. It’s unfortunate that you shared your extensive comment 45 minutes before the start of the ProCom call, but perhaps you were hoping to avoid a substantive response. Given the time available, I can do no
more than attach ANSI’s 2016 decision rejecting the appeal submitted by Qualcomm, Ericsson, and Alcatel-Lucent challenging ANSI’s decision to reaccredit IEEE-SA following the 2015 adoption of updates to the IEEE-SA Patent Policy. ANSI’s decision disposes
conclusively of a number of the arguments you made in the intervention you submitted shortly before the call. I am also attaching an ANSI publication from last year entitled “Understanding ANSI’s Patent Policy – A Primer”. The text on page 11, copied below, addresses the question of whether royalty-free policies are consistent with the ANSI Essential
Requirements: C. Requirements Relating to Royalty-Free Licenses
An ASD may also customize its patent policy to require only compensation-free types of licensing commitments for essential patent claims, as described in Section 3.1.1(b)(ii) of the Patent Policy.10
As with other terms, such policies also might
contain a mechanism allowing a patent holder to decline to license essential patent claims on compensation-free terms (such as an opt-out provision). (italicization provided by me) As standards professionals well know, “might” is permissive. Had ANSI meant to prohibit the use of royalty-free patent policies without provisions permitting a patentee from refusing to license, ANSI would have used “shall” or “must”,
not “might”. I look forward to the discussion during the ProCom call today. Best regards, Gil Ohana From: Mielert, Stefanie <stefanie.mielert@xxxxxxxxxxxxxxxxx>
Dear David, Dear All, Fraunhofer has reviewed the material provided for Item 6.3 of the 5 August 2021 ProCom meeting, along with some of the material submitted as part of IEEE’s 2021 Reaccreditation application to ANSI. Fraunhofer observes that:
On the RAND aspect in the US context, when an ANSI-accredited standards developer (ASD) provides for compensation free-type of licensing commitments for essential patent claims, there must
also be a reasonable mechanism to allow patent holders to decline to license identified essential patents or essential patent claims on compensation-free terms. Section II of the ANSI Guidelines for Implementation of the ANSI Patent Policy states: An ASD’s Patent Policy may provide for compensation-free types of licensing commitments for essential patent claims, as described in Section 3.1.1 (b)(ii) of the ANSI Essential Requirements,
to the exclusion of other types of commitments. However, such a policy must also contain a reasonable mechanism which would allow a patent holder to decline to license identified essential patents or essential patent claims on compensation-free terms (such
as an opt-out provision). Such a policy must also comply with Section 1.1 of the Essential Requirements, which requires that participation be open to all persons who are directly and materially affected by the standards activity in question, including directly
and materially-affected patent holders who decline to license essential patents or essential patent claims under compensation-free terms. IEEE’s proposals have not allowed for this opt-out. The proposed CLA document and its use rather appear to undermine or call into question the possibility of RAND licensing. This is because participation in any IEEE standards development
activity which involves open source software mandates the use of a CLA, which in turn mandates compensation-free licensing for both copyright (software) and patents. Such a structure does not appear to align well with the voluntary, irrevocable undertakings
provided (or which may in the future be provided) by contributors to IEEE standards. The aim should be to develop clear and transparent processes, which are relevant to both the development of standards in IEEE and the implementation of IEEE standards in the
market. · On the TBT aspects, the IEEE has publicly stated its commitment to the
WTO TBT Principles: http://globalpolicy.ieee.org/wp-content/uploads/2020/08/IEEE20013.pdf Looking at the US SDO context, Section 1.1 of the ANSI Essential Requirements states participation in an ANS shall be open to all parties who are directly and materially interested in
the activity in question and there shall be no undue financial barriers to participation. The present requirement proposed for the IEEE SA Standards Board Operations Manual (this being subject to ANSI’s reaccreditation) is that a participant in an open source activity must sign
a CLA, and that CLA shall impose a royalty-free patent license. RAND is recognized at policy and law to cater for both (i) the legitimate compensation for contributions to standards development, with it being open to decide whether to allow access on
compensation-free terms and conditions; and (ii) incentives to contribute to sustainable innovation.
It is also recognized as a basic tenet of IP that patents are a different IP asset to copyright (software), and there is no need to tie the license of one to the other. Indeed, all sophisticated
technologies will comprise of many different forms of IP. For cutting-edge, globally-competitive technology developed through SDOs, the development of such technology is achieved by open and broad participation by all different types of contributors. IEEE´s 2021 ANSI reaccreditation application remains in progress. A complete record or summary of the public comments received as part of that application process has not been provided along with the material presented
on Item 6.3 of the IEEE ProCom meeting agenda. With respect, the material which has been provided as part of Item 6.3 does not appear to address the comments submitted to ANSI for IEEE´s 2021 reaccreditation, or risks noted above. We look forward to the meeting today, and can be available to further elaborate on the above. Sincerely, Stefanie Mielert ----- Kind regards / Mit freundlichem Gruss, Stefanie Mielert Rechtsanwältin Fraunhofer Gesellschaft zur Förderung der angewandten Forschung e.V./ Fraunhofer Institut für Integrierte Schaltungen IIS Am Wolfsmantel 33 * 91058 Erlangen * http://www.fraunhofer.de Phone: +49 (0) 9131 776 6137 Mobile: +49 (0) 173 929 6369 Von:
Dave Ringle <d.ringle@xxxxxxxx> The 05 August 2021 ProCom agenda is available at https://standards.ieee.org/content/dam/ieee-standards/standards/web/governance/procom/agenda.pdf ****************************************************************** To unsubscribe from the PP-DIALOG list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=PP-DIALOG&A=1
To unsubscribe from the PP-DIALOG list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=PP-DIALOG&A=1 To unsubscribe from the PP-DIALOG list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=PP-DIALOG&A=1 To unsubscribe from the PP-DIALOG list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=PP-DIALOG&A=1 To unsubscribe from the PP-DIALOG list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=PP-DIALOG&A=1 To unsubscribe from the PP-DIALOG list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=PP-DIALOG&A=1 To unsubscribe from the PP-DIALOG list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=PP-DIALOG&A=1 To unsubscribe from the PP-DIALOG list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=PP-DIALOG&A=1 To unsubscribe from the PP-DIALOG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=PP-DIALOG&A=1 |