[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
Expires: July 26, 2007                                  January 22, 2007


      Advice to the IAOC on Rights to be Granted in IETF Documents
                   draft-ietf-ipr-outbound-rights-02

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

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 26, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   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 July 26, 2007                 [Page 1]


Internet-Draft           Outbound Rights Advice             January 2007


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 . . . . . . . . . . . . . . 5
     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 . . . . . . . . . . . . . . . . . . . . . . . 6
     5.4.  Rights Granted for use of text from IETF Contributions  . . 7
     5.5.  Additional Licenses for IETF Contributions  . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9






























Halpern                   Expires July 26, 2007                 [Page 2]


Internet-Draft           Outbound Rights Advice             January 2007


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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].


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 from
   internet drafts make use of descriptions in those internet-drafts,
   similar desires apply to internet-drafts.

   Similar considerations also apply to non-standard, non-protocol
   documents such as BCPs and informational documents; in this document,



Halpern                   Expires July 26, 2007                 [Page 3]


Internet-Draft           Outbound Rights Advice             January 2007


   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.


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.

   The rough consensus described in this document reflects the agreement
   of the IETF as of the IETF Last call, and the IASA is to begin acting
   on these instructions upon IESG approval of this document for RFC
   publication.  Changes to the iETF documentation, and document
   policies themselves take effect as determined by the IASA.

   As stated earlier, this document describes the IETFs desires in terms
   of granting rights to those who read or make use of material in IETF
   contributions.  This document does not specify what rights the IETF
   Trust receives from others in IETF contributions.  That is left to
   another document.  While care will be taken by both the working group
   and the IASA to see that sufficient rights are granted to the IETF
   trust in IETF contributions, it is also the case that the trust can
   not grant rights it has not or does not receive, and it is expected
   that policies will be in line with that fact.  Similarly, the text
   for pre-existing documents can not be changed.  Nonetheless, to the
   degree it can, and without embarking on a massive effort, it is
   desirable if similar rights to those described below can be granted
   in older RFCs.




Halpern                   Expires July 26, 2007                 [Page 4]


Internet-Draft           Outbound Rights Advice             January 2007


5.  Recommended Grants of Right to Copy

   The IETF grants rights to copy and modify parts of IETF contributions
   in order to meet the objectives described earlier.  As such,
   different circumstances and different parts of documents may need
   different grants.  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.

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

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



Halpern                   Expires July 26, 2007                 [Page 5]


Internet-Draft           Outbound Rights Advice             January 2007


   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
   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 the IETF trust is to grant
   rights such that code components of IETF contributions can be
   extracted, modified, and used by anyone in any way desired.  As the
   IETF trust can not grant rights it does not receive, this right to
   use code can not be granted in IETF contributions which are
   explicitly marked as not permitting derivatives works.

   While it is up to the IASA to determine the best way of meeting this
   objective, two mechanisms are suggested here that are believed to be
   helpful in documenting the intended grant to readers and users of
   IETF contributions.

   Firstly, the IASA should maintain, in a suitable, easily accessible
   fashion, a list of common RFC components which will be considered to
   be code.  To start, this list should include at least the items
   listed above, ABNF definitions, XML Schemas, XML DTDs, and MIBs.  The
   IASA would add to this list as it deems suitable or as it is directed
   by the IETF.

   Additionally, the IASA should define a textualy representation to be
   included in an IETF contibution to indicate that a portion of the
   document is considered by the authors (and later the working group,
   and upon approval the IETF) to be code, and to be subject to the



Halpern                   Expires July 26, 2007                 [Page 6]


Internet-Draft           Outbound Rights Advice             January 2007


   permissions granted to use code.

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.  It would be inappropriate and confusing if such
   additional licenses restricted the rights the IETF intends to grant
   in the content of RFCS.

   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.  Specifically, additional text in the document, and any
   additional license referred to by permitted additional text MUST NOT
   in any way restrict the rights the IETF intends to grant to others
   for using the contents of IETF contributions.

   Authors of contributions retain all rights in their contributions.
   As such, an author may directly grant any rights they wish separately
   from what the IETF grants.  However, a reader wishing to determine or
   make use of such grants will need to contact the author directly.


6.  IANA Considerations

   No values are assigned in this document, no registries are created,
   and there is no action assigned to the IANA by this document.  One
   list (of kinds of code sections) is anticipated, to be created and
   maintained by the IASA.  It is up to the IASA whether they create
   such a list and whether they choose to involve the IANA in



Halpern                   Expires July 26, 2007                 [Page 7]


Internet-Draft           Outbound Rights Advice             January 2007


   maintaining that list.


7.  Security Considerations

   This document introduces no new security considerations.  It is a
   process document about the IETFs IPR rights being granted to other
   people.  While there may be attacks against the integrity or
   effectiveness of the IETF processes, this document does not address
   such issues.


8.  References

8.1.  Normative References

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

8.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)
   Self
   P. O. Box 6049
   Leesburg, VA  20178
   US

   Email: jmh@joelhalpern.com









Halpern                   Expires July 26, 2007                 [Page 8]


Internet-Draft           Outbound Rights Advice             January 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.


Acknowledgment

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





Halpern                   Expires July 26, 2007                 [Page 9]


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