RFC 8721

Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents

📅 published February 2020, from ietf

Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents 💖

RFC 8721 🦋 Title: Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents Series: Internet Engineering Task Force (IETF) Editor: J. Halpern, Ed. (Ericsson) 💅 Date: February 2020 📅 Category: Informational 🎀 Obsoletes: RFC 5377 (only to remove references to the IAOC, which was part of IASA) 🧹 Updates: nothing 🙅‍♀️ ISSN: 2070-1721 ✨

Abstract 🌸

Okay so contributors give intellectual property rights to the IETF, and the IETF Trust holds and manages them for the IETF. The Trustees of the IETF Trust are the ones in charge of that management, which includes licensing people to copy, implement, and otherwise use IETF Contributions like Internet-Drafts and RFCs. The Trustees take direction from the IETF about which rights to grant. This document is the IETF's wish list for the outbound rights granted in IETF Contributions 💜. It also obsoletes RFC 5377, but only to delete references to the IETF Administrative Oversight Committee (IAOC), which was part of the IETF Administrative Support Activity (IASA). Bye bye, old names 👋.

Status of This Memo 📝

This one is not an Internet Standards Track spec, so don't go looking for it in that category. It's published for informational purposes 🧚.

This document is a product of the Internet Engineering Task Force (IETF). It reflects the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious about that 🤓.

If you want the latest on this document's status, any errata, or how to send feedback, go to https://www.rfc-editor.org/info/rfc8721 🔗.

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), as they stand on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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 ✨

Okay so the IETF's intellectual property rights are vested in the IETF Trust, which is run by a board of trustees. That includes the right to use IETF Contributions, which contributors grant under the rules in [RFC5378] 🦋. That means the Trustees are the ones responsible for deciding which copying rights the IETF hands out to people who want to use the material in these documents 💅.

For consistency and clarity, this document uses the same terminology as [RFC5378], with the same meanings 📚.

The IETF Trust, through its Trustees, has said (in a way that fits how the IETF is structured) that it will respect the IETF's wishes about what these granted rights should be. So it's the IETF's job to spell those wishes out, and that's exactly what this document does 🫶. It stays the go-to statement of the IETF's wishes about rights granted to all users in IETF Contributions until it gets superseded 👑.

2. Purpose in Granting Rights 🎀

Before we get into the wishlist, it helps to remember why we grant these rights at all 🧠.

The IETF's mission is to produce documents that make the Internet work better (see [RFC3935] for more details). Once those documents are finished, they get published as RFCs 🌈.

A big, important subclass of RFCs is the standards that describe protocols. For those, the main value to the Internet is that implementers can build products, software, and so on that interoperate with each other using those standards 🔥. So the IETF really cares about accurate, interoperable implementations of what it publishes. The IETF Trust grants copying rights so people can use the text in RFCs, which encourages accurate and interoperable implementations 💜.

Early implementations often get built straight from Internet-Drafts, so the same wishes apply to Internet-Drafts too 🍓.

Similar thinking applies to non-standard, non-protocol documents like BCP (Best Current Practice) and Informational documents. This document recommends one common approach to right-to-use licenses for all IETF documents 🌸.

Here's the tea ☕: earlier documents about rights put specific legal wording right into the RFC text. That turned out to be a problem. Whenever a problem showed up in that wording, even one that wasn't about a change in intent, the RFC had to be revised to fix it. Best case, that just delays fixing legal issues that need prompt attention 🙈. So this document describes the IETF's wishes to the Trustees and does not supply the specific legal wording. Picking the wording, and updating it as needed, is left to the Trustees of the IETF Trust 👑.

3. Powers and Authority 👑

As we said in the introduction, and as formally specified in [RFC5378], the legal authority to decide and grant users' rights to copy material in RFCs and other IETF Contributions belongs to the Trustees of the IETF Trust. This document is guidance for that body, based on the rough consensus of the IETF 🫶. The Trustees have the authority and the responsibility to decide 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 keep things continuous, the starting point for license text and other materials is whatever the Trustees of the IETF already created under the authority of [RFC5377], which this document supersedes 🧡. Changes to IETF documentation, and to the document policies themselves, take effect as the Trustees of the IETF Trust decide 🌟.

This document does not say what rights the IETF Trust receives from others in IETF Contributions. That's covered by another document, [RFC5378] 📖. The working group took care when writing this, and the Trustees will take care too, to make sure sufficient rights go to the IETF Trust in IETF Contributions. But real talk: the Trust can't grant rights it hasn't received or doesn't receive, so policies are expected to line up with that fact 🙃. Likewise, the rights granted for pre-existing documents can't be expanded unless the people holding rights in those Contributions choose to grant expanded rights 🔒. Still, to whatever degree it can, and without launching a massive effort, it's desirable to grant similar rights to the ones described below for older RFCs too 🕰️.

The IETF grants rights to copy and modify parts of IETF Contributions so it can meet the objectives we covered earlier 🎯. Different circumstances and different parts of documents may need different grants, so this section has a subsection for each grant that's currently envisioned 💖. Each subsection describes one particular usage, how that usage is recognizable, and guidance for the Trustees on which rights the IETF would like to see granted in that situation and what limits should go on that grant ✨.

These recommendations for outgoing rights are built on the assumptions documented in [RFC5378]. So this document is about granting rights that come from the rights granted to the IETF Trust 🦋. The recommendations below describe how those granted rights should be passed along to others who use IETF documents, in ways and for purposes that fit the goals of the IETF 🫶. This discussion is separate from the rights the IETF itself needs in documents to do its job, because those aren't "outbound" rights 🙅‍♀️. It's expected that the rights granted to the IETF will be a superset of the copying rights we want to grant to others 👑.

4.1. Rights Granted for Reproduction of RFCs 📚

It's been IETF policy for a long time to encourage copying RFCs in full 💜. That allows wide dissemination of the material without risking loss of context or meaning 🌈. The IETF wants to keep letting anyone make full copies and translations of RFCs 🎀.

4.2. Rights Granted for Quoting from IETF Contributions 💬

There's rough consensus that it's useful to allow quoting excerpts from IETF Contributions without modification 🫶. Such excerpts may be of any length and used in any context, no cap 🔥. Translating quotations is also to be permitted 🌍. All such quotations should be attributed properly to the IETF and to the IETF Contribution they came from 🙌.

4.3. Rights Granted for Implementing Based on IETF Contributions ✨

okay so IETF Contributions often have bits that are meant to be directly processed by a computer 💻 like ABNF definitions, XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, MIBs, ASN.1, and classical programming code. They're in there for clarity and precision in the spec, and it's clearly beneficial to let those code bits show up in products that implement the Contribution 🫶

It's been pointed out that in several important contexts, using that code means you need to be able to modify it. One common example is just adapting code for specific contexts (languages, compilers, tool systems, etc.), which usually needs some changes to the text of the code from the IETF Contribution. Another example is that code in open source products is often licensed so that any and all of it can be modified. Since we want this code in those products, it follows that we need to permit modification 😭 There has been discussion about restricting modification rights in some way, but the rough consensus of the IETF is that such restrictions are likely a bad idea, and are certainly very complex to define 💀

So the rough consensus is that the IETF Trust grants rights so code components of IETF Contributions can be extracted, modified, and used by anyone in any way they want ✨ To make that as broad as possible, the IETF Trust should avoid adding software license obligations beyond the ones already in a Contribution. The rights to extract, modify, and use code should allow derived works outside the IETF that may carry additional license obligations. Since the IETF Trust can not grant rights it does not receive, these rights to extract, modify, and use code can not be granted in IETF Contributions that are explicitly marked as not permitting derivative works 🙈

It's up to the Trustees of the IETF Trust to figure out the best way to hit this goal, but two mechanisms are suggested here that are believed to be helpful for documenting the intended grant for readers and users of IETF Contributions 🎀

Firstly, the Trustees of the IETF Trust should keep, in a suitable and easily accessible spot, 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 will add to the list as they deem suitable or as the IETF directs them to 📝

Additionally, the Trustees of the IETF Trust should define a textual representation to be included in an IETF Contribution. It indicates 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 is therefore subject to the permissions granted for 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. That said, the authors of IETF Contributions may be able and willing to grant such rights independently of the rights they've 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 wants to be able to include content that's available under those licenses, and it's desirable to indicate in the IETF Contribution that other licenses are available. It would be inappropriate and confusing if those additional licenses restricted the rights the IETF intends to grant in the content of RFCs 😤

BUT the IETF does not want IETF Contributions to contain additional licenses, because that introduces a bunch of extra 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 keep all rights in their Contributions. So an author can directly grant any rights they wish, separately from what the IETF grants. However, a reader who wants to figure out or make use of those 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's 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's 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. Plot twist, but it's true: that's out of scope here 😭🔥

7. References 📚

7.1. Normative References 💜

7.2. Informative References 🌸

Author's Address 🎀

Joel M. Halpern (editor)
Ericsson
P. O. Box 6049
Leesburg, VA 20178
United States of America

Email: joel.halpern@ericsson.com
📦 where this page comes from