Summary

  • RFC 5377 expressed the IETF community's desired outbound rights, but deliberately left exact legal wording and other implementation mechanisms to the IETF Trust's Trustees. Consensus was guidance to an authorized body, not the operative licence itself.
  • The Trust could not grant rights it had not received. Inbound contributor authority, current policy text, component classification, effective date and a downstream user's conduct therefore form separate receipts.
  • RFC 8721 obsoleted RFC 5377 solely to remove IAOC references. It preserved the substantive division among complete-copy, quotation, code-component and ordinary-prose permissions. This analysis is not legal advice.

The meeting could close before the licence changed

Imagine the final objection has been answered. The mailing-list archive shows the discussion, the chairs record rough consensus, the IESG approves publication, and the RFC appears. A governance dashboard might mark the work complete at that moment.

RFC 5377 refuses that compression. The document described what the IETF wanted the outbound-rights regime to accomplish. It did not provide the exact legal text that would accomplish it. The Trustees of the IETF Trust held the authority and responsibility to choose the insertions or other mechanisms used in Internet-Drafts, RFCs and Contributions. Changes to documents and policies took effect when the Trustees determined.

That creates at least four moments. The community articulates a desired result. An authorized body converts the result into a legal mechanism. That mechanism receives a version and effective date. A later user relies on a particular permission for a particular act. Treating the first moment as proof of the fourth discards the decisions in between.

The distinction is not distrust of consensus. It is a design for maintainability and accountable delegation. Rough consensus can specify the purpose and limits of an outbound-rights policy. Trustees can then implement those instructions using legal language suited to the current administrative and legal setting. The record of direction remains visible without pretending that a process document is the licence text a user must apply.

Exact words were separated from durable intent

Earlier practice could embed specific rights language in an RFC. RFC 5377 identified a practical problem: if a flaw appeared in that wording, correcting it could require revising the RFC even when the community's intent had not changed. Legal issues that needed prompt attention would wait on a standards-document cycle.

The answer was to separate durable direction from maintainable implementation. The RFC described the desired outcome; the Trustees selected and updated the precise wording. This resembles a well-governed technical control. A policy defines what must be achieved. An authorized implementation can change how the requirement is expressed without silently changing the requirement itself.

But the analogy works only if provenance survives. An operator needs the consensus record, the Trustee decision, the exact text version, the effective date and the material to which the text applied. If only the newest licence is retained, analysts cannot determine what governed an older Contribution. If only the RFC is retained, they have the desired direction but not the operative mechanism.

The version boundary also prevents a different error: assuming that a wording fix necessarily proves a policy change. A Trustee may correct ambiguity while preserving intent. Conversely, a new policy outcome requires authority and evidence beyond a silent textual edit. The change record should say which occurred.

The Trust could pass on only what entered the Trust

RFC 5377's outbound recommendations rested on the inbound-rights structure described in RFC 5378. Contributors grant rights; the Trust holds and manages the rights it actually receives; Trustees grant outbound permissions derived from that inventory.

The ceiling is explicit. The Trust cannot grant rights it did not receive. Rights in pre-existing material cannot be expanded merely because the community prefers a broad modern permission. The relevant holder must have granted the necessary authority.

This turns provenance into an executable constraint. A downstream licence statement is not enough by itself when material contains third-party or pre-existing content with a narrower grant. The system needs to know what entered, from whom, under which terms, and whether the component now being reused falls inside that chain.

The adjacent RFC 5378 question is inbound: did the contributor possess and grant sufficient rights? The RFC 5377 question is outbound: what should the Trust permit users to do with the rights it holds? The first bounds the second. Neither receipt substitutes for the other.

For leadership, this is a useful model of delegated authority. A body may be empowered to distribute an asset while remaining unable to enlarge the asset. Administrative control over the licence does not manufacture upstream ownership.

Four uses entered four different lanes

RFC 5377 did not treat every act involving RFC material as one permission. It distinguished complete reproduction, quotation, implementation-oriented code components and ordinary text that someone wished to modify.

A complete copy or translation preserves the document as a whole. The policy goal is wide dissemination without loss of context or meaning. This does not imply that every sentence may be altered and redistributed as though it were code.

A quotation is an excerpt. The recommended model permits quotations without modification and requires proper attribution to the IETF and the relevant Contribution. Length alone does not erase provenance. The evidence is the selected passage, its unchanged form, its source and its attribution.

A code component is included so machines or implementations can use it. RFC 5377 names examples such as ABNF, XML schemas, DTDs, Relax NG definitions, value tables, MIBs, ASN.1 and classical program code. Implementation often requires extraction and modification. The community therefore wanted broad permission for that use, including derived works that may carry additional licence obligations.

Ordinary prose occupied a different lane. The document recorded no consensus at that time for general permission to reuse RFC text in contexts requiring modification. An author might offer a separate licence, but that grant would need its own source and conditions.

These distinctions matter because one physical document can contain all four surfaces. File possession does not collapse them. A compliance system that assigns one blanket state to the PDF will either overclaim rights or block uses the policy was designed to enable.

Classification was part of the permission decision

If code receives a different modification permission from prose, someone must decide which portions are code. RFC 5377 suggested two implementation mechanisms: a maintained list of common code-component types and a textual representation marking a portion as code.

The classification is not decorative metadata. It determines which outbound lane a user enters. A parser grammar marked as code may be extracted and adapted; a narrative explanation beside it may not carry the same permission merely because both occupy one section.

Therefore a trustworthy reuse record needs the component boundaries and the policy version that recognized them. It should not infer code from typography alone, nor infer prose because a component lacks a familiar file extension. The authorized marker and current Trust provisions control the decision.

Classification can also change operationally without rewriting the underlying technical bytes. A maintained list may add a component type. That does not prove every older document automatically gained rights the Trust never received. The inbound ceiling remains in force.

A separate author licence remained separate

Authors retain rights in their Contributions and may offer additional licences outside the IETF mechanism. RFC 5377 recognized that possibility while warning against embedding restrictive extra licences in a way that confuses or narrows the IETF's intended grant.

For a downstream user, a separate author licence is a different evidence path. It has a different issuer, text, scope, effective date and possibly a different work definition. A link saying “also available elsewhere” is not the licence itself. The user must retrieve and evaluate the external terms and confirm that the purported grantor holds the relevant rights.

The two paths should not be merged into a synthetic permission. A use may be allowed by the Trust policy, by the author's separate licence, by both, or by neither. Recording the chosen basis matters for later audit, especially if one path changes or disappears.

Supersession changed the institution reference, not the core direction

RFC 8721 obsoleted RFC 5377 in February 2020. The successor states that the sole purpose was to remove references to the IETF Administrative Oversight Committee, part of the former IASA structure.

That sentence prevents two symmetrical mistakes. Operators must not present RFC 5377 as the current governing process document. They also must not infer that the substantive outbound-rights direction was repudiated. RFC 8721 preserves the same core account of community wishes, Trustee authority, exact wording, received-rights limits and use-specific grants.

A status transition is therefore its own receipt. Obsoleted tells the reader to follow the successor. The successor's stated reason explains the scope of change. The current Trust Legal Provisions remain the relevant implementation surface for real reliance.

This article uses RFC 5377 historically because it reveals the architecture and the reason for decoupling legal wording. It uses RFC 8721 to establish the current documentary authority. It does not convert either Informational RFC into legal advice.

An evidence chain for outbound permission

An auditable system can preserve the following chain:

  • identity and status of the Contribution;
  • contributors and any pre-existing or third-party material;
  • inbound rights and applicable limitations;
  • consensus document and its current or obsolete status;
  • authorized Trustee decision and exact legal-provision version;
  • effective date and affected document class;
  • component boundary and classification;
  • intended downstream act: complete copy, translation, quotation, code use or prose modification;
  • attribution and licence notices actually carried forward;
  • any independent author licence used instead;
  • final distributed artefact and observed compliance.

Each line answers a different question. The consensus record explains purpose. The licence version explains operative permission. The inbound record explains the ceiling. Classification selects the lane. The final artefact proves what the user actually did.

Missing evidence must remain missing. A repository scan that finds an RFC reference does not prove the extracted bytes were code. A current licence page does not prove it governed a 2009 distribution. A consensus RFC does not prove the Trustees activated every suggested mechanism exactly as imagined.