Network Working Group S. Bradner Request for Comments: 3668 Harvard University BCP: 79 February 2004 Updates: 2028, 2026 Category: Best Current Practice Intellectual Property Rights in IETF Technology Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved.
AbstractThe 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 about any IPR constraints on a technical proposal as possible. The policies are also 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 and, with RFC 3667, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference  in RFC 2418. 1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Contributions to the IETF. . . . . . . . . . . . . . . . . . . 6 3.1. General Policy . . . . . . . . . . . . . . . . . . . . . 6 3.2. Rights and Permissions . . . . . . . . . . . . . . . . . 6 4. Actions for Documents for which IPR Disclosure(s) Have Been Received . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. No Determination of Reasonable and Non-discriminatory Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Notice to be included in RFCs. . . . . . . . . . . . . . . . . 8 6. IPR Disclosures. . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Who must make an IPR disclosure? . . . . . . . . . . . . 9
6.2. The timing of providing disclosure . . . . . . . . . . . 9 6.3. How must a disclosure be made? . . . . . . . . . . . . . 11 6.4. What must be in a disclosure?. . . . . . . . . . . . . . 11 6.5. What licensing information to detail in a disclosure . . 12 6.6. When is a disclosure required? . . . . . . . . . . . . . 12 7. Failure to disclose. . . . . . . . . . . . . . . . . . . . . . 12 8. Evaluating alternative technologies in IETF working groups . . 13 9. Change control for technologies. . . . . . . . . . . . . . . . 14 10. Licensing requirements to advance standards track documents. . 14 11. No IPR disclosures in IETF documents . . . . . . . . . . . . . 14 12. Security Considerations. . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . 15 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 15. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 16 16. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 RFC 2028]. a. "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. b. "IETF Standards Process": the activities undertaken by the IETF in any of the settings described in 1(c) below. c. "IETF Contribution": any submission to the IETF intended by the Contributor for publication as all or part of an Internet-Draft or RFC (except for RFC Editor Contributions described below) and any statement made within the context of an IETF activity. Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group 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, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function (except for RFC Editor Contributions described below). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this document. d. "Internet-Draft": temporary documents used in the IETF and RFC Editor processes. Internet-Drafts are posted on the IETF web site by the IETF Secretariat and have a nominal maximum lifetime in the Secretariat's public directory of 6 months, after which they are removed. Note that Internet-Drafts are archived many places on the Internet, and not all of these places remove expired Internet-Drafts. Internet-Drafts that are under active consideration by the IESG are not removed from the Secretariat's public directory until that consideration is complete. In addition, the author of an Internet-Draft can request that the lifetime in the Secretariat's public directory be extended before the expiration. e. "RFC": the basic publication series for the IETF. RFCs are published by the RFC Editor and once published are never modified. (See [RFC 2026] Section 2.1) f. "RFC Editor Contribution": An Internet-Draft intended by the Contributor to be submitted to the RFC Editor for publication as an Informational or Experimental RFC but not intended to be part of the IETF Standards Process. g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor Contributions. Note that under Section 3.3(a) the grant of rights in regards to IETF Internet-Drafts as specified in this document is perpetual and irrevocable and thus survives the Secretariat's removal of an Internet-Draft from the public directory, except as limited by Section 3.3(a)(C). (See [RFC 2026] Sections 2.2 and 8) h. "IETF Documents": RFCs and Internet-Drafts except for Internet- Drafts that are RFC Editor Contributions and the RFCs that are published from them. i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC Editor Contributions and the RFCs that may be published from them. j. "Contribution": IETF Contributions or RFC Editor Contributions
k. "Contributor": an individual submitting a Contribution 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. "Implementing Technology": means a technology that implements an IETF specification or standard. n. "Covers" or "Covered" mean that a valid claim of a patent or a patent application in any jurisdiction or a protected claim, 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. o. "IPR" or "Intellectual Property Rights": means patent, copyright, utility model, invention registration, database and data rights 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. RFC 2026 was published there have been a number of times when the exact intent of Section 10, the section which deals with IPR disclosures has been the subject of vigorous debate within the IETF community. This is because it is becoming increasingly common for IETF working groups to have to deal with claims of Intellectual Property Rights (IPR), such as patent rights, with regards to technology under discussion in working groups. The aim of this document is to clarify various ambiguities in Section 10 of [RFC 2026] that led to these debates and to amplify the policy in order to clarify what the IETF is, or should be, doing. IPR disclosures can come at any point in the IETF Standards Process, e.g., before the first Internet-Draft has been submitted, prior to RFC publication, or after an RFC has been published and the working
group has been closed down; they can come from people submitting technical proposals as Internet-Drafts, on mailing lists or at meetings, from other people participating in the working group or from third parties who find out that the work is going or has gone on; and they can be based on granted patents or on patent applications, and in some cases be disingenuous, i.e., made to affect the IETF Standards Process rather than to inform. RFC 2026, Section 10 established three basic principles regarding the IETF dealing with claims of Intellectual Property Rights: (a) the IETF will make no determination about the validity of any particular IPR claim (b) the IETF following normal processes can decide to use technology for which IPR disclosures have been made if it decides that such a use is warranted (c) in order for the working group and the rest of the IETF to have the information needed to make an informed decision about the use of a particular technology, all those contributing to the working group's discussions must disclose the existence of any IPR the Contributor or other IETF participant believes Covers or may ultimately Cover the technology under discussion. This applies to both Contributors and other participants, and applies whether they contribute in person, via email or by other means. The requirement applies to all IPR of the participant, the participant's employer, sponsor, or others represented by the participants, that is reasonably and personally known to the participant. No patent search is required. Section 1 defines the terms used in this document. Sections 3, 4 and 5 of this document address the intellectual property issues previously addressed by Section 10 of RFC 2026. Sections 6 thru 12 then explain the rationale for these provisions, including some of the clarifications that have been made since the adoption of RFC 2026. The rules and procedures set out in this document are not intended to modify or alter the IETF's current policy toward IPR in the context of the IETF Standards Process. They are intended to clarify and fill in procedural gaps. A companion document [RFC 3667] 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 those issues.
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. RFC 3667].
(B) The IESG disclaims any responsibility for identifying the existence of or for evaluating the applicability 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 claims. (C) Where Intellectual Property Rights have been disclosed for IETF Documents as provided in Section 6 of this document, the IETF Executive Director shall request from the discloser of such IPR, a written assurance that upon approval by the IESG for publication as RFCs 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 Implementing Technology under one of the licensing options specified in Section 6.5 below unless such a statement has already been submitted. The working group proposing the use of the technology with respect to which the Intellectual Property Rights are disclosed may assist the IETF Executive Director 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 Executive Director, and be made available online. RFC 2026, Section 4.1.3.) Note that this also applies to the case where 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.
BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com."
RFC 1790] and [RFC 2339] 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. RFC 2026 Section 4.1.2 states: "If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process." A key word in this text is "required." The mere existence of disclosed IPR does not necessarily mean that licenses are actually required in order to implement the technology. Section 4.1 of this document should be taken to apply to the case where there are multiple implementations and none of the implementers have felt that they needed to license the technology and they have no plausible indications that any IPR holder(s) will try to enforce their IPR.
[RFC 2026] Bradner, S., Ed., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC 2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC 2418] Bradner, S., Ed., "Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. [RFC 3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC 1790] 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. [RFC 2339] IETF & 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.
BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.