Trust rights advice: Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents
What the IETF wants the IETF Trust to let people do with the text and code in its documents.
Halpern, J., Ed., "Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents", RFC 8721, DOI 10.17487/RFC8721, February 2020, <https://www.rfc-editor.org/info/rfc8721>.
@misc{rfc8721,
series = {Request for Comments},
number = 8721,
howpublished = {RFC 8721},
publisher = {RFC Editor},
doi = {10.17487/RFC8721},
url = {https://www.rfc-editor.org/info/rfc8721},
author = {J. Halpern},
title = {{Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents}},
pagetotal = 8,
year = 2020,
month = feb,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Halpern, Ed.
Request for Comments: 8721 Ericsson
Obsoletes: 5377 February 2020
Category: Informational
ISSN: 2070-1721
Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF
Documents
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 accept 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. This document obsoletes RFC 5377 solely for the
purpose of removing references to the IETF Administrative Oversight
Committee (IAOC), which was part of the IETF Administrative Support
Activity (IASA).
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8721.
Copyright Notice
Copyright (c) 2020 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
(https://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 Simplified BSD License.
Table of Contents
1. Introduction
2. Purpose in Granting Rights
3. Powers and Authority
4. Recommended Grants of Right to Copy
4.1. Rights Granted for Reproduction of RFCs
4.2. Rights Granted for Quoting from IETF Contributions
4.3. Rights Granted for Implementing Based on IETF Contributions
4.4. Rights Granted for Use of Text from IETF Contributions
4.5. Additional Licenses for IETF Contributions
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Author's Address
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. This includes the right to make
use of IETF Contributions, as granted by Contributors under the rules
laid out in [RFC5378]. 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 [RFC5378] 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.) that
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
documents such as BCP (Best Current Practice) 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 that 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.
3. Powers and Authority
As described in the introduction, and formally specified in
[RFC5378], 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. 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 IETF Trust License Policy is available from
[TRUST-LEGAL] <https://trustee.ietf.org/docs/IETF-Trust-License-
Policy.pdf>.
To ensure continuity, the starting point for license text and other
materials will be that previously created by the Trustees of the IETF
under the authority of [RFC5377] which this document supersedes.
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
([RFC5378]). While care has been taken by 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
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
circumstance and what limitations should be put on such granting.
These recommendations for outgoing rights are structured around the
assumptions documented in [RFC5378]. 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 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.
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, and 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 that 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 in some way the rights to make such modifications, 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
that 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 deem suitable or as they are
directed by the IETF.
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
thus 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 that 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 either consult external sources
of information, possibly including 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.
6. Security Considerations
This document introduces no new security considerations. It is a
process document about the IETF's 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
[RFC5377] Halpern, J., Ed., "Advice to the Trustees of the IETF
Trust on Rights to Be Granted in IETF Documents",
RFC 5377, DOI 10.17487/RFC5377, November 2008,
<https://www.rfc-editor.org/info/rfc5377>.
[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights
Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
DOI 10.17487/RFC5378, November 2008,
<https://www.rfc-editor.org/info/rfc5378>.
7.2. Informative References
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
<https://www.rfc-editor.org/info/rfc3935>.
[TRUST-LEGAL]
IETF Trust, "Legal Provisions Relating to IETF Documents",
March 2015, <http://trustee.ietf.org/docs/IETF-Trust-
License-Policy.pdf>.
Author's Address
Joel M. Halpern (editor)
Ericsson
P. O. Box 6049
Leesburg, VA 20178
United States of America
Email: joel.halpern@ericsson.com
ISO Plain Language
On this page
§1Who Holds the Rights and Who Decides
Under the current operational and administrative structures, IETF intellectual property rights are vested in the IETF Trust, administered by a board of trustees. This includes the right to make use of IETF Contributions, as granted by contributors under the rules laid out in RFC 5378. 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. The document uses the same terminology and the same meanings as RFC 5378.
The IETF Trust has indicated that it will respect the wishes of the IETF about what the granted rights ought to be, and 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.
The RFC explains that the direction of the rights matters. The recommendations for outgoing rights are structured around the assumptions documented in RFC 5378: this document is about granting rights derived from those granted to the IETF Trust, and 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. The discussion is separate from the rights the IETF itself requires in documents to do its job, because those are not outbound rights, and it is expected that the rights granted to the IETF will be a superset of those copying rights the IETF wishes to grant to others.
There are two steps. First, the author gives the Trust permission to pass the work on. Second, the Trust passes rights on to everyone else. This document is about the second step, and about the limits the IETF wants the Trust to keep in mind when making it.
- Rights to use IETF Contributions
- Inbound Contributors grant rights to the IETF Trust, as set out in RFC 5378
- Outbound The IETF Trust grants rights to users. This document describes these
§2Why These Rights Are Granted
The mission of the IETF is to produce documents that make the Internet work better. An important subclass of RFCs is standards describing protocols, and for these the primary value to the Internet is the ability of implementors to build solutions, whether products or software, that interoperate using these standards. The IETF therefore has a strong interest in seeing accurate, interoperable implementations of the material it publishes, and the IETF Trust grants rights to copy to people who make use of the text in RFCs in order to encourage exactly that.
As early implementations drawn from Internet-Drafts make use of descriptions in those drafts, similar desires apply to Internet-Drafts. The same considerations apply to non-standard, non-protocol documents such as Best Current Practice and Informational documents, and in this document the RFC recommends a common approach to the issue of right-to-use licences for all IETF documents.
The reason is interoperability. A standard is only useful if independent teams can build things that work together, and that requires them to be free to copy the text and to build on the machine-readable parts of it. The same reasoning applies to drafts and to documents that are not standards at all.
§3Powers and Authority
The legal authority for determining and granting users rights to copy material in RFCs and other IETF Contributions rests with the Trustees of the IETF Trust, and this document provides guidance to that body, based on the rough consensus of the IETF. The Trustees have the authority and responsibility to determine the exact text insertions, or other mechanisms, needed in Internet-Drafts, RFCs and all IETF Contributions to meet these goals.
Earlier documents included the specific licence wording in the RFC text itself. The RFC says 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, and at best this delays fixing legal issues that need prompt attention. This document therefore describes the IETF's desires to the Trustees but does not provide the specific legal wording to address the goals, and the selection and updating as necessary of that wording is left to the Trustees. To ensure continuity, the starting point for licence text and other materials will be that previously created by the Trustees under the authority of RFC 5377, which this document supersedes. Changes to the IETF documentation and to document policies themselves take effect as determined by the Trustees.
One limit is stated plainly. The document does not specify what rights the IETF Trust receives from others in IETF Contributions, which is left to RFC 5378, and the Trust cannot grant rights it has not received. Likewise, the rights granted for pre-existing documents cannot be expanded unless the holders of rights in those contributions choose to grant expanded rights, although to the degree it can, without embarking on a massive effort, it is desirable if similar rights can be granted in older RFCs.
The Trust's lawyers write the actual licence wording; this document tells them what it should achieve. That separation exists because a wording mistake in an RFC can only be fixed by revising the RFC, which is slow, and the same mistake can be fixed in the licence policy without touching the document at all.
§4.1Copying RFCs and Quoting from Contributions
It has long been IETF policy to encourage copying of RFCs in full, because 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.
For quoting, there is rough consensus that it is useful to permit quoting without modification of excerpts from IETF Contributions. Such excerpts may be of any length and in any context, and translation of quotations is also to be permitted. All such quotations should be attributed properly to the IETF and to the IETF Contribution from which they are taken.
For the running text there is no consensus at this time to permit its use 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.
On additional licences, there have been contexts where the material in an IETF Contribution is also available under other licence terms, and the IETF wishes to be able to include content that is available under such licences, and it is desirable to indicate in the Contribution that other licences are available. It would be inappropriate and confusing if such additional licences restricted the rights the IETF intends to grant in the content of RFCs. The IETF does not wish to have contributions contain additional licences, because additional text in the document, and any additional licence referred to by permitted additional text, must not in any way restrict the rights the IETF intends to grant to others. Authors of contributions retain all rights in their contributions, so an author may grant any rights they wish separately from what the IETF grants, but a reader wishing to use such grants will need to consult external sources of information or contact the author directly.
Copying a whole RFC and translating it are both fine. Quoting a passage is fine, of any length, with the source named. What is not licensed is rewriting the prose of a specification: if you need to change it, you have to ask the author. A document may also point at another licence for the material, but only if that licence takes nothing away from what the IETF grants.
- Reproduction of RFCsAnyone may make full copies and translations of RFCs, so the material spreads without losing its context.
- Quoting from ContributionsExcerpts of any length and in any context, without modification, with translation permitted and proper attribution to the IETF.
- Using the running textNo consensus to permit use of RFC text where the right to modify it is required. Authors may grant that themselves.
- Additional licencesOther licences may be named in a contribution, but they must not restrict the rights the IETF grants.
§4.3Code Components
IETF Contributions often include components intended to be directly processed by a computer. These include ABNF definitions, XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, MIBs, ASN.1, and classical programming code. They are included for clarity and precision in specification, and it is clearly beneficial to permit their inclusion in products that implement the contribution.
Use of such code requires the ability to modify it. One common example is the need to adapt code for specific contexts such as languages, compilers and tool systems, which frequently requires some changes to the text of the code. Another example is that code included in open source products is frequently licensed to permit any and all of the code to be modified, and since the IETF wants this code included in such products, it follows that such modification must be permitted. While there has been discussion of restricting in some way the rights to make such modifications, the rough consensus of the IETF is that such restrictions are likely a bad idea and are certainly very complex to define.
The rough consensus is therefore 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 Trust should avoid adding software licence obligations beyond those already present in a contribution. The granted rights should allow creation of derived works outside the IETF that may carry additional licence obligations. As the Trust cannot grant rights it does not receive, these rights cannot be granted in contributions that are explicitly marked as not permitting derivative works.
Two mechanisms are suggested to document the intended grant to readers and users. The Trustees should maintain, in an easily accessible fashion, a list of common RFC components that will be considered to be code, starting with at least the items listed above and added to as they deem suitable or as directed by the IETF. And the Trustees 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, later the working group and upon approval the IETF, to be code and thus subject to the permissions granted to use code.
Some parts of an RFC are meant to be run by a computer: the grammar rules, the schema files, the tables of numbers, the code samples. The Trust should let anyone take those, change them, and use them however they like, including inside products with their own licence terms. The Trust is also asked to keep a published list of what counts as code, and to define a marker that authors can put in a document to say that a section is code.
- ABNF definitionsGrammar rules that a parser can process.
- XML SchemasMachine-readable descriptions of XML documents.
- XML DTDsDocument type definitions for XML.
- XML RelaxNG definitionsAnother machine-readable schema language for XML.
- Tables of valuesTables of numbers and codes that a program can read.
- MIBsManagement information base definitions.
- ASN.1Abstract syntax notation definitions.
- Classical programming codeCode written in an ordinary programming language.
§5IANA and the Security Note
No values are assigned in this document, no registries are created, and there is no action assigned to IANA. One list, of kinds of code sections, is anticipated, to be created and maintained by the Trustees of the IETF Trust, and it is up to the Trustees whether they create such a list and whether they choose to involve IANA in maintaining it.
The Security Considerations section says the document introduces no new security considerations. It is a process document about the IETF's intellectual property rights being granted to other people, and while there may be attacks against the integrity or effectiveness of the IETF processes, the document does not address such issues.
Nothing is registered with IANA here. The only list envisaged is the one of code section types, and the Trust decides whether to keep it and whether IANA should help. On security, the document simply says it is about process and not about security.