RFC 8179

Intellectual Property Rights in IETF Technology

📅 published May 2017, from ietf

Intellectual Property Rights in IETF Technology ✨

Part 1 of 7 🎀

Okay bestie, this is RFC 8179 💖, a Best Current Practice (that's BCP 79 on the label) from the Internet Engineering Task Force (IETF). It came out in May 2017 and was written by S. Bradner (Harvard University) and J. Contreras (University of Utah). The ISSN is 2070-1721. It obsoletes RFCs 3979 and 4879 and updates RFC 2026, so it's basically the new main character of IPR policy 👑.

Abstract

Okay so the IETF has rules about Intellectual Property Rights (IPR), like patent rights, for the tech we develop here 🦋. The whole point is that working groups and participants get as much info as possible about any IPR constraints on a technical proposal, as early as possible in the process 🧚. These policies are meant to help the Internet community and the public at large, while still respecting the legit rights of IPR holders 🫶.

This document lays out the IETF policies on IPR related to technology worked on within the IETF, and it explains the goals those policies are built to hit 🌈. It updates RFC 2026 and, together with RFC 5378, replaces Section 10 of RFC 2026 🔥. It also obsoletes RFCs 3979 and 4879 💅.

Status of This Memo

This memo documents an Internet Best Current Practice 🌸.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has gotten public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on BCPs, check out Section 2 of RFC 7841 ✨.

For info on the current status of this document, any errata, and how to send feedback on it, go to http://www.rfc-editor.org/info/rfc8179 🍓.

Copyright (c) 2017 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 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these carefully, because they describe your rights and restrictions with respect to this document 🙈. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 🎀.

Table of Contents

1. Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
3. Participation in the IETF  . . . . . . . . . . . . . . . . . .  8
3.1. General Policy   . . . . . . . . . . . . . . . . . . . . . .  8
3.2. Rights and Permissions in Contributions. . . . . . . . . . .  8
3.3. Obligations on Participants  . . . . . . . . . . . . . . . .  8
4.  Actions for Documents for Which IPR Disclosure(s)
    Have Been Received  . . . . . . . . . . . . . . . . . . . . .  8
5. IPR Disclosures  . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Who Must Make an IPR Disclosure? . . . . . . . . . . . . . . 10
5.1.1.  A Contributor's IPR in His or Her Contribution  . . . . . 10
5.1.2. An IETF Participant's IPR in Contributions by Others   . . 10
5.1.3. IPR of Others  . . . . . . . . . . . . . . . . . . . . . . 10
5.2. The Timing of Providing Disclosure . . . . . . . . . . . . . 11
5.2.1. Timing of Disclosure under Section 5.1.1 . . . . . . . . . 11
5.2.2. Timing of Disclosure under Section 5.1.2 . . . . . . . . . 11
5.2.3. Timing of Disclosure by ADs and Others . . . . . . . . . . 12
5.3. How Must an IPR Disclosure be Made?  . . . . . . . . . . . . 12
5.4. What Must be in an IPR Disclosure? . . . . . . . . . . . . . 12
5.4.1. Content of IPR Disclosures . . . . . . . . . . . . . . . . 12
5.4.2. Updating IPR Disclosures . . . . . . . . . . . . . . . . . 12
5.4.3. Blanket IPR Statements . . . . . . . . . . . . . . . . . . 13
5.5. Licensing Information in an IPR Disclosure . . . . . . . . . 14
5.6. Level of Control over IPR Requiring Disclosure . . . . . . . 15
5.7. Disclosures for Oral Contributions . . . . . . . . . . . . . 15
5.8.  General Disclosures . . . . . . . . . . . . . . . . . . . . 15
6. Failure to Disclose  . . . . . . . . . . . . . . . . . . . . . 16
7. Evaluating Alternative Technologies in IETF Working Groups . . 17
8. Change Control for Technologies  . . . . . . . . . . . . . . . 19
9. Licensing Requirements to Advance Standards Track
   IETF Documents . . . . . . . . . . . . . . . . . . . . . . . . 19
10. No IPR Disclosures in IETF Documents  . . . . . . . . . . . . 19
11. Application to Non-IETF Stream Documents  . . . . . . . . . . 19
12. Security Considerations   . . . . . . . . . . . . . . . . . . 20
13. Changes since RFCs 3979 and 4879  . . . . . . . . . . . . . . 20
14. References  . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References  . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References  . . . . . . . . . . . . . . . . . . 26
Editors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 26

1. Definitions ✨

okay bestie, these are the definitions for the terms used in this doc 💅 Other terms, like "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. "Blanket IPR Statement" or "Blanket Disclosure": see Section 5.4.3. 🦋

c. "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 policy. 💖

Such statements include oral statements, as well as written and electronic communications, which are addressed to:

  • any IETF plenary session,
  • any IETF working group (WG; see BCP 25) or portion thereof or any WG chair on behalf of the relevant WG,
  • any IETF "birds of a feather" (BOF) session or portion thereof,
  • WG design teams (see BCP 25) and other design teams that intend to deliver an output to IETF, or portions thereof,
  • the IESG, or any member thereof on behalf of the IESG,
  • the IAB, or any member thereof on behalf of the IAB,
  • 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,
  • 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. And while the IETF's IPR rules apply in all cases, not all presentations represent a Contribution. For example, many invited plenary, area-meeting, or research group presentations will cover useful background material, such as general discussions of existing Internet technology and products, and will not be a Contribution. (Some such presentations can represent a Contribution as well, of course). Throughout this document, the term "written Contribution" is used. For purposes of this document, "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, email messages, discussion board postings, slide presentations, text messages, instant messages, and transcriptions of oral statements. 📝

d. "Contributor": an individual submitting a Contribution 🫶

e. "Covers" or "Covered": 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. ⚖️

f. "General Disclosure": see Section 5.8. 🌸

g. "IETF": In the context of this document, the IETF includes all individuals who participate in meetings, working groups, mailing lists, functions, and other activities that 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. 🧚

h. "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 [RFC4844]. 📚

i. "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 and Experimental documents (see Section 4 of [RFC2026]). 🍓

j. "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. 👑

k. "Implementing Technology": a technology that implements an IETF specification or standard. ⭐

l. "Internet-Draft": a document used in the IETF and RFC Editor processes, as described in Section 2.2 of [RFC2026]. 🦋

m. "Participating in an IETF discussion or activity": 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. 🎀

m. "Reasonably and personally known": 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. 🙈

o. "RFC": the basic publication series for the IETF. RFCs are published by the RFC Editor. (See Section 2.1 of [RFC2026].) 💜

2. Introduction 🌷

okay so the IETF's policies about Intellectual Property Rights (IPR), like patent rights, for technologies developed in the IETF are designed to make sure IETF working groups and Participants know as much as possible about any IPR constraints on a technical proposal, as early as possible in the development process 🧠 The policies are meant to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document details the IETF policies concerning IPR related to technology worked on within the IETF, and it also describes the objectives those policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFC 3979 and RFC 4879. 🔥

There are three basic principles regarding how the IETF deals with claims of Intellectual Property Rights (originally outlined in Section 10 of [RFC2026]):

(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 a 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 any 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 Participant that are reasonably and personally known to the Participant. No patent search is required. 🫶

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 the IETF and IETF Participants to publish and create derivative works of those Contributions. This document is not intended to address 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 reasonably 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 the 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 the 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. Okay so the IESG, IAB, ISOC, and IETF Trust are basically saying "not our problem" 💅 They disclaim any responsibility for identifying the existence of IPR, disclosed or otherwise, or for evaluating whether it applies to any IETF technology, specification, or standard. They also won't take a position on the validity or scope of any such IPR 🫶

B. When the IETF Secretariat gets a notification under Section 5.1.3 about non-participant IPR that potentially Covers a technology under discussion at IETF, or that is the subject of an IETF Document, they shall promptly publish that notification 📢 and will ask the identified third party to make an IPR disclosure under the rules in Section 5.

C. When an IPR disclosure has been made as Section 5 describes, the IETF Secretariat may ask the purported holder of that IPR for a written assurance. The assurance says that once the IESG approves the relevant IETF specification(s) for publication as one or more RFCs, all persons will be able to get the right to implement, use, distribute, and exercise other rights with respect to Implementing Technology under one of the licensing options in Section 5.5.A below. The only exception is if the IETF Secretariat has already received a statement picking one of the Section 5.5.A licensing options 🎀 The working group proposing the technology that the IPR is disclosed for can help the IETF Secretariat with this.

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 the results into account when evaluating the technology, and the IESG may defer approval when a delay might help get those assurances. The IETF Secretariat will still record the results and make them available online 🌈

D. The IESG will not decide that the terms for using an Implementing Technology (for example, the assurance of reasonable and non-discriminatory terms) have been fulfilled in practice 🙅‍♀️ Instead it applies the normal requirements for advancing Internet Standards (see RFC 6410). If the two unrelated implementations of the specification that are required to advance from Proposed Standard to Internet Standard were made by different organizations or individuals, or if the "significant implementation and successful operational experience" required to advance from Proposed Standard to Internet Standard has been achieved, the IESG will presume that the terms are reasonable and to some degree non-discriminatory. Note that this also applies when 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, which fits the general IETF philosophy that Participants 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.

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 that the Contributor believes Covers or may ultimately Cover his or her written Contribution, which is intended to be used as an input into the IETF Standards Process, must make a disclosure under Section 5. The same goes if the Contributor reasonably and personally knows that his or her employer or sponsor may assert that IPR against Implementing Technologies based on that written Contribution 🔥

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 the Participant reasonably and personally knows of IPR meeting the conditions of Section 5.6 that the Participant believes Covers or may ultimately Cover that Contribution, then the Participant must make a disclosure under Section 5. The same applies if the Participant reasonably and personally knows that his or her employer or sponsor may assert that IPR against Implementing Technologies based on that written Contribution 🌸

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 that person isn't required to disclose it under Section 5.1.1 or 5.1.2 above, they're still encouraged to file an IPR disclosure as described in Section 5.3 below. The disclosure should be filed as soon as reasonably possible after the person realizes that the IPR may Cover a Contribution 🧁

Voluntary disclosures can happen in a few situations: (a) the IPR doesn't meet the criteria in Section 5.6 because it isn't owned or controlled by an IETF Participant or his or her sponsor or employer (this is called third party IPR), (b) an individual isn't required to disclose IPR meeting the requirements of Section 5.6 because that individual isn't Participating in the relevant IETF activity, or (c) the IPR Covers technology that doesn't meet the criteria for a Contribution hereunder yet (for example, it was disclosed in an informal or other non-IETF setting) 🍓

5.2. The Timing of Disclosure ⏰

Timely IPR disclosure matters because working groups need as much information as they can get while they're evaluating alternative solutions 💜

5.2.1. Timing of Disclosure under Section 5.1.1

A. The IPR disclosure required under 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. For when updates are needed to an existing disclosure, see Section 5.4.2 ✍️

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 under 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 may Cover technology that will be or has been incorporated into a Contribution, or that is being seriously discussed in a working group, are strongly encouraged to make a preliminary IPR disclosure. That disclosure should be made as soon as reasonably possible after they realize it, rather than waiting until the Contribution is actually made 🌟

If an IETF Participant first learns of IPR meeting the conditions of Section 5.6 that may Cover 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 is 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 and Others

Because of the nature of their office, IETF Area Directors or the persons assisting them may become aware of Contributions late in the process (for example at IETF Last Call or during IESG review). In those cases, they can't 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 before publication as an RFC 🧹

5.4. What Must Be in an IPR Disclosure? 📋

5.4.1. Content of IPR Disclosures

An IPR disclosure must include the following information, to the extent reasonably available to the discloser: (a) the numbers of any issued patents or published patent applications (or an indication that the disclosure is based on unpublished patent applications), (b) the name(s) of the inventor(s) (for issued patents and published patent applications), (c) the specific IETF Document(s) or activity affected, and (d) if the IETF Document is an Internet-Draft, its specific version number 🥹 Also, if it isn't reasonably apparent which part of an IETF Document is allegedly Covered by disclosed IPR, it's helpful if the discloser points out the sections of the IETF Document that are allegedly Covered by that IPR 💅

5.4.2. Updating IPR Disclosures ✨

Okay bestie, the big thing to remember is that Internet-Drafts glow up over time 🌸 text can get added or removed as they evolve, so it is recommended that disclosers keep that in mind when they write their disclosure text 💅

A. Unless sufficient information to identify the issued patent was disclosed when the patent application was disclosed, an IPR disclosure must be updated or a new disclosure made promptly after any of the following happens: (1) a previously unpublished patent application gets published, (2) a patent application gets abandoned, (3) a patent gets issued on a previously disclosed patent application, or (4) there's 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 that application. Also, IPR disclosures against a particular Contribution are assumed to be inherited by revisions of the Contribution and by any RFCs published from the Contribution, unless the disclosure has been updated or withdrawn. It's giving continuity 🦋

B. If an IPR holder files patent applications in additional countries which refer to, and whose claims 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 because of filing those applications or because of patents being issued on them. No extra paperwork just for copycat filings, periodt 🎀

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 an update to an existing IPR disclosure. If such an update is submitted by someone other than the submitter of the original IPR disclosure (as identified by name and email address), then the IETF Secretariat shall attempt to contact the original submitter to verify the update. If the original submitter says the proposed update is valid, the Secretariat will update the IPR disclosure accordingly. If the original submitter says the proposed update is not valid, the IETF Secretariat will not update the IPR disclosure. If the original submitter doesn't respond after the IETF Secretariat has made three separate inquiries, and at least 30 days have passed since the initial inquiry, then the IETF Secretariat will tell the person who proposed the update that it wasn't validated, and that they 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 that evidence is satisfactory to the IETF Secretariat, after consulting with the IETF legal counsel, then the IETF Secretariat will make the requested update. If it isn't satisfactory, the IETF Secretariat will not make the requested update. This is a lot of checks, but it keeps things honest 🫶

5.4.3. Blanket IPR Statements 🌈

Here's the tea: the requirement to make an IPR disclosure is not satisfied by submitting a blanket statement saying IPR may exist on every Contribution or on a general category of Contributions. The reason is that the whole point of the disclosure requirement is to share information about specific IPR against specific technology under discussion in the IETF, so vague vibes just don't cut it 💀 The requirement also isn't 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 that same reason.

That said, the requirement for an IPR disclosure is satisfied by a blanket statement of the IPR discloser's commitment to license all of its IPR that meets 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. Main character energy in the best way 👑

5.5. Licensing Information in an IPR Disclosure 🔥

A. Since IPR disclosures get used by IETF working groups while they evaluate alternative technical solutions, it's super helpful if an IPR disclosure includes licensing information in case Implementing Technologies require a license. Specifically, it helps to say whether, once the IESG approves the relevant IETF specification(s) for publication as an RFC, all persons will be able to get 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 with reasonable and non-discriminatory terms and conditions, including a reasonable royalty or other payment, or c) without needing a license from the IPR holder (for example, a covenant not to sue, with or without defensive suspension, as described in Section 7). 🦋

B. Including a licensing declaration isn't mandatory, but it's encouraged so working groups have as much info as possible while they deliberate 🍓 If adding a licensing declaration would significantly delay the disclosure's submission, the discloser may submit an IPR disclosure without one, and then submit a new IPR disclosure once the licensing declaration is ready. IPR disclosures can also voluntarily include text with licensing information, comments, notes, or URLs for other information, and they may include details about specific licensing terms the IPR holder intends to offer to implementers of Implementing Technologies, including maximum royalties.

C. The IETF is likely to rely on licensing declarations and other information in an IPR disclosure, and implementers will make technical, legal, and commercial decisions based on those commitments and that information. So when licensing declarations and other information, comments, notes, or URLs for further information are included in an IPR disclosure, the people making the disclosure agree and acknowledge that the commitments and information in it are irrevocable. They'll attach, to the extent permitted by law, to the associated IPR, and all implementers of Implementing Technologies are justified and entitled to rely on those materials in relation to that IPR, whether or not the IPR holder transfers it to a third party later 🫶 IPR holders who make disclosures with licensing declarations, or who provide such information, comments, notes, or URLs for further information, must make sure those commitments are binding on any transferee of the relevant IPR. That transferee must then use reasonable efforts to make sure the commitments bind any subsequent transferee of the relevant IPR, and so on down the line 🔗

D. Licensing declarations must be made by people who are authorized to make them, as discussed in Section 5.6 of this document. 💜

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 (a) is owned, directly or indirectly, by the individual Contributor or his/her employer or sponsor (if any), or (b) that such persons otherwise have the right to license or assert, or (c) from which such persons derive a direct or indirect pecuniary benefit, or (d) for which an individual Contributor is listed as an inventor on the relevant patent or patent application. Basically, if you've got control, a cut, or your name on it, it counts ✨

5.7. Disclosures for Oral Contributions 🎤

If a Contribution is oral, and it isn't promptly followed by a written disclosure of the same material, and if that oral Contribution would have been subject to a requirement that an IPR Disclosure be made had it been written, then the Contributor must accompany the oral Contribution with either an oral declaration that they're aware of relevant IPR, in as much detail as reasonably possible, or an IPR Declaration with respect to that oral Contribution that otherwise complies with the provisions of Sections 5.1 to 5.6 above. Say it out loud or write it down, no skipping 🙈

5.8. General Disclosures 📣

As described in Section 5.3, the IETF will make available a public facility (for example, a web page and associated database) for posting IPR disclosures that conform with the disclosure requirements of this policy. The IETF may also make available a public facility for posting other IPR-related information and disclosures that don't satisfy the requirements of this policy but may still be informative and relevant to the IETF ("General Disclosures"). General Disclosures may include, among other things, "blanket disclosures" that don't contain a royalty-free licensing commitment as described in Section 5.4.3, disclosures of IPR that don't identify the specific IETF Documents Covered by the disclosed IPR, and licensing statements or commitments that apply generally and not to specific IPR disclosures. All of this info can be really helpful to the IETF community, and sharing it 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 doesn't meet the requirements of this policy, the IETF may choose to post the non-conforming disclosure as a General Disclosure, so the community gets as much information as possible. That doesn't 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 aren't relevant to IETF activities, that are (or are suspected of being) defamatory, false, misleading, or in violation of privacy or other applicable laws or regulations, or that are in a format unsuitable for posting on the IETF facility designated for General Disclosures. No drama, just rules 💅

6. Failure to Disclose ✨

okay so, there might be times when people aren't allowed by their employers (or other stuff) to say that patent applications or other IPR even exist, or what's in them. 🥺 totally understandable, but here's the deal: disclosure is required for anyone making a Contribution or Participating in IETF activities. So if you're not willing or able to disclose IPR for that reason (or any other reason), you MUST NOT contribute to or participate in IETF activities about technologies you reasonably and personally know may be Covered by IPR you won't disclose. 🙅‍♀️ The only exception is if you know your employer or sponsor will make the required disclosures for you. 💖

Contributing to or Participating in IETF activities about a technology without making required IPR disclosures is a violation of IETF policy. 🚫 It's giving rule-break, bestie. 💀

Now, on top of whatever remedies or defenses implementers and others might have under the law for a violation like this (e.g., rendering the relevant IPR unenforceable 👀), sanctions are also available through the normal IETF processes for handling disruptions to IETF work. 🔥 If you want the details on the sanctions defined in various existing Best Current Practice documents, check out [RFC6701]. 🦋

7. Evaluating Alternative Technologies in IETF Working Groups 🌈

okay this one is my fave tbh 😭 so in general, IETF working groups prefer technologies with no known IPR claims or, if there are claims against a technology, an offer of royalty-free licensing. 🎀 BUT, to solve a given technical problem, working groups have the discretion to adopt a technology with IPR claims made against it if they feel it's superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. ✨ To help with this, it's super helpful for IPR claimants to declare, in their IPR Declarations, the terms (if any) on which they're willing to license their IPR Covering the relevant IETF Documents. 💅

A. When adopting new technologies, participants in an IETF working group are expected to evaluate all the relevant tradeoffs from their perspective. 🧠 Most of the time it's purely about technical excellence, but IPR considerations may also affect the evaluation, and specific licensing terms may affect how participants feel about adopting a particular technology. 🤔

B. The IETF has no official preference among different licensing terms beyond what was stated at the beginning of this section. 🙌 Still, for info, and to help participants understand what license conditions may imply, here are some general observations about common types of conditions. The following paragraphs are provided for information only. ℹ️

C. When there's no commitment to license patents covering the technology, that creates uncertainty, and that's obviously concerning. 😬 Those concerns don't exist when there IS a commitment to license, but the license terms can still differ a LOT. 💸 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, possibly conditional on reciprocity. 🫶 Open source projects, for instance, often prefer the latter two. 🌸 Just note that licenses often come with complex terms that have to be evaluated in detail, so this crude classification may not be enough for a proper evaluation. 🙈 For instance, licenses may also include reciprocity and defensive suspension requirements that need careful evaluation. 🔍

D. The level of use of a technology against which IPR is disclosed is also a big factor when weighing IPR encumbrances and 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. 🍓

E. IETF working groups and IETF areas may, however, adopt stricter requirements in specific cases. 🛡️ For instance, the IETF Security Area has adopted stricter requirements for some security technologies. It's become common to have a mandatory-to-implement security technology in IETF technology specifications, so that there's at least one common security technology in all implementations of such a specification that can be used in all cases. 🔐 This doesn't stop a specification from including other security technologies, whose use 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 of this principle if there's a very good reason to do so and that reason is documented and agreed to through IETF consensus. 📝 This limitation doesn't extend to other security technologies in the same specification if they aren't listed as mandatory to implement. 💜

F. It's also worth noting that the absence of IPR disclosures at any given time is NOT the same thing as knowing 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 is relevant in their patent portfolios, can make IPR disclosures at any time. ⏰

G. 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. 🙅‍♀️ The IETF can make no actual determination of validity, enforceability, or applicability of any particular IPR, but it's reasonable that individuals in a working group or the IESG will take their own views of those things into account when evaluating alternative technologies. 🧐

8. Change Control for Technologies 🦄

The IETF MUST have change control over the technology described in any Standards Track IETF Documents, so it can fix problems that may be discovered or produce other derivative works. 🛠️

Sometimes the developer of patented or otherwise controlled technology decides to hand over to the IETF the right to evolve the technology (a.k.a., "change control"). 🤝 Making that agreement between the IETF and the developer work 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 🚀

Section 2.2 of RFC 6410 [RFC6410] 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 online web page <https://www.ietf.org/ipr/> to get a full list of IPR disclosures received by the IETF concerning any Contribution. 🌐

11. Application to Non-IETF Stream Documents 🌊

This document was developed for the benefit and use of the IETF community. 💜 So the rules set out here apply to all Contributions and IETF Documents that are in the "IETF Document Stream" as defined in Section 5.1.1 of [RFC4844] (i.e., those that are contributed, developed, edited, and published as part of the IETF Standards Process). 🎀

The rules for documents in Alternate Streams are set by the managers of those streams (currently the Internet Architecture Board (IAB), Internet Research Steering Group (IRSG), and Independent Submission Editor, as specified in [RFC4844]). 👑 These managers may choose, through their own internal processes, to apply this document to documents contributed to them for development, editing, and publication in their respective Alternate Streams. 🌈 If an Alternate Stream manager adopts this document, they MUST do so in a way that is public and notifies their document Contributors that this document applies to their Alternate Streams. 📣 In that case, each occurrence of the terms "Contribution" and "IETF Document" in this document SHALL be read to mean a contribution or document in that Alternate Stream, as the case may be. 🧩 It would be advisable for those managers to consider adapting the definition of "Contribution" and other provisions in this document to suit their particular needs. 🛠️

12. Security Considerations 🔐

This document relates to the 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 RFCs 3979 and 4879 ✨

okay bestie, RFC 3979 got a full glow-up to make this document, and this section is the "what actually changed" recap 💅 It doesn't walk through the reorganization. The changes are listed from this document's point of view, with a pointer back to the RFC 3979 section where that helps. It's just an informational summary of Sections 1-12, and it is not official IETF policy, so please don't quote it as one 🙈 If anything here disagrees with Sections 1-12, those win, no debate.

  • Boilerplate: The boilerplate that used to live in Section 5 of RFC 3979 moved to the Trust Legal Provisions back in 2009, so the boilerplate requirements got deleted from this doc 📜
  • 1 - Definitions
    • 1.a - "Alternate Stream" definition (new): Added so the IRTF, IAB, and Independent Submission streams can adopt and use BCP 79 more easily 🌈
    • 1.c - "Contribution" (was 1.c):
      • "IETF" got removed so other Streams can adopt this policy more easily.
      • "intended to affect the IETF Standards Process" got added. It's needed so information presentations, like plenary guest speakers, don't count as Contributions 🎤
      • BOF, design team, web site, and chat room got added. Contributions can happen in any of these places 💬
    • 1.e - "Covers" (was 1.n): "provisional patent application" got added. This was required to end the confusion over whether provisional applications are included 🦋
    • 1.h - "IETF Documents" (was 1.h): Limited to IETF documents, not Alternate Stream ones ✨
    • 1.i - "IETF Standards Process" (was 1.b): Clarified that Contributions can be made in contexts other than traditional IETF standards development 🌸
    • 1.j - "IPR" (was 1.o): Removed the reference to copyrights, database rights, and data rights. Copyright in IETF Documents and contributions is handled under RFC 5378 and is treated very differently than patents, which are the focus of BCP 79. Data and database rights aren't relevant to IETF standards, and they can't be registered or disclosed the way patents can 🧚
    • 1.l - "Internet-Draft" (was 1.g): Reduced to a reference to RFC 2026, with no extra description, for clarity 💜
    • 1.m - "Participating in an IETF discussion or activity" (new): There were lots of ambiguities over the years, so a new section got added to explain what it means to "participate" in an IETF activity 🫶
    • 1.o - "RFC" (was 1.e): Added a cross-reference to RFC 2026 and removed the textual description of RFC permanence 📖
  • 2 - Introduction: Added text giving an overview of why we have this policy. Cut the earlier discussion of Section 10 of RFC 2026 because it's no longer necessary, and added references to later RFCs about IPR, including RFC 5378 and 6702 🎀
  • 3 - Participation in the IETF (was "Contributions to the IETF"): The focus changed from making Contributions to participation, and the text now explains 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 the Trust Legal Provisions ⚖️
    • 3.3 - Obligations on Participants: Added to make it clear that participating in the IETF obligates the participant to follow IETF rules 👑
  • old 4.A: Removed because it was inconsistent with current and historical practice. All legends in IETF Documents are now handled in the Trust Legal Provisions 🙃
  • 4.A - "The IESG, IAB...": Added IAB, ISOC, and the IETF Trust to the disclaimer 🌷
  • 4.B - "When the IETF Secretariat...": Added a description of the current procedure for publishing third-party IPR disclosures 📮
  • 4.C - "When an IPR disclosure...": Updated to match current practice and roles, like the Secretariat instead of the IETF Exec Dir 🔥
  • 4.D - Determination of Provision of Reasonable and Non-discriminatory Terms (was Section 4.1): Various edits to this paragraph to reflect the current process for advancing standards 🍓
  • old 5: Deleted because it wasn't needed 🗑️
  • 5.1.1 - Contributor's IPR in His or Her Contribution (was Section 6.1.1): Limits the disclosure obligation to written Contributions intended to be used as inputs to the IETF Standards Process. Oral disclosures are now covered in Section 5.7 🎙️
  • 5.1.2 - An IETF Participant's IPR in Contributions by Others (was Section 6.1.2): Revised to match Section 5.1.1 above 🫧
  • 5.1.3 - Voluntary IPR Disclosures (was Section 6.1.3): Fixes the procedures for making voluntary IPR disclosures and adds examples of when they may be appropriate. On top of IPR of others, voluntary disclosures are encouraged when an IETF Participant is aware of its own IPR that covers IETF work it isn't actively participating in, and when the technology is disclosed somewhere other than an IETF setting 💖
  • 5.2.1 - Timing of Disclosure under Section 5.1.1 (was Section 6.2.1): The trigger for disclosure changed from publication of a Contribution in an I-D to "submitted or made". A lengthy example about updates got deleted in favour of a cross-reference to Section 5.4.2 for updates ⏰
  • 5.2.2 - Timing of Disclosure under Section 5.1.2 (was Section 6.2.2): Corresponding changes made to match Section 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 on the prohibition against including IPR information directly in IETF Documents 🚫
  • 5.4.1 - Content of IPR Disclosures (was Section 6.4.1): Added a requirement to disclose the names of inventors. Knowing the inventor's name makes it more likely that IETF Participants will recognize whether that inventor is a Participant and which IETF activities they're in. This is easy for the discloser to provide, and way less annoying for every reader to dig up in patent office records (if they're even available) 🕵️‍♀️
  • 5.4.2 - Updating IPR Disclosures (was Section 6.4.2): Significant revisions and extra detail added about updating IPR disclosures when things happen, like a patent being issued, claims being amended, an employee changing jobs, or an employer acquiring another company 🔄
    • 5.4.2.D: Clarified that additional IPR disclosures aren't needed for foreign counterparts 🌍
  • 5.4.3 - Blanket IPR Statements (was Section 6.4.3): Wording clarified, and "willingness" changed to "commitment". A blanket IPR disclosure that doesn't list specific patent numbers doesn't comply with this policy unless the discloser commits (not just is 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 implementers can rely on them in the future 🔒
  • 5.5.D - "Licensing declarations ..." (new paragraph): Requires that licensing declarations be made by people who are authorized to make them 🪪
  • 5.6 - Level of Control over IPR Requiring Disclosure (was Section 6.6): On top of ownership of IPR, language was added to require disclosure when Participants get a pecuniary benefit from the IPR, or when the individual is a listed inventor. There were also clarifications for situations the earlier version didn't cover 💰
  • 5.7 - Disclosures for Oral Contributions (new): Describes the procedure for oral Contributions. Before this, the statements about oral contributions contradicted each other. Some places said disclosures must be made for oral statements, while others only required disclosures after publication as an I-D. Under the new text, oral statements don't trigger the normal IPR disclosure obligations, because they're inherently imprecise and it's hard to tell when they describe something covered by a patent claim's technical terms. However, if an oral contribution is made and no written contribution follows, the oral discloser must either make a concurrent oral IPR disclosure or file a formal written disclosure 🗣️
  • 5.8 - General Disclosures (new): Describes the IETF's public disclosure feature, which lets anyone make an IPR disclosure, whether or not they're an IETF Participant. The feature has been running for years, and this language describes how it works now 🌐
  • 6 - Failure to Disclose (was Section 7): Technical and clarity corrections, plus new language describing possible remedies for failing to disclose IPR under IETF rules, including IESG actions described in RFC 6701 🚨
  • 7 - Evaluating Alternative Technologies in IETF Working Groups (was Section 8):
    • Paragraph 1: Minor wording changes for clarity ✏️
    • Paragraphs 2-5 (new): Cover the considerations IETF WGs make when evaluating patent and licensing disclosures about IETF standards 🧐
    • Paragraph 6 - security technologies (new): Makes clear that security is only one example of stricter requirements. It also requires that a violation of the requirements for royalty-free licensing in the security area can only be made with IETF consensus 🔐
    • Paragraphs 7-8 (were paragraphs 3-4): Wording changes for clarity 💫
  • 9 - Licensing Requirements to Advance Standards Track IETF Documents (was Section 10): Wording updated to reflect RFC 6410 🛤️
  • 10 - No IPR Disclosures in IETF Documents (was Section 11): Wording simplified to refer to Section 5 🫶
  • 11 - Application to Non-IETF Stream Documents (new): Adds procedures for Alternate Stream managers (IAB, IRTF, Independent Submission) to adopt these rules and procedures. The copyright language from the Trust Legal Provisions was borrowed and adapted. Each Alternate Stream (Independent Submission, IRTF, and IAB) would need to take some action, preferably issuing an RFC, to adopt BCP 79 for its stream. That worked out pretty smoothly for copyright already, so fingers crossed 🤞

14. References ✨

14.1. Normative References 📚

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
          3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
          <http://www.rfc-editor.org/info/rfc2026>.

[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
          the IETF Standards Process", BCP 11, RFC 2028,
          DOI 10.17487/RFC2028, October 1996,
          <http://www.rfc-editor.org/info/rfc2028>.

[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC
          Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
          July 2007, <http://www.rfc-editor.org/info/rfc4844>.

[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the
          Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
          DOI 10.17487/RFC6410, October 2011,
          <http://www.rfc-editor.org/info/rfc6410>.

14.2. Informative References 📚

okay so these are the informative refs, bestie 🫶 you don't need them to implement anything, but they're the backstory on the IPR agreements that shaped this whole situation 💅

Editors' Addresses 💌

the editors, the people to contact, all in one spot 🧚

Scott Bradner
15 High St.
Cambridge, MA  02138
United States of America

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
United States of America

Email:  cntreras@gmail.com

(yes, that's how the second email is spelled in the original, typo and all 🙈 we don't touch the facts, bestie)

📦 where this page comes from