Independent Stream Rights: Procedures for Rights Handling in the RFC Independent Submission Stream
The copyright rules for Independent Submission RFCs: what authors grant, and what readers may do with the text.
Braden, R. and J. Halpern, "Procedures for Rights Handling in the RFC Independent Submission Stream", RFC 5744, DOI 10.17487/RFC5744, December 2009, <https://www.rfc-editor.org/info/rfc5744>.
@misc{rfc5744,
series = {Request for Comments},
number = 5744,
howpublished = {RFC 5744},
publisher = {RFC Editor},
doi = {10.17487/RFC5744},
url = {https://www.rfc-editor.org/info/rfc5744},
author = {R. Braden and J. Halpern},
title = {{Procedures for Rights Handling in the RFC Independent Submission Stream}},
pagetotal = 6,
year = 2009,
month = dec,
} RFC text
Contents
Network Working Group R. Braden
Request for Comments: 5744 ISI
Updates: 4846 J. Halpern
Category: Informational Ericsson
December 2009
Procedures for Rights Handling in
the RFC Independent Submission Stream
Abstract
This document specifies the procedures by which authors of RFC
Independent Submission 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 . . . . . . . . . . . 4
5. Procedures Requested of the IETF Trust . . . . . . . . . . . . 4
6. Patent and Trademark Rules for the Independent Submission
Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction
As the IETF has grown, the process and the community have gotten 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.
This document defines the copyright procedures for RFC Independent
Submission documents. It parallels the procedures for IETF-produced
documents defined in [RFC5377] and [RFC5378].
In summary, submissions in the Independent Submission 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
Independent Submission documents, and it explicitly requests the IETF
Trust to manage the rights in accordance with this advice.
This document also specifies the policies regarding the disclosure of
Patents and Trademarks that may be relevant to a submission intended
for the Independent Submission stream.
2. Background
The concept of RFC streams in general, and the Independent Submission
stream in particular, are described in Section 5 of [RFC4844] and in
RFC 4846 [RFC4846]. In general terms, the Independent Submission
stream continues the long-established tradition in the Internet
community of allowing and encouraging the RFC Editor to publish
documents that are relevant to the community but are not products of,
and do not conflict with, the IETF process. These may be comments on
IETF documents or they may be other work relevant to the Internet
that, historically, the RFC Editor has chosen to publish.
With the publication of [RFC5620], the IETF began a process shift in
which the responsibility for Independent Submission stream
publication will move to an individual designated by the IAB as the
Independent Submission Editor (ISE).
Section 8 of RFC 4846 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.
3. Goals
The goal of the RFC Independent Submission stream is to publish
information that is intended to advance the state of the art and the
interoperability of solutions for use in conjunction with the
Internet. As specified in Section 8 of RFC 4846, the community has
determined that this objective will best be met with a liberal
copyright policy on Independent Submission documents. Therefore, the
Independent Submission 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". (It should be noted
that this liberal policy was always followed by the original RFC
Editor, Jon Postel; in a sense, the present document is a
formalization of a 30-year-old policy on RFC copyrights.)
However, for a small subset of documents published as Independent
Submissions, it is not reasonable to permit unlimited derivative
works. Examples are proprietary protocols and output from other
standards bodies. In such cases, authors are permitted to request
that the published Independent Submission documents permit no
derivative works.
Note also that this unlimited derivative works policy applies to all
parts of an Independent Submission document, including any code.
Therefore, no separate licensing procedure is required for extracting
and adapting code that is contained in an Independent Submission
document submitted under the (preferred) unlimited derivative works
terms. On the other hand, code may not be extracted and adapted from
Independent Submission documents submitted under the no derivative
works terms.
4. Rules for Submission and Use of Material
Independent Submission 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 Independent Submission 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 indicate that, in cooperation with the
Independent Submission Editor, the Trust grants to readers and users
of material from Independent Submission documents the right to make
unlimited derivative works, unless the document specifies that no
derivative works are permitted. This will permit anyone to copy,
extract, modify, or otherwise use material from Independent
Submission documents as long as suitable attribution is given.
Contributors of Internet-Drafts intended for the Independent
Submission stream will include suitable 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.
It should be understood that the final publication decision for the
Independent Submission stream rests with the Independent Submission
Editor (ISE). Compliance with these terms is not a guarantee of
publication. In particular, the ISE may question the appropriateness
of a "no derivative works" restriction requested by an author. The
appropriateness of such usage must be negotiated among the authors
and the ISE.
5. Procedures Requested of the IETF Trust
The Independent Submission Editor 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 Independent Submission stream. They are also requested to
indicate their willingness and intent to work according to the
procedures and goals defined by the ISE.
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 documents to grant 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 Independent Submission Stream
As specified above, contributors of documents for the Independent
Submission 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, by 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 Independent Submission stream has chosen to use the IETF's IPR
disclosure mechanism, www.ietf.org/ipr/, for this purpose. The
Independent Submission Editor would prefer the most liberal terms
possible be made available for specifications published as
Independent Submission 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, there are no specific requirements
on the licensing terms for intellectual property related to
Independent Submission publication.
7. Security Considerations
The integrity and quality of the Independent Submission stream are
the responsibility of the Independent Submission Editor. 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., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
[RFC4846] Klensin, J. and D. Thaler, "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. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC5620] Kolkman, O. and IAB, "RFC Editor Model (Version 1)",
RFC 5620, August 2009.
8.2. Informative References
[RFC5377] Halpern, J., "Advice to the Trustees of the IETF Trust on
Rights to Be Granted in IETF Documents", RFC 5377,
November 2008.
Authors' Addresses
Robert Braden
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
US
EMail: braden@isi.edu
Joel M. Halpern
Ericsson
P. O. Box 6049
Leesburg, VA 20178
US
EMail: jhalpern@redback.com
AI ELI5
On this page
§1Background and Purpose
The Independent Submission stream continues the tradition of letting the RFC Editor publish documents relevant to the Internet community that are not products of, and do not conflict with, the IETF process. They may be comments on IETF documents or other relevant work.
RFC 5744 defines copyright procedures for these documents, in parallel with those for IETF documents in RFC 5377 and RFC 5378. It is meant to be fully consistent with Section 8 of RFC 4846 and updates it by clarifying the formal procedures the IETF Trust will use. The Independent Submission Editor (ISE) takes over responsibility for the stream, following RFC 5620.
Some RFCs come from individuals outside the main committees. This note sets the copying rules for those, matching how the other RFCs work.
§2Goals: A Liberal Copyright Policy
The stream aims to publish information that advances the state of the art and the interoperability of Internet solutions. The community decided a liberal copyright policy serves that best: any reader may use the content in any manner, with the only restriction being proper credit, or attribution. Lawyers call this permitting unlimited derivative works. The RFC notes it formalizes a 30-year-old policy followed by Jon Postel.
The policy covers all parts of a document, including code, so no separate license is needed to extract and adapt code from a document under the unlimited terms.
For a small subset, such as proprietary protocols or output from other standards bodies, authors may ask for a no derivative works restriction. Code cannot be extracted and adapted from those documents.
The default is generous: use it however you like, just give credit. A few special documents can say 'look but do not remix'.
§3How Authors Submit and Readers Use Material
Authors submit Internet-Drafts to the IETF Internet-Drafts repository like any IETF draft, and grant rights as described in RFC 5378. To ask for a no-derivative-works RFC, an author may use the form specified for RFC 5378.
The IETF Trust, in cooperation with the ISE, grants readers the right to make unlimited derivative works unless the document says otherwise. Drafts include boilerplate from the IETF Trust that indicates RFC 5378 compliance and states either that no derivative works may be based on the contribution or, as preferred, that unlimited derivative works are allowed.
Compliance is not a guarantee of publication. The final decision rests with the ISE, who may question a no-derivative-works request, and the matter is negotiated among the authors and the ISE.
Authors tick a box saying how others may reuse their work, and the editor decides whether the paper gets printed at all.
§4What Is Asked of the IETF Trust
The ISE asks the IETF Trust and its Trustees to publicly confirm that they can and will accept responsibility for the intellectual property rights of the stream and will work according to the procedures defined by the ISE.
The Trustees are asked to develop boilerplate so the Trust receives the rights specified in RFC 5378, and so documents can grant either no derivative-works rights or, preferably, unlimited derivative-works rights. How this is indicated in each document is left to the Trust.
The editor asks the group that looks after the rights to write the standard wording and to take care of the paperwork.
§5Patents, Trademarks and Security
Contributors follow the Internet-Draft process under the rules of BCP 9, then RFC 2026. This includes disclosing known or reasonably knowable patent and trademark issues, and, as requested by BCP 79 (then RFC 3979, updated by RFC 4879), disclosing license terms. The stream uses the IETF IPR disclosure mechanism.
The ISE prefers the most liberal terms possible, ideally without fees or licensing and non-discriminatory, but there are no specific requirements on licensing terms.
The Security Considerations say the integrity and quality of the stream are the ISE's responsibility, and this document does not change that.
Authors must tell everyone about any patents or trademarks that might get in the way. The editor hopes for the friendliest terms, but does not force them.