diff options
Diffstat (limited to 'doc/rfc/rfc8721.txt')
| -rw-r--r-- | doc/rfc/rfc8721.txt | 349 |
1 files changed, 349 insertions, 0 deletions
diff --git a/doc/rfc/rfc8721.txt b/doc/rfc/rfc8721.txt new file mode 100644 index 0000000..674366a --- /dev/null +++ b/doc/rfc/rfc8721.txt @@ -0,0 +1,349 @@ + + + + +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 |