RFC 5745 INFORMATIONAL COPYRIGHT · IAB · PROCESS

IAB Stream Rights: Procedures for Rights Handling in the RFC IAB Stream

What authors give, and what readers may do, with the text of RFCs published through the IAB stream.

On rfc-editor.org ↗
PUBLISHED
December 2009
AUTHORS
A. Malis, IAB
STREAM
IAB
DEFAULT READER RIGHTS
Unlimited derivative works, with attribution
ALTERNATIVE
No derivative works, on author request
AUTHOR RIGHTS GRANTED AS IN
RFC 5378
UPDATES
RFC 4846
DOI
10.17487/RFC5745

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                      A. Malis, Ed.
Request for Comments: 5745                                   For the IAB
Updates: 4846                                              December 2009
Category: Informational


          Procedures for Rights Handling in the RFC IAB Stream

Abstract

This document specifies the procedures by which authors of RFC IAB
stream documents grant the community "incoming" rights for copying and
using the text.  It also specifies the "outgoing" rights the community
grants to readers and users of those documents, and it requests that the
IETF Trust manage the outgoing rights to effect this result.

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Rules for Submission and Use of Material  . . . . . . . . . . . 3
   5.  Procedures Requested of the IETF Trust  . . . . . . . . . . . . 4
   6.  Patent and Trademark Rules for the IAB Stream . . . . . . . . . 4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
   10. IAB Members at the Time of This Writing . . . . . . . . . . . . 6

1.  Introduction

   As the IETF has grown, the process and the community have become more
   careful about defining the rights relating to copying documents that
   are granted by authors to the community, and the corresponding rights
   that are granted by the community to readers and users of these
   documents.  The creation of the IETF Trust [RFC4371], with its
   special role in managing intellectual property rights (IPR), has also
   increased the need to be explicit about these rights and decisions.

   This document defines the copyright procedures for RFC IAB stream
   documents.  It parallels the procedures for IETF-produced documents
   defined in RFC 5377 [RFC5377] and RFC 5378 [RFC5378].

   In summary, submissions in the IAB stream use the same submission
   procedures and mechanisms that are defined in RFC 5378, and hence
   require the same "incoming rights" as IETF-stream documents.  This
   document provides advice to the Trustees of the IETF Trust on
   "outgoing" rights to be granted to readers and users of IAB stream
   documents, and it explicitly requests the IETF Trust to manage the
   rights in accordance with this advice.

   This document also specifies the policies with regard to the
   disclosure of Patents and Trademarks that may be relevant to a
   submission intended for the IAB stream.

2.  Background

   The concept of RFC streams in general, and the IAB stream in
   particular, is described in Section 5 of RFC 4844 [RFC4844].

   Section 8 of RFC 4846 [RFC4846] presented the copyright rules for the
   Independent Submission stream.  The present document is intended to
   be fully consistent with that section, and to update it by clarifying
   the formal procedures that the IETF Trust will use to effect those
   rules.  In particular, it is the intention of this document to make
   the copyright rules for IAB stream documents identical to those for
   Independent Submission stream documents.

3.  Goals

   The goal of the IAB stream of RFCs is to publish information from the
   IAB to the Internet community.  Consistent with the principle stated
   for the Independent Submission stream in Section 8 of RFC 4846, this
   objective will best be met with a liberal copyright policy on IAB
   stream documents.  Therefore, the IAB stream policy is to allow any
   individual reading such documents to use the content thereof in any
   manner.  The only restriction is that proper credit ("attribution")
   must be given.  Lawyers describe this liberal policy by saying that
   this stream normally permits "unlimited derivative works".  The only
   additional restriction for the use of IAB documents is that proper
   credit ("attribution") must be given.

   However, for a small subset of documents published as IAB stream
   documents, such as output from other standards bodies, it is not
   reasonable to permit unlimited derivative works.  In such cases,
   authors are permitted to request that the published IAB stream
   documents permit no derivative works.

   Note also that this unlimited derivative works policy applies to all
   parts of an IAB stream document, including any code.  Therefore, no
   separate licensing procedure is required for extracting and adapting
   code that is contained in an IAB stream document submitted under the
   (preferred) unlimited derivative works terms.  On the other hand,
   code may not be extracted and adapted from IAB stream documents
   submitted under the "no derivative works" terms.

4.  Rules for Submission and Use of Material

   IAB stream authors will submit their material as Internet-Drafts.
   These drafts will be submitted to, and stored in, the IETF Internet-
   Drafts repository in the same fashion as IETF Internet-Drafts.

   During Internet-Draft submission, authors who intend to submit their
   document for publication in the IAB stream will grant rights as
   described in [RFC5378].  To request that the contribution be
   published as an RFC that permits no derivative works, an author may
   use the form specified for use with RFC 5378.

   The IETF Trust will publish rules that provide that the Trust grants
   to readers and users of material from IAB stream RFCs the right to
   make unlimited derivative works, unless the RFC specifies that no
   derivative works are permitted.  This will permit anyone to copy,
   extract, modify, or otherwise use material from IAB stream RFCs as
   long as suitable attribution is given.

   Contributors of Internet-Drafts intended for the IAB stream will
   include the appropriate boilerplate defined by the IETF Trust.  This
   boilerplate shall indicate compliance with RFC 5378 and shall
   explicitly indicate either that no derivative works can be based on
   the contribution, or, as is preferred, that unlimited derivative
   works may be crafted from the contribution.

5.  Procedures Requested of the IETF Trust

   The IAB requests that the IETF Trust and its Trustees assist in
   meeting the goals and procedures set forth in this document.

   The Trustees are requested to publicly confirm their willingness and
   ability to accept responsibility for the Intellectual Property Rights
   for the IAB stream.

   Specifically, the Trustees are asked to develop the necessary
   boilerplate to enable the suitable marking of documents so that the
   IETF Trust receives the rights as specified in RFC 5378.  These
   procedures need to also allow authors to indicate either no rights to
   make derivative works, or preferentially, the right to make unlimited
   derivative works from the documents.  It is left to the Trust to
   specify exactly how this shall be clearly indicated in each document.

6.  Patent and Trademark Rules for the IAB Stream

   As specified above, contributors of documents for the IAB stream are
   expected to use the IETF Internet-Draft process, complying therein
   with the rules specified in the latest version of BCP 9, whose
   version at the time of writing was [RFC2026].  This includes the
   disclosure of Patent and Trademark issues that are known, or can be
   reasonably expected to be known, to the contributor.

   Disclosure of license terms for patents is also requested, as
   specified in the most recent version of BCP 79.  The version of BCP
   79 at the time of this writing was [RFC3979], updated by [RFC4879].
   The IAB stream has chosen to use the IETF's IPR disclosure mechanism,
   www.ietf.org/ipr/, for this purpose.  The IAB would prefer the most
   liberal terms possible be made available for IAB stream documents.
   Terms that do not require fees or licensing are preferable.  Non-
   discriminatory terms are strongly preferred over those that
   discriminate among users.  However, although disclosure is required
   and the IAB may consider disclosures and terms in making a decision
   as to whether to submit a document for publication, there are no
   specific requirements on the licensing terms for intellectual
   property related to IAB stream publication.

7.  Security Considerations

   The integrity and quality of the IAB stream are the responsibility of
   the IAB.  This document does not change those responsibilities.

8.  References

8.1.  Normative References

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

   [RFC3979]  Bradner, S., Ed., "Intellectual Property Rights in IETF
              Technology", BCP 79, RFC 3979, March 2005.

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


   [RFC4844]  Daigle, L., Ed., and Internet Architecture Board, "The RFC
              Series and RFC Editor", RFC 4844, July 2007.

   [RFC4846]  Klensin, J., Ed., and D. Thaler, Ed., "Independent
              Submissions to the RFC Editor", RFC 4846, July 2007.

   [RFC4879]  Narten, T., "Clarification of the Third Party Disclosure
              Procedure in RFC 3979", BCP 79, RFC 4879, April 2007.

   [RFC5378]  Bradner, S., Ed., and J. Contreras, Ed., "Rights
              Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
              November 2008.

8.2.  Informative References

   [RFC5377]  Halpern, J., Ed., "Advice to the Trustees of the IETF
              Trust on Rights to Be Granted in IETF Documents", RFC
              5377, November 2008.

   [RFC5744]  Braden, R. and J. Halpern, "Procedures for Rights Handling
              in the RFC Independent Submission Stream", RFC 5744,
              December 2009.

9.  Acknowledgements

   The author wishes to acknowledge that the majority of text of this
   document was derived from [RFC5744], and wishes to thank the authors
   of that document.

10.  IAB Members at the Time of This Writing

   Marcelo Bagnulo
   Gonzalo Camarillo
   Stuart Cheshire
   Vijay Gill
   Russ Housley
   John Klensin
   Olaf Kolkman
   Gregory Lebovitz
   Andrew Malis
   Danny McPherson
   David Oran
   Jon Peterson
   Dave Thaler

Author's Address

   Andrew G. Malis
   Verizon Communications
   117 West St.
   Waltham, MA 02451
   USA

   EMail: andrew.g.malis@verizon.com


   IAB

   EMail: iab@iab.org

AI ELI5

On this page
PROBLEMAs the IETF grew and the IETF Trust took on a role managing intellectual property rights, the rights for RFCs from the IAB stream had to be spelled out.
MECHANISMAuthors grant rights as in RFC 5378, readers get the right to make unlimited derivative works with attribution unless the RFC says otherwise, and the IAB asks the IETF Trust to manage this.
WHY IT MATTERSThe copyright rules for IAB stream documents are made identical to those for Independent Submission stream documents.

§1Introduction and Background

The IETF community has become more careful about defining the rights authors grant to the community for copying documents, and the rights the community grants back to readers. Creating the IETF Trust (RFC 4371) increased the need to be explicit.

This document defines the copyright procedures for RFC IAB stream documents and parallels the procedures for IETF-produced documents in RFC 5377 and RFC 5378. The RFC streams are described in RFC 4844. The text is meant to be consistent with the Independent Submission rules in Section 8 of RFC 4846, and to update that section by clarifying the formal procedures the IETF Trust will use.

People now care more about who may copy what. This note writes down the rules for documents from the Internet Architecture Board.

§3Goals: A Liberal Copyright Policy

The goal of the IAB stream is to publish information from the IAB to the Internet community, and the RFC argues this is best met with a liberal policy. Any reader may use the content in any manner, and the only restriction is that proper credit (attribution) is given. Lawyers call this permitting unlimited derivative works.

A small subset of documents, such as output from other standards bodies, cannot reasonably allow that. Authors may request that such a document permit no derivative works.

The unlimited policy covers all parts of a document, including code, so no separate licensing step is needed to extract and adapt code. Code in a no-derivative-works document may not be extracted and adapted.

Most of the time you can copy and change the text as long as you say who wrote it. A few documents are marked do-not-change.

§4Rules for Submission and Requests to the IETF Trust

IAB stream authors submit Internet-Drafts to the same IETF repository as other drafts. At submission they grant rights as described in RFC 5378, and may use the form specified for that RFC to ask for publication with no derivative works. Drafts carry boilerplate defined by the IETF Trust that indicates compliance with RFC 5378 and says either that no derivative works are allowed or, as preferred, that unlimited ones are.

The IETF Trust is expected to publish rules granting readers the right to make unlimited derivative works unless the RFC says otherwise. The IAB also asks the Trustees to publicly confirm their willingness to take responsibility for the rights in the IAB stream and to develop the boilerplate. How this is shown in each document is left to the Trust.

Authors hand in their work with a label saying how it can be reused, and the Trust, which looks after the rights, makes the label and the rules.

§6Patent and Trademark Rules

Contributors use the IETF Internet-Draft process and must follow BCP 9 (RFC 2026 at the time of writing), including disclosing Patent and Trademark issues that are known or reasonably should be known to them. Disclosure of license terms is also requested under BCP 79, which at the time was RFC 3979, updated by RFC 4879.

The IAB stream uses the IETF IPR disclosure mechanism. The IAB would prefer the most liberal terms, without fees or licensing, and non-discriminatory terms are strongly preferred. There are no specific requirements on licensing terms for IAB stream publication.

If someone owns an idea that the document needs, they must say so. The IAB likes it best when that idea is free to use, but does not force it.

§7Security Considerations

The integrity and quality of the IAB stream are the responsibility of the IAB. The RFC states that this document does not change those responsibilities.

The IAB is still in charge of keeping its documents good and correct, and this note does not change that.

§6References