Network Working Group Scott Bradner Internet-Draft Harvard University Intended status: BCP Obsoletes: 3979, 4879 Jorge Contreras Updates: 2026 University of Utah Expires: July 25, 2017 January 25, 2017 Intellectual Property Rights in IETF Technology draft-bradner-rfc3979bis-11.txt Abstract The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo replaces section 10 of RFC 2026 and obsoletes RFC 3979 and RFC 4879. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 20, 2014. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Bradner & Contreras [Page 1]
Internet-Draft RFC 3979 bis January 2017 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Table of Contents 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Participation in the IETF . . . . . . . . . . . . . . . . . . . . 3.1. General Policy . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Rights and Permissions in Contributions. . . . . . . . . . . . . 3.3. Obligations on Participants . . . . . . . . . . . . . . . . . . 4. Actions for Documents for which IPR Disclosure(s) Have Been Received . . . . . . . . . . . . . . . . . . . . . . . 5. IPR Disclosures . . . . . . . . . . . . . . . . . . . . . . . . . 5.1. Who Must Make an IPR Disclosure? . . . . . . . . . . . . . . . . 5.1.1. A Contributor's IPR in his or her Contribution . . . . . . . 5.1.2. An IETF Participant's IPR in Contributions by Others . . . . 5.1.3. IPR of Others . . . . . . . . . . . . . . . . . . . . . . . . 5.2. The Timing of Providing Disclosure . . . . . . . . . . . . . . . 5.2.1. Timing of Disclosure Under Section 5.1.1 . . . . . . . . . . . 5.2.2. Timing of Disclosure Under Section 5.1.2 . . . . . . . . . . . 5.3. How Must an IPR Disclosure be Made? . . . . . . . . . . . . . . 5.4. What Must be in an IPR Disclosure? . . . . . . . . . . . . . . . 5.4.2. Updating IPR Disclosures . . . . . . . . . . . . . . . . . . . 5.4.3. Blanket IPR Statements . . . . . . . . . . . . . . . . . . . . 5.5. Licensing Information in an IPR Disclosure . . . . . . . . . . . 5.6. Level of Control over IPR requiring Disclosure . . . . . . . . . 5.7. Disclosures for Oral Contributions . . . . . . . . . . . . . . . 5.8. General Disclosures . . . . . . . . . . . . . . . . . . . . . . 6. Failure to Disclose . . . . . . . . . . . . . . . . . . . . . . . 7. Evaluating Alternative Technologies in IETF Working Groups . . . . 8. Change Control for Technologies . . . . . . . . . . . . . . . . . 9. Licensing Requirements to Advance Standards Track IETF Documents . 10. No IPR Disclosures in IETF Documents . . . . . . . . . . . . . . Bradner & Contreras [Page 2]
Internet-Draft RFC 3979 bis January 2017 11. Application to non-IETF Stream Documents . . . . . . . . . . . . 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 13. Changes Since RFC 3979 and RFC 4879 . . . . . . . . . . . . . . . 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1. Normative References . . . . . . . . . . . . . . . . . . . . . 14.2. Informative References . . . . . . . . . . . . . . . . . . . . 15. Editor's Addresses . . . . . . . . . . . . . . . . . . . . . . . 16. Changes since RFC 3979 . . . . . . . . . . . . . . . . . . . . . 1. Definitions The following definitions are for terms used in the context of this document. Other terms, including "IESG," "ISOC," "IAB," and "RFC Editor," are defined in [RFC2028]. a. "Alternate Stream": the IAB Document Stream, the IRTF Document Stream and the Independent Submission Stream, each as defined in Section 5.1 of [RFC4844], along with any future non-IETF streams that might be defined. b. "Contribution": any submission to the IETF intended by the Contributor for publication as all or part of an Internet-Draft or RFC and any statement made within the context of an IETF activity, in each case that is intended to affect the IETF Standards Process or that is related to the activity of an Alternate Stream that has adopted this specification. Such statements include oral statements, as well as written and electronic communications, which are addressed to: o the IETF plenary session, o any IETF working group [see BCP 25] or portion thereof, o any IETF "birds of a feather" (BOF) session or portion thereof, o any design team [see BCP 25] or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, web site, chat room or discussion board, operated by or under the auspices of the IETF, including the IETF list itself, o the RFC Editor or the Internet-Drafts function. Statements made outside of an IETF session, mailing list or other function, or that are clearly not intended to be input to an IETF activity, group or function, are not Contributions in the context of this document. For example, the presentations made by invited speakers at IETF plenary sessions to discuss advances in Internet technology generally, or to describe their existing products or technologies, are not Contributions. Bradner & Contreras [Page 3]
Internet-Draft RFC 3979 bis January 2017 Throughout this memo, the term "written Contribution" is used. For purposes of this memo, "written" means reduced to a written or visual form in any language and any media, permanent or temporary, including but not limited to traditional documents, e-mail messages, discussion board postings, slide presentations, text messages, instant messages, and transcriptions of oral statements. c. "Contributor": an individual submitting a Contribution d. "Covers" or "Covered" mean that a valid claim of a patent or a patent application (including a provisional patent application) in any jurisdiction , or any other Intellectual Property Right, would necessarily be infringed by the exercise of a right (e.g., making, using, selling, importing, distribution, copying, etc.) with respect to an Implementing Technology. For purposes of this definition, "valid claim" means a claim of any unexpired patent or patent application which shall not have been withdrawn, cancelled or disclaimed, nor held invalid by a court of competent jurisdiction in an unappealed or unappealable decision. e. "IETF": In the context of this document, the IETF includes all individuals who participate in meetings, working groups, mailing lists, functions and other activities which are organized or initiated by ISOC, the IESG or the IAB under the general designation of the Internet Engineering Task Force or IETF, but solely to the extent of such participation. f. "IETF Documents": RFCs and Internet-Drafts that are published as part of the IETF Standards Process. These are also referred to as "IETF Stream Documents" as defined in Section 5.1.1 of RFC 4844. g. "IETF Standards Process": the activities undertaken by the IETF in any of the settings described in the above definition of Contribution. The IETF Standards Process may include participation in activities and publication of documents that are not directed toward the development of IETF standards or specifications, such as the development and publication of informational documents. h. "IPR" or "Intellectual Property Rights": means a patent, utility model, or similar right that may Cover an Implementing Technology, whether such rights arise from a registration or renewal thereof, or an application therefore, in each case anywhere in the world. See [RFC5378] for a discussion of Trademarks. i. "Implementing Technology": means a technology that implements an IETF specification or standard. Bradner & Contreras [Page 4]
Internet-Draft RFC 3979 bis January 2017 j. "Internet-Draft": a temporary document used in the IETF and RFC Editor processes, as described in [RFC2026]. k. "Participating in an IETF discussion or activity": means making a Contribution, as described above, or in any other way acting in order to influence the outcome of a discussion relating to the IETF Standards Process. Without limiting the generality of the foregoing, acting as a working group chair or Area Director constitutes "Participating" in all activities of the relevant working group(s) he or she is responsible for in an area. "Participant" and "IETF Participant" mean any individual Participating in an IETF discussion or activity. l. "Reasonably and personally known": means something an individual knows personally or, because of the job the individual holds, would reasonably be expected to know. This wording is used to indicate that an organization cannot purposely keep an individual in the dark about patents or patent applications just to avoid the disclosure requirement. But this requirement should not be interpreted as requiring the IETF Contributor or Participant (or his or her represented organization, if any) to perform a patent search to find applicable IPR. m. "RFC": the basic publication series for the IETF. RFCs are published by the RFC Editor. (See [RFC2026] Section 2.1) 2. Introduction The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and Participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 [RFC2026] and obsoletes RFC 3979 [RFC3979] and RFC 4879 [RFC4879]. Section 1 defines the terms used in this document. Sections 3 through 11 set forth the IETF's policies and procedures relating to IPR. Section 13 lists the changes between this document and RFCs 3979 and 4879. A separate document [RFC5378] deals with rights (such as copyrights and Trademarks) in Contributions, including the right of IETF and its Participants to publish and create derivative works of those Contributions. This document is not intended to address Bradner & Contreras [Page 5]
Internet-Draft RFC 3979 bis January 2017 those issues. See RFC 6702 [RFC6702] for a discussion of "Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules". This document is not intended as legal advice. Readers are advised to consult their own legal advisors if they would like a legal interpretation of their rights or the rights of the IETF in any Contributions they make. 3. Participation in the IETF 3.1. General Policy In all matters relating to Intellectual Property Rights, the intent is to benefit the Internet community and the public at large, while respecting the legitimate rights of others. The disclosures required by this policy are intended to help IETF working groups define superior technical solutions with the benefit of as much information as possible about potential IPR claims relating to technologies under consideration. 3.2. Rights and Permissions in Contributions By submission of a Contribution, each person actually submitting the Contribution, and each named co-Contributor, is deemed to agree to the following terms and conditions, on his or her own behalf, and on behalf of the organizations the Contributor represents or is sponsored by (if any) when submitting the Contribution. 3.3. Obligations on Participants By Participating in IETF, each Participant is deemed to agree to comply with all requirements of this RFC that relate to Participation in IETF activities. Without limiting the foregoing, each Participant that is a Contributor makes the following representations to IETF: A. Such Contributor represents that he or she has made or will promptly make all disclosures required by Section 5.1.1 of this document. B. Such Contributor represents that there are no limits to the Contributor's ability to make the grants, acknowledgments and agreements herein that are reasonably and personally known to the Contributor. 4. Actions for Documents for which IPR Disclosure(s) Have Been Received A. The IESG, IAB, ISOC and IETF Trust disclaim any responsibility for identifying the existence of or for evaluating the applicability Bradner & Contreras [Page 6]
Internet-Draft RFC 3979 bis January 2017 of any IPR, disclosed or otherwise, to any IETF technology, specification or standard, and will take no position on the validity or scope of any such IPR. B. When the IETF Secretariat has received a notification under Section 5.1.3 of the existence of non-participant IPR that potentially Covers a technology under discussion at IETF or which is the subject of an IETF Document, the IETF Secretariat shall promptly publish such notification and will request that the identified third party make an IPR disclosure in accordance with the provisions of Section 5. C. When an IPR disclosure has been made as provided in Section 5 of this document, the IETF Secretariat may request from the purported holder of such IPR a written assurance that upon approval by the IESG for publication of the relevant IETF specification(s) as one or more RFCs, all persons will be able to obtain the right to implement, use, distribute and exercise other rights with respect to Implementing Technology under one of the licensing options specified in Section 5.5.A below unless a statement identifying one of the licensing options described in Section 5.5.A has already been received by the IETF Secretariat. The working group proposing the use of the technology with respect to which the Intellectual Property Rights are disclosed may assist the IETF Secretariat in this effort. The results of this procedure shall not, in themselves, block publication of an IETF Document or advancement of an IETF Document along the standards track. A working group may take into consideration the results of this procedure in evaluating the technology, and the IESG may defer approval when a delay may facilitate obtaining such assurances. The results will, however, be recorded by the IETF Secretariat, and be made available online. D. Determination of Provision of Reasonable and Non-discriminatory Terms The IESG will not make any determination that any terms for the use of an Implementing Technology has been fulfilled in practice. It will instead apply the normal requirements for the advancement of Internet Standards (see RFC 6410). If the two unrelated implementations of the specification that are required to advance from Proposed Standard to Standard have been produced by different organizations or individuals, or if the "significant implementation and successful operational experience" required to advance from Proposed Standard to Standard has been achieved, the IESG will presume that the terms are reasonable and to some degree non-discriminatory. Note that this also applies to the case where Bradner & Contreras [Page 7]
Internet-Draft RFC 3979 bis January 2017 multiple implementers have concluded that no licensing is required. This presumption may be challenged at any time, including during the Last-Call period by sending email to the IESG. 5. IPR Disclosures This document refers to the IETF Participant making disclosures, consistent with the general IETF philosophy that Participants in the IETF act as individuals. A Participant's obligation to make a disclosure is also considered satisfied if the IPR owner, which may be the Participant's employer or sponsor, makes an appropriate disclosure in place of the Participant doing so. 5.1. Who Must Make an IPR Disclosure? 5.1.1. A Contributor's IPR in his or her Contribution Any Contributor who reasonably and personally knows of IPR meeting the conditions of Section 5.6 which the Contributor believes Covers or may ultimately Cover his or her written Contribution that is intended to be used as an input into the IETF Standards Process, or which the Contributor reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such written Contribution, must make a disclosure in accordance with this Section 5. 5.1.2. An IETF Participant's IPR in Contributions by Others If an individual's Participation relates to a written Contribution made by somebody else that is intended to be used as an input into the IETF Standards Process, and such Participant reasonably and personally knows of IPR meeting the conditions of Section 5.6 which the Participant believes Covers or may ultimately Cover that Contribution, or which the Participant reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such written Contribution, then such Participant must make a disclosure in accordance with this Section 5. 5.1.3. Voluntary IPR Disclosures If any person has information about IPR that may Cover a technology relevant to the IETF Standards Process, but such person is not required to disclose such IPR under Sections 5.1.1 or 5.1.2 above, such person is nevertheless encouraged to file an IPR disclosure as described in Section 5.3 below. Such an IPR disclosure should be filed as soon as reasonably possible after the person realizes that Bradner & Contreras [Page 8]
Internet-Draft RFC 3979 bis January 2017 such IPR may Cover a Contribution. Situations in which such voluntary IPR disclosures may be made include (a) when IPR does not meet the criteria in Section 5.6 because it is not owned or controlled by an IETF Participant or his or her sponsor or employer (referred to as third party IPR), (b) an individual is not required to disclose IPR meeting the requirements of Section 5.6 because that individual is not Participating in the relevant IETF activity or (c) the IPR Covers technology that does not yet meet the criteria for a Contribution hereunder (e.g., it is disclosed in an informal or other non-IETF setting). 5.2. The Timing of Disclosure Timely IPR disclosure is important because working groups need to have as much information as they can while they are evaluating alternative solutions. 5.2.1. Timing of Disclosure Under Section 5.1.1 A. The IPR disclosure required pursuant to section 5.1.1 must be made as soon as reasonably possible after the Contribution is submitted or made unless the required disclosure is already on file. See Section 5.4.2 for a discussion of when updates need to be made for an existing disclosure. B. If a Contributor first learns of IPR in its Contribution that meets the conditions of Section 5.6, for example a new patent application or the discovery of a relevant patent in a patent portfolio, after the Contribution is published in an Internet- Draft, a disclosure must be made as soon as reasonably possible after the IPR becomes reasonably and personally known to the Contributor. 5.2.2. Timing of Disclosure Under Section 5.1.2 The IPR disclosure required pursuant to section 5.1.2 must be made as soon as reasonably possible after the Contribution is made, unless the required disclosure is already on file. Participants who realize that IPR meeting the conditions of Section 5.6 Covers technology that will be or has been incorporated into a Contribution, or is seriously being discussed in a working group, are strongly encouraged to make a preliminary IPR disclosure. That IPR disclosure should be made as soon after coming to the realization as reasonably possible, not waiting until the Contribution is actually made. Bradner & Contreras [Page 9]
Internet-Draft RFC 3979 bis January 2017 If an IETF Participant first learns of IPR that meets the conditions of Section 5.6 that Covers a Contribution by another party, for example a new patent application or the discovery of a relevant patent in a patent portfolio, after the Contribution was made, an IPR disclosure must be made as soon as reasonably possible after the Contribution or IPR becomes reasonably and personally known to the Participant. 5.2.3 Timing of Disclosure by ADs By the nature of their office, IETF area directors may become aware of Contributions late in the process (for example at IETF Last Call or during IESG review) and, therefor and in such cases, cannot reasonably be expected to disclose IPR Covering those Contributions until they become aware of them. 5.3. How Must an IPR Disclosure be Made? IPR disclosures must be made by following the instructions at https://www.ietf.org/ipr-instructions. IPR disclosures and other IPR-related information, including licensing information, must not be included in RFCs or other IETF Contributions. The RFC-Editor will remove any IPR-related information from Contributions prior to publication as an RFC. 5.4. What Must be in an IPR Disclosure? 5.4.1. Content of IPR Disclosures An IPR disclosure must list the numbers of any issued patents or published patent applications or indicate that the disclosure is based on unpublished patent applications. The IPR disclosure must also list the name(s) of the inventor(s) (with respect to issued patents and published patent applications) and the specific IETF Document(s) or activity affected. If the IETF Document is an Internet-Draft, it must be referenced by specific version number. In addition, if the IETF Document includes multiple parts and it is not reasonably apparent which part of such IETF Document is alleged to be Covered by the IPR in question, it is helpful if the discloser identifies the sections of the IETF Document that are alleged to be so Covered. 5.4.2. Updating IPR Disclosures. Those who disclose IPR should be aware that as drafts evolve, text may be added or removed, and it is recommended that they keep this in mind when composing text for disclosures. Bradner & Contreras [Page 10]
Internet-Draft RFC 3979 bis January 2017 A. An IPR disclosure must be updated or a new disclosure made promptly after any of the following has occurred unless sufficient information to identify the issued patent was disclosed when the patent application was disclosed: (1) the publication of a previously unpublished patent application, (2) the abandonment of a patent application (3) the issuance of a patent on a previously disclosed patent application ), (4) a material change to the IETF Document covered by the Disclosure that causes the Disclosure to be covered by additional IPR. If the patent application was abandoned, then the new IPR disclosure must explicitly withdraw any earlier IPR disclosures based on the application. IPR disclosures against a particular Contribution are assumed to be inherited by revisions of the Contribution and by any RFCs that are published from the Contribution unless the disclosure has been updated or withdrawn. B. If an IPR holder files patent applications in additional countries which refer to, and the claims of which are substantially identical to, the claims of a patent or patent application previously disclosed in an IPR disclosure, the IPR holder is not required to make a new or updated IPR disclosure as a result of filing such applications or the issuance of patents on such applications. C. New or revised IPR disclosures may be made voluntarily at any other time, provided that licensing information may only be updated in accordance with Section 5.5.C. D. Any person may submit to IETF an update to an existing IPR disclosure. If such update is submitted by a person other than the submitter of the original IPR disclosure (as identified by name and e-mail address), then the Secretariat shall attempt to contact the original submitter to verify the update. If the original submitter responds that the proposed update is valid, the Secretariat will update the IPR disclosure accordingly. If the original submitter responds that the proposed update is not valid, the Secretariat will not update the IPR disclosure. If the original submitter fails to respond after the Secretariat has made three separate inquiries and at least 30 days have elapsed since the initial inquiry was made, then the Secretariat will inform the submitter of the proposed update that the update was not validated, and that the updater must produce legally sufficient evidence that the submitter (or his/her employer) owns or has the legal right to exercise control over the IPR subject to the IPR disclosure. If such evidence is satisfactory to the Secretariat, after consultation with legal counsel, then the Secretariat will make the requested update. If such evidence is not satisfactory, then the Secretariat will not make the requested update. Bradner & Contreras [Page 11]
Internet-Draft RFC 3979 bis January 2017 5.4.3. Blanket IPR Statements The requirement to make an IPR disclosure is not satisfied by the submission of a blanket statement that IPR may exist on every Contribution or a general category of Contributions. This is the case because the aim of the disclosure requirement is to provide information about specific IPR against specific technology under discussion in the IETF. The requirement is also not satisfied by a blanket statement of willingness or commitment to license all potential IPR Covering such technology under fair, reasonable and non-discriminatory terms for the same reason. However, the requirement for an IPR disclosure is satisfied by a blanket statement of the IPR discloser's commitment to license all of its IPR meeting the requirements of Section 5.6 (and either Section 5.1.1 or 5.1.2) to implementers of an IETF specification on a royalty-free (and otherwise reasonable and non-discriminatory) basis as long as any other terms and conditions are disclosed in the IPR disclosure. 5.5. Licensing Information in an IPR Disclosure A. Since IPR disclosures will be used by IETF working groups during their evaluation of alternative technical solutions, it is helpful if an IPR disclosure includes information about licensing of the IPR in case Implementing Technologies require a license. Specifically, it is helpful to indicate whether, upon approval by the IESG for publication as an RFC of the relevant IETF specification(s), all persons will be able to obtain the right to implement, use, distribute and exercise other rights with respect to an Implementing Technology a) under a royalty-free and otherwise reasonable and non- discriminatory license, or b) under a license that contains reasonable and non-discriminatory terms and conditions, including a reasonable royalty or other payment, or c) without the need to obtain a license from the IPR holder (e.g., a covenant not to sue). B. The inclusion of a licensing declaration is not mandatory but it is encouraged so that the working groups will have as much information as they can during their deliberations. If the inclusion of a licensing declaration in an IPR disclosure would significantly delay its submission then the discloser may submit an IPR disclosure without a licensing declaration and then submit a new IPR disclosure when the licensing declaration becomes available. IPR disclosures that voluntarily provide text that includes licensing information, comments, notes, or URL for other information may also voluntarily include details regarding specific licensing terms that the IPR holder intends to offer to implementers of Implementing Technologies, including maximum Bradner & Contreras [Page 12]
Internet-Draft RFC 3979 bis January 2017 royalties. C. It is likely that IETF will rely on licensing declarations and other information that may be contained in an IPR disclosure and that implementers will make technical, legal and commercial decisions on the basis of such commitments and information. Thus, when licensing declarations and other information, comments, notes, or URLs for further information are contained in an IPR disclosure, the persons making such disclosure agree and acknowledge that the commitments and information contained in such disclosure shall be irrevocable, and will attach, to the extent permissible by law, to the associated IPR, and all implementers of Implementing Technologies will be justified and entitled to rely on such materials in relating to such IPR, whether or not such IPR is subsequently transferred to a third party by the IPR holder making the commitment or providing the information. IPR holders making IPR disclosures that contain licensing declarations or providing such information, comments, notes or URLs for further information must ensure that such commitments are binding on any transferee of the relevant IPR, and that such transferee will use reasonable efforts to ensure that such commitments are binding on a subsequent transferee of the relevant IPR, and so on. D. Licensing declarations must be made by people who are authorized to make such declarations. 5.6. Level of Control over IPR requiring Disclosure IPR disclosures under Sections 5.1.1. and 5.1.2 are required with respect to IPR that is (a) owned, directly or indirectly, by the individual or his/her employer or sponsor (if any) or (b) that such persons otherwise have the right to license or assert or (c) that such persons derive a direct or indirect pecuniary benefit from such IPR, or (d) in the case of an individual, the individual is listed as an inventor on a patent or patent application. 5.7. Disclosures for Oral Contributions. If a Contribution is oral and is not followed promptly by a written disclosure of the same material, and if such oral Contribution would be subject to a requirement that an IPR Disclosure be made had such oral Contribution been written, then the Contributor must accompany such oral Contribution with an oral declaration that he/she is aware of relevant IPR in as much detail as reasonably possible, or file an IPR Declaration with respect to such oral Contribution that otherwise complies with the provisions of Sections 5.1 to 5.6 above. 5.8. General Disclosures. Bradner & Contreras [Page 13]
Internet-Draft RFC 3979 bis January 2017 The IETF may make available a public facility (e.g., a web page and associated database) for the posting of IPR-related information and disclosures that do not conform to the requirements of Sections 5.1 to 5.6 ("General Disclosures"). General Disclosures may include, among other things, "blanket disclosures" described in Section 5.4.3 (other than blanket disclosures accompanied by royalty-free licensing commitments, as permitted by Section 5.4.3), disclosures of IPR that do not identify the specific IETF Documents Covered by the disclosed IPR, and licensing statements or commitments that are applicable generally and not to specific IPR disclosures. All of this information may be helpful to the IETF community, and its disclosure is encouraged. However, General Disclosures do not satisfy an IETF Participant's obligation to make IPR disclosures as required by this policy. In some cases, if an IPR disclosure submitted by an IETF Participant does not meet the requirements of this policy, the IETF may elect to post the non-conforming IPR disclosure as a General Disclosure, in order to provide the greatest amount of information to the IETF community. This action does not excuse the IETF Participant from submitting a new IPR disclosure that conforms with the requirements of Sections 5.1 to 5.6. The IETF reserves the right to decline to publish General Disclosures that are not relevant to IETF activities, that are, or are suspected of being, defamatory, false, misleading, in violation of privacy or other applicable laws or regulations, or that are in a format that is not suitable for posting on the IETF facility that has been designated for General Disclosures. 6. Failure to Disclose There may be cases in which individuals are not permitted by their employers or by other factors to disclose the existence or substance of patent applications or other IPR. Since disclosure is required for anyone making a Contribution or participating in IETF activities, a person who is not willing or able to disclose IPR for this reason, or any other reason, must not contribute to or participate in IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she will not disclose, unless that person knows that his or her employer or sponsor will make the required disclosures on his or her behalf. Contributing to or participating in IETF activities about a technology without making required IPR disclosures is a violation of IETF process. In addition to any remedies or defenses that may be available to implementers and others under the law with respect to such a violation (e.g., rendering the relevant IPR unenforceable), the IESG Bradner & Contreras [Page 14]
Internet-Draft RFC 3979 bis January 2017 may, when it in good faith concludes that such a violation has occurred, impose penalties including, but not limited to, suspending the posting/participation rights of the offending individual, suspending the posting/participation rights of other individuals employed by the same company as the offending individual, amending, withdrawing or superseding the relevant IETF Documents, and publicly announcing the facts surrounding such violation, including the name of the offending individual and his or her employer or sponsor. See [RFC6701] for details. 7. Evaluating Alternative Technologies in IETF Working Groups In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing. However, to solve a given technical problem, IETF working groups have the discretion to adopt a technology as to which IPR claims have been made if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. To assist these working groups, it is helpful for the IPR claimants to declare, in their IPR Declarations, the terms, if any, on which they are willing to license their IPR Covering the relevant IETF Documents. When adopting new technologies, the participants in an IETF working group are expected to evaluate all the relevant tradeoffs from their perspective. Most of the time these considerations are based purely on technical excellence, but IPR considerations may also affect the evaluation and specific licensing terms may affect the participants' opinion on the desirability of adopting a particular technology. The IETF has no official preference among different licensing terms beyond what was stated at the beginning of this section. However, for information and to assist participants in understanding what license conditions may imply, what follows are some general observations about some common types of conditions. The following paragraphs are provided for information only: When there is no commitment to license patents covering the technology, this creates uncertainty that obviously is concerning. These concerns do not exist when there is a commitment to license, but the license terms can still differ greatly. Some common conditions include 1) terms that are fair, reasonable and non- discriminatory, and which may bear royalties or other financial obligations (FRAND or RAND); 2) royalty-free terms that are otherwise fair, reasonable and non-discriminatory (RAND-z); and 3) commitments not to assert declared IPR. Open source projects, for instance, often prefer the latter two. However, licenses often come with complex terms that have to be evaluated in detail, and this crude Bradner & Contreras [Page 15]
Internet-Draft RFC 3979 bis January 2017 classification may not be sufficient to make a proper evaluation. For instance, licenses may also include reciprocity and defensive suspension requirements that require careful evaluation. The level of use of a technology against which IPR is disclosed is also an important factor in weighing IPR encumbrances and associated licensing conditions against technical merits. For example, if technologies are being considered for a mandatory-to-implement change to a widely deployed protocol, the hurdle should be very high for encumbered technologies, whereas a similar hurdle for a new protocol could conceivably be lower. Working groups and areas may, however, adopt stricter requirements in specific cases. For instance, the IETF Security Area has adopted stricter requirements for some security technologies. It has become common to have a mandatory-to-implement security technology in IETF technology specifications. This is to ensure that there will be at least one common security technology present in all implementations of such a specification that can be used in all cases. This does not limit the specification from including other security technologies, the use of which could be negotiated between implementations. An IETF consensus has developed that no mandatory-to-implement security technology can be specified in an IETF specification unless it has no known IPR claims against it or a royalty-free license is available to implementers of the specification. It is possible to specify such a technology in violation if this principle if there is a very good reason to do so, and if that reason is documented and agreed to through IETF consensus. This limitation does not extend to other security technologies in the same specification if they are not listed as mandatory-to-implement. It should also be noted that the absence of IPR disclosures at any given time is not the same thing as the knowledge that there will be no IPR disclosure in the future, or that no IPR Covers the relevant technology. People or organizations not currently involved in the IETF or people or organizations that discover IPR they feel to be relevant in their patent portfolios can make IPR disclosures at any time. It should be noted that the validity and enforceability of any IPR may be challenged for legitimate reasons outside the IETF. The mere existence of an IPR disclosure should not be taken to mean that the disclosed IPR is valid or enforceable or actually Covers a particular Contribution. Although the IETF can make no actual determination of validity, enforceability or applicability of any particular IPR, it is reasonable that a working group or the IESG will take into account on their own views of the validity, enforceability or applicability of IPR in their evaluation of alternative technologies. Bradner & Contreras [Page 16]
Internet-Draft RFC 3979 bis January 2017 8. Change Control for Technologies The IETF must have change control over the technology described in any standards track IETF Documents in order to fix problems that may be discovered or to produce other derivative works. In some cases the developer of patented or otherwise controlled technology may decide to hand over to the IETF the right to evolve the technology (a.k.a., "change control"). The implementation of an agreement between the IETF and the developer of the technology can be complex. (See [RFC1790] and [RFC2339] for examples.) Note that there is no inherent prohibition against a standards track IETF Document making a normative reference to proprietary technology. For example, a number of IETF Standards support proprietary cryptographic transforms. 9. Licensing Requirements to Advance Standards Track IETF Documents RFC 6410 [RFC6410] Section 2.2 states: "If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. " A key word in this text is "requires." The mere existence of disclosed IPR does not necessarily mean that licenses are actually required in order to implement the technology. 10. No IPR Disclosures in IETF Documents IETF Documents must not contain any mention of specific IPR. All specific IPR disclosures must be submitted as described in Section 5. Readers should always refer to the on-line web page to get a full list of IPR disclosures received by the IETF concerning any Contribution. (https://www.ietf.org/ipr/) 11. Application to non-IETF Stream Documents This memo has been developed for the benefit and use of the IETF community. As such, the rules set forth herein apply to all Contributions and IETF Documents that are in the "IETF Document Stream" as defined in Section 5.1.1 of RFC 4844 (i.e., those that are contributed, developed, edited and published as part of the IETF Standards Process). The legal rules that apply to documents in Alternate Streams are established by the managers of those Alternate Streams (currently the Internet Architecture Board (IAB), Internet Research Steering Group (IRSG) and Independent Submission Editor, as specified in RFC 4844). Bradner & Contreras [Page 17]
Internet-Draft RFC 3979 bis January 2017 These managers may elect, through their own internal processes, to cause this memo to be applied to documents contributed to them for development, editing and publication in their respective Alternate Streams. If an Alternate Stream manager elects to adopt this memo, they must do so in a manner that is public and notifies their respective document contributors that this memo applies to their respective Alternate Streams. In such case, each occurrence of the term "Contribution," and "IETF Document" in this memo shall be read to mean a contribution or document in such Alternate Stream, as the case may be. It would be advisable for such Alternate Stream manager to consider adapting the definitions of "Contribution," and other provisions in the memo to suit their particular needs. 12. Security Considerations This memo relates to IETF process, not any particular technology. There are security considerations when adopting any technology, whether IPR-protected or not. A working group should take those security considerations into account as one part of evaluating the technology, just as IPR is one part, but there are no known issues of security with IPR procedures. 13. Changes Since RFC 3979 and RFC 4879 [this section will be revised before publication to list the actual changes that are approved] This document combines RFC 3979 and RFC 4879. Reordered the defined terms Boilerplate -- since the document boilerplate formerly in BCP79 Sec. 5 has been moved to the Trust Legal Provisions since 2009, deleted the boilerplate requirements from this document. Foreign Counterparts -- don't need to file a new IPR disclosure Provisional Apps -- suggest that these be required to be disclosed when covering the technology in question. Inventor names -- added words requiring that inventors be listed along with patent numbers as result of WG discussion. Oral statements -- the existing text is internally contradictory. Some places say that disclosures must be made for oral statements, but others talk about disclosures only being required following publication as an ID. Proposed that oral statements don't trigger the normal IPR disclosure obligations, as oral statements are Bradner & Contreras [Page 18]
Internet-Draft RFC 3979 bis January 2017 inherently imprecise and it's hard to know when they describe something covered by the technical terms of a patent claim. However, if an oral contribution is made and it is not followed by a written contribution, then the oral discloser must either make a concurrent oral IPR disclosure or file a formal written disclosure. Other Contribution Clarification -- suggested a number of other clarifications to the definition of Contribution that have come up over the years, including the addition of BOFs. Disclosure of licensing terms is ok -- added a sentence. Licensing commitments are irrevocable -- added a paragraph. Participation -- this is a complicated issue that runs throughout the document. At a high level, suggested that anyone who says something on a list or in a WG meeting is required to make IPR disclosures Updating Disclosures - added a number of clauses to address issues that have come up over the years, including updating obligations if an employee changes jobs or his/her employer buys another company. Alternate Streams - borrowed and adapted the copyright language used in the Trust Legal Provisions. Each alternate stream (Independent, IRTF and IAB) would need to take some action (preferably issuing an RFC) to adopt BCP 79 for its stream. This was done with copyright already, and pretty smoothly. 14. References 14.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC4844] Daigle, L. Ed. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007. [RFC6410] Housley, R., D. Crocker, and E. Burger, "Reducing the Standards Track to Two Maturity Levels", RFC 6401, October 2011. Bradner & Contreras [Page 19]
Internet-Draft RFC 3979 bis January 2017 14.2. Informative References [RFC1790] Cerf, V., "An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols", RFC 1790, April 1995. [RFC2339] The Internet Society and Sun Microsystems, "An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols", RFC 2339, May 1998. [RFC5378] Bradner, S. Ed, J. Contreras, Ed, "Rights Contributors Provide to the IETF Trust", RFC 5378, November 2008 [RFC6701] Farrel, A., and P. Resnick, "Sanctions Available for Application to Violators of IETF IPR Policy", RFC 6702, August 2012 [RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with Intellectual Property Rights (IPR)Disclosure Rules", RFC 6702, August 2012 IANA Considerations This memo requires no action by the IANA. [this section should be removed for publication] 15. Editor's Addresses Scott Bradner 15 High St. Cambridge MA, 02138 Phone: +1 202 558 5661 EMail: sob@sobco.com Jorge Contreras University of Utah S.J. Quinney College of Law 383 South University St. Salt Lake City, UT 84112 Email: cntreras@gmail.com 16. Changes Since RFC 3979 The material in RFC 3979 was significantly reorganized to produce this document. This changes section reviews the actual changes in content since RFC 3979 and does not detail the reorganization. These changes are listed from the point of view of this document with reference to the RFC 3979 section where useful. Bradner & Contreras [Page 20]
Internet-Draft RFC 3979 bis January 2017 Section 1 - Definitions 1.a "Alternate Stream" definition (new): Added to enable IRTF, IAB and RFC Editor streams to adopt and use BCP79 more easily. 1.b - "Contribution": (was 1.c) Removed "IETF" to more easily enable other Streams to adopt this policy Added "intended to affect the IETF Standards Process" - Addition needed to prevent information presentations (e.g., plenary guest speakers) from being considered Contributions. Added BOFs, design teams, web sites, chat rooms - Contributions can be made in any of these places 1.d "Covers" ( was 1.n) -added provisional patent applications - Required to eliminate ambiguity whether provisional applications are included 1.f - "IETF documents" (was 1.h) - Limited to IETF (not Alternate Stream) documents 1.g - "IETF Standards Process" (was 1.b) - Clarify that Contributions can be made in contexts other than traditional IETF standards development. 1.h - "IPR" (was 1.o) - removed reference to copyrights, database rights and data rights - Copyright in IETF documents and contributions is addressed under RFC 5378 and is treated very differently than patents, which are the focus of BCP79. Data/database rights not relevant to IETF standards, and cannot be registered or disclosed in the manner of patents. 1.j - "Internet Draft" (was 1.g) - reduced to reference RFC 2026 without additional description for clarity 1.k - "Participating in an IETF discussion or activity" (new) - Due to numerous ambiguities over the years, it was necessary to add a section describing what it means to "participate" in an IETF activity 1.m - "RFC" (was 1.e) - Added cross-reference to RFC 2026 and eliminated textual description of RFC features 2. - Introduction - This added text that offers an overview of why we have this policy, cut prior discussion of RFC 2026 Section 10 as no longer necessary & added references to subsequent RFCs relating to IPR, including RFC 5378 and 6702 3. - Contributions to the IETF - Changed focus to participation rather than making of contributions and explain why we require IPR disclosure old 3.2.1.C - Deleted because all required legends in IETF documents are now described in RFC 5378 and Trust Legal Provisions 3.3 - Obligations on Participants - Added to make clear that participation in IETF obligates the participant to comply with IETF rules old 4A - Removed because inconsistent with current and historical practice. Also, all legends in IETF documents now addressed in Trust Legal Provisions. Bradner & Contreras [Page 21]
Internet-Draft RFC 3979 bis January 2017 4.A - The IESG, IAB - added IAB, ISOC and IETF Trust to disclaimer 4.B - When the IETF Secretariat - Added description of current procedure used to publish third party IPR disclosures 4.C - When an IPR disclosure ... - updated to reflect current practice and roles (e.g., Secretariat rather than IETF Exec Dir). 4.D - Determination of Provision of Reasonable and Non-discriminatory Terms (was 4.1) - Various edits made to this paragraph to reflect current process for advancement of standards. old 5. - deleted as not needed 5.1.1 - Contributor's IPR in his or her Contribution (was 6.1.1) - Limits disclosure obligation to written Contributions intended to be used as inputs to the IETF Standards Process. - Oral disclosures are now covered in Sec. 5.7. 5.1.2 - Contributions by others (was 6.1.2) - Revisions made consistent with 5.1.1 above 5.1.3 - Voluntary IPR Disclosures (was 6.1.3) - Fixes procedures for making voluntary IPR disclosures and adds examples of when voluntary disclosures may be appropriate. In addition to IPR of others, voluntary disclosures are encouraged when an IETF Participant is aware of its own IPR that covers IETF work in which it is not an active participant, and when the technology is disclosed in other than an IETF setting. 5.2.1 - Timing of Disclosure Under Section 5.1.1 (was 6.2.1) - Trigger for disclosure changed from publication of a Contribution in an I-D to "submitted or made", Lengthy example regarding updates deleted in lieu of cross-reference to Sec. 5.4.2 re. updates. 5.2.2 - Timing of Disclosure Under Section 5.1.2 (was 6.2.2)- Corresponding changes made per 5.2.1 5.2.3 - Timing of Disclosure by ADs - Added to clarify AD disclosure obligations 5.3 - IPR disclosures and other ... - Reflects current practice re. prohibition of including IPR information directly in IETF documents. 5.4.1 - Content of Disclosures (was 6.4.1) - added requirement to disclose names of inventors - Disclosing the name(s) of inventors on a patent will make it more likely that IETF participants will recognize whether the inventor is an IETF participant, and what IETF activities that individual participates in. This information is easy for the discloser to provide, and less convenient for every reader of the IPR disclosure to look up in patent office records (if even available). 5.4.2 - Updating IPR Disclosures (was 6.4.2) - Significant revisions and additional detail added regarding updating of IPR disclosures upon events such as issuance of patents, amendment of claims, etc. 5.4.3 - Blanket IPR Statements (was 6.4.3) - wording clarifications plus changed "willingness" to "commitment" - A blanket IPR disclosure which does not list specific patent numbers is not Bradner & Contreras [Page 22]
Internet-Draft RFC 3979 bis January 2017 compliant with this policy unless the discloser commits (and is not just willing) to license such patents on royalty-free and otherwise reasonable terms. 5.5.C - It is likely that IETF will rely ... - new paragraph - Makes licensing declarations irrevocable so that they may be relied upon in the future by implementers 5.5.D - Licensing declarations ... - new paragraph - Requires that licensing declarations must be made by people authorized to make them. 5.6 - Level of Control over IPR requiring disclosure (was 6.6) - n addition to ownership of IPR, language added to require disclosure when Participants derive a pecuniary benefit from the IPR, or the individual is a listed inventor - Clarifications to address situations not covered in earlier version 5.7 - Disclosures for Oral Contributions - New section describing procedure for oral contributions. 5.8 - General Disclosures - This new section describes the IETF's public disclosure feature, which allows IPR disclosures to be made by anyone, whether or not an IETF participant. The feature has been up and running for years, and this language describes its current implementation. 6 Failure to Disclose (was 7) - technical and clarity corrections, as well as new language describing potential remedies for failures to disclose IPR in accordance with IETF rules, including IESG actions under RFC 6701 and potential for invalidity of IPR - RFC 6701 outlines IESG actions when IETF participants fail to make required IPR disclosures. 7. - Evaluating Alternative Technologies (was 8) Para. 1 - minor wording changes for clarity Para. 2-5 - new and relate to the considerations made by IETF WGs when evaluating patent and licensing disclosures concerning IETF standards Para 6. - security technologies - New paragraph makes clear that security is only one example of stricter requirements. Also requires that violation of requirements for royalty-free licensing in the security area can be made only with IETF consensus. Para 7-8 - (were paras 3-4) - Wording changes for clarity 8. - Change control (was 9) - Wording updated to reflect RFC 6410 10. - No IPR Disclosures in IETF Documents (was 11) - Wording simplified to refer to Section 5. 11. - Application to non-IETF Stream Documents - new - Adds procedures to be followed by Alternate Stream (IAB, IRTF, RFC Ed) managers to adopt these rules and procedures. Changes in revisions of this document [this section should be removed before publication] Bradner & Contreras [Page 23]
Internet-Draft RFC 3979 bis January 2017 version 00 -> version 01 many clean ups suggested by Russ Housley removed "informational" from section 5.1.1 version 01 -> version 02 change RFC 2026 reference in section 9 to RFC 6410 fixed multiple references to (old) section 6 revised section 5.5 to clarify the intention, as suggested by David Rudin version 02 -> version 03 created a definition of "participation" in the definitions section as suggested by multiple people A number of changes suggested by Adrian Farrel expanded introduction by including a copy of the abstract fixed reference to RFC 6701 add mention of RFC 6702 to the introduction and added RFC 6702 to the references removed last sentence of section 5.4.2 B removed discussion of asking for info on non-US patents from section 13 revised 5.4.2.C added 5.4.2 D based on a suggestion by Alexa Morris add note about inheritance to section 5.4.2.A revise list of bullets for definition of contribution - section 1.b added 5.5.D fixed wording problem in 5.2.2 noted by SM version 03 -> version 04 revised definition of "Participating in an IETF discussion or activity" section 1.k changed language re "foreign" patents - section 5.4.2 B removed mention of claims in provisional applications in section 1.d version 04 -> version 05 revised section 1.k based on list discussion tightened up section 4.B and removed the last sentence which describes a function that does not seem to be done - suggested by Fabian Gonell change the requirement in section 5.1.1.B to a request - - suggested by Fabian Gonell replaced "withdraw" with "update" in 5.1.1.B since the disclosure is still valid against the older Contribution Bradner & Contreras [Page 24]
Internet-Draft RFC 3979 bis January 2017 remove section 5.2.1.C as redundant - suggested by Fabian Gonell added text from the mailing list discussion to Section 5.4.2 revised section 5.4.2.D to have the licensing information requirements in one place. - suggested by Fabian Gonell version 05 -> version 06 revised 1.k based on BOF and list discussion, added assumptive participation for WG chairs & ADs changed "should" in 4.C to reflect current practice removed 5.1.1 B since the topic is covered in 5.4.3 added "with respect to issued patents and published patent applications" in 5.4.1 based on BOF discussion revised 5.4.2 A based on BOF discussion removed 5.4.2 C since it was redundant added parenthetical at the end of 5.5 A added additional clause to 5.6 based on issue that came up added 5.8 on general disclosures based on BOF discussion revised 7 based on suggestions by Stephen Wegner and mailing list discussions removed the last sentence of 7 since the legal picture is changing version 06 -> version 07 5.3 -- clarify that extraneous IPR disclosures should not be made in Contributions, only in IPR Disclosures in 5.4.1 went from "must" disclose section of document affected to "it is helpful" to disclose this, at AD request (restore to 3979) 6 -- refer to RFC 6701 in discussion of non-compliance penalties. 7 -- removed order of preference for licensing terms and replaced with AD suggested language version 07 -> version 08 added ToC revised section 5.1.2 changed "working group" to "implementer" in section 5.5 c version 08 -> version 09 update abstract to make it clear that this document replaces RFC 2026 section 10 changed "http" to "https" in a few places In "Alternate Stream" definition, allowed for definition of future streams. In "Contribution" definition, made "design team" generic and referenced BCP25 (RFC 2418] In Sec. 3.1, added sentence about WGs that summarizes ideas from Sec. 7. In Sec. 5.1.2, cleaned up language for clarity Broadened Sec. 5.1.3 to allow voluntary IPR disclosures in any situations not otherwise required by 5.1.1 and 5.1.2 (e.g., hallway Bradner & Contreras [Page 25]
Internet-Draft RFC 3979 bis January 2017 conversations, IPR owned by someone else, etc.) In Sec. 6, put back list of penalties since it was pointed out that RFC 6701 is informational only. In Sec. 7, cleaned up language for clarity and added reference to IETF consensus Deleted redundant definition of "Alternate Streams". version 09 -> version 10 removed reference to Draft Standard in Section 4 D clarified that some working groups and areas have adopted stricter standards not the IETF as a whole in the 6th paragraph of Section 7 version 10 -> version 11 added changes since RFC 3979 section Bradner & Contreras [Page 26]