RFC 3667

IETF Rights in Contributions

📅 published February 2004, from ietf

RFC 3667: IETF Rights in Contributions ✨

Okay bestie, here's the header tea 🍵 RFC 3667 is called IETF Rights in Contributions, written by S. Bradner of Harvard University in February 2004 🎀 It's a Best Current Practice (BCP 78), so it's the community's recommended way of doing things. It doesn't list anything it obsoletes, but it updates RFC 2026 💅 It's part of the Network Working Group series, so yes, very official, very iconic 👑

Status of this Memo

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. 🌸

Copyright (C) The Internet Society (2004). All Rights Reserved. 💜

Abstract ✨

Okay so the big idea 🦋 The IETF has policies about who owns the rights to stuff people contribute, and they're designed so that contributions can be shared with the IETF and the wider Internet community while the authors keep as many rights as possible. Honestly so fair 🫶 This memo spells out those policies and explains what they're trying to achieve. It also updates RFC 2026 and, together with RFC 3668, replaces Section 10 of RFC 2026 😭

Table of Contents ✨

1.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Rights in IETF Contributions . . . . . . . . . . . . . . . . .  5
    3.1.  General Policy . . . . . . . . . . . . . . . . . . . . .  5
    3.2.  Confidentiality Obligations. . . . . . . . . . . . . . .  5
    3.3.  Granting of Rights and Permissions . . . . . . . . . . .  6
    3.4.  Representations and Warranties . . . . . . . . . . . . .  7
    3.5.  No Duty to Publish . . . . . . . . . . . . . . . . . . .  7
    3.6.  Trademarks . . . . . . . . . . . . . . . . . . . . . . .  7
4.  Rights in RFC Editor Contributions . . . . . . . . . . . . . .  8
    4.1.  Requirements from Section 3. . . . . . . . . . . . . . .  8
    4.2.  Granting of Rights and Permissions . . . . . . . . . . .  8
5.  Notices Required in IETF Documents . . . . . . . . . . . . . .  9
    5.1.  IPR Disclosure Acknowledgement . . . . . . . . . . . . . 10
    5.2.  Derivative Works Limitation. . . . . . . . . . . . . . . 10
    5.3.  Publication Limitation . . . . . . . . . . . . . . . . . 11
    5.4.  Copyright Notice . . . . . . . . . . . . . . . . . . . . 11
    5.5.  Disclaimer . . . . . . . . . . . . . . . . . . . . . . . 11
    5.6.  Exceptions . . . . . . . . . . . . . . . . . . . . . . . 12
6.  Notices and Rights Required in RFC Editor Contributions. . . . 13
7.  Exposition of why these procedures are the way they are. . . . 13
    7.1.  Rights Granted in IETF Contributions . . . . . . . . . . 13
    7.2.  Rights to use Contributed Material . . . . . . . . . . . 14
    7.3.  Right to Produce Derivative Works. . . . . . . . . . . . 14
    7.4.  Rights to use Trademarks . . . . . . . . . . . . . . . . 16
    7.5.  Who Does This Apply To?. . . . . . . . . . . . . . . . . 16
8.  Contributions Not Subject to Copyright . . . . . . . . . . . . 16
9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
    10.1. Normative References . . . . . . . . . . . . . . . . . . 17
    10.2. Informative References . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
12. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 17
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18

1. Definitions 📖

Okay, so these are the terms the rest of the doc uses 🧚 Anything else, like "IESG," "ISOC," "IAB" and "RFC Editor," is defined in [RFC 2028].

a. "IETF": For this document, the IETF includes everyone who participates in meetings, working groups, mailing lists, functions and other activities that ISOC, the IESG or the IAB organize or start under the general name Internet Engineering Task Force or IETF. But that only counts to the extent of their participation 💅

b. "IETF Standards Process": the stuff the IETF does in any of the settings described in 1(c) below.

c. "IETF Contribution": any submission to the IETF that the Contributor intends to publish as all or part of an Internet-Draft or RFC (except for RFC Editor Contributions, which we'll get to). It also covers any statement made within the context of an IETF activity. That includes oral statements in IETF sessions, plus written and electronic communications made at any time or place, as long as they're addressed to:

  • the IETF plenary session,
  • any IETF working group or portion thereof,
  • the IESG, or any member thereof on behalf of the IESG,
  • the IAB or any member thereof on behalf of the IAB,
  • any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices,
  • the RFC Editor or the Internet-Drafts function (except for RFC Editor Contributions described below).

Statements made outside of an IETF session, mailing list or other function, that are clearly not meant to be input to an IETF activity, group or function, are not IETF Contributions for this document 🙈

d. "Internet-Draft": temporary documents used in the IETF and RFC Editor processes. Internet-Drafts get posted on the IETF web site by the IETF Secretariat and have a nominal maximum lifetime in the Secretariat's public directory of 6 months, after which they're removed. Note that Internet-Drafts are archived in lots of places on the Internet, and not all of those places remove expired Internet-Drafts. Internet-Drafts that are under active consideration by the IESG aren't removed from the Secretariat's public directory until that consideration is complete. Also, the author of an Internet-Draft can request that the lifetime in the Secretariat's public directory be extended before it expires 🌈

e. "RFC": the basic publication series for the IETF. RFCs are published by the RFC Editor and, once published, are never modified. (See [RFC 2026] Section 2.1) 🔥

f. "RFC Editor Contribution": an Internet-Draft that the Contributor intends to submit to the RFC Editor for publication as an Informational or Experimental RFC, but that isn't intended to be part of the IETF Standards Process.

g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor Contributions. Note that under Section 3.3(a), the grant of rights for IETF Internet-Drafts in this document is perpetual and irrevocable, so it survives the Secretariat's removal of an Internet-Draft from the public directory, except as limited by Section 3.3(a)(C). (See [RFC 2026] Sections 2.2 and 8) ✨

h. "IETF Documents": RFCs and Internet-Drafts, except for Internet-Drafts that are RFC Editor Contributions and the RFCs that are published from them.

i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC Editor Contributions, and the RFCs that may be published from them.

j. "Contribution": IETF Contributions and RFC Editor Contributions.

k. "Contributor": an individual submitting a Contribution.

l. "Reasonably and personally known": means something an individual knows personally or, because of the job they hold, would reasonably be expected to know. This wording is there so an organization can't purposely keep an individual in the dark about patents or patent applications just to dodge the disclosure requirement. But this requirement should not be read as requiring the IETF Contributor or participant (or their represented organization, if any) to do a patent search to find applicable IPR. Lowkey reasonable 🫶

2. Introduction 🦋

Okay so under the laws of most countries and current international treaties (for example the "Berne Convention for the Protection of Literary and Artistic Work" [Berne]), authors get a bunch of rights in the stuff they make, automatically, as soon as they make it 🎀 These include copyrights, moral rights and other rights. If someone creates a work as part of their job, most of those rights usually get assigned to the employer, either by operation of law or, often, under contract. (The Berne Convention calls some rights "inalienable," which means the author keeps them in all cases 😭)

This document covers the rights the IETF needs in IETF Contributions, and the rights the IETF, as publisher of Internet-Drafts, needs in all such Drafts, including RFC Editor Contributions. The RFC Editor can also define extra rights needed for RFC Editor Contributions 💜

For works to be used within the IETF Standards Process or to be published as Internet-Drafts, certain limited rights in all Contributions must be granted to the IETF and Internet Society (ISOC). Contributors also have to make representations to IETF and ISOC about their ability to grant those rights. Until now, these necessary rights and representations were laid out in Section 10 of [RFC 2026]. Since [RFC 2026] came out, there have been a bunch of times when the exact intent of Section 10 was the subject of seriously vigorous debate within the IETF community 🙈 So the aim of this document is to clear up the ambiguities in Section 10 of [RFC 2026] that led to those debates, and to beef up the policy so it's clear what the IETF is actually doing right now 🔥

Section 1 gives the definitions used to describe these policies. Sections 3, 4, 5 and 6 cover the rights in Contributions that were previously covered by Section 10 of [RFC 2026] and by the "Note Well" explanatory text presented at lots of IETF activities. Sections 7 and 8 then explain the reasoning behind these provisions, including some clarifications that have become understood since [RFC 2026] was adopted. The rules and procedures in this document are not meant to substantially modify or alter the IETF's current policy toward Contributions ✨

There's a companion document, [RFC 3668], that deals with rights in technologies developed or specified as part of the IETF Standards Process. This document isn't meant to address those issues 🌸

The rights covered in this document fall into these categories:

  • rights to make use of contributed material
  • copyrights in IETF documents
  • rights to produce derivative works
  • rights to use trademarks

This document is not legal advice. If you want a legal interpretation of your rights, or the rights of the IETF in any Contributions you make, please go talk to your own legal advisors 🫶

3. Rights in IETF Contributions 💅

The following are the rights the IETF requires in all IETF Contributions:

3.1. General Policy 🌈

In all matters of copyright and document procedures, the intent is to benefit the Internet community and the public at large, while respecting the legitimate rights of others. Honestly the main character energy of this whole doc 👑

3.2. Confidentiality Obligations 🔒

okay bestie, this one is a hard no on secrets 🙅‍♀️. Any info that has a confidentiality requirement or a restriction on sharing must not be submitted as a Contribution, and it can't be considered in any part of the IETF Standards Process either. There also must be no assumption of any confidentiality obligation for any Contribution.

And here's the part I'm obsessed with: if a Contribution says it's confidential or privileged, whether a machine wrote that line or a human did, every Contributor agrees it can be ignored for all purposes and has no force or effect ✨. No secret-keeping vibes allowed in the process 💅

3.3. Granting of Rights and Permissions 🎀

By submitting a Contribution, the person actually submitting it and every named co-Contributor is deemed to agree to the terms below and to grant the rights below. They do this for themselves, and for the organization they represent or are sponsored by (if any) when they submit.

  • a. Okay, so if a Contribution (or any part of it) is protected by copyright or other authorship rights, the Contributor, each named co-Contributor, and their organization (if any) grant ISOC and the IETF a perpetual, irrevocable, non-exclusive, royalty-free, world-wide right and license under all intellectual property rights in the Contribution:
    • (A) to copy, publish, display and distribute the Contribution as part of the IETF Standards Process or in an Internet-Draft,
    • (B) to prepare or allow the preparation of translations of the Contribution into languages other than English,
    • (C) unless explicitly disallowed in the notices contained in a Contribution [as per Section 5.2 below], to prepare derivative works (other than translations) that are based on or incorporate all or part of the Contribution, or comment upon it, within the IETF Standards Process. The license to such derivative works doesn't grant ISOC and the IETF any more rights than the license to the original Contribution,
    • (D) to reproduce any trademarks, service marks or trade names which are included in the Contribution solely in connection with the reproduction, distribution or publication of the Contribution and derivative works thereof as permitted by this paragraph. When reproducing Contributions, the IETF will preserve trademark and service mark identifiers used by the Contributor of the Contribution, including (TM) and (R) where appropriate, and
    • (E) to extract, copy, publish, display, distribute, modify and incorporate into other works, for any purpose (and not limited to use within the IETF Standards Process) any executable code or code fragments that are included in any IETF Document (such as MIB and PIB modules), subject to the requirements of Section 5 (it also being understood that the licenses granted under this paragraph (E) shall not be deemed to grant any right under any patent, patent application or other similar intellectual property right disclosed by the Contributor under [IETF IPR]).
  • b. The Contributor gives the IETF and ISOC permission to reference the name(s) and address(es) of the Contributor(s), and of the organization(s) s/he represents or is sponsored by (if any). 🌸

3.4. Representations and Warranties 🧚

For each Contribution, every Contributor represents that, to the best of their knowledge and ability:

  • a. The Contribution properly acknowledges all major Contributors. A major Contributor is anyone who has materially or substantially contributed to the IETF Contribution. 🙌
  • b. No information in the Contribution is confidential, and the IETF, ISOC, and its affiliated organizations may freely disclose any information in the Contribution.
  • c. There are no limits to the Contributor's ability to make the grants, acknowledgments and agreements herein that are reasonably and personally known to the Contributor.
  • d. The Contributor has not intentionally included in the Contribution any material which is defamatory or untrue, or which is illegal under the laws of the jurisdiction in which the Contributor has his or her principal place of business or residence. 🚫
  • e. All trademarks, trade names, service marks and other proprietary names used in the Contribution that are reasonably and personally known to the Contributor are clearly designated as such where reasonable. ™️

3.5. No Duty to Publish 📭

The Contributor, and each named co-Contributor, acknowledges that the IETF has no duty to publish or otherwise use or disseminate any Contribution. 🫶 The IETF reserves the right to withdraw or cease using any Contribution that does not comply with the requirements of Section 3.4 and Section 3.3 or 4.2.

3.6. Trademarks 🏷️

Contributors, and each named co-Contributor, who claim trademark rights in terms used in their IETF Contributions are requested to state specifically what conditions apply to implementers of the technology relative to the use of such trademarks. Those statements should be submitted the same way as other intellectual property claims are. (See [RFC 3668] Section 6.) 💜

4. Rights in RFC Editor Contributions 📚

Here are the rights the IETF needs in all RFC Editor Contributions, since the IETF is the publisher of Internet-Drafts 👑

4.1. Requirements from Section 3

All RFC Editor Contributions must meet the requirements of Sections 3.1, 3.2, 3.4, 3.5 and 3.6. ✅

4.2. Granting of Rights and Permissions

By submitting an RFC Editor Contribution, the person actually submitting it and every named co-Contributor is deemed to agree to the terms below and to grant the rights below. They do this for themselves, and for the organization they represent or are sponsored by (if any) when they submit. 🦋

  • a. If an RFC Editor Contribution (or any part of it) is protected by copyright or other authorship rights, the Contributor, each named co-Contributor, and their organization (if any) grant ISOC and the IETF a perpetual, irrevocable, non-exclusive, royalty-free, world-wide right and license under all intellectual property rights in the RFC Editor Contribution for at least the life of the Internet-Draft:
    • (A) to copy, publish, display and distribute the RFC Editor Contribution as an RFC, and
    • (B) to prepare or allow the preparation of translations of the RFC into languages other than English.
    • (C) unless explicitly disallowed in the notices contained in an RFC Editor Contribution (as per Section 5.2 below), to prepare derivative works (other than translations) that are based on or incorporate all or part of the RFC Editor Contribution, or comment upon it. The license to such derivative works doesn't grant ISOC and the IETF any more rights than the license to the original RFC Editor Contribution, and
    • (D) to reproduce any trademarks, service marks or trade names which are included in the RFC Editor Contribution solely in connection with the reproduction, distribution or publication of the RFC Editor Contribution and derivative works thereof as permitted by this paragraph. When reproducing RFC Editor Contributions, the IETF will preserve trademark and service mark identifiers used by the Contributor of the RFC Editor Contribution, including (TM) and (R) where appropriate.
  • b. The Contributor gives the IETF and ISOC permission to reference the name(s) and address(es) of the Contributor(s), and of the organization(s) s/he represents or is sponsored by (if any). 🎀

5. Notices Required in IETF Documents 📢

The IETF requires that certain notices and disclaimers described in this Section 5 be reproduced verbatim in all IETF Documents. That covers copies, derivative works and translations of IETF Documents too, though there are limited exceptions noted in Section 5.2. ✨ The point is to protect IETF and its participants from liabilities connected with these documents.

The copyright notice also tells readers that the document is an IETF Document. It shows that ISOC claims copyright over certain aspects, like its layout, the RFC numbering convention and the prefatory language of the document. 🤓 It does not mean ISOC owns the IETF Contribution itself. That stays with the author(s) or in the public domain, depending on the case.

Each IETF Document must include the required notices described in this Section 5. Those notices are:

  • a. The IPR Disclosure Acknowledgement described in Section 5.1 (required in all Internet-Drafts).
  • b. The Derivative Works Limitation described in Section 5.2 (for specific IETF Documents only).
  • c. The Publication Limitation described in Section 5.3 (for specific types of Internet-Drafts only).
  • d. The Copyright Notice described in Section 5.4 (for all IETF Documents).
  • e. The Disclaimer described in Section 5.5 (for all IETF Documents). 🫧

5.1. IPR Disclosure Acknowledgement (required in all Internet-Drafts only) 💖

Every Internet-Draft carries this acknowledgement, word for word:

"By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668."

5.2. Derivative Works Limitation

okay so bestie, this is the section for when a Contributor wants to stop the IETF from changing or building on their work 🔒. If they want that, one of two notices can go in the Status of Memo section of an Internet-Draft, and it stays in the published RFC too. (Translations are the one exception here, so those are still allowed.) The two options are:

a. Notice 5.2(a):

This document may not be modified, and derivative works of it may
not be created, except to publish it as an RFC and to translate it
into languages other than English.

b. Notice 5.2(b):

This document may not be modified, and derivative works of it may
not be created.

When the contribution has MIB or PIB modules, or other material that's meant to be pulled out and used on its own, you add this to the end of 5.2 (a) or 5.2 (b):

other than to extract section XX as-is for separate use.

Here's how to pick: 5.2(a) is for when you do want the contribution published as an RFC. 5.2(b) goes with the Publication Limitation in Section 5.3 when you don't want it published as an RFC at all 💅.

These notices can't be used on standards-track documents, or on most working group documents, except as covered in Section 7.3 below. The reason is that the IETF has to keep change control over its documents so it can keep adding to, clarifying, and improving the original contribution through the IETF Standards Process. Totally makes sense 🫶.

5.2(a) can be a good fit when someone is republishing standards made by other (non-IETF) standards organizations, industry consortia, or companies. Those usually come out as Informational RFCs, and they don't need to hand change control over to the IETF, since they're basically sharing info with the Internet community 🌸.

Section 7.3 below has the full reasoning behind all of this.

5.3. Publication Limitation

If the Contributor only wants the contribution posted as an Internet-Draft, and not published as an RFC, they can put this notice in the Status of Memo section of the Internet-Draft:

This document may only be posted in an Internet-Draft.

This one's for contributions that give background info and help kick off discussions inside IETF working groups, but that aren't meant to become RFCs 🦋.

This one is normally placed at the end of the IETF Document, and it's required everywhere 📜:

Copyright (C) The Internet Society (year).  This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.

Extra copyright notices aren't allowed in IETF Documents. The only exceptions are when the document comes from a joint development effort between the IETF and another standards development organization, or when it's a republication of another standards organization's work. Even then, each exception has to be approved one at a time by the IAB 🙈.

5.5. Disclaimer (required in all IETF Documents)

This is normally placed at the end of the IETF Document, right after the copyright notice. It's required in every IETF Document, and the wording is serious, so no skipping it 💀:

This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.

5.6 Exceptions

Even with everything in Section 5 above, there are a few special cases where a shorter notice can go on certain derivative works of IETF Documents, following this Section 5.6 🎀.

a. For MIB modules, PIB modules, and similar material that usually gets pulled out of IETF Documents, the short notice goes in the body of the material that will be extracted, instead of the notices Section 5 would normally ask for. This doesn't apply to material that's being placed under IANA maintenance. The standard short version is:

Copyright (C) The Internet Society <year> .  This version of
this MIB module is part of RFC XXXX; see the RFC itself for
full legal notices.

If the MIB or PIB module is the first version of a module that IANA is going to maintain, this short notice is used instead:

Copyright (C) The Internet Society <year>.  The initial
version of this MIB module was published in RFC XXXX; for full
legal notices see the RFC itself.  Supplementary information
may be available on
http://www.ietf.org/copyrights/ianamib.html.

For components other than "MIB", swap "MIB module" for a suitable identifier. With MIB and PIB modules, this statement goes in the DESCRIPTION clause of the MODULE-IDENTITY macro 🧚.

Variations on these short notices aren't allowed, unless the material being extracted comes from a joint IETF and other standards development organization effort, or is a republication of another standards organization's work. Those variations also need individual IAB approval ✨.

b. Short excerpts of IETF Documents that show up in electronic help systems, like the DESCRIPTION clauses for MIB variables, don't need a copyright notice at all 🌈.

6. Notices and Rights Required in RFC Editor Contributions

The IETF acts as the publisher of Internet-Drafts, and that's true even for Internet-Drafts that won't become part of the Standards Process. So everything below is required in every one of those drafts, to protect the IETF and its processes 🛡️. The RFC Editor might ask for extra notices too.

a. An IPR Disclosure Acknowledgement, the same as the one specified in Section 5.1.

b. One of these two copyright release statements:

A.

By submitting this Internet-Draft, I accept the provisions of
Section 3 of RFC 3667.

B.

By submitting this Internet-Draft, I accept the provisions of
Section 4 of RFC 3667.

7. Exposition of Why These Procedures Are the Way They Are

Okay, this part explains the reasoning behind everything above, which I think is lowkey the most interesting part 🤓.

7.1. Rights Granted in IETF Contributions

The IETF and ISOC have to get the right to publish an IETF Contribution as an RFC or an Internet-Draft from the Contributors 📝.

A big goal of this policy is to only collect the non-exclusive rights that are actually needed to develop and publish IETF Documents, and to use IETF Contributions in the IETF Standards Process. Everything else stays with the authors 🦋.

The non-exclusive rights the IETF needs are:

  • a. the right to publish the document
  • b. the right to let the document be freely reproduced in the formats that the IETF publishes it in
  • c. the right to let third parties translate it into languages other than English
  • d. except where explicitly excluded (see Section 5.2), the right to make derivative works within the IETF process
  • e. the right to let third parties extract some logical parts, for example MIB modules

The authors keep all their other rights, but they can't take back any of the rights above from the IETF/ISOC 🔥.

7.2. Rights to use Contributed Material

Under the laws of most countries and applicable international treaties, copyright rights come into existence the moment a work of authorship is created. (See Section 8 below for public domain documents.) The IETF can't use IETF Contributions unless it has enough rights in those copyrights, so it's really important that the IETF gets assurances from every Contributor that they have the authority to grant the rights they're claiming to grant. Without that assurance, the IETF and its participants would be at a greater risk of liability to the owners of those rights 😬.

That's why the IETF asks Contributors to give the assurances in Section 3.4 above. These assurances are only requested to the extent of the Contributor's reasonable and personal knowledge (see Section 1(l)) ✨.

7.3. Right to Produce Derivative Works

okay so the IETF has to be able to evolve IETF Documents as people learn from actually deploying the technologies in them, bring in new research, and keep up with whatever the Internet is doing ✨. to do that, it has to make derivatives of its documents, which means it needs the right from Contributors to produce derivative works 🦋. ngl, the IETF only needs this right for derivative works made inside the IETF Standards Process. it does not need, and does not get, the right to let derivative works be made outside the IETF Standards Process, other than as noted in Section 3.3 (E) 💅.

the right to produce derivative works is needed for all IETF standards track documents and for most IETF non-standards track documents 🌸. there are two exceptions: documents describing proprietary technologies, and documents that are republications of the work of other standards organizations 🙈.

the right to produce derivative works has to be granted before an IETF working group can accept an IETF Contribution as a working group document or otherwise work on it 🎀. for non-working group IETF Contributions where the Contributor asks for publication as a standards track RFC, that right has to be granted before the IESG will issue an IETF Last-Call. and for most non-standards track non-working group IETF Contributions, it has to be granted before the IESG will consider the Internet-Draft for publication 🔥.

sometimes a Contributor doesn't want to grant publication rights or the right to produce derivative works until they find out whether the IETF Contribution has been accepted for development in the IETF Standards Process 🥺. in that case, the Contributor can include the Derivative Works Limitation described in Section 5.2 and the Publication Limitation described in Section 5.3 in their IETF Contribution 🧚. a working group can still talk about the Internet-Draft and decide whether it should become a working group document, even though the right to produce derivative works, or to publish the IETF Contribution as an RFC, hasn't been granted yet 💜. but if the IETF Contribution is accepted for development, the Contributor then has to resubmit it without the limitation notices before a working group can formally adopt it as a working group document ✨.

the IETF has historically encouraged organizations to publish details of their technologies, even proprietary ones, because understanding how existing technology is being used helps when people are building new technology 📚. but organizations that publish information about proprietary technologies often don't want the IETF to revise those technologies and then claim that the IETF version is the "new version" of the organization's technology 😭. organizations that feel this way can specify that an IETF Contribution may be published under the other rights granted in this document, while withholding the right to produce derivative works other than translations 🍓. the right to produce translations is needed before any IETF Contribution can be published as an RFC, so that the material in RFCs can reach the widest possible audience 🌈.

on top of that, IETF Documents often make normative references to standards or recommendations developed by other standards organizations 🧠. since the publications of some of those organizations aren't public documents, it can really help the IETF to republish some of them as RFCs, with the permission of the other standards organization. that way the IETF community has open access and can understand what the IETF documents are referring to 🫶. in these cases, the RFCs can be published without the right for the IETF to produce derivative works 💖.

in both of the cases above where the production of derivative works is excluded, the Contributor has to include a special legend in the IETF Contribution, as specified in Section 5.2, so IETF participants know about the restriction 🚨.

7.4. Rights to Use Trademarks

Contributors may want trademark or service mark protection for any terms they coin or use in their IETF Contributions 💅. the IETF makes no judgment about whether any such trademark rights are valid 🤷‍♀️. however, under the licenses described in Section 3.3 above, the IETF requires each Contributor to grant it a perpetual license to use any such trademarks or service marks, solely in exercising its rights to reproduce, publish and modify the IETF Contribution 🦋. this license does not let any IETF participant use a trademark or service mark in connection with any product or service offering. it only covers the context of IETF Documents and discussions 🎀.

7.5. Who Does This Apply To?

the rights and licenses granted to the IETF under this document go to all the individuals noted in Section 1(a), no matter who employs them or what institution they're affiliated with 🌟. but these licenses don't stretch out to those individuals' employers, sponsors or institutions. they also don't let the individuals use any of these rights outside the specific context of the IETF Standards Process 🙅‍♀️.

some documents, including ones produced by the U.S. government and ones in the public domain, may not be protected by the same copyright and other legal rights as other documents 🏛️. even so, we ask each Contributor to grant the IETF the same rights, and to make the same representations, as they would if the IETF Contribution were protected by the same legal rights as other documents, and as if the Contributor could actually grant those rights 🫶. we only ask for these grants and representations to the extent that the Contribution may be protected 💜. we think they're needed to protect the ISOC, the IETF, the IETF Standards Process and all IETF participants 🛡️. it's also because the IETF doesn't have the resources or wherewithal to independently investigate the actual proprietary status of every document submitted to it 🥹.

9. Security Considerations

this memo is about IETF process, not any particular technology 📋. there are security considerations when adopting any technology, but there are no known security issues with IETF Contribution rights policies 🔐.

10. References

10.1. Normative References

  • [RFC 2026] Bradner, S., Ed, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 📖
  • [RFC 3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 📖

10.2. Informative References

11. Acknowledgements

the editor would like to thank the IETF IPR Working Group, and especially Jorge Contreras of Hale and Dorr for his careful legal reviews of this and other IETF IPR-related and process documents 🙌. the editor would also like to thank John Klensin for his extensive help during the development of the document 💕.

12. Editor's Address

Scott Bradner Harvard University 29 Oxford St. Cambridge MA, 02138

Phone: +1 617 495 3864 EMail: sob@harvard.edu

Copyright (C) The Internet Society (2004). this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth there, the authors keep all their rights 📜.

this document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 😤.

Intellectual Property

the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to implementing or using the technology described in this document, or on whether any license under such rights might or might not be available. it also doesn't claim to have made any independent effort to find such rights 🔍. information about the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📚.

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users of this specification to use such proprietary rights can be obtained from the IETF's online IPR repository at http://www.ietf.org/ipr 💻.

the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. please send that information to the IETF at ietf-ipr@ietf.org 📬.

Acknowledgement

funding for the RFC Editor function is currently provided by the Internet Society 💖✨

📦 where this page comes from