rfc.txt | bradner.txt | |||
---|---|---|---|---|
Network Working Group S. Bradner, Ed. | Network Working Group Scott Bradner | |||
Request for Comments: 3979 Harvard University | Internet-Draft Harvard University | |||
Intended status: BCP | ||||
Obsoletes: 3668 | Obsoletes: 3979, 4879 Jorge Contreras | |||
Updates: 2028, 2026 | Updates: 2026 American University | |||
Category: Best Current Practice | Expires: April 11, 2014 October 11, 2013 | |||
Intellectual Property Rights in IETF Technology | Intellectual Property Rights in IETF Technology | |||
draft-bradner-rfc3979bis-06.txt | ||||
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 (2005). | ||||
Abstract | Abstract | |||
The IETF policies about Intellectual Property Rights (IPR), such as | The IETF policies about Intellectual Property Rights (IPR), such as | |||
patent rights, relative to technologies developed in the IETF are | patent rights, relative to technologies developed in the IETF are | |||
designed to ensure that IETF working groups and participants have as | designed to ensure that IETF working groups and participants have as | |||
much information about any IPR constraints on a technical proposal as | much information about any IPR constraints on a technical proposal as | |||
possible. The policies are also intended to benefit the Internet | possible. The policies are intended to benefit the Internet | |||
community and the public at large, while respecting the legitimate | community and the public at large, while respecting the legitimate | |||
rights of IPR holders. This memo details the IETF policies | rights of IPR holders. This memo details the IETF policies | |||
concerning IPR related to technology worked on within the IETF. It | concerning IPR related to technology worked on within the IETF. It | |||
also describes the objectives that the policies are designed to meet. | also describes the objectives that the policies are designed to meet. | |||
This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of | This memo updates RFC 2026 and obsoletes RFC 3979 and RFC 4879. | |||
RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC | ||||
2028, for all purposes, including reference [2] in RFC 2418. | 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 http://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 April 11, 2014. | ||||
Copyright Notice | ||||
Copyright (c) 2012 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 review these documents | ||||
carefully, as 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 are provided without warranty as | ||||
described in the Simplified BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 2 | [tbd] | |||
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 | ||||
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 | ||||
1. Definitions | 1. Definitions | |||
The following definitions are for terms used in the context of this | The following definitions are for terms used in the context of this | |||
document. Other terms, including "IESG," "ISOC," "IAB," and "RFC | document. Other terms, including "IESG," "ISOC," "IAB," and "RFC | |||
Editor," are defined in [RFC2028]. | Editor," are defined in [RFC2028]. | |||
b. "IETF Contribution": any submission to the IETF intended by the | 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]. | ||||
b. "Contribution": any submission to the IETF intended by the | ||||
Contributor for publication as all or part of an Internet-Draft or | Contributor for publication as all or part of an Internet-Draft or | |||
RFC (except for RFC Editor Contributions described below) and any | RFC and any statement made within the context of an IETF activity, | |||
statement made within the context of an IETF activity. Such | in each case that is intended to affect the IETF Standards Process | |||
statements include oral statements in IETF sessions, as well as | or that is related to the activity of an Alternate Stream that has | |||
written and electronic communications made at any time or place, | adopted this definition. | |||
which are addressed to: | ||||
Such statements include oral statements, as well as written and | ||||
electronic communications, which are addressed to: | ||||
o the IETF plenary session, | o the IETF plenary session, | |||
o any IETF working group or portion thereof, | o any IETF working group or portion thereof, | |||
o any IETF "birds of a feather" (BOF) session or portion thereof, | ||||
o any IETF-sanctioned design team or portion thereof, | ||||
o the IESG, or any member thereof on behalf of the IESG, | 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 the IAB or any member thereof on behalf of the IAB, | |||
o any IETF mailing list, including the IETF list itself, any | o any IETF mailing list, web site, chat room or discussion board, | |||
working group or design team list, or any other list | operated by or under the auspices of the IETF, including the | |||
functioning under IETF auspices, | IETF list itself, | |||
o the RFC Editor or the Internet-Drafts function (except for RFC | o the RFC Editor or the Internet-Drafts function. | |||
Editor Contributions described below). | ||||
Statements made outside of an IETF session, mailing list or other | Statements made outside of an IETF session, mailing list or other | |||
function, that are clearly not intended to be input to an IETF | function, or that are clearly not intended to be input to an IETF | |||
activity, group or function, are not IETF Contributions in the | activity, group or function, are not Contributions in the context | |||
context of this document. | 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. | ||||
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 | d. "Covers" or "Covered" mean that a valid claim of a patent or a | |||
patent application in any jurisdiction or a protected claim, or | patent application (including a provisional patent application) in | |||
any other Intellectual Property Right, would necessarily be | any jurisdiction , or any other Intellectual Property Right, would | |||
infringed by the exercise of a right (e.g., making, using, | necessarily be infringed by the exercise of a right (e.g., making, | |||
selling, importing, distribution, copying, etc.) with respect to | using, selling, importing, distribution, copying, etc.) with | |||
an Implementing Technology. For purposes of this definition, | respect to an Implementing Technology. For purposes of this | |||
"valid claim" means a claim of any unexpired patent or patent | definition, "valid claim" means a claim of any unexpired patent or | |||
application which shall not have been withdrawn, cancelled or | patent application which shall not have been withdrawn, cancelled | |||
disclaimed, nor held invalid by a court of competent jurisdiction | or disclaimed, nor held invalid by a court of competent | |||
in an unappealed or unappealable decision. | jurisdiction in an unappealed or unappealable decision. | |||
e. "IETF": In the context of this document, the IETF includes all | e. "IETF": In the context of this document, the IETF includes all | |||
individuals who participate in meetings, working groups, mailing | individuals who participate in meetings, working groups, mailing | |||
lists, functions and other activities which are organized or | lists, functions and other activities which are organized or | |||
initiated by ISOC, the IESG or the IAB under the general | initiated by ISOC, the IESG or the IAB under the general | |||
designation of the Internet Engineering Task Force or IETF, but | designation of the Internet Engineering Task Force or IETF, but | |||
solely to the extent of such participation. | solely to the extent of such participation. | |||
f. "IETF Documents": RFCs and Internet-Drafts except for Internet- | f. "IETF Documents": RFCs and Internet-Drafts that are published as | |||
Drafts that are RFC Editor Contributions and the RFCs that are | part of the IETF Standards Process. These are also referred to as | |||
published from them. | "IETF Stream Documents" as defined in Section 5.1.1 of RFC 4844. | |||
g. "IETF Standards Process": the activities undertaken by the IETF in | g. "IETF Standards Process": the activities undertaken by the IETF in | |||
any of the settings described in 1(c) below. | 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 patent, copyright, | h. "IPR" or "Intellectual Property Rights": means a patent, utility | |||
utility model, invention registration, database and data rights | model, or similar right that may Cover an Implementing Technology, | |||
that may Cover an Implementing Technology, whether such rights | whether such rights arise from a registration or renewal thereof, | |||
arise from a registration or renewal thereof, or an application | or an application therefore, in each case anywhere in the world. | |||
therefore, in each case anywhere in the world. | ||||
See [RFC5378] for a discussion of Trademarks. | ||||
i. "Implementing Technology": means a technology that implements an | i. "Implementing Technology": means a technology that implements an | |||
IETF specification or standard. | IETF specification or standard. | |||
j. "Internet-Draft": temporary documents used in the IETF and RFC | j. "Internet-Draft": a temporary document used in the IETF and RFC | |||
Editor processes. Internet-Drafts are posted on the IETF web site | Editor processes, as described in [RFC2026]. | |||
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. | ||||
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 [RFC2026] Sections 2.2 and 8) | ||||
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. "Participating in an IETF discussion or activity": means making a | |||
k. "Contributor": an individual submitting a Contribution | 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 or area. | ||||
l. "Reasonably and personally known": means something an individual | l. "Reasonably and personally known": means something an individual | |||
knows personally or, because of the job the individual holds, | knows personally or, because of the job the individual holds, | |||
would reasonably be expected to know. This wording is used to | would reasonably be expected to know. This wording is used to | |||
indicate that an organization cannot purposely keep an individual | indicate that an organization cannot purposely keep an individual | |||
in the dark about patents or patent applications just to avoid the | in the dark about patents or patent applications just to avoid the | |||
disclosure requirement. But this requirement should not be | disclosure requirement. But this requirement should not be | |||
interpreted as requiring the IETF Contributor or participant (or | interpreted as requiring the IETF Contributor or participant (or | |||
his or her represented organization, if any) to perform a patent | his or her represented organization, if any) to perform a patent | |||
search to find applicable IPR. | search to find applicable IPR. | |||
m. "RFC": the basic publication series for the IETF. RFCs are | m. "RFC": the basic publication series for the IETF. RFCs are | |||
published by the RFC Editor and once published are never modified. | published by the RFC Editor and once published are never modified. | |||
(See [RFC2026] Section 2.1) | (See [RFC2026] 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. | ||||
2. Introduction | 2. Introduction | |||
In the years since RFC 2026 was published there have been a number of | The IETF policies about Intellectual Property Rights (IPR), such as | |||
times when the exact intent of Section 10, the section which deals | patent rights, relative to technologies developed in the IETF are | |||
with IPR disclosures has been the subject of vigorous debate within | designed to ensure that IETF working groups and participants have as | |||
the IETF community. This is because it is becoming increasingly | much information about any IPR constraints on a technical proposal as | |||
common for IETF working groups to have to deal with claims of | possible. The policies are intended to benefit the Internet | |||
Intellectual Property Rights (IPR), such as patent rights, with | community and the public at large, while respecting the legitimate | |||
regards to technology under discussion in working groups. The aim of | rights of IPR holders. This memo details the IETF policies | |||
this document is to clarify various ambiguities in Section 10 of | concerning IPR related to technology worked on within the IETF. It | |||
[RFC2026] that led to these debates and to amplify the policy in | also describes the objectives that the policies are designed to meet. | |||
order to clarify what the IETF is, or should be, doing. | This memo updates RFC 2026 [RFC2026] and obsoletes RFC 3979 [RFC3979] | |||
and RFC 4879 [RFC4879]. | ||||
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 | Section 1 defines the terms used in this document. Sections 3 | |||
5 of this document address the intellectual property issues | through 11 set forth the IETF's policies and procedures relating to | |||
previously addressed by Section 10 of RFC 2026. Sections 6 thru 12 | IPR. Section 13 lists the changes between this document and RFCs | |||
then explain the rationale for these provisions, including some of | 3979 and 4879. A separate document [RFC5378] deals with rights (such | |||
the clarifications that have been made since the adoption of RFC | as copyrights and Trademarks) in Contributions, including the right | |||
2026. The rules and procedures set out in this document are not | of IETF and its participants to publish and create derivative works | |||
intended to modify or alter the IETF's current policy toward IPR in | of those Contributions. This document is not intended to address | |||
the context of the IETF Standards Process. They are intended to | those issues. See RFC 6702 [RFC6702] for a discussion of "Promoting | |||
clarify and fill in procedural gaps. | Compliance with Intellectual Property Rights (IPR) Disclosure Rules". | |||
/ This document is not intended as legal advice. Readers are advised | / This document is not intended as legal advice. Readers are advised | |||
to consult their own legal advisors if they would like a legal | to consult their own legal advisors if they would like a legal | |||
interpretation of their rights or the rights of the IETF in any | interpretation of their rights or the rights of the IETF in any | |||
Contributions they make. | Contributions they make. | |||
A companion document [RFC3978] 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. | ||||
3. Contributions to the IETF | 3. Contributions to the IETF | |||
3.1. General Policy | 3.1. General Policy | |||
In all matters of Intellectual Property Rights, the intent is to | In all matters relating to Intellectual Property Rights, the intent | |||
benefit the Internet community and the public at large, while | is to benefit the Internet community and the public at large, while | |||
respecting the legitimate rights of others. | respecting the legitimate rights of others. | |||
3.2. Rights and Permissions | 3.2. Rights and Permissions | |||
3.2.1. All Contributions | ||||
By submission of a Contribution, each person actually submitting the | By submission of a Contribution, each person actually submitting the | |||
Contribution, and each named co-Contributor, is deemed to agree to | Contribution, and each named co-Contributor, is deemed to agree to | |||
the following terms and conditions, on his or her own behalf, and on | the following terms and conditions, on his or her own behalf, and on | |||
behalf of the organizations the Contributor represents or is | behalf of the organizations the Contributor represents or is | |||
sponsored by (if any) when submitting the Contribution. | sponsored by (if any) when submitting the Contribution. | |||
A. The Contributor represents that he or she has made or will | A. The Contributor represents that he or she has made or will | |||
promptly make all disclosures required by Section 6.1.1 of this | promptly make all disclosures required by Section 5.1.1 of this | |||
document. | document. | |||
B. The Contributor represents that there are no limits to the | B. The Contributor represents that there are no limits to the | |||
Contributor's ability to make the grants, acknowledgments and | Contributor's ability to make the grants, acknowledgments and | |||
agreements herein that are reasonably and personally known to the | agreements herein that are reasonably and personally known to the | |||
Contributor. | Contributor. | |||
C. If the Contribution is an Internet-Draft, this agreement must be | ||||
acknowledged, by including in the "Status of this Memo" section on | ||||
the first page of the Contribution, the appropriate notices | ||||
described in Section 5 of [RFC3978]. | ||||
4. Actions for Documents for which IPR Disclosure(s) Have Been Received | 4. Actions for Documents for which IPR Disclosure(s) Have Been Received | |||
A. The IESG disclaims any responsibility for identifying the | A. The IESG, IAB, ISOC and IETF Trust disclaim any responsibility for | |||
existence of or for evaluating the applicability of any IPR, | identifying the existence of or for evaluating the applicability | |||
disclosed or otherwise, to any IETF technology, specification or | of any IPR, disclosed or otherwise, to any IETF technology, | |||
standard, and will take no position on the validity or scope of | specification or standard, and will take no position on the | |||
any such IPR claims. | validity or scope of any such IPR. | |||
B. When any Intellectual Property Right is disclosed before | B. When the IETF Secretariat has received a notification under | |||
publication as an RFC, with respect to any technology or | Section 5.1.3 of the existence of non-participant IPR that | |||
specification, described in a Contribution in the manner set | potentially Covers a technology under discussion at IETF or which | |||
forth in Section 6 of this document, the RFC Editor shall ensure | is the subject of an IETF Document, the IETF Secretariat shall | |||
that the document include a note indicating the existence of such | promptly publish such notification and will request that the | |||
claimed Intellectual Property Rights in any RFC published from | identified third party make an IPR disclosure in accordance with | |||
the Contribution. (See Section 5 below.) | the provisions of Section 5. | |||
C. Where Intellectual Property Rights have been disclosed for IETF | ||||
Documents as provided in Section 6 of this document, the IETF | C. When an IPR disclosure has been made as provided in Section 5 of | |||
Executive Director shall request from the discloser of such IPR, | this document, the IETF Secretariat may request from the purported | |||
a written assurance that upon approval by the IESG for | holder of such IPR, a written assurance that upon approval by the | |||
publication as RFCs of the relevant IETF specification(s), all | IESG for publication of the relevant IETF specification(s) as one | |||
persons will be able to obtain the right to implement, use, | or more RFCs, all persons will be able to obtain the right to | |||
distribute and exercise other rights with respect to Implementing | implement, use, distribute and exercise other rights with respect | |||
Technology under one of the licensing options specified in | to Implementing Technology under one of the licensing options | |||
Section 6.5 below unless such a statement has already been | specified in Section 5.5.A below unless such a statement has | |||
submitted. The working group proposing the use of the technology | already been submitted. The working group proposing the use of | |||
with respect to which the Intellectual Property Rights are | the technology with respect to which the Intellectual Property | |||
disclosed may assist the IETF Executive Director in this effort. | Rights are disclosed may assist the IETF Secretariat in this | |||
effort. | ||||
The results of this procedure shall not, in themselves, block | The results of this procedure shall not, in themselves, block | |||
publication of an IETF Document or advancement of an IETF | publication of an IETF Document or advancement of an IETF Document | |||
Document along the standards track. A working group may take | along the standards track. A working group may take into | |||
into consideration the results of this procedure in evaluating | consideration the results of this procedure in evaluating the | |||
the technology, and the IESG may defer approval when a delay may | technology, and the IESG may defer approval when a delay may | |||
facilitate obtaining such assurances. The results will, however, | facilitate obtaining such assurances. The results will, however, | |||
be recorded by the IETF Executive Director, and be made available | be recorded by the IETF Secretariat, and be made available online. | |||
online. | ||||
D. No Determination of Reasonable and Non-discriminatory Terms | ||||
The IESG will not make any explicit determination that the assurance | ||||
of reasonable and non-discriminatory terms or any other 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. If the two unrelated implementations of the | ||||
specification that are required to advance from Proposed Standard to | ||||
Draft Standard have been produced by different organizations or | ||||
individuals, or if the "significant implementation and successful | ||||
operational experience" required to advance from Draft Standard to | ||||
Standard has been achieved, the IESG will presume that the terms are | ||||
reasonable and to some degree non-discriminatory. (See 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. | ||||
5. Notice to be Included in RFCs | ||||
The RFC Editor will ensure that the following notice is present in | ||||
all IETF RFCs and all other RFCs for which an IPR disclosure or | ||||
assertion has been received prior to publication. | ||||
Disclaimer of validity: | ||||
"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 | D. Determination of Provision of Reasonable and Non-discriminatory | |||
any copyrights, patents or patent applications, or other | Terms | |||
proprietary rights that may cover technology that may be required | ||||
to implement this standard. Please address the information to the | ||||
IETF at ietf-ipr@ietf.org." | ||||
6. IPR Disclosures | The IESG will not make any determination that any terms for the | |||
use of an Implementing Technology has been fulfilled in practice. | ||||
This section discusses aspects of obligations associated with IPR | 5. IPR Disclosures | |||
disclosure. | ||||
This document refers to the IETF participant making disclosures, | This document refers to the IETF participant making disclosures, | |||
consistent with the general IETF philosophy that participants in the | consistent with the general IETF philosophy that participants in the | |||
IETF act as individuals. A participant's obligation to make a | IETF act as individuals. A participant's obligation to make a | |||
disclosure is also considered satisfied if the IPR owner or the | disclosure is also considered satisfied if the IPR owner or the | |||
participant's employer or sponsor makes an appropriate disclosure in | participant's employer or sponsor makes an appropriate disclosure in | |||
place of the participant doing so. | place of the participant doing so. | |||
6.1. Who Must Make an IPR Disclosure? | 5.1. Who Must Make an IPR Disclosure? | |||
6.1.1. A Contributor's IPR in his or her Contribution | 5.1.1. A Contributor's IPR in his or her Contribution | |||
Any Contributor who reasonably and personally knows of IPR meeting | Any Contributor who reasonably and personally knows of IPR meeting | |||
the conditions of Section 6.6 which the Contributor believes Covers | the conditions of Section 5.6 which the Contributor believes Covers | |||
or may ultimately Cover his or her Contribution, or which the | or may ultimately Cover his or her written Contribution (other than a | |||
Contributor reasonably and personally knows his or her employer or | Contribution that is not intended to be used as an input into the | |||
sponsor may assert against Implementing Technologies based on such | IETF Standards Process), or which the Contributor reasonably and | |||
Contribution, must make a disclosure in accordance with this Section | personally knows his or her employer or sponsor may assert against | |||
6. | Implementing Technologies based on such written Contribution, must | |||
make a disclosure in accordance with this Section 5. | ||||
This requirement specifically includes Contributions that are made by | ||||
any means including electronic or spoken comments, unless the latter | ||||
are rejected from consideration before a disclosure could reasonably | ||||
be submitted. An IPR discloser is requested to withdraw a previous | ||||
disclosure if a revised Contribution negates the previous IPR | ||||
disclosure, or to amend a previous disclosure if a revised | ||||
Contribution substantially alters the previous disclosure. | ||||
Contributors must disclose IPR meeting the description in this | ||||
section; there are no exceptions to this rule. | ||||
6.1.2. An IETF Participant's IPR in Contributions by Others | 5.1.2. An IETF Participant's IPR in Contributions by Others | |||
Any individual participating in an IETF discussion who reasonably and | Any individual participating in an IETF discussion or activity who | |||
personally knows of IPR meeting the conditions of Section 6.6 which | reasonably and personally knows of IPR meeting the conditions of | |||
the individual believes Covers or may ultimately Cover a Contribution | Section 5.6 which the individual believes Covers or may ultimately | |||
made by another person, or which such IETF participant reasonably and | Cover a written Contribution made by another person, or which such | |||
personally knows his or her employer or sponsor may assert against | IETF participant reasonably and personally knows his or her employer | |||
Implementing Technologies based on such Contribution, must make a | or sponsor may assert against Implementing Technologies based on such | |||
disclosure in accordance with this Section 6. | written Contribution, must make a disclosure in accordance with this | |||
Section 5. | ||||
6.1.3. IPR of Others | 5.1.3. IPR of Others | |||
If a person has information about IPR that may Cover IETF | If any person has information about IPR that may Cover a written | |||
Contributions, but the participant is not required to disclose | Contribution, but such person is not required to disclose such IPR | |||
because they do not meet the criteria in Section 6.6 (e.g., the IPR | because it does not meet the criteria in Section 6.6 (e.g., the IPR | |||
is owned by some other company), such person is encouraged to notify | is not owned or controlled by the person or his or her employer or | |||
the IETF by sending an email message to ietf-ipr@ietf.org. Such a | sponsor, or such person is not an IETF participant), such person is | |||
notice should be sent as soon as reasonably possible after the person | encouraged to file a third party disclosure as described in Section | |||
realizes the connection. | 5.3 below. Such a notice should be filed as soon as reasonably | |||
possible after the IETF participant realizes the connection. | ||||
6.2. The Timing of Providing Disclosure | 5.2. The Timing of Providing Disclosure | |||
Timely IPR disclosure is important because working groups need to | Timely IPR disclosure is important because working groups need to | |||
have as much information as they can while they are evaluating | have as much information as they can while they are evaluating | |||
alternative solutions. | alternative solutions. | |||
6.2.1. Timing of Disclosure Under Section 6.1.1 | 5.2.1. Timing of Disclosure Under Section 5.1.1 | |||
The IPR disclosure required pursuant to section 6.1.1 must be made as | A. The IPR disclosure required pursuant to section 5.1.1 must be made | |||
soon as reasonably possible after the Contribution is published in an | as soon as reasonably possible after the Contribution is submitted | |||
Internet Draft unless the required disclosure is already on file. | or made unless the required disclosure is already on file. For | |||
For example, if the Contribution is an update to a Contribution for | example, if the Contribution is an update to a Contribution for | |||
which an IPR disclosure has already been made and the applicability | which an IPR disclosure has already been made and the | |||
of the disclosure is not changed by the new Contribution, then no new | applicability of the disclosure is not changed by the new | |||
disclosure is required. But if the Contribution is a new one, or is | Contribution, then no new disclosure is required. But if the | |||
one that changes an existing Contribution such that the revised | Contribution is a new one, or is one that changes an existing | |||
Contribution is no longer Covered by the disclosed IPR or would be | Contribution such that the revised Contribution is no longer | |||
Covered by new or different IPR, then a disclosure must be made. | Covered by the disclosed IPR or would be Covered by new or | |||
different IPR, then a disclosure must be made. | ||||
If a Contributor first learns of IPR in its Contribution that meets | B. If a Contributor first learns of IPR in its Contribution that | |||
the conditions of Section 6.6, for example a new patent application | meets the conditions of Section 5.6, for example a new patent | |||
or the discovery of a relevant patent in a patent portfolio, after | application or the discovery of a relevant patent in a patent | |||
the Contribution is published in an Internet-Draft, a disclosure must | portfolio, after the Contribution is published in an Internet- | |||
be made as soon as reasonably possible after the IPR becomes | Draft, a disclosure must be made as soon as reasonably possible | |||
reasonably and personally known to the Contributor. | after the IPR becomes reasonably and personally known to the | |||
Contributor. | ||||
Participants who realize that a Contribution will be or has been | 5.2.2. Timing of Disclosure Under Section5.1.2 | |||
incorporated into a submission to be published in an Internet Draft, | ||||
or is seriously being discussed in a working group, are strongly | ||||
encouraged to make at least a preliminary disclosure. That | ||||
disclosure should be made as soon after coming to the realization as | ||||
reasonably possible, not waiting until the document is actually | ||||
posted or ready for posting. | ||||
6.2.2. Timing of Disclosure Under Section 6.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. | ||||
The IPR disclosure required pursuant to section 6.1.2 must be made as | Participants who realize that IPR meeting the conditions of Section | |||
soon as reasonably possible after the Contribution is published in an | 5.6 will be or has been incorporated into a Contribution, or is | |||
Internet Draft or RFC, unless the required disclosure is already on | seriously being discussed in a working group, are strongly encouraged | |||
file. Participants who realize that the IPR will be or has been | to make a preliminary IPR disclosure. That IPR disclosure should be | |||
incorporated into a submission to be published in an Internet Draft, | made as soon after coming to the realization as reasonably possible, | |||
or is seriously being discussed in a working group, are strongly | not waiting until the Contribution is actually made. | |||
encouraged to make at least a preliminary disclosure. That | ||||
disclosure should be made as soon after coming to the realization as | ||||
reasonably possible, not waiting until the document is actually | ||||
posted or ready for posting. | ||||
If a participant first learns of IPR that meets the conditions of | If an IETF participant first learns of IPR that meets the conditions | |||
Section 6.6 in a Contribution by another party, for example a new | of Section 5.6 in a Contribution by another party, for example a new | |||
patent application or the discovery of a relevant patent in a patent | patent application or the discovery of a relevant patent in a patent | |||
portfolio, after the Contribution was published in an Internet-Draft | portfolio, after the Contribution was made, an IPR disclosure must be | |||
or RFC, a disclosure must be made as soon as reasonably possible | made as soon as reasonably possible after the Contribution or IPR | |||
after the IPR becomes reasonably and personally known to the | becomes reasonably and personally known to the participant. | |||
participant. | ||||
6.3. How Must a Disclosure be Made? | 5.3. How Must an IPR Disclosure be Made? | |||
IPR disclosures are made by following the instructions at | IPR disclosures are made by following the instructions at | |||
http://www.ietf.org/ipr-instructions. | http://www.ietf.org/ipr-instructions. | |||
6.4. What Must be in a Disclosure? | 5.4. What Must be in an IPR Disclosure? Updating IPR Disclosures. | |||
6.4.1. The disclosure must list the numbers of any issued patents or | 5.4.1. What Must be in an IPR Disclosure? | |||
An IPR disclosure must list the numbers of any issued patents or | ||||
published patent applications or indicate that the claim is based on | published patent applications or indicate that the claim is based on | |||
unpublished patent applications. The disclosure must also list the | unpublished patent applications. The IPR disclosure must also list | |||
specific IETF or RFC Editor Document(s) or activity affected. If the | the name(s) of the inventor(s) (with respect to issued patents and | |||
IETF Document is an Internet-Draft, it must be referenced by specific | published patent applications) and the specific IETF Document(s) or | |||
version number. In addition, if the IETF Document includes multiple | activity affected. If the IETF Document is an Internet-Draft, it | |||
parts and it is not reasonably apparent which part of such IETF | must be referenced by specific version number. In addition, if the | |||
Document is alleged to be Covered by the IPR in question, it is | IETF Document includes multiple parts and it is not reasonably | |||
helpful if the discloser identifies the sections of the IETF Document | apparent which part of such IETF Document is alleged to be Covered by | |||
that are alleged to be so Covered. | the IPR in question, the discloser must identify the sections of the | |||
IETF Document that are alleged to be so Covered. | ||||
6.4.2. If a disclosure was made on the basis of a patent application | 5.4.2. Updating IPR Disclosures. | |||
(either published or unpublished), then, if requested to do so by the | ||||
IESG or by a working group chair, the IETF Executive Director can | ||||
request a new disclosure indicating whether any of the following has | ||||
occurred: the publication of a previously unpublished patent | ||||
application, the abandonment of the application and/or the issuance | ||||
of a patent thereon. If the patent has issued, then the new | ||||
disclosure must include the patent number and, if the claims of the | ||||
granted patent differ from those of the application in manner | ||||
material to the relevant Contribution, it is helpful if such a | ||||
disclosure describes any differences in applicability to the | ||||
Contribution. If the patent application was abandoned, then the new | ||||
disclosure must explicitly withdraw any earlier disclosures based on | ||||
the application. | ||||
New or revised disclosures may be made voluntarily at any time. | Claimants 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. | ||||
6.5. What Licensing Information to Detail in a Disclosure | A. An IPR disclosure must be updated or a new disclosure made | |||
promptly after any of the following has occurred: (1) the | ||||
publication of a previously unpublished patent application, | ||||
(unless sufficient information to identify the published | ||||
application was disclosed when the unpublished application was | ||||
disclosed), (2) the abandonment of a patent application | ||||
(3) the issuance of a patent on a previously disclosed patent | ||||
application (unless sufficient information to identify the issued | ||||
patent was disclosed when the patent application was disclosed), | ||||
(4) a material change to the IETF Document covered by the | ||||
Disclosure that causes the Disclosure to be covered by additional | ||||
IPR. If a patent has issued, then the new IPR disclosure must | ||||
include the patent number and, if the claims of the granted patent | ||||
differ from those of the application in manner material to the | ||||
relevant Contribution, the IPR disclosure must describe any | ||||
differences in applicability to the Contribution. 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. | ||||
Since IPR disclosures will be used by IETF working groups during | B. If an IPR holder files patent applications in additional | |||
their evaluation of alternative technical solutions, it is helpful if | countries, the claims of which are substantially identical to the | |||
an IPR disclosure includes information about licensing of the IPR in | claims of a patent or patent application previously disclosed in | |||
case Implementing Technologies require a license. Specifically, it | an IPR disclosure, the IPR holder is not required to make a new or | |||
is helpful to indicate whether, upon approval by the IESG for | updated IPR disclosure as a result of filing such applications or | |||
publication as RFCs of the relevant IETF specification(s), all | the issuance of patents on such applications. | |||
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. | ||||
The inclusion of licensing information in IPR disclosures is not | C. New or revised IPR disclosures may be made voluntarily at any | |||
mandatory but it is encouraged so that the working groups will have | other time, provided that licensing information may only be | |||
as much information as they can during their deliberations. If the | updated in accordance with Section 5.5.C. | |||
inclusion of licensing information in an IPR disclosure would | ||||
significantly delay its submission it is quite reasonable to submit a | ||||
disclosure without licensing information and then submit a new | ||||
disclosure when the licensing information becomes available. | ||||
5.4.3. The requirement for an IPR disclosure is not satisfied by the | D. Any person may submit to IETF an update to an existing IPR | |||
submission of a blanket statement of possible IPR on every | disclosure. If such update is submitted by a person other than | |||
Contribution. This is the case because the aim of the disclosure | the submitter of the original IPR disclosure (as identified by | |||
requirement is to provide information about specific IPR against | name and e-mail address), then the Secretariat shall attempt to | |||
specific technology under discussion in the IETF. The requirement is | contact the original submitter to verify the update. If the | |||
also not satisfied by a blanket statement of willingness to license | original submitter responds that the proposed update is valid, the | |||
all potential IPR under fair and non-discriminatory terms for the | Secretariat will update the IPR disclosure accordingly. If the | |||
same reason. However, the requirement for an IPR disclosure is | original submitter responds that the proposed update is not valid, | |||
satisfied by a blanket statement of the IPR discloser's willingness | the Secretariat will not update the IPR disclosure. If the | |||
to license all of its potential IPR meeting the requirements of | original submitter fails to respond after the Secretariat has made | |||
Section 6.6 (and either Section 6.1.1 or 6.1.2) to implementers of an | three separate inquiries and at least 30 days have elapsed since | |||
IETF specification on a royalty-free basis as long as any other terms | the initial inquiry was made, then the Secretariat will inform the | |||
and conditions are disclosed in the IPR disclosure statement. | 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. | ||||
6.6. When is a Disclosure Required? | 5.4.3. 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. | ||||
IPR disclosures under Sections 6.1.1. and 6.1.2 are required with | 5.5. Licensing Information in an IPR Disclosure | |||
respect to IPR that is owned directly or indirectly, by the | ||||
individual or his/her employer or sponsor (if any) or that such | ||||
persons otherwise have the right to license or assert. | ||||
7. Failure to Disclose | 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 | ||||
(i.e., a covenant not to sue). | ||||
There are cases where individuals are not permitted by their | 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 it is quite reasonable to | ||||
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 | ||||
royalty rates | ||||
C. It is likely that IETF participants will rely on licensing | ||||
declarations and other information that may be contained in an IPR | ||||
disclosure and that they will make technical, legal and commercial | ||||
decisions on the basis of such commitments and information. Thus, | ||||
when licensing declarations and information, comments, notes, or | ||||
URLs for further information are contained in an IPR disclosure, | ||||
such materials shall be deemed irrevocable, and will attach 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 it 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 subsequent | ||||
transferee of the relevant IPR. | ||||
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. | ||||
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 | employers or by other factors to disclose the existence or substance | |||
of patent applications or other IPR. Since disclosure is required | of patent applications or other IPR. Since disclosure is required | |||
for anyone submitting documents or participating in IETF discussions, | for anyone making a Contribution or participating in IETF activities, | |||
a person who does not disclose IPR for this reason, or any other | a person who is not willing or able to disclose IPR for this reason, | |||
reason, must not contribute to or participate in IETF activities with | or any other reason, must not contribute to or participate in IETF | |||
respect to technologies that he or she reasonably and personally | activities with respect to technologies that he or she reasonably and | |||
knows to be Covered by IPR which he or she will not disclose. | personally knows to be Covered by IPR which he or she will not | |||
Contributing to or participating in IETF discussions about a | disclose. | |||
Contributing to or participating in IETF activities about a | ||||
technology without making required IPR disclosures is a violation of | technology without making required IPR disclosures is a violation of | |||
IETF process. | IETF process. | |||
8. Evaluating Alternative Technologies in IETF Working Groups | 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 | ||||
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 | In general, IETF working groups prefer technologies with no known IPR | |||
claims or, for technologies with claims against them, an offer of | claims or, for technologies with claims against them, an offer of | |||
royalty-free licensing. But IETF working groups have the discretion | royalty-free licensing. However, to solve a given technical problem, | |||
to adopt technology with a commitment of fair and non-discriminatory | IETF working groups have the discretion to adopt a technology as to | |||
terms, or even with no licensing commitment, if they feel that this | which IPR claims have been made if they feel that this technology is | |||
technology is superior enough to alternatives with fewer IPR claims | superior enough to alternatives with fewer IPR claims or free | |||
or free licensing to outweigh the potential cost of the licenses. | 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 evaluating the desirability of adopting such technologies, IETF | ||||
working groups generally prefer such terms in the following order | ||||
(from most to least desirable): | ||||
a) commitment not to assert declared IPR; | ||||
b) commitment to license declared IPR on royalty-free terms that are | ||||
otherwise fair, reasonable and non-discriminatory (RAND-z); | ||||
c) commitment to license declared IPR on terms that are fair, | ||||
reasonable and non-discriminatory, and which may bear royalties or | ||||
other financial obligations (FRAND or RAND); | ||||
d) commitment to license, with no constraints on terms; | ||||
e) no commitment to license. | ||||
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. | ||||
It is also important to note that monetary compensation is only one | ||||
of several factors that individuals in WGs and the IESG need to | ||||
consider when analyzing licensing terms contained in IPR disclosures. | ||||
Thus, if particularly onerous non-monetary terms are included in a | ||||
particular disclosure, they may be viewed as less desirable than less | ||||
onerous terms that may bear a higher monetary burden. | ||||
Over the last few years the IETF has adopted stricter requirements | Over the last few years the IETF has adopted stricter requirements | |||
for some security technologies. It has become common to have a | for some security technologies. It has become common to have a | |||
mandatory-to-implement security technology in IETF technology | mandatory-to-implement security technology in IETF technology | |||
specifications. This is to ensure that there will be at least one | specifications. This is to ensure that there will be at least one | |||
common security technology present in all implementations of such a | common security technology present in all implementations of such a | |||
specification that can be used in all cases. This does not limit the | specification that can be used in all cases. This does not limit the | |||
specification from including other security technologies, the use of | specification from including other security technologies, the use of | |||
which could be negotiated between implementations. An IETF consensus | which could be negotiated between implementations. An IETF consensus | |||
has developed that no mandatory-to-implement security technology can | has developed that no mandatory-to-implement security technology can | |||
be specified in an IETF specification unless it has no known IPR | be specified in an IETF specification unless it has no known IPR | |||
claims against it or a royalty-free license is available to | claims against it or a royalty-free license is available to all | |||
implementers of the specification unless there is a very good reason | implementers of the specification unless there is a very good reason | |||
to do so. This limitation does not extend to other security | to do so. This limitation does not extend to other security | |||
technologies in the same specification if they are not listed as | technologies in the same specification if they are not listed as | |||
mandatory-to-implement. | mandatory-to-implement. | |||
It should also be noted that the absence of IPR disclosures is not | It should also be noted that the absence of IPR disclosures at any | |||
the same thing as the knowledge that there will be no IPR claims in | given time is not the same thing as the knowledge that there will be | |||
the future. People or organizations not currently involved in the | 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 | IETF or people or organizations that discover IPR they feel to be | |||
relevant in their patent portfolios can make IPR disclosures at any | relevant in their patent portfolios can make IPR disclosures at any | |||
time. | time and ma, in fact, be required to do so under Section 6. | |||
It should also be noted that the validity and enforceability of any | It should be noted that the validity and enforceability of any IPR | |||
IPR may be challenged for legitimate reasons, and the mere existence | may be challenged for legitimate reasons outside the IETF. The mere | |||
of an IPR disclosure should not automatically be taken to mean that | existence of an IPR disclosure should not automatically be taken to | |||
the disclosed IPR is valid or enforceable. Although the IETF can | mean that the disclosed IPR is valid or enforceable. Although the | |||
make no actual determination of validity, enforceability or | IETF can make no actual determination of validity, enforceability or | |||
applicability of any particular IPR claim, it is reasonable that a | applicability of any particular IPR claim, it is reasonable that a | |||
working group will take into account on their own opinions of the | working group or the IESG will take into account on their own views | |||
validity, enforceability or applicability of Intellectual Property | of the validity, enforceability or applicability of IPR in their | |||
Rights in their evaluation of alternative technologies. | evaluation of alternative technologies. | |||
9. Change Control for Technologies | 8. Change Control for Technologies | |||
The IETF must have change control over the technology described in | The IETF must have change control over the technology described in | |||
any standards track IETF Documents in order to fix problems that may | any standards track IETF Documents in order to fix problems that may | |||
be discovered or to produce other derivative works. | be discovered or to produce other derivative works. | |||
In some cases the developer of patented or otherwise controlled | In some cases the developer of patented or otherwise controlled | |||
technology may decide to hand over to the IETF the right to evolve | technology may decide to hand over to the IETF the right to evolve | |||
the technology (a.k.a., "change control"). The implementation of an | the technology (a.k.a., "change control"). The implementation of an | |||
agreement between the IETF and the developer of the technology can be | agreement between the IETF and the developer of the technology can be | |||
complex. (See [RFC1790] and [RFC2339] for examples.) | complex. (See [RFC1790] and [RFC2339] for examples.) | |||
Note that there is no inherent prohibition against a standards track | Note that there is no inherent prohibition against a standards track | |||
IETF Document making a normative reference to proprietary technology. | IETF Document making a normative reference to proprietary technology. | |||
For example, a number of IETF Standards support proprietary | For example, a number of IETF Standards support proprietary | |||
cryptographic transforms. | cryptographic transforms. | |||
10. Licensing Requirements to Advance Standards Track IETF Documents | 9. Licensing Requirements to Advance Standards Track IETF Documents | |||
RFC 2026 Section 4.1.2 states: "If patented or otherwise controlled | RFC 6410 [RFC6410] Section 2.2 states: "If the technology required to | |||
technology is required for implementation, the separate | implement the specification requires patented or otherwise controlled | |||
implementations must also have resulted from separate exercise of the | technology, then the set of implementations must demonstrate at least | |||
licensing process." A key word in this text is "required." The mere | 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 | existence of disclosed IPR does not necessarily mean that licenses | |||
are actually required in order to implement the technology. Section | are actually required in order to implement the technology. | |||
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. | ||||
11. No IPR Disclosures in IETF Documents | 10. No IPR Disclosures in IETF Documents | |||
IETF and RFC Editor Documents must not contain any mention of | IETF Documents must not contain any mention of specific IPR. All | |||
specific IPR. All specific IPR disclosures must be submitted as | specific IPR disclosures must be submitted as described in Section 5. | |||
described in Section 6. Specific IPR disclosures must not be in the | Readers should always refer to the on-line web page to get a full | |||
affected IETF and RFC Editor Documents because the reader could be | list of IPR disclosures received by the IETF concerning any | |||
misled. The inclusion of a particular IPR disclosure in a document | Contribution. (http://www.ietf.org/ipr/) | |||
could be interpreted to mean that the IETF, IESG, or RFC Editor has | ||||
formed an opinion on the validity, enforceability, or applicability | 11. Application to non-IETF Stream Documents | |||
of the IPR. The reader could also be misled to think that the | ||||
included IPR disclosures are the only IPR disclosures the IETF has | This memo has been developed for the benefit and use of the IETF | |||
received concerning the IETF document. Readers should always refer | community. As such, the rules set forth herein apply to all | |||
to the on-line web page to get a full list of IPR disclosures | Contributions and IETF Documents that are in the "IETF Document | |||
received by the IETF concerning any Contribution. | Stream" as defined in Section 5.1.1 of RFC 4844 (i.e., those that are | |||
(http://www.ietf.org/ipr/) | contributed, developed, edited and published as part of the IETF | |||
Standards Process). The IAB Document Stream, the IRTF Document | ||||
Stream and the Independent Submission Stream, each as defined in | ||||
Section 5.1 of RFC 4844 are referred to collectively herein as | ||||
"Alternate Streams". | ||||
The legal rules that apply to documents in Alternate Streams are | ||||
established by the managers of those Alternate Streams as defined in | ||||
[RFC 4844]. (i.e., the Internet Architecture Board (IAB), Internet | ||||
Research Steering Group (IRSG) and Independent Submission Editor). | ||||
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 | 12. Security Considerations | |||
This memo relates to IETF process, not any particular technology. | This memo relates to IETF process, not any particular technology. | |||
There are security considerations when adopting any technology, | There are security considerations when adopting any technology, | |||
whether IPR-protected or not. A working group should take those | whether IPR-protected or not. A working group should take those | |||
security considerations into account as one part of evaluating the | security considerations into account as one part of evaluating the | |||
technology, just as IPR is one part, but there are no known issues of | technology, just as IPR is one part, but there are no known issues of | |||
security with IPR procedures. | security with IPR procedures. | |||
13. References | 13. Changes Since RFC 3979 and RFC 4879 | |||
13.1. Normative References | [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 | ||||
only if they are filed with claims. | ||||
Inventor names -- added words requiring that inventors be listed | ||||
along with patent numbers. | ||||
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 | ||||
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. | ||||
WG Consideration of Patents -- this is mostly in the existing | ||||
language, but added a sentence saying that WGs should not engage | ||||
in collective licensing negotiation. | ||||
Disclosure of licensing terms is ok -- added a sentence. | ||||
Licensing commitments are irrevocable -- added a paragraph. | ||||
Lurkers -- this is a complicated issue that runs throughout the | ||||
document. At a high level, suggested that lurkers ARE required to | ||||
make IPR disclosures, to avoid a Rambus situation. | ||||
Penalties -- This paragraph outlining possible sanctions the IESG may | ||||
impose should be reconciled with the recent RFC that discusses | ||||
penalties. | ||||
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. | ||||
IETF Exec Dir -- flagged the various places where the IETF Exec | ||||
Director is supposed to do something under this policy. Not sure | ||||
whether these things are getting done today or by whom. Need to | ||||
rationalize and update these procedures based on the current admin | ||||
structure. | ||||
Generally, also tried to cut back some of the historical and | ||||
explanatory text that seemed outdated | ||||
14. References | ||||
14.1. Normative References | ||||
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | |||
3", BCP 9, RFC 2026, October 1996. | 3", BCP 9, RFC 2026, October 1996. | |||
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in | [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in | |||
the IETF Standards Process", BCP 11, RFC 2028, October | the IETF Standards Process", BCP 11, RFC 2028, October 1996. | |||
1996. | ||||
[RFC2418] Bradner, S., "IETF Working Group Guidelines and | [RFC4844] Daigle, L. Ed. and Internet Architecture Board, "The RFC | |||
Procedures", BCP 25, RFC 2418, September 1998. | Series and RFC Editor", RFC 4844, July 2007. | |||
[RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78, | [RFC6410] Housley, R., D. Crocker, and E. Burger, "Reducing the | |||
RFC 3978, January 2005. | Standards Track to Two Maturity Levels", RFC 6401, October 2011. | |||
13.2. Informative References | 14.2. Informative References | |||
[RFC1790] Cerf, V., "An Agreement between the Internet Society and | [RFC1790] Cerf, V., "An Agreement between the Internet Society and | |||
Sun Microsystems, Inc. in the Matter of ONC RPC and XDR | Sun Microsystems, Inc. in the Matter of ONC RPC and XDR | |||
Protocols", RFC 1790, April 1995. | Protocols", RFC 1790, April 1995. | |||
[RFC2339] The Internet Society and Sun Microsystems, "An Agreement | [RFC2339] The Internet Society and Sun Microsystems, "An Agreement | |||
Between the Internet Society, the IETF, and Sun | Between the Internet Society, the IETF, and Sun Microsystems, Inc. | |||
Microsystems, Inc. in the matter of NFS V.4 Protocols", RFC | in the matter of NFS V.4 Protocols", RFC 2339, May 1998. | |||
2339, May 1998. | ||||
14. Acknowledgements | [RFC5378] Bradner, S. Ed, J. Contreras, Ed, "Rights Contributors | |||
Provide to the IETF Trust", RFC 5378, November 2008 | ||||
The editor would like to acknowledge the help of the IETF IPR Working | [RFC6701] Farrel, A., and P. Resnick, "Sanctions Available for | |||
Group and, in particular the help of Jorge Contreras of Hale and Dorr | Application to Violators of IETF IPR Policy", RFC 6702, August | |||
for his careful legal reviews of this and other IETF IPR-related and | 2012 | |||
process documents. The editor would also like to thank Valerie See | ||||
for her extensive comments and suggestions. | ||||
Editor's Address | [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 | Scott Bradner | |||
Harvard University | Harvard University | |||
29 Oxford St. | 1350 Mass. Ave. | |||
Cambridge MA, 02138 | Cambridge MA, 02138 | |||
Phone: +1 617 495 3864 | Phone: +1 617 495 3864 | |||
EMail: sob@harvard.edu | EMail: sob@harvard.edu | |||
Full Copyright Statement | Jorge Contreras | |||
American University | ||||
4801 Massachusetts Ave. NW | ||||
Washington, DC 20016 | ||||
Email: cntreras@gmail.com | ||||
Copyright (C) The Internet Society (2005). | Changes in revisions of this document | |||
This document is subject to the rights, licenses and restrictions | version 00 -> version 01 | |||
contained in 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 | many clean ups suggested by Russ Housley | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | removed "informational" from section 5.1.1 | |||
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 | version 01 -> version 02 | |||
The IETF takes no position regarding the validity or scope of any | change RFC 2026 reference in section 9 to RFC 6410 | |||
Intellectual Property Rights or other rights that might be claimed to | fixed multiple references to (old) section 6 | |||
pertain to the implementation or use of the technology described in | revised section 5.5 to clarify the intention, as suggested by David | |||
this document or the extent to which any license under such rights | Rudin | |||
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 | version 02 -> version 03 | |||
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 | created a definition of "participation" in the definitions section as | |||
copyrights, patents or patent applications, or other proprietary | suggested by multiple people | |||
rights that may cover technology that may be required to implement | A number of changes suggested by Adrian Farrel | |||
this standard. Please address the information to the IETF at ietf- | expanded introduction by including a copy of the abstract | |||
ipr@ietf.org. | 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 | ||||
Acknowledgement | 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 | ||||
Funding for the RFC Editor function is currently provided by the | version 04 -> version 05 | |||
Internet Society. | 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 | ||||
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 | ||||
End of changes. 98 change blocks. | ||||
505 lines changed or deleted | 663 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |