diff options
Diffstat (limited to 'doc/rfc/rfc3668.txt')
| -rw-r--r-- | doc/rfc/rfc3668.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc3668.txt b/doc/rfc/rfc3668.txt new file mode 100644 index 0000000..9a33522 --- /dev/null +++ b/doc/rfc/rfc3668.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group S. Bradner +Request for Comments: 3668 Harvard University +BCP: 79 February 2004 +Updates: 2028, 2026 +Category: Best Current Practice + + + Intellectual Property Rights in IETF Technology + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + The IETF policies about Intellectual Property Rights (IPR), such as + patent rights, relative to technologies developed in the IETF are + designed to ensure that IETF working groups and participants have as + much information about any IPR constraints on a technical proposal as + possible. The policies are also intended to benefit the Internet + community and the public at large, while respecting the legitimate + rights of IPR holders. This memo details the IETF policies + concerning IPR related to technology worked on within the IETF. It + also describes the objectives that the policies are designed to meet. + This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of + RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC + 2028, for all purposes, including reference [2] in RFC 2418. + +Table of Contents + + 1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Contributions to the IETF. . . . . . . . . . . . . . . . . . . 6 + 3.1. General Policy . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. Rights and Permissions . . . . . . . . . . . . . . . . . 6 + 4. Actions for Documents for which IPR Disclosure(s) Have Been + Received . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. No Determination of Reasonable and Non-discriminatory + Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Notice to be included in RFCs. . . . . . . . . . . . . . . . . 8 + 6. IPR Disclosures. . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1. Who must make an IPR disclosure? . . . . . . . . . . . . 9 + + + +Bradner Best Current Practice [Page 1] + +RFC 3668 IP in IETF Technology February 2004 + + + 6.2. The timing of providing disclosure . . . . . . . . . . . 9 + 6.3. How must a disclosure be made? . . . . . . . . . . . . . 11 + 6.4. What must be in a disclosure?. . . . . . . . . . . . . . 11 + 6.5. What licensing information to detail in a disclosure . . 12 + 6.6. When is a disclosure required? . . . . . . . . . . . . . 12 + 7. Failure to disclose. . . . . . . . . . . . . . . . . . . . . . 12 + 8. Evaluating alternative technologies in IETF working groups . . 13 + 9. Change control for technologies. . . . . . . . . . . . . . . . 14 + 10. Licensing requirements to advance standards track documents. . 14 + 11. No IPR disclosures in IETF documents . . . . . . . . . . . . . 14 + 12. Security Considerations. . . . . . . . . . . . . . . . . . . . 15 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 13.2. Informative References . . . . . . . . . . . . . . . . . 15 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 + 15. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 16 + 16. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 + +1. Definitions + + The following definitions are for terms used in the context of this + document. Other terms, including "IESG," "ISOC," "IAB," and "RFC + Editor," are defined in [RFC 2028]. + + a. "IETF": In the context of this document, the IETF includes all + individuals who participate in meetings, working groups, mailing + lists, functions and other activities which are organized or + initiated by ISOC, the IESG or the IAB under the general + designation of the Internet Engineering Task Force or IETF, but + solely to the extent of such participation. + + b. "IETF Standards Process": the activities undertaken by the IETF in + any of the settings described in 1(c) below. + + c. "IETF Contribution": any submission to the IETF intended by the + Contributor for publication as all or part of an Internet-Draft or + RFC (except for RFC Editor Contributions described below) and any + statement made within the context of an IETF activity. Such + statements include oral statements in IETF sessions, as well as + written and electronic communications made at any time or place, + which are addressed to: + + o the IETF plenary session, + o any IETF working group or portion thereof, + o the IESG, or any member thereof on behalf of the IESG, + o the IAB or any member thereof on behalf of the IAB, + + + + + +Bradner Best Current Practice [Page 2] + +RFC 3668 IP in IETF Technology February 2004 + + + o any IETF mailing list, including the IETF list itself, any + working group or design team list, or any other list + functioning under IETF auspices, + o the RFC Editor or the Internet-Drafts function (except for RFC + Editor Contributions described below). + + Statements made outside of an IETF session, mailing list or other + function, that are clearly not intended to be input to an IETF + activity, group or function, are not IETF Contributions in the + context of this document. + + d. "Internet-Draft": temporary documents used in the IETF and RFC + Editor processes. Internet-Drafts are posted on the IETF web site + by the IETF Secretariat and have a nominal maximum lifetime in the + Secretariat's public directory of 6 months, after which they are + removed. Note that Internet-Drafts are archived many places on + the Internet, and not all of these places remove expired + Internet-Drafts. Internet-Drafts that are under active + consideration by the IESG are not removed from the Secretariat's + public directory until that consideration is complete. In + addition, the author of an Internet-Draft can request that the + lifetime in the Secretariat's public directory be extended before + the expiration. + + e. "RFC": the basic publication series for the IETF. RFCs are + published by the RFC Editor and once published are never modified. + (See [RFC 2026] Section 2.1) + + f. "RFC Editor Contribution": An Internet-Draft intended by the + Contributor to be submitted to the RFC Editor for publication as + an Informational or Experimental RFC but not intended to be part + of the IETF Standards Process. + + g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor + Contributions. Note that under Section 3.3(a) the grant of rights + in regards to IETF Internet-Drafts as specified in this document + is perpetual and irrevocable and thus survives the Secretariat's + removal of an Internet-Draft from the public directory, except as + limited by Section 3.3(a)(C). (See [RFC 2026] Sections 2.2 and 8) + + h. "IETF Documents": RFCs and Internet-Drafts except for Internet- + Drafts that are RFC Editor Contributions and the RFCs that are + published from them. + + i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC + Editor Contributions and the RFCs that may be published from them. + + j. "Contribution": IETF Contributions or RFC Editor Contributions + + + +Bradner Best Current Practice [Page 3] + +RFC 3668 IP in IETF Technology February 2004 + + + k. "Contributor": an individual submitting a Contribution + + l. "Reasonably and personally known": means something an individual + knows personally or, because of the job the individual holds, + would reasonably be expected to know. This wording is used to + indicate that an organization cannot purposely keep an individual + in the dark about patents or patent applications just to avoid the + disclosure requirement. But this requirement should not be + interpreted as requiring the IETF Contributor or participant (or + his or her represented organization, if any) to perform a patent + search to find applicable IPR. + + m. "Implementing Technology": means a technology that implements an + IETF specification or standard. + + n. "Covers" or "Covered" mean that a valid claim of a patent or a + patent application in any jurisdiction or a protected claim, or + any other Intellectual Property Right, would necessarily be + infringed by the exercise of a right (e.g., making, using, + selling, importing, distribution, copying, etc.) with respect to + an Implementing Technology. For purposes of this definition, + "valid claim" means a claim of any unexpired patent or patent + application which shall not have been withdrawn, cancelled or + disclaimed, nor held invalid by a court of competent jurisdiction + in an unappealed or unappealable decision. + + o. "IPR" or "Intellectual Property Rights": means patent, copyright, + utility model, invention registration, database and data rights + that may Cover an Implementing Technology, whether such rights + arise from a registration or renewal thereof, or an application + therefore, in each case anywhere in the world. + +2. Introduction + + In the years since RFC 2026 was published there have been a number of + times when the exact intent of Section 10, the section which deals + with IPR disclosures has been the subject of vigorous debate within + the IETF community. This is because it is becoming increasingly + common for IETF working groups to have to deal with claims of + Intellectual Property Rights (IPR), such as patent rights, with + regards to technology under discussion in working groups. The aim of + this document is to clarify various ambiguities in Section 10 of [RFC + 2026] that led to these debates and to amplify the policy in order to + clarify what the IETF is, or should be, doing. + + IPR disclosures can come at any point in the IETF Standards Process, + e.g., before the first Internet-Draft has been submitted, prior to + RFC publication, or after an RFC has been published and the working + + + +Bradner Best Current Practice [Page 4] + +RFC 3668 IP in IETF Technology February 2004 + + + group has been closed down; they can come from people submitting + technical proposals as Internet-Drafts, on mailing lists or at + meetings, from other people participating in the working group or + from third parties who find out that the work is going or has gone + on; and they can be based on granted patents or on patent + applications, and in some cases be disingenuous, i.e., made to affect + the IETF Standards Process rather than to inform. + + RFC 2026, Section 10 established three basic principles regarding the + IETF dealing with claims of Intellectual Property Rights: + + (a) the IETF will make no determination about the validity of any + particular IPR claim + (b) the IETF following normal processes can decide to use technology + for which IPR disclosures have been made if it decides that such + a use is warranted + (c) in order for the working group and the rest of the IETF to have + the information needed to make an informed decision about the use + of a particular technology, all those contributing to the working + group's discussions must disclose the existence of any IPR the + Contributor or other IETF participant believes Covers or may + ultimately Cover the technology under discussion. This applies + to both Contributors and other participants, and applies whether + they contribute in person, via email or by other means. The + requirement applies to all IPR of the participant, the + participant's employer, sponsor, or others represented by the + participants, that is reasonably and personally known to the + participant. No patent search is required. + + Section 1 defines the terms used in this document. Sections 3, 4 and + 5 of this document address the intellectual property issues + previously addressed by Section 10 of RFC 2026. Sections 6 thru 12 + then explain the rationale for these provisions, including some of + the clarifications that have been made since the adoption of RFC + 2026. The rules and procedures set out in this document are not + intended to modify or alter the IETF's current policy toward IPR in + the context of the IETF Standards Process. They are intended to + clarify and fill in procedural gaps. + + A companion document [RFC 3667] deals with rights (such as copyrights + and trademarks) in Contributions, including the right of IETF and its + participants to publish and create derivative works of those + Contributions. This document is not intended to address those + issues. + + + + + + + +Bradner Best Current Practice [Page 5] + +RFC 3668 IP in IETF Technology February 2004 + + + 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. Contributions to the IETF + +3.1. General Policy + + In all matters of Intellectual Property Rights, the intent is to + benefit the Internet community and the public at large, while + respecting the legitimate rights of others. + +3.2. Rights and Permissions + +3.2.1. All 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. + + A. The Contributor represents that he or she has made or will + promptly make all disclosures required by Section 6.1.1 of this + document. + + B. The 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. + + 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 [RFC 3667]. + + +4. Actions for Documents for which IPR Disclosure(s) Have Been Received + + (A) When any Intellectual Property Right is disclosed before + publication as an RFC, with respect to any technology or + specification, described in a Contribution in the manner set + forth in Section 6 of this document, the RFC Editor shall ensure + that the document include a note indicating the existence of such + claimed Intellectual Property Rights in any RFC published from + the Contribution. (See Section 5 below.) + + + + +Bradner Best Current Practice [Page 6] + +RFC 3668 IP in IETF Technology February 2004 + + + (B) The IESG disclaims any responsibility for identifying the + existence of or for evaluating the applicability of any IPR, + disclosed or otherwise, to any IETF technology, specification or + standard, and will take no position on the validity or scope of + any such IPR claims. + + (C) Where Intellectual Property Rights have been disclosed for IETF + Documents as provided in Section 6 of this document, the IETF + Executive Director shall request from the discloser of such IPR, + a written assurance that upon approval by the IESG for + publication as RFCs of the relevant IETF specification(s), all + persons will be able to obtain the right to implement, use, + distribute and exercise other rights with respect to Implementing + Technology under one of the licensing options specified in + Section 6.5 below unless such a statement has already been + submitted. The working group proposing the use of the technology + with respect to which the Intellectual Property Rights are + disclosed may assist the IETF Executive Director in this effort. + + The results of this procedure shall not, in themselves, block + publication of an IETF Document or advancement of an IETF + Document along the standards track. A working group may take + into consideration the results of this procedure in evaluating + the technology, and the IESG may defer approval when a delay may + facilitate obtaining such assurances. The results will, however, + be recorded by the IETF Executive Director, and be made available + online. + +4.1. 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. + + + + + + +Bradner Best Current Practice [Page 7] + +RFC 3668 IP in IETF Technology February 2004 + + +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 + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org." + +6. IPR Disclosures + + This section discusses aspects of obligations associated with IPR + disclosure. + + This document refers to the IETF participant making disclosures, + consistent with the general IETF philosophy that participants in the + IETF act as individuals. A participant's obligation to make a + disclosure is also considered satisfied if the IPR owner or the + participant's employer or sponsor makes an appropriate disclosure in + place of the participant doing so. + + + + + + + + + + +Bradner Best Current Practice [Page 8] + +RFC 3668 IP in IETF Technology February 2004 + + +6.1. Who must make an IPR disclosure? + +6.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 6.6 which the Contributor believes Covers + or may ultimately Cover his or her Contribution, or which the + Contributor reasonably and personally knows his or her employer or + sponsor may assert against Implementing Technologies based on such + Contribution, must make a disclosure in accordance with this Section + 6. + + 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 + + Any individual participating in an IETF discussion who reasonably and + personally knows of IPR meeting the conditions of Section 6.6 which + the individual believes Covers or may ultimately Cover a Contribution + made by another person, or which such IETF participant reasonably and + personally knows his or her employer or sponsor may assert against + Implementing Technologies based on such Contribution, must make a + disclosure in accordance with this Section 6. + +6.1.3. IPR of others + + If a person has information about IPR that may Cover IETF + Contributions, but the participant is not required to disclose + because they do not meet the criteria in Section 6.6 (e.g., the IPR + is owned by some other company), such person is encouraged to notify + the IETF by sending an email message to ietf-ipr@ietf.org. Such a + notice should be sent as soon as reasonably possible after the person + realizes the connection. + +6.2. The timing of providing disclosure + + Timely IPR disclosure is important because working groups need to + have as much information as they can while they are evaluating + alternative solutions. + + + +Bradner Best Current Practice [Page 9] + +RFC 3668 IP in IETF Technology February 2004 + + +6.2.1. Timing of disclosure under Section 6.1.1 + + The IPR disclosure required pursuant to section 6.1.1 must be made as + soon as reasonably possible after the Contribution is published in an + Internet Draft unless the required disclosure is already on file. + For example, if the Contribution is an update to a Contribution for + which an IPR disclosure has already been made and the applicability + of the disclosure is not changed by the new Contribution, then no new + disclosure is required. But if the Contribution is a new one, or is + one that changes an existing Contribution such that the revised + Contribution is no longer 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 + the conditions of Section 6.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. + + Participants who realize that a Contribution will be or has been + 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 6.1.2 must be made as + soon as reasonably possible after the Contribution is published in an + Internet Draft or RFC, unless the required disclosure is already on + file. Participants who realize that the IPR will be or has been + 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. + + If a participant first learns of IPR that meets the conditions of + Section 6.6 in a Contribution by another party, for example a new + patent application or the discovery of a relevant patent in a patent + portfolio, after the Contribution was published in an Internet-Draft + or RFC, a disclosure must be made as soon as reasonably possible + after the IPR becomes reasonably and personally known to the + participant. + + + +Bradner Best Current Practice [Page 10] + +RFC 3668 IP in IETF Technology February 2004 + + +6.3. How must a disclosure be made? + + IPR disclosures are made by following the instructions at + http://www.ietf.org/ipr-instructions. + +6.4. What must be in a disclosure? + +6.4.1. The disclosure must list the numbers of any issued patents or + published patent applications or indicate that the claim is based on + unpublished patent applications. The disclosure must also list the + specific IETF or RFC Editor Document(s) or activity affected. If the + IETF Document is an Internet-Draft, it must be referenced by specific + version number. In addition, if the IETF Document includes multiple + parts and it is not reasonably apparent which part of such IETF + Document is alleged to be Covered by the IPR in question, it is + helpful if the discloser identifies the sections of the IETF Document + that are alleged to be so Covered. + +6.4.2. If a disclosure was made on the basis of a patent application + (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. + +6.4.3. The requirement for an IPR disclosure is not satisfied by the + submission of a blanket statement of possible IPR on every + Contribution. 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 to license + all potential IPR under fair 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 willingness + to license all of its potential IPR meeting the requirements of + Section 6.6 (and either Section 6.1.1 or 6.1.2) to implementers of an + IETF specification on a royalty-free basis as long as any other terms + and conditions are disclosed in the IPR disclosure statement. + + + +Bradner Best Current Practice [Page 11] + +RFC 3668 IP in IETF Technology February 2004 + + +6.5. What licensing information to detail in a disclosure. + + 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 RFCs of the relevant IETF specification(s), all + persons will be able to obtain the right to implement, use, + distribute and exercise other rights with respect to 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 + 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 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. + +6.6. When is a disclosure required? + + IPR disclosures under Sections 6.1.1. and 6.1.2 are required with + 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 + + There are cases where individuals are not permitted by their + employers or by other factors to disclose the existence or substance + of patent applications or other IPR. Since disclosure is required + for anyone submitting documents or participating in IETF discussions, + a person who does not disclose IPR for this reason, or any other + reason, must not contribute to or participate in IETF activities with + respect to technologies that he or she reasonably and personally + knows to be Covered by IPR which he or she will not disclose. + Contributing to or participating in IETF discussions about a + technology without making required IPR disclosures is a violation of + IETF process. + + + + + + + +Bradner Best Current Practice [Page 12] + +RFC 3668 IP in IETF Technology February 2004 + + +8. Evaluating alternative technologies in IETF working groups + + In general, IETF working groups prefer technologies with no known IPR + claims or, for technologies with claims against them, an offer of + royalty-free licensing. But IETF working groups have the discretion + to adopt technology with a commitment of fair and non-discriminatory + terms, or even with no licensing commitment, if they feel that this + technology is superior enough to alternatives with fewer IPR claims + or free licensing to outweigh the potential cost of the licenses. + + Over the last few years the IETF has adopted stricter requirements + for some security technologies. It has become common to have a + mandatory-to-implement security technology in IETF technology + specifications. This is to ensure that there will be at least one + common security technology present in all implementations of such a + specification that can be used in all cases. This does not limit the + specification from including other security technologies, the use of + which could be negotiated between implementations. An IETF consensus + has developed that no mandatory-to-implement security technology can + be specified in an IETF specification unless it has no known IPR + claims against it or a royalty-free license is available to + implementers of the specification unless there is a very good reason + to do so. This limitation does not extend to other security + technologies in the same specification if they are not listed as + mandatory-to-implement. + + It should also be noted that the absence of IPR disclosures is not + the same thing as the knowledge that there will be no IPR claims in + the future. People or organizations not currently involved in the + IETF or people or organizations that discover IPR they feel to be + relevant in their patent portfolios can make IPR disclosures at any + time. + + It should also be noted that the validity and enforceability of any + IPR may be challenged for legitimate reasons, and the mere existence + of an IPR disclosure should not automatically be taken to mean that + the disclosed IPR is valid or enforceable. Although the IETF can + make no actual determination of validity, enforceability or + applicability of any particular IPR claim, it is reasonable that a + working group will take into account on their own opinions of the + validity, enforceability or applicability of Intellectual Property + Rights in their evaluation of alternative technologies. + + + + + + + + + +Bradner Best Current Practice [Page 13] + +RFC 3668 IP in IETF Technology February 2004 + + +9. Change control for technologies + + The IETF must have change control over the technology described in + any standards track IETF Documents in order to fix problems that may + be discovered or to produce other derivative works. + + In some cases the developer of patented or otherwise controlled + technology may decide to hand over to the IETF the right to evolve + the technology (a.k.a., "change control"). The implementation of an + agreement between the IETF and the developer of the technology can be + complex. (See [RFC 1790] and [RFC 2339] for examples.) + + Note that there is no inherent prohibition against a standards track + IETF Document making a normative reference to proprietary technology. + For example, a number of IETF Standards support proprietary + cryptographic transforms. + +10. Licensing requirements to advance standards track IETF Documents + + RFC 2026 Section 4.1.2 states: "If patented or otherwise controlled + technology is required for implementation, the separate + implementations must also have resulted from separate exercise of the + licensing process." A key word in this text is "required." The mere + existence of disclosed IPR does not necessarily mean that licenses + are actually required in order to implement the technology. Section + 4.1 of this document should be taken to apply to the case where there + are multiple implementations and none of the implementers have felt + that they needed to license the technology and they have no plausible + indications that any IPR holder(s) will try to enforce their IPR. + +11. No IPR disclosures in IETF Documents + + IETF and RFC Editor Documents must not contain any mention of + specific IPR. All specific IPR disclosures must be submitted as + described in Section 6. Specific IPR disclosures must not be in the + affected IETF and RFC Editor Documents because the reader could be + misled. The inclusion of a particular IPR disclosure in a document + could be interpreted to mean that the IETF, IESG or RFC Editor has + formed an opinion on the validity, enforceability or applicability of + the IPR. The reader could also be misled to think that the included + IPR disclosures are the only IPR disclosures the IETF has received + concerning the IETF document. Readers should always refer to the + on-line web page to get a full list of IPR disclosures received by + the IETF concerning any Contribution. (http://www.ietf.org/ipr/) + + + + + + + +Bradner Best Current Practice [Page 14] + +RFC 3668 IP in IETF Technology February 2004 + + +12. Security Considerations + + This memo relates to IETF process, not any particular technology. + There are security considerations when adopting any technology, + whether IPR-protected or not. A working group should take those + security considerations into account as one part of evaluating the + technology, just as IPR is one part, but there are no known issues of + security with IPR procedures. + +13. References + +13.1. Normative References + + [RFC 2026] Bradner, S., Ed., "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996. + + [RFC 2028] Hovey, R. and S. Bradner, "The Organizations Involved in + the IETF Standards Process", BCP 11, RFC 2028, October + 1996. + + [RFC 2418] Bradner, S., Ed., "Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + [RFC 3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC + 3667, February 2004. + +13.2. Informative References + + [RFC 1790] Cerf, V., "An Agreement between the Internet Society and + Sun Microsystems, Inc. in the Matter of ONC RPC and XDR + Protocols", RFC 1790, April 1995. + + [RFC 2339] IETF & Sun Microsystems, "An Agreement Between the + Internet Society, the IETF, and Sun Microsystems, Inc. in + the matter of NFS V.4 Protocols", RFC 2339, May 1998. + +14. Acknowledgements + + The editor would like to acknowledge the help of the IETF IPR Working + Group and, in particular the help of Jorge Contreras of Hale and Dorr + for his careful legal reviews of this and other IETF IPR-related and + process documents. The editor would also like to thank Valerie See + for her extensive comments and suggestions. + + + + + + + + +Bradner Best Current Practice [Page 15] + +RFC 3668 IP in IETF Technology February 2004 + + +15. Editor's Address + + Scott Bradner + Harvard University + 29 Oxford St. + Cambridge MA, 02138 + + Phone: +1 617 495 3864 + EMail: sob@harvard.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bradner Best Current Practice [Page 16] + +RFC 3668 IP in IETF Technology February 2004 + + +16. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions 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 + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Bradner Best Current Practice [Page 17] + |