RFC 5377

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

Title block, the tea: ✨

• RFC: 5377
• Title: Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents
• Author: J. Halpern, Ed. (affiliation: Self 💅)
• Category: Informational
• Date: November 2008
• Obsoletes / Updates: the header doesn't list any RFCs this one obsoletes or updates 🦋
• Stream: Network Working Group

---

Status of This Memo

okay so this memo just provides information for the Internet community 🧚 It does not specify an Internet standard of any kind. Distribution of this memo is unlimited, so share it with everyone 💖

Copyright Notice

Copyright (c) 2008 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, bestie, because they describe your rights and restrictions with respect to this document 📜🫶

Abstract

so contributors grant intellectual property rights to the IETF, and the IETF Trust holds and manages those rights on the IETF's behalf 👑 The Trustees of the IETF Trust are the ones in charge of that management ✨ That includes granting the licenses to copy, implement, and otherwise use IETF Contributions, which covers Internet-Drafts and RFCs. The Trustees accept direction from the IETF about which rights get granted, and this document is where the IETF spells out what it wants for outbound rights in IETF Contributions. It's giving clear instructions 💅

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Purpose in Granting Rights  . . . . . . . . . . . . . . . . . . 2
   3.  Powers and Authority  . . . . . . . . . . . . . . . . . . . . . 3
   4.  Recommended Grants of Right to Copy . . . . . . . . . . . . . . 4
     4.1.  Rights Granted for Reproduction of RFCs . . . . . . . . . . 5
     4.2.  Rights Granted for Quoting from IETF Contributions  . . . . 5
     4.3.  Rights Granted for Implementing Based on IETF
           Contributions . . . . . . . . . . . . . . . . . . . . . . . 5
     4.4.  Rights Granted for Use of Text from IETF Contributions  . . 6
     4.5.  Additional Licenses for IETF Contributions  . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7

1. Introduction 💖

Okay, so the way the IETF is set up right now, its intellectual property rights are held by the IETF Trust, which is run by a board of trustees made up of the members of the IAOC [RFC4371] 🏛️ That includes the right to use IETF Contributions, which Contributors grant under the rules in [RFC5378]. So the Trustees are the ones responsible for defining the 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] and gives those terms the same meanings it does 🧠

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 ought to be. So it's on the IETF to put those wishes into words 🫶 This document is that statement. It represents the IETF's wishes about the rights granted to all users in regard to IETF Contributions, until it gets superseded 🌸

2. Purpose in Granting Rights ✨

Before we get into the details, it helps to remember why we grant these rights in the first place 🔥

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 really important subclass of RFCs is standards that describe protocols. For those, the biggest value to the Internet is that implementors can build products, software, and so on that interoperate with each other using the standard 🤝 So the IETF cares a lot about accurate, interoperable implementations of what it publishes. The IETF Trust grants people the right to copy so they can make use of the text in the RFCs, which helps encourage accurate and interoperable implementations 💅

Early implementations often run off Internet-Drafts, so the same wishes apply to Internet-Drafts too 🧚

Non-standard, non-protocol documents like BCP (Best Current Practice) and Informational documents are in a similar spot. In this document we recommend one shared approach to right-to-use licenses for all IETF documents, so everything is consistent 🌈

Here's the tea ☕ Older documents about rights in IETF documents put specific legal wording right into the RFC text to get the goals across. That turned out to be a problem. When a problem with that wording was found, even if the problem wasn't a change in intent, the RFC had to be revised to fix it. At best that just delayed fixing legal issues that needed prompt attention 😭 So this document describes the IETF's desires to the Trustees of the IETF Trust, but it does not provide the specific legal wording. Picking the wording, and updating it as needed, is left to the Trustees. Appeals of the Trustees' actions are governed by other documents. Since the Trustees are the members of the IAOC, the appeals procedure in BCP 101 (currently [RFC4371]) applies 👑

3. Powers and Authority 🏛️

As the introduction said, and as [RFC5378] formally specifies, 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. That body is made up of the members of the IAOC, as described in [RFC4071] and [RFC4371] 💅 This document gives that body guidance, based on the rough consensus of the IETF ✨

The Trustees have the authority and the responsibility to figure out 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 lives at http://trustee.ietf.org/license-info 📜

The rough consensus in this document reflects the IETF's agreement as of the IETF Last Call. The Trustees will start drafting license text and other materials to act on these instructions once the IESG approves this document for RFC publication. Changes to IETF documentation, and to the document policies themselves, take effect as the Trustees of the IETF Trust decide 🎀

This document doesn't say what rights the IETF Trust receives from others in IETF Contributions. That's covered by another document, [RFC5378] 🧚 The working group took care in writing this, and the Trustees will too, to make sure enough rights go to the IETF Trust in IETF Contributions. But here's the catch: the Trust can not grant rights it hasn't received, so policies have to line up with that reality 😬 Likewise, rights granted for pre-existing documents can't be expanded unless the people who hold those rights choose to grant more. Still, as far as it can, and without starting a massive effort, it's desirable that similar rights to the ones described below get granted in older RFCs too 🌸

4. Recommended Grants of Right to Copy 🌈

The IETF grants rights to copy and modify parts of IETF Contributions so the objectives above can be met. Different circumstances and different parts of documents may need different grants, so this section has a subsection for each grant currently envisioned 💅 Each subsection describes one particular usage, how to recognize that usage, and guidance for the Trustees about which rights the IETF would like granted in that situation and what limits should go with them 🫶

These recommendations for outgoing rights are built around the assumptions documented in [RFC5378]. So this document is really about granting rights that come from the ones granted to the IETF Trust. The recommendations below explain how those granted rights should then be passed on to others using IETF documents, in ways and for purposes that fit the IETF's goals ✨ This is separate from the rights the IETF itself needs in documents to do its job, because those aren't "outbound" rights. The rights granted to the IETF are expected to be a superset of the copying rights we want to grant to others 🔥

4.1. Rights Granted for Reproduction of RFCs 📚

It has long been IETF policy to encourage copying RFCs in full 💖 That lets the material spread widely 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 is rough consensus that it's useful to permit quoting excerpts from IETF Contributions without modification 🎀 Those excerpts can be any length and can appear in any context. Translating quotations is also meant to be permitted ✨ Every quotation should be properly attributed to the IETF and to the IETF Contribution it came from, so credit where credit is due 👑

4.3. Rights Granted for Implementing Based on IETF Contributions ✨

okay so IETF Contributions often have bits that are meant to be read straight 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, and it's honestly so smart 🧠 because it's clearly good to let those code bits show up in products that implement the Contribution 🎀

BUT here's the tea ☕ it's been pointed out that in a bunch of important situations, using that code means you have to be able to change it 😭 one super common example is just adapting the code for a specific context, like a particular language, compiler, or tool system. and that usually means tweaking the text of the code from the Contribution. another example: code in open source products is often licensed so that any and all of it can be modified. so if we want this code in those products (and we do 🫶), we need to allow the modifications. there was a whole discussion about restricting those modification rights somehow, but the rough consensus of the IETF is that restrictions are likely a bad idea 🙅‍♀️ and they'd be super complicated to define anyway. so no thank you 💅

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 the reach as big as possible, the IETF Trust should avoid adding software license obligations beyond the ones already in a Contribution. and the rights to extract, modify, and use code should allow derived works outside the IETF that might carry extra license obligations, which is totally fine 🌈 now, the IETF Trust can't grant rights it never received 🥲 so these code rights can't be granted in any IETF Contribution that's explicitly marked as not permitting derivative works. no way around that one, bestie 🙈

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 to help readers and users understand the intended grant 📖

first, the Trustees of the IETF Trust should keep, in a suitable and easy-to-find place, a list of common RFC components that will be considered code. to start, the list should include at least the items listed above 📝 and the Trustees will add to it as they think is suitable or as the IETF directs them to 💜

second, the Trustees of the IETF Trust should define a textual representation that goes inside an IETF Contribution to show that a part of the document is considered code by the authors (and later the working group, and upon approval, the IETF). that way everyone knows which parts get the code permissions 🔥

4.4. Rights Granted for Use of Text from IETF Contributions 🌸

ngl this one is a little sad 🥺 there is no consensus right now to allow the use of text from RFCs in contexts where you need the right to modify that text. the authors of IETF Contributions might be able and willing to grant those rights on their own, separate from what they've already granted to the IETF by making the Contribution 💌

4.5. Additional Licenses for IETF Contributions 🍓

okay this part is kinda interesting 👀 sometimes the material in an IETF Contribution is also available under other license terms, and the IETF wants to be able to include content that's under those licenses. so it's desirable to say in the IETF Contribution that other licenses are available 🧚 but it would be inappropriate and confusing if those additional licenses restricted the rights the IETF intends to grant in the content of RFCS 🙃

however, the IETF doesn't want IETF Contributions to contain additional licenses, because that causes a bunch of extra difficulties 😩 specifically, any additional text in the document, and any additional license that the permitted additional text refers to, must not in any way restrict the rights the IETF intends to grant to others for using the contents of IETF Contributions. no restrictions, no exceptions, periodt 💅

authors of Contributions keep all rights in their Contributions 👑 so an author can directly grant any rights they want, separately from what the IETF grants. but if a reader wants to figure out or use those grants, they'll need to check external sources (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 🙌 the only list that's anticipated is a list of kinds of code sections, which will be created and maintained by the Trustees of the IETF Trust. it's up to the Trustees whether they create that list and whether they choose to involve the IANA in maintaining it 💖

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. Please keep that in mind, bestie: this document doesn't cover those attacks at all. 🚨

7. References 📚

7.1. Normative References

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

7.2. Informative References

• [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004.
• [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, April 2005.
• [RFC4371] Carpenter, B. and L. Lynch, "BCP 101 Update for IPR Trust", BCP 101, RFC 4371, January 2006.

Author's Address 💜

Joel M. Halpern (editor)
Self
P. O. Box 6049
Leesburg, VA  20178
US

EMail: jmh@joelhalpern.com