[Docs] [txt|pdf|xml|html] [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: January 13, 2009                                  July 12, 2008


Advice to the Trustees of the IETF Trust on Rights to be Granted in IETF
                               Documents
                   draft-ietf-ipr-outbound-rights-07

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 January 13, 2009.

Abstract

   Contributors grant intellectual property rights to the IETF.  The
   IETF Trust holds and manages those rights on behalf of the IETF.  The
   Trustees of the IETF Trust are responsible for that management.  This
   management includes granting the licenses to copy, implement and
   otherwise use IETF contributions, among them Internet-Drafts and
   RFCs.  The Trustees of the IETF Trust 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 January 13, 2009                [Page 1]

Internet-Draft           Outbound Rights Advice                July 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Purpose in Granting Rights  . . . . . . . . . . . . . . . . . . 3
   3.  Powers and Authority  . . . . . . . . . . . . . . . . . . . . . 4
   4.  Recommended Grants of Right to Copy . . . . . . . . . . . . . . 5
     4.1.  Rights Granted for Reproduction of RFCs . . . . . . . . . . 5
     4.2.  Rights Granted for Quoting from IETF Contributions  . . . . 5
     4.3.  Rights Granted for Implementing based on IETF
           Contributions . . . . . . . . . . . . . . . . . . . . . . . 6
     4.4.  Rights Granted for use of text from IETF Contributions  . . 7
     4.5.  Additional Licenses for IETF Contributions  . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
































Halpern                 Expires January 13, 2009                [Page 2]

Internet-Draft           Outbound Rights Advice                July 2008


1.  Introduction

   Under the current operational and administrative structures, IETF
   intellectual property rights are vested in the IETF Trust
   administered by a board of trustees made up of the members of the
   IAOC [RFC4371].  This includes the right to make use of IETF
   contributions, as granted by contributors under the rules laid out in
   [InboundRights].  The Trustees of the IETF Trust are 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.

   For consistency and clarity, this document uses the same terminology
   laid out in [InboundRights] and uses the same meanings as defined in
   that document.

   The IETF Trust, by way of its Trustees, has indicated, as is
   consistent with the IETF structure, that it will respect the wishes
   of the IETF in regard to what these granted rights ought to be.  It
   is therefore the IETF's 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
   superseded.


2.  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 mission of the IETF is to produce documents that make the
   Internet work better (see [RFC3935] 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 using these standards.  Hence, the IETF has a strong
   interest in seeing accurate, interoperable implementations of the
   material the IETF publishes.  The IETF Trust grants 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



Halpern                 Expires January 13, 2009                [Page 3]

Internet-Draft           Outbound Rights Advice                July 2008


   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.

   Previous documents regarding rights in IETF documents have included
   in the RFC text specific text to be used to achieve the stated goals.
   This has proved problematic.  When problems are found with such text,
   even when the problem is not a change in intent, it is necessary to
   revise the RFC to fix the problem.  At best this delays fixing legal
   issues which need prompt attention.  As such, this document describes
   the IETF desires to the Trustees of the IETF Trust, but does not
   provide the specific legal wording to address the goals.  The
   selection, and updating as necessary, of legal wording is left to the
   Trustees of the IETF Trust.  Appeals of the actions of the Trustees
   of the IETF Trust are governed by other documents.  As the Trustees
   are the members of the IAOC, the appeals procedure documented in BCP
   101 (currently [RFC4371]) is applicable.


3.  Powers and Authority

   As described in the introduction, and formally specified in
   [InboundRights], the legal authority for determining and granting
   users rights to copy material in RFCs and other IETF contributions
   rests with the Trustees for the IETF Trust, which is made up of the
   members of the IAOC, as described in [RFC4071] and [RFC4371].  This
   document provides guidance to that body, based on the rough consensus
   of the IETF.  The trustees of the IETF Trust have the authority and
   responsibility to determine the exact text insertions (or other
   mechanisms), if any, needed in Internet-Drafts, RFCs, and all IETF
   Contributions to meet these goals.

   The rough consensus described in this document reflects the agreement
   of the IETF as of the IETF Last call, and the Trustees of the IETF
   Trust are to begin drafting license text and other materials to act
   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 Trustees of the
   IETF Trust.

   This document does not specify what rights the IETF Trust receives
   from others in IETF contributions.  That is left to another document
   ([InboundRights]).  While care has been taken the working group in
   developing this document, and care will be taken by the Trustees of
   the IETF Trust, 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 rights



Halpern                 Expires January 13, 2009                [Page 4]

Internet-Draft           Outbound Rights Advice                July 2008


   granted for pre-existing documents can not be expanded unless the
   holders of rights in those contributions choose to grant expanded
   rights.  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.


4.  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 usage, to describe how that usage
   is recognizable, and to provide guidance to the Trustees of the IETF
   Trust as to what rights the IETF would like to see granted in that
   circumstances, and what limitations should be put on such granting.

   These recommendations for outgoing rights are structured around the
   assumptions documented in [InboundRights].  Thus, this document is
   about granting rights derived from those granted to the IETF Trust.
   The recommendations below are how those granted rights should in turn
   be passed on to others using IETF documents in ways and for purposes
   that fit with the goals of the IETF.  This discussion is also
   separate from discussion of 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.

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

4.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 contribution from which
   they are taken.






Halpern                 Expires January 13, 2009                [Page 5]

Internet-Draft           Outbound Rights Advice                July 2008


4.3.  Rights Granted for Implementing based on IETF Contributions

   IETF contributions often include components intended to be directly
   processed by a computer.  Examples of these include ABNF definitions,
   XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
   MIBs, ASN.1, or classical programming code.  These are included in
   IETF contributions 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 components 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 of the IETF 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.  To
   enable the broadest possible extraction, modification and usage, the
   IETF Trust should avoid adding software license obligations beyond
   those already present in a contribution.  The granted rights to
   extract, modify and use code should allow creation of derived works
   outside the IETF that may carry additional license obligations.  As
   the IETF Trust can not grant rights it does not receive, the rights
   to extract, modify and use code described in this paragraph can not
   be granted in IETF contributions that are explicitly marked as not
   permitting derivative works.

   While it is up to the Trustees of the IETF Trust 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 Trustees of the IETF Trust 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.  The Trustees of the IETF
   Trust will add to this list as they deems suitable or as it is
   directed by the IETF.




Halpern                 Expires January 13, 2009                [Page 6]

Internet-Draft           Outbound Rights Advice                July 2008


   Additionally, the Trustees of the IETF Trust should define a textual
   representation to be included in an IETF contribution 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 permissions granted to use code.

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

4.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 licenses, as that introduces a number of additional
   difficulties.  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 consult external sources of
   information, including possibly open source code and documents, or
   contact the author directly.


5.  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 Trustees of the IETF Trust.  It is up to the
   Trustees of the IETF Trust whether they create such a list and
   whether they choose to involve the IANA in maintaining that list.




Halpern                 Expires January 13, 2009                [Page 7]

Internet-Draft           Outbound Rights Advice                July 2008


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


7.  References

7.1.  Normative References

   [InboundRights]
              Bradner, S. and J. Contreras, "I-D.ietf-ipr-3978-incoming-
              09.txt", 2006.

7.2.  Informative References

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

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

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


Author's Address

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

   Email: jmh@joelhalpern.com












Halpern                 Expires January 13, 2009                [Page 8]

Internet-Draft           Outbound Rights Advice                July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.











Halpern                 Expires January 13, 2009                [Page 9]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/