[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5377

IPR                                                      J. Halpern, Ed.
Internet-Draft                                                      Self
Intended status: Informational                            September 2006
Expires: March 5, 2007

      Advice to the IAOC on Rights to be Granted in IETF Documents

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on March 5, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   The IASA is resposible for managing intellectual property rights on
   behalf of the IETF.  This includes the license to copy, implement and
   otherwise use IETF contributions, among them Internet-Drafts and
   RFCs.  The IASA accepts direction from the IETF regarding the rights
   to be granted.  This document describes the desires of the IETF
   regarding outbound rights to be granted in IETF contributions.

Halpern                   Expires March 5, 2007                 [Page 1]

Internet-Draft           Outbound Rights Advice           September 2006

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
   3.  Purpose in Granting Rights  . . . . . . . . . . . . . . . . . . 3
     3.1.  Specific Issues . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Powers and Authority  . . . . . . . . . . . . . . . . . . . . . 4
   5.  Recommended Grants of Right to Copy . . . . . . . . . . . . . . 4
     5.1.  Rights Granted for Reproduction of RFCs . . . . . . . . . . 5
     5.2.  Rights Granted for Quoting from IETF Contributions  . . . . 5
     5.3.  Rights Granted for Implementing based on IETF
           Contributions . . . . . . . . . . . . . . . . . . . . . . . 5
     5.4.  Rights Granted for use of text from IETF Contributions  . . 6
     5.5.  Additional Licenses for IETF Contributions  . . . . . . . . 6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8

Halpern                   Expires March 5, 2007                 [Page 2]

Internet-Draft           Outbound Rights Advice           September 2006

1.  Introduction

   Under the current operational and administrative structures, IETF
   intellectual property rights are vested in a trust administered by a
   board of trustees made up of the members of the IASA.  This includes
   the right to make use of IETF contributions, as granted by
   contributors under the rules laid out in [5].  The IASA is therefore
   responsible for defining the rights to copy granted by the IETF to
   people who wish to make use of the material in these documents.

   The IASA has indicated, as is consistent with the IETF structure,
   that it will respect the wishes of the IETF in regard to what these
   rights ought to be.  It is therefore the IETFs responsibility to
   articulate those wishes.  This document represents the wishes of the
   IETF regarding the rights granted to all users in regard to IETF
   contributions, until it is superceded.

2.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [1].

   This section is retained for now in case it turns out that these
   terms are needed.  If, as seems likely to the editor, these are not
   needed, the section and the normative reference will be removed.

3.  Purpose in Granting Rights

   In providing a description of the wishes of the IETF with regard to
   rights granted in RFCs, it is helpful to keep in mind the purpose of
   granting such rights.

   The IETF's mission is to write documents that help make the internet
   work better (see [2] for more details.)  These documents, when
   completed, are published as RFCs.

   An important subclass of RFCs is standards describing protocols; for
   these, the primary value to the Internet is the ability of
   implementors to build solutions (products, software, etc) which
   interoperate uing these standards.  Hence, the IETF has a strong
   interest in seeing accurate, interoperable implementations of the
   material we publish.  We grant rights to copy to people to make use
   of the text in the RFCs in order to encourage accurate and
   interoperable implementations.  As early implementations of make use
   of descriptions in internet-drafts, similar desires apply to

Halpern                   Expires March 5, 2007                 [Page 3]

Internet-Draft           Outbound Rights Advice           September 2006


   Similar considerations also apply to non-standard, non-protocol
   documents such as BCPs and informational documents; in this document,
   we recommend a common approach to the issue of right-to-use licenses
   for all IETF documents.

3.1.  Specific Issues

   There are a number of specific concerns that have been raised over
   time, which this document acknowledges and addresses.

   One issue that has been noted is that the legal wording for rights is
   defined in RFCs.  As such, if the wording needs modification, without
   changing the intent of the IETF, there is still a need to revise the
   RFC. this is at best cumbersome, and often much worse than that.  It
   introduces unnecessary delays in fixing legal matters.  And often
   opens the door to longer discussions that delay resolving the
   immediate matter.

   [Editor's note: Further concerns go here.]

4.  Powers and Authority

   As stated in the introduction, the legal authority for determining
   and granting rights to copy in RFCs rests with the trustees for the
   IETF trust, which is made up of the members of the IAOC, as described
   in [3] and [4].  This document provides guidance to that body, based
   on the rough consensus of the IETF.  The IASA, in conjunction with
   legal counsel has the authority and responsibility to determine the
   exact copyright text needed in Internet-Drafts, RFCs, and all IETF
   Contributions to meet these needs.

5.  Recommended Grants of Right to Copy

   In principle, different grants of rights to copy can be granted to
   individuals based on the purpose or use being made, and the
   particular material being copied.  This section contains subsections
   for each such different grant that is currently envisioned.  Each
   section is intended to describe a particular problem / situation /
   usage, to describe how that situation is recognizable, and to provide
   guidance to the IASA as to what rights the IETF would like to see
   granted in that circumstances, and what limitations should be put on
   such granting.  As stated above, the formulation of legal language
   for granting these rights (including the determination of how many
   sets of legal language are required is largely left to the IASA.

Halpern                   Expires March 5, 2007                 [Page 4]

Internet-Draft           Outbound Rights Advice           September 2006

   It is particularly noted that there has been a historical issue where
   it is difficult to fix legal wording and boilerplate if the direction
   defining that boilerplate is in an RFC, and then it turns out the
   wording needs modification.  As such, this document does not specify
   such wording.  Further, it is strongly recommended that all future
   RFCs on this topic refrain from defining the precises wording of
   boilerplate.  Similarly, legal issues of how to indicate usage
   restrictions are left to the IASA and legal consel to determine.

   In structuring these desires, it is to be kept in mind that the autor
   has not given up his copyright in granting rights to the IETF, and
   the IETF is not attempting to transfer or relinquish the rights it
   has.  The purpose is to enable to IASA to grant people the right to
   make copies of material in RFCs in ways that fit the goals of the
   IETF.  This discussion is also separate from the rights the IETF
   itself requires in documents to do its job, as those are not
   "outbound" rights.  It is expected that the rights granted to the
   IETF will be a superset of those copying rights we wish to grant to

   [Editors note: This structure will likely change as working group
   consens emerges on the rights to be granted.]

5.1.  Rights Granted for Reproduction of RFCs

   It has long been IETF policy to encourage copying of RFCs in full.
   This permits wide dissemination of the material, without risking loss
   of context or meaning.  The IETF wishes to continue to permit anyone
   to make full copies and translations of RFCs.

5.2.  Rights Granted for Quoting from IETF Contributions

   There is rough consensus that it is useful to permit the quoting
   without modification of excerpts from IETF Contributions.  Such
   excerpts may be of any length and in any context.  Translation of
   quotations is also to be permitted.  All such quotations SHOULD be
   attributed properly to the IETF and the IETF document from which they
   are taken.

5.3.  Rights Granted for Implementing based on IETF Contributions

   IETF contributions often include components intended to be directly
   processed by a computer.  These may be ABNF definitions, XML Schemas
   or DTDs, MIBs, or even classical programming code.  These are include
   for clarity and precision in specification.  It is clearly
   beneficial, when such items are included in IETF contributions, to
   permit the inclusion of such code fragments in products which
   implement the contribution.  It has been pointed out that in several

Halpern                   Expires March 5, 2007                 [Page 5]

Internet-Draft           Outbound Rights Advice           September 2006

   important contexts, use of such code requires the ability to modify
   the code.  One common example of this is simply the need to adapt
   code for use in specific contexts (languages, compilers, tool
   systems, etc.)  Such use frequently requires some changes to the text
   of the code from the IETF contribution.  Another example is that code
   included in open source products is frequently licensed to permit any
   and all of the code to be modified.  Since we want this code included
   in such products, it follows that we need to permit such
   modification.  While there has been discussion of restricting the
   rights to make such modifications in some way, the rough consensus is
   that such restrictions are likely a bad idea, and are certainly very
   complex to define.

   As such, the rough consensus is that code components of IETF
   contributions can be extracted, modified, and used by anyone in any
   way desired.

5.4.  Rights Granted for use of text from IETF Contributions

   There is no consensus at this time to permit the use of text from
   RFCs in contexts where the right to modify the text is required.  The
   authors of IETF contributions may be able and willing to grant such
   rights independently of the rights they have granted to the IETF by
   making the contribution.

   As such, in crafting legal language and boiler plate, the IASA is
   also asked to resolve and indicate how code segments of IETF
   documents, which can be extracted and subsequently modified, are to
   be indicated by authors and editors as distinct from text segments,
   which can be extract but not modified.

5.5.  Additional Licenses for IETF Contributions

   There have been contexts where the material in an IETF contribution
   is also available under other license terms.  The IETF wishes to be
   able to include content which is available under such licenses.  It
   is desirable to indicate in the IETF contribution that other licenses
   are available.  However, the IETF does not wish to have IETF
   Contributions contain additional copyright notices and licenses, as
   that introduces a number of additional difficulties.  Providing the
   correct legal approach to such indications is left to the IASA, as
   all legal language is.

6.  References

Halpern                   Expires March 5, 2007                 [Page 6]

Internet-Draft           Outbound Rights Advice           September 2006

6.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

6.2.  Informative References

   [2]  Alvestrand, H., "A Mission Statement for the IETF", BCP 95,
        RFC 3935, October 2004.

   [3]  Austein, R. and B. Wijnen, "Structure of the IETF Administrative
        Support Activity (IASA)", BCP 101, RFC 4071, April 2005.

   [4]  Carpenter, B. and L. Lynch, "BCP 101 Update for IPR Trust",
        BCP 101, RFC 4371, January 2006.

   [5]  Bradner, S., "I-D.ietf-ipr-rules-update-07.txt", 2006.

Author's Address

   Joel M. Halpern (editor)
   P. O. Box 6049
   Leesburg, VA  20178

   Email: jmh@joelhalpern.com

Halpern                   Expires March 5, 2007                 [Page 7]

Internet-Draft           Outbound Rights Advice           September 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Halpern                   Expires March 5, 2007                 [Page 8]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/