Network Working Group                                         S. Bradner
Request for Comments: 3667                            Harvard University
BCP: 78                                                    February 2004
Updates: 2026
Category: Best Current Practice


                     IETF Rights in Contributions

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 rights in Contributions to the IETF are
  designed to ensure that such Contributions can be made available to
  the IETF and Internet communities while permitting the authors to
  retain as many rights as possible.  This memo details the IETF
  policies on rights in Contributions to the IETF.  It also describes
  the objectives that the policies are designed to meet.  This memo
  updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC
  2026.

Table of Contents

  1.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .  2
  2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
  3.  Rights in IETF Contributions . . . . . . . . . . . . . . . . .  5
      3.1.  General Policy . . . . . . . . . . . . . . . . . . . . .  5
      3.2.  Confidentiality Obligations. . . . . . . . . . . . . . .  5
      3.3.  Granting of Rights and Permissions . . . . . . . . . . .  6
      3.4.  Representations and Warranties . . . . . . . . . . . . .  7
      3.5.  No Duty to Publish . . . . . . . . . . . . . . . . . . .  7
      3.6.  Trademarks . . . . . . . . . . . . . . . . . . . . . . .  7
  4.  Rights in RFC Editor Contributions . . . . . . . . . . . . . .  8
      4.1.  Requirements from Section 3. . . . . . . . . . . . . . .  8
      4.2.  Granting of Rights and Permissions . . . . . . . . . . .  8
  5.  Notices Required in IETF Documents . . . . . . . . . . . . . .  9
      5.1.  IPR Disclosure Acknowledgement . . . . . . . . . . . . . 10
      5.2.  Derivative Works Limitation. . . . . . . . . . . . . . . 10
      5.3.  Publication Limitation . . . . . . . . . . . . . . . . . 11



Bradner                  Best Current Practice                  [Page 1]

RFC 3667               IETF Rights in Submissions          February 2004


      5.4.  Copyright Notice . . . . . . . . . . . . . . . . . . . . 11
      5.5.  Disclaimer . . . . . . . . . . . . . . . . . . . . . . . 11
      5.6.  Exceptions . . . . . . . . . . . . . . . . . . . . . . . 12
  6.  Notices and Rights Required in RFC Editor Contributions. . . . 13
  7.  Exposition of why these procedures are the way they are. . . . 13
      7.1.  Rights Granted in IETF Contributions . . . . . . . . . . 13
      7.2.  Rights to use Contributed Material . . . . . . . . . . . 14
      7.3.  Right to Produce Derivative Works. . . . . . . . . . . . 14
      7.4.  Rights to use Trademarks . . . . . . . . . . . . . . . . 16
      7.5.  Who Does This Apply To?. . . . . . . . . . . . . . . . . 16
  8.  Contributions Not Subject to Copyright . . . . . . . . . . . . 16
  9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 16
  10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
      10.1. Normative References . . . . . . . . . . . . . . . . . . 17
      10.2. Informative References . . . . . . . . . . . . . . . . . 17
  11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
  12. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 17
  13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18

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 3667               IETF Rights in Submissions          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 and RFC Editor Contributions.



Bradner                  Best Current Practice                  [Page 3]

RFC 3667               IETF Rights in Submissions          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.

2. Introduction

  Under the laws of most countries and current international treaties
  (for example the "Berne Convention for the Protection of Literary and
  Artistic Work" [Berne]), authors obtain numerous rights in the works
  they produce automatically upon producing them.  These rights include
  copyrights, moral rights and other rights.  In many cases, if the
  author produces a work within the scope of his or her employment,
  most of those rights are usually assigned to the employer, either by
  operation of law or, in many cases, under contract.  (The Berne
  Convention names some rights as "inalienable", which means that the
  author retains them in all cases.)

  This document details the rights that the IETF requires in IETF
  Contributions and rights the IETF, as publisher of Internet-Drafts,
  requires in all such Drafts including RFC Editor Contributions.  The
  RFC Editor may also define additional rights required for RFC Editor
  Contributions.

  In order for works to be used within the IETF Standards Process or to
  be published as Internet-Drafts, certain limited rights in all
  Contributions must be granted to the IETF and Internet Society
  (ISOC). In addition, Contributors must make representations to IETF
  and ISOC regarding their ability to grant these rights.  These
  necessary rights and representations have until now been laid out in
  Section 10 of [RFC 2026].  In the years since [RFC 2026] was
  published there have been a number of times when the exact intent of
  Section 10 has been the subject of vigorous debate within the IETF
  community.  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 currently
  doing.

  Section 1 gives definitions used in describing these policies.
  Sections 3, 4, 5 and 6 of this document address the rights in
  Contributions previously covered by Section 10 of [RFC 2026] and the



Bradner                  Best Current Practice                  [Page 4]

RFC 3667               IETF Rights in Submissions          February 2004


  "Note Well" explanatory text presented at many IETF activities.
  Sections 7 and 8 then explain the rationale for these provisions,
  including some of the clarifications that have become understood
  since the adoption of [RFC 2026].  The rules and procedures set out
  in this document are not intended to substantially modify or alter
  the IETF's current policy toward Contributions.

  A companion document [RFC 3668] deals with rights in technologies
  developed or specified as part of the IETF Standards Process.  This
  document is not intended to address those issues.

  The rights addressed in this document fall into the following
  categories:

  o  rights to make use of contributed material
  o  copyrights in IETF documents
  o  rights to produce derivative works
  o  rights to use trademarks

  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. Rights in IETF Contributions

  The following are the rights the IETF requires in all IETF
  Contributions:

3.1.  General Policy

  In all matters of copyright and document procedures, the intent is to
  benefit the Internet community and the public at large, while
  respecting the legitimate rights of others.

3.2.  Confidentiality Obligations

  No information or document that is subject to any requirement of
  confidentiality or any restriction on its dissemination may be
  submitted as a Contribution or otherwise considered in any part of
  the IETF Standards Process, and there must be no assumption of any
  confidentiality obligation with respect to any Contribution.  Each
  Contributor agrees that any statement in a Contribution, whether
  generated automatically or otherwise, that states or implies that the
  Contribution is confidential or subject to any privilege, can be
  disregarded for all purposes, and will be of no force or effect.





Bradner                  Best Current Practice                  [Page 5]

RFC 3667               IETF Rights in Submissions          February 2004


3.3.  Granting of Rights and Permissions

  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, and to grant the following
  rights, on his or her own behalf and on behalf of the organization
  the Contributor represents or is sponsored by (if any) when
  submitting the Contribution.

  a. To the extent that a Contribution or any portion thereof is
     protected by copyright and other rights of authorship, the
     Contributor, and each named co-Contributor, and the organization
     he or she represents or is sponsored by (if any) grant a
     perpetual, irrevocable, non-exclusive, royalty-free, world-wide
     right and license to the ISOC and the IETF under all intellectual
     property rights in the Contribution:

     (A)  to copy, publish, display and distribute the Contribution as
          part of the IETF Standards Process or in an Internet-Draft,

     (B)  to prepare or allow the preparation of translations of the
          Contribution into languages other than English,

     (C)  unless explicitly disallowed in the notices contained in a
          Contribution [as per Section 5.2 below], to prepare
          derivative works (other than translations) that are based on
          or incorporate all or part of the Contribution, or comment
          upon it, within the IETF Standards Process.  The license to
          such derivative works not granting the ISOC and the IETF any
          more rights than the license to the original Contribution,

     (D)  to reproduce any trademarks, service marks or trade names
          which are included in the Contribution solely in connection
          with the reproduction, distribution or publication of the
          Contribution and derivative works thereof as permitted by
          this paragraph.  When reproducing Contributions, the IETF
          will preserve trademark and service mark identifiers used by
          the Contributor of the Contribution, including (TM) and (R)
          where appropriate, and

     (E)  to extract, copy, publish, display, distribute, modify and
          incorporate into other works, for any purpose (and not
          limited to use within the IETF Standards Process) any
          executable code or code fragments that are included in any
          IETF Document (such as MIB and PIB modules), subject to the
          requirements of Section 5 (it also being understood that the
          licenses granted under this paragraph (E) shall not be deemed
          to grant any right under any patent, patent application or



Bradner                  Best Current Practice                  [Page 6]

RFC 3667               IETF Rights in Submissions          February 2004


          other similar intellectual property right disclosed by the
          Contributor under [IETF IPR]).

  b. The Contributor grants the IETF and ISOC permission to reference
     the name(s) and address(es) of the Contributor(s) and of the
     organization(s) s/he represents or is sponsored by (if any).

3.4.  Representations and Warranties

  With respect to each Contribution, each Contributor represents that
  to the best of his or her knowledge and ability:

  a. The Contribution properly acknowledges all major Contributors.  A
     major Contributor is any person who has materially or
     substantially contributed to the IETF Contribution.

  b. No information in the Contribution is confidential and the IETF,
     ISOC, and its affiliated organizations may freely disclose any
     information in the Contribution.

  c. 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.

  d. The Contributor has not intentionally included in the Contribution
     any material which is defamatory or untrue or which is illegal
     under the laws of the jurisdiction in which the Contributor has
     his or her principal place of business or residence.

  e. All trademarks, trade names, service marks and other proprietary
     names used in the Contribution that are reasonably and personally
     known to the Contributor are clearly designated as such where
     reasonable.

3.5.  No Duty to Publish

  The Contributor, and each named co-Contributor, acknowledges that the
  IETF has no duty to publish or otherwise use or disseminate any
  Contribution.  The IETF reserves the right to withdraw or cease using
  any Contribution that does not comply with the requirements of
  Section 3.4 and Section 3.3 or 4.2.

3.6.  Trademarks

  Contributors, and each named co-Contributor, who claim trademark
  rights in terms used in their IETF Contributions are requested to
  state specifically what conditions apply to implementers of




Bradner                  Best Current Practice                  [Page 7]

RFC 3667               IETF Rights in Submissions          February 2004


  the technology relative to the use of such trademarks.  Such
  statements should be submitted in the same way as is done for other
  intellectual property claims.  (See [RFC 3668] Section 6.)

4. Rights in RFC Editor Contributions

  The following are the rights the IETF, as the publisher of Internet-
  Drafts, requires in all RFC Editor Contributions:

4.1.  Requirements from Section 3

  All RFC Editor Contributions must meet the requirements of Sections
  3.1, 3.2, 3.4, 3.5 and 3.6.

4.2.  Granting of Rights and Permissions

  By submission of an RFC Editor Contribution, each person actually
  submitting the RFC Editor Contribution, and each named co-
  Contributor, is deemed to agree to the following terms and
  conditions, and to grant the following rights, on his or her own
  behalf and on behalf of the organization the Contributor represents
  or is sponsored by (if any) when submitting the RFC Editor
  Contribution.

  a. To the extent that an RFC Editor Contribution or any portion
     thereof is protected by copyright and other rights of authorship,
     the Contributor, and each named co-Contributor, and the
     organization he or she represents or is sponsored by (if any)
     grant a perpetual, irrevocable, non-exclusive, royalty-free,
     world-wide right and license to the ISOC and the IETF under all
     intellectual property rights in the RFC Editor Contribution for at
     least the life of the Internet-Draft:

     (A) to copy, publish, display and distribute the RFC Editor
         Contribution as an RFC, and

     (B) to prepare or allow the preparation of translations of the RFC
         into languages other than English.

     (C) unless explicitly disallowed in the notices contained in an
         RFC Editor Contribution (as per Section 5.2 below), to prepare
         derivative works (other than translations) that are based on
         or incorporate all or part of the RFC Editor Contribution, or
         comment upon it.  The license to such derivative works not
         granting the ISOC and the IETF any more rights than the
         license to the original RFC Editor Contribution, and





Bradner                  Best Current Practice                  [Page 8]

RFC 3667               IETF Rights in Submissions          February 2004


     (D) to reproduce any trademarks, service marks or trade names
         which are included in the RFC Editor Contribution solely in
         connection with the reproduction, distribution or publication
         of the RFC Editor Contribution and derivative works thereof as
         permitted by this paragraph.  When reproducing RFC Editor
         Contributions, the IETF will preserve trademark and service
         mark identifiers used by the Contributor of the RFC Editor
         Contribution, including (TM) and (R) where appropriate.

  b. The Contributor grants the IETF and ISOC permission to reference
     the name(s) and address(es) of the Contributor(s) and of the
     organization(s) s/he represents or is sponsored by (if any).

5.  Notices Required in IETF Documents

  The IETF requires that certain notices and disclaimers described in
  this Section 5 be reproduced verbatim in all IETF Documents
  (including copies, derivative works and translations of IETF
  Documents, but subject to the limited exceptions noted in Section
  5.2).  This requirement protects IETF and its participants from
  liabilities connected with these documents.  The copyright notice
  also alerts readers that the document is an IETF Document, and that
  ISOC claims copyright rights to certain aspects of the document, such
  as its layout, the RFC numbering convention and the prefatory
  language of the document.  This legend is not intended to imply that
  ISOC has obtained ownership of the IETF Contribution itself, which is
  retained by the author(s) or remains in the public domain, as
  applicable.

  Each IETF Document must include the required notices described in
  this Section 5.  The required notices are the following:

  a. The IPR Disclosure Acknowledgement described in Section 5.1
     (required in all Internet-Drafts).
  b. The Derivative Works Limitation described in Section 5.2 (for
     specific IETF Documents only).
  c. The Publication Limitation described in Section 5.3 (for specific
     types of Internet-Drafts only).
  d. The Copyright Notice described in Section 5.4 (for all IETF
     Documents).
  e. The Disclaimer described in Section 5.5 (for all IETF Documents).










Bradner                  Best Current Practice                  [Page 9]

RFC 3667               IETF Rights in Submissions          February 2004


5.1.  IPR Disclosure Acknowledgement (required in all Internet-Drafts
     only)

  "By submitting this Internet-Draft, I certify that any applicable
  patent or other IPR claims of which I am aware have been disclosed,
  and any of which I become aware will be disclosed, in accordance with
  RFC 3668."

5.2.  Derivative Works Limitation

  If the Contributor desires to eliminate the IETF's right to make
  modifications and derivative works of an IETF Contribution (other
  than translations), one of the two of the following notices may be
  included in the Status of Memo section of an Internet-Draft and
  included in a published RFC:

  a. "This document may not be modified, and derivative works of it may
     not be created, except to publish it as an RFC and to translate it
     into languages other than English."

  b. "This document may not be modified, and derivative works of it may
     not be created."

  In the cases of MIB or PIB modules and in other cases where the
  Contribution includes material that is meant to be extracted in order
  to be used, the following should be appended to statement 5.2 (a) or
  5.2 (b):

     "other than to extract section XX as-is for separate use."

  Notice 5.2(a) is used if the Contributor intends for the IETF
  Contribution to be published as an RFC.  Notice 5.2(b) is used along
  with the Publication Limitation in Section 5.3 when the Contributor
  does not intend for the IETF Contribution to be published as an RFC.

  These notices may not be used with any standards-track document or
  with most working group documents, except as discussed in Section 7.3
  below, since the IETF must retain change control over its documents
  and the ability to augment, clarify and enhance the original IETF
  Contribution in accordance with the IETF Standards Process.

  Notice 5.2(a) may be appropriate when republishing standards produced
  by other (non-IETF) standards organizations, industry consortia or
  companies.  These are typically published as Informational RFCs, and
  do not require that change control be ceded to the IETF.  Basically,
  documents of this type convey information for the Internet community.





Bradner                  Best Current Practice                 [Page 10]

RFC 3667               IETF Rights in Submissions          February 2004


  A fuller discussion of the rationale behind these requirements is
  contained in Section 7.3 below.

5.3.  Publication Limitation

  If the Contributor only wants the IETF Contribution to be made
  available in an Internet-Draft (i.e., does not want the IETF
  Contribution to be published as an RFC) then the Contributor may
  include the following notice in the Status of Memo section of the
  Internet-Draft.

     "This document may only be posted in an Internet-Draft."

  This notice can be used on IETF Contributions that are intended to
  provide background information to educate and to facilitate
  discussions within IETF working groups but are not intended to be
  published as an RFCs.

5.4.  Copyright Notice (required for all IETF Documents)

  (Normally placed at the end of the IETF Document.)

     "Copyright (C) The Internet Society (year).  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."

  Additional copyright notices are not permitted in IETF Documents
  except in the case where such document is the product of a joint
  development effort between the IETF and another standards development
  organization or the document is a republication of the work of
  another standards organization.  Such exceptions must be approved on
  an individual basis by the IAB.

5.5.  Disclaimer (required in all IETF Documents)

  (Normally placed at the end of the IETF Document after the copyright
  notice.)

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




Bradner                  Best Current Practice                 [Page 11]

RFC 3667               IETF Rights in Submissions          February 2004


5.6 Exceptions

  Notwithstanding the provisions of this Section 5, in certain limited
  cases an abbreviated notice may be placed on certain types of
  derivative works of IETF Documents in accordance with this Section
  5.6.

  a. in MIB modules, PIB modules and similar material commonly
     extracted from IETF Documents, except for material that is being
     placed under IANA maintenance, the following abbreviated notice
     shall be included in the body of the material that will be
     extracted in lieu of the notices otherwise required by Section 5:

        "Copyright (C) The Internet Society <year> .  This version of
        this MIB module is part of RFC XXXX; see the RFC itself for
        full legal notices."

     When the MIB or PIB module is the initial version of a module that
     is to be maintained by the IANA, the following abbreviated notice
     shall be included:

        "Copyright (C) The Internet Society <year>.  The initial
        version of this MIB module was published in RFC XXXX; for full
        legal notices see the RFC itself.  Supplementary information
        may be available on
        http://www.ietf.org/copyrights/ianamib.html."

     For other types of components than "MIB", substitute "MIB module"
     with an appropriate identifier.  In the case of MIB and PIB
     modules this statement should be placed in the DESCRIPTION clause
     of the MODULE-IDENTITY macro.

     Variations of these abbreviated notices are not permitted except
     in cases where the material to be extracted is the product of a
     joint development effort between the IETF and another standards
     development organization or is a republication of the work of
     another standards organization.  Such variations must be approved
     on an individual basis by the IAB.

  b. short excerpts of IETF Documents presented in electronic help
     systems, for example, the DESCRIPTION clauses for MIB variables,
     do not need to include a copyright notice.









Bradner                  Best Current Practice                 [Page 12]

RFC 3667               IETF Rights in Submissions          February 2004


6.  Notices and Rights Required in RFC Editor Contributions

  Since the IETF acts as publisher of Internet Drafts, even for
  Internet Drafts that are not intended to become part of the Standards
  Process, the following are required in all such drafts to protect the
  IETF and its processes.  The RFC Editor may require additional
  notices.

  a. An IPR Disclosure Acknowledgement, identical to that specified in
     Section 5.1.

  b. One of the following two copyright release statements:

     A. "By submitting this Internet-Draft, I accept the provisions of
        Section 3 of RFC 3667."

     B. "By submitting this Internet-Draft, I accept the provisions of
        Section 4 of RFC 3667."

7.  Exposition of Why These Procedures Are the Way They Are

7.1.  Rights Granted in IETF Contributions

  The IETF/ISOC must obtain the right to publish an IETF Contribution
  as an RFC or an Internet-Draft from the Contributors.

  A primary objective of this policy is to obtain from the document
  authors only the non-exclusive rights that are needed to develop and
  publish IETF Documents and to use the IETF Contributions in the IETF
  Standards Process while leaving all other rights with the authors.

  The non-exclusive rights that the IETF needs are:

  a. the right to publish the document
  b. the right to let the document be freely reproduced in the formats
     that the IETF publishes it in
  c. the right to let third parties translate it into languages other
     than English
  d. except where explicitly excluded (see Section 5.2), the right to
     make derivative works within the IETF process.
  e. the right to let third parties extract some logical parts, for
     example MIB modules

  The authors retain all other rights, but cannot withdraw the above
  rights from the IETF/ISOC.






Bradner                  Best Current Practice                 [Page 13]

RFC 3667               IETF Rights in Submissions          February 2004


7.2.  Rights to use Contributed Material

  Because, under the laws of most countries and applicable
  international treaties, copyright rights come into existence whenever
  a work of authorship is created (but see Section 8 below regarding
  public domain documents), and IETF cannot make use of IETF
  Contributions if it does not have sufficient rights with respect to
  these copyright rights, it is important that the IETF receive
  assurances from all Contributors that they have the authority to
  grant the IETF the rights that they claim to grant.  Without this
  assurance, IETF and its participants would run a greater risk of
  liability to the owners of these rights.

  To this end, IETF asks Contributors to give the assurances in Section
  3.4 above.  These assurances are requested, however, only to the
  extent of the Contributor's reasonable and personal knowledge.  (See
  Section 1(l))

7.3.  Right to Produce Derivative Works

  The IETF needs to be able to evolve IETF Documents in response to
  experience gained in the deployment of the technologies described in
  such IETF Documents, to incorporate developments in research and to
  react to changing conditions on the Internet and other IP networks.
  In order to do this the IETF must be able to produce derivatives of
  its documents; thus the IETF must obtain the right from Contributors
  to produce derivative works.  Note though that the IETF only requires
  this right for the production of derivative works within the IETF
  Standards Process.  The IETF does not need, nor does it obtain, the
  right to let derivative works be created outside of the IETF
  Standards Process other than as noted in Section 3.3 (E).

  The right to produce derivative works is required for all IETF
  standards track documents and for most IETF non-standards track
  documents.  There are two exceptions to this requirement:  documents
  describing proprietary technologies and documents that are
  republications of the work of other standards organizations.

  The right to produce derivative works must be granted in order for an
  IETF working group to accept an IETF Contribution as a working group
  document or otherwise work on it.  For non-working group IETF
  Contributions where the Contributor requests publication as a
  standards track RFC the right to produce derivative works must be
  granted before the IESG will issue an IETF Last-Call and, for most
  non-standards track non-working group IETF Contributions, before the
  IESG will consider the Internet-Draft for publication.





Bradner                  Best Current Practice                 [Page 14]

RFC 3667               IETF Rights in Submissions          February 2004


  Occasionally a Contributor may not want to grant publication rights
  or the right to produce derivative works before finding out if an
  IETF Contribution has been accepted for development in the IETF
  Standards Process.  In these cases the Contributor may include the
  Derivative Works Limitation described in Section 5.2 and the
  Publication Limitation described in Section 5.3 in their IETF
  Contribution.  A working group can discuss the Internet-Draft with
  the aim to decide if it should become a working group document, even
  though the right to produce derivative works or to publish the IETF
  Contribution as an RFC has not yet been granted.  If the IETF
  Contribution is accepted for development the Contributor must then
  resubmit the IETF Contribution without the limitation notices before
  a working group can formally adopt the IETF Contribution as a working
  group document.

  The IETF has historically encouraged organizations to publish details
  of their technologies, even when the technologies are proprietary,
  because understanding how existing technology is being used helps
  when developing new technology.  But organizations that publish
  information about proprietary technologies are frequently not willing
  to have the IETF produce revisions of the technologies and then claim
  that the IETF version is the "new version" of the organization's
  technology. Organizations that feel this way can specify that an IETF
  Contribution can be published with the other rights granted under
  this document but may withhold the right to produce derivative works
  other than translations.  The right to produce translations is
  required before any IETF Contribution can be published as an RFC to
  ensure the widest possible distribution of the material in RFCs.

  In addition, IETF Documents frequently make normative references to
  standards or recommendations developed by other standards
  organizations. Since the publications of some standards organizations
  are not public documents, it can be quite helpful to the IETF to
  republish, with the permission of the other standards organization,
  some of these documents as RFCs so that the IETF community can have
  open access to them to better understand what they are referring to.
  In these cases the RFCs can be published without the right for the
  IETF to produce derivative works.

  In both of the above cases in which the production of derivative
  works is excluded, the Contributor must include a special legend in
  the IETF Contribution, as specified in Section 5.2, in order to
  notify IETF participants about this restriction.








Bradner                  Best Current Practice                 [Page 15]

RFC 3667               IETF Rights in Submissions          February 2004


7.4.  Rights to Use Trademarks

  Contributors may wish to seek trademark or service mark protection on
  any terms that are coined or used in their IETF Contributions.  IETF
  makes no judgment about the validity of any such trademark rights.
  However, the IETF requires each Contributor, under the licenses
  described in Section 3.3 above, to grant IETF a perpetual license to
  use any such trademarks or service marks solely in exercising its
  rights to reproduce, publish and modify the IETF Contribution.  This
  license does not authorize any IETF participant to use any trademark
  or service mark in connection with any product or service offering,
  but only in the context of IETF Documents and discussions.

7.5.  Who Does This Apply To?

  Rights and licenses granted to the IETF under this document are
  granted to all individuals noted in Section 1(a), irrespective of
  their employment or institutional affiliation.  However, these
  licenses do not extend broadly to the employers, sponsors or
  institutions of such individuals, nor do they authorize the
  individuals to exercise any rights outside the specific context of
  the IETF Standards Process.

8.  Contributions Not Subject to Copyright

  Certain documents, including those produced by the U.S. government
  and those which are in the public domain, may not be protected by the
  same copyright and other legal rights as other documents.
  Nevertheless, we ask each Contributor to grant to the IETF the same
  rights as he or she would grant, and to make the same
  representations, as though the IETF Contribution were protected by
  the same legal rights as other documents, and as though the
  Contributor could be able to grant these rights.  We ask for these
  grants and representations only to the extent that the Contribution
  may be protected.  We believe they are necessary to protect the ISOC,
  the IETF, the IETF Standards Process and all IETF participants, and
  also because the IETF does not have the resources or wherewithal to
  make any independent investigation as to the actual proprietary
  status of any document submitted to it.

9. Security Considerations

  This memo relates to IETF process, not any particular technology.
  There are security considerations when adopting any technology, but
  there are no known issues of security with IETF Contribution rights
  policies.





Bradner                  Best Current Practice                 [Page 16]

RFC 3667               IETF Rights in Submissions          February 2004


10.  References

10.1.  Normative References

  [RFC 2026]   Bradner, S., Ed, "The Internet Standards Process --
               Revision 3", BCP 9, RFC 2026, October 1996.

  [RFC 3668]   Bradner, S., Ed., "Intellectual Property Rights in IETF
               Technology", BCP 79, RFC 3668, February 2004.

10.2.  Informative References

  [Berne]      "Berne Convention for the Protection of Literary and
               Artistic Work",
               http://www.wipo.int/treaties/ip/berne/index.html

11.  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 acknowledge the
  extensive help John Klensin provided during the development of the
  document.

12.  Editor's Address

  Scott Bradner
  Harvard University
  29 Oxford St.
  Cambridge MA, 02138

  Phone: +1 617 495 3864
  EMail: [email protected]

















Bradner                  Best Current Practice                 [Page 17]

RFC 3667               IETF Rights in Submissions          February 2004


13.  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 [email protected].

Acknowledgement

  Funding for the RFC Editor function is currently provided by the
  Internet Society.









Bradner                  Best Current Practice                 [Page 18]