[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

Obsoleted by: 3979 BEST CURRENT PRACTICE
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?