Summary

  • Under RFC 5378, submitting an IETF Contribution is itself a legally binding act for the submitter and named co-Contributors; no further acknowledgment or signature is required.
  • The same act does not independently establish copyright ownership or authority over employer, sponsor, co-author or third-party material. The policy relies on permissions and representations bounded by what the contributor reasonably and personally knows.
  • The contributor can retain copyright in the underlying contribution while granting the IETF Trust a perpetual, irrevocable, non-exclusive, royalty-free, worldwide and sublicensable licence; patent rights remain outside that grant.

A fast agreement with a precise edge

Open standards work depends on thousands of small contributions: an Internet-Draft, a paragraph on a mailing list, a correction offered at a microphone, a design argument sent to a working group. Requiring a negotiated paper contract for each contribution would paralyse the process. RFC 5378 solves that operational problem by attaching legal consequence to participation itself.

Section 5.1 is direct. By submitting a Contribution, the actual submitter and every named co-Contributor are deemed to have read and understood the policy and to have entered a legally binding agreement. Nothing else is needed to bind them. That means the operative event is not publication as an RFC, acceptance by a working group or a later copyright form. It is submission of material that falls within the policy's definition of a Contribution.

That definition is wider than a document upload. It includes material intended for an Internet-Draft or RFC, but it also reaches statements made within an IETF activity: oral remarks in a session and written or electronic communications directed to the listed IETF bodies, working groups, lists and functions. A contributor can therefore cross the legal threshold before there is an “IETF Document” to point at.

This is a powerful compression of process, not a compression of truth. The receipt “Daniel submitted text X under BCP 78 at time T” can support the conclusion that Daniel undertook the policy's obligations. It cannot alone support “Daniel owned every copyright interest in X.” The first proposition concerns a recorded act under declared rules. The second concerns a chain of title that may run through co-authors, employers, sponsors, previous publications and incorporated material.

The distinction matters most when automation makes the first receipt look like the second. A submission portal can reliably preserve identity, payload, time and policy version. It cannot inspect employment contracts, reconstruct the provenance of every paragraph or discover a third party whose work was copied without attribution. Binding the actor is within the portal's control. Manufacturing authority is not.

The promise includes permission, not proof of permission

RFC 5378 does not ignore this gap. It says the contributor is deemed to have obtained necessary permission from any party the contributor reasonably and personally knows may have rights in the Contribution, expressly including a sponsor or employer. It also requires representations, to the best of the contributor's knowledge and ability, that contributors are acknowledged, the material is not confidential and no reasonably and personally known limit prevents the promised grants and agreements.

“Reasonably and personally known” is an important boundary. It includes what the individual actually knows and what someone in that job would reasonably be expected to know. The definition is designed so an organization cannot deliberately keep its representative ignorant merely to avoid a duty. Yet it remains a knowledge standard. It is not a warranty that the IETF has independently searched every registry, contract and historical source.

The RFC explains why it relies on this architecture. Copyright and related rights can arise automatically, and work produced in employment may belong to an employer by law or contract. The IETF needs confidence that it can use contributions without assuming liability to an unseen owner, but it lacks the resources to investigate the proprietary status of every submitted item. The process therefore places the representation with the contributor, where knowledge and access to permission are most likely to exist.

That allocation is sensible only if the evidence remains attributed. A declaration from a submitter is evidence of what that person represented. An employer approval is evidence that the employer authorized use of rights it controls. A co-author acknowledgment is evidence from that co-author. None should be silently replaced by a single database flag called “rights cleared.” Such a flag hides whose knowledge supported the decision and which rights were actually in scope.

The practical record should preserve at least the exact contribution, the submitter and named co-Contributors, the policy version, any employer or sponsor authorization, the provenance of incorporated material, and any legend limiting derivative use. When one of these is absent, the honest state is “not evidenced,” not “false” and not “implicitly supplied by submission.”

Copyright stayed; a durable licence moved

Another common error is to treat the incoming grant as a total transfer of the author's work. RFC 5378 deliberately separates ownership from permission. Contributors or their employers retain copyright in their underlying Contributions, subject to the rights they grant. The IETF Trust receives a perpetual, irrevocable, non-exclusive, royalty-free, worldwide and sublicensable licence under the relevant copyrights and other rights of authorship.

The grant is broad because the standards process must be able to work. It covers copying, publishing, displaying and distributing a Contribution in whole or part. It covers translation. Unless a permitted notice withholds the relevant permission, it covers modification and derivative works. It also allows included marks to be reproduced in the limited context of permitted reproduction and distribution while preserving mark identifiers.

These rights are not decorative. A standard must survive the departure of an author, the failure of a company and changes in the Internet. The Trust needs enough authority to preserve, publish, translate and sublicense material to participants. Irrevocability protects that continuity: a contributor cannot later withdraw the granted rights merely because the document became influential or a commercial relationship changed.

But non-exclusive means the owner does not lose all use of the underlying work. The contributor's retained copyright and the Trust's durable licence coexist. RFC 5378 also distinguishes the underlying Contributions from the collective work and format of an RFC. Rights in a paragraph written by a contributor and rights in the published RFC as assembled, edited and formatted are related but not identical assets.

This split is a useful institutional pattern. A common project need not centralize all ownership to secure continuity. It can obtain a narrowly described, durable licence while leaving residual ownership with the legitimate holder. The design reduces the temptation to claim more authority than the shared work actually requires.

A notice is not the grant

Standards documents carry notices, legends and a Note Well environment. Those surfaces matter because they tell participants and readers which rules apply. They should not be treated as magic words that create ownership or cure a missing permission.

RFC 5378 says legends and notices in written Contributions do not themselves convey rights. They inform readers about legal rights and limitations; the grant arises from the policy and the act of making the Contribution. The IETF's own process guidance likewise distinguishes Note Well as notice of the rules from the rules themselves.

This creates a clean control model. Notice should make the boundary conspicuous before action. The submission receipt should record which policy was operative. The contributor's representation should remain attributable. Permission from an employer, sponsor or third party should be captured where that party has authority. Later users should follow the outbound licence issued by the IETF Trust. Each surface does one job.

When all four are reduced to a footer, operators lose the ability to diagnose failure. Was the participant never shown the policy? Was the wrong person named? Did the employer own the material? Did a third-party extract carry incompatible terms? Did a later user exceed the Trust's outbound licence? A prominent notice may reduce surprise, but it cannot answer those questions.

Inbound authority and outbound reuse are different decisions

The contributor grants rights to the IETF Trust. The Trust then sublicenses rights for work inside the IETF standards process and publishes Trust Legal Provisions governing use outside it. That sequence contains two distinct authority checks: could the contributor grant the rights coming in, and does the downstream user have a licence for the intended use going out?

An RFC URL is not a universal permission token. Text, translations, derivative works and Code Components can follow different outbound rules. The Trust's current provisions define Code Components as material intended for direct computer processing and provide a specific licence path for them. The existence of a source fragment in an IETF document does not erase the conditions governing its reuse.

Historical material makes the distinction concrete. Contributions made before RFC 5378 took effect may not have carried the full set of rights demanded by the later policy. When new Contributions incorporated such material, the Trust introduced a legend that could withhold certain derivative-work rights rather than pretending the new submitter could grant authority that earlier contributors had never supplied.

That response respected provenance. It did not classify every old line as unusable, nor did it let a new uploader overwrite the historical rights state. It preserved a bounded exception that later readers could see. The larger lesson is that rights metadata must follow material across revisions. A new container cannot silently upgrade the licence of its contents.

Patents stayed on another track

The breadth of the copyright licence can obscure one explicit exclusion. RFC 5378 states that the Section 5.3 grants do not convey rights under patents, patent applications or similar intellectual property. Patent disclosure and related obligations belong to BCP 79, now RFC 8179.

This is more than a lawyerly distinction. Copyright in the wording or code of a specification and a patent claim covering an implemented technique are different control surfaces. Permission to copy an RFC does not necessarily permit practicing every technology it describes. Conversely, a patent disclosure says nothing by itself about the right to republish someone else's prose.

The system should therefore resist a universal “IP cleared” state. It needs separate records for copyright authority, contribution representations, patent disclosure, outbound text reuse and code-component licensing. A green result in one stream is not evidence for another.

This article does not determine any person's rights or offer legal advice. RFC 5378 itself directs contributors seeking a legal interpretation to their own advisers. The operational conclusion is narrower: because the standards process intentionally divides rights regimes, its evidence model must preserve those divisions.

Seven receipts for one contribution

A defensible contribution workflow can keep seven linked records without slowing the act of participation:

  1. a participation receipt showing that the contributor received the applicable notice before acting;
  2. a classification receipt showing why the statement or document was an IETF Contribution and which stream or activity was involved;
  3. an identity receipt for the actual submitter, named co-Contributors and attributed indirect contributors;
  4. an authority receipt containing employer, sponsor, co-author or third-party permission where the provenance makes it necessary;
  5. a representation receipt preserving the exact policy version and the contributor's knowledge-bounded assertions;
  6. an inbound-rights receipt identifying the material, exceptions and licence granted to the Trust; and
  7. an outbound-use receipt showing the Trust provision and conditions relied on by a later publisher, implementer or translator.

The records can share an identifier, but they should not overwrite one another. A valid submission may later reveal an authority defect. A valid copyright licence may coexist with an unresolved patent issue. An accepted Contribution may never become an RFC. An RFC may be copied faithfully while a proposed derivative use remains outside the relevant licence.

Keeping those states separate makes remediation proportionate. A questionable excerpt can be isolated while the rest of a draft proceeds. A missing employer permission can be obtained from the actor who controls it. A derivative-work restriction can remain visible. There is no need to pretend the whole history was valid or invalid from the beginning.

Acceptance was never the promised outcome

RFC 5378 also denies a different inference: the IETF has no duty to publish, use or disseminate a Contribution. It may withdraw or stop using material that does not comply. The binding agreement secures terms under which the process may receive material; it is not a promise of editorial acceptance, standards-track advancement or technical endorsement.

That boundary keeps institutional authority narrow. Contributors decide what to offer and make representations within their knowledge. Rights holders decide whether to authorize use of what they control. The Trust administers rights actually granted. IETF process bodies decide what to work on. The RFC Editor publishes within a defined stream architecture. Implementers decide what to deploy. No single receipt can speak for all of them.

The submit button is therefore both stronger and weaker than it appears. It is stronger because it can create a binding agreement without another signature. It is weaker because it cannot summon missing title, permission, patent rights or technical merit into existence. Good governance preserves both truths at once.