RFC 3978

IETF Rights in Contributions

📅 published March 2005, from ietf

RFC 3978: IETF Rights in Contributions 💖✨

okay bestie, welcome to the Best Current Practice that decides who owns what when you post to the IETF 🎀 Here's the vibe check on the title block:

  • Number: RFC 3978 (BCP 78) 🌸
  • Author: S. Bradner, Ed., from Harvard University 🎓
  • Date: March 2005 📅
  • Category: Best Current Practice 👑
  • Obsoletes: RFC 3667 🙈
  • Updates: RFC 2026 💅

Status of this Memo

okay so this document is a Best Current Practice for the Internet Community 🦋 It's also asking for discussion and suggestions for improvements, so if something feels off, speak up! Distribution of this memo is unlimited, so share it with your whole group chat 💜

Copyright (C) The Internet Society (2005). 🌈

Abstract

the IETF has policies about rights in Contributions, and the whole goal is to keep those Contributions available to the IETF and the Internet community while letting authors keep as many rights as they can 🫶 This memo spells out those policies and explains what they're trying to achieve ✨ It updates RFC 2026 and, together with RFC 3979, replaces Section 10 of RFC 2026. no cap, that's a big glow-up 🔥

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
    Editor's Address. . . . . . . . . . . . . . . . . . . . . . .  17
    Full Copyright Statement. . . . . . . . . . . . . . . . . . .  18

1. Definitions 📚

these are the terms the rest of the doc relies on, so pay attention, bestie 👀 Other terms, like "IESG," "ISOC," "IAB," and "RFC Editor," are defined in [RFC2028].

a. "IETF": for this document, the IETF covers everyone who takes part in meetings, working groups, mailing lists, functions and other activities organized or started by ISOC, the IESG or the IAB under the general name Internet Engineering Task Force or IETF. but only to the extent of that 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 for publication as all or part of an Internet-Draft or RFC (except for RFC Editor Contributions, more on those below) AND any statement made within the context of an IETF activity 🎀 Those statements include oral statements in IETF sessions, plus written and electronic communications made at any time or place that are 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. (the vibe is "don't overthink it, you were just chatting" 🙈)

d. "Internet-Draft": temporary documents used in the IETF and RFC Editor processes 🌸 Internet-Drafts are posted on the IETF web site by the IETF Secretariat and have a nominal maximum lifetime of 6 months in the Secretariat's public directory, after which they get 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 are not removed from the Secretariat's public directory until that consideration is complete. the author of an Internet-Draft can also request that its 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 [RFC2026] Section 2.1) 🦋

f. "RFC Editor Contribution": an Internet-Draft the Contributor intends to submit to the RFC Editor for publication as an Informational or Experimental RFC, but not 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 as specified 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 [RFC2026] Sections 2.2 and 8) 👑

h. "IETF Documents": RFCs and Internet-Drafts, except for Internet-Drafts that are RFC Editor Contributions and the RFCs 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 the individual holds, 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 his or her represented organization, if any) to do a patent search to find applicable IPR. no homework required here, bestie 🙈💜

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 works they make, automatically, the moment they make them 🌟 Those rights include copyrights, moral rights and other rights. In many cases, if the author makes a work as part of their job, most of those rights get assigned to the employer, either by operation of law or, in lots of cases, by contract. (The Berne Convention calls some rights "inalienable," which means the author keeps them in all cases 🔥)

this document details 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 may also define additional rights it needs for RFC Editor Contributions 🦋

so for works to be used within the IETF Standards Process or published as Internet-Drafts, certain limited rights in all Contributions must be granted to the IETF and the Internet Society (ISOC). On top of that, Contributors have to make representations to the IETF and ISOC about their ability to grant those rights 💖 These necessary rights and representations have, until now, been laid out in Section 10 of [RFC2026]. in the years since [RFC2026] was published, the exact intent of Section 10 has been the subject of some seriously heated debate in the IETF community 😭 The aim of this document is to clear up the ambiguities in Section 10 of [RFC2026] that led to those debates, and to spell out the policy so it's clear what the IETF is doing right now ✨

Section 1 gives the definitions used to describe these policies. Sections 3, 4, 5, and 6 of this document cover the rights in Contributions previously handled by Section 10 of [RFC2026] and by the "Note Well" explanatory text presented at many IETF activities 🎀

Sections 7 and 8 then explain the reasoning behind these provisions, including some of the clarifications that have become understood since [RFC2026] was adopted 🧚 The rules and procedures in this document are NOT meant to substantially modify or alter the IETF's current policy toward Contributions.

A companion document, [RFC3979], deals with rights in technologies developed or specified as part of the IETF Standards Process. This document is NOT 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, bestie 🚨 If you want a legal interpretation of your rights, or of the IETF's rights in any Contributions you make, go talk to your own legal advisors 💅

3. Rights in IETF Contributions 💜

the following are the rights the IETF needs in all IETF Contributions:

3.1. General Policy 🌸

in all matters of copyright and document procedures, the goal is to benefit the Internet community and the public at large, while respecting the legitimate rights of others 🫶

3.2. Confidentiality Obligations 🔒

Okay bestie, this one is a big rule. No information or document that has any confidentiality requirement or any restriction on who can see it may be submitted as a Contribution or otherwise considered in any part of the IETF Standards Process 🚫. And there must be no assumption of any confidentiality obligation with respect to any Contribution 💅. Each Contributor agrees that any statement in a Contribution, whether it was generated automatically or written by hand, that says or implies the Contribution is confidential or under some privilege can be disregarded for all purposes, and it has no force or effect at all 🙅‍♀️.

3.3. Granting of Rights and Permissions 🎀

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

  • a. To the extent that a Contribution or any part of it is protected by copyright and other rights of authorship, the Contributor, each named co-Contributor, and the organization they represent or are sponsored by (if any) grant a perpetual, irrevocable, non-exclusive, royalty-free, world-wide right and license to the ISOC and the IETF 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 does not grant the 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 [RFC3979]).
  • b. The Contributor grants 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, each Contributor represents that, to the best of their knowledge and ability:

  • a. The Contribution properly acknowledges all major Contributors. A major Contributor is any person 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. Such statements should be submitted in the same way as is done for other intellectual property claims. (See [RFC3979] Section 6.)

4. Rights in RFC Editor Contributions 🌸

The following are the rights the IETF, as the publisher of Internet-Drafts, requires in all RFC Editor Contributions:

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 submission of an RFC Editor Contribution, each person actually submitting the RFC Editor Contribution, and each named co-Contributor, is deemed to agree to the following terms and conditions, and to grant the following rights, on their own behalf and on behalf of the organization the Contributor represents or is sponsored by (if any) when submitting the RFC Editor Contribution.

  • a. To the extent that an RFC Editor Contribution or any portion thereof is protected by copyright and other rights of authorship, the Contributor, each named co-Contributor, and the organization they represent or are sponsored by (if any) grant a perpetual, irrevocable, non-exclusive, royalty-free, world-wide right and license to the ISOC and the IETF 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 Internet-Draft,
    • (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 does not grant the 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 grants 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 (including copies, derivative works and translations of IETF Documents, but subject to the limited exceptions noted in Section 5.2). This requirement protects IETF and its participants from liabilities connected with these documents. The copyright notice also alerts readers that the document is an IETF Document, and that ISOC claims copyright rights to certain aspects of the document, such as its layout, the RFC numbering convention and the prefatory language of the document. This legend is not intended to imply that ISOC has obtained ownership of the IETF Contribution itself, which is retained by the author(s) or remains in the public domain, as applicable.

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

  • 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) 📜

The notice text below is copied verbatim:

"By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79."

5.2. Derivative Works Limitation ✨

Okay so, if a Contributor wants to stop the IETF from modifying or making derivative works of their IETF Contribution (translations are still allowed 🌍), they can put one of two notices in the Status of Memo section of an Internet-Draft. That notice also gets included in the published RFC. Here are the two options 💅

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.

For MIB or PIB modules, and for other Contributions with material meant to be pulled out and used on its own 🧩, the following should be added to the end of 5.2(a) or 5.2(b):

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

Notice 5.2(a) is for when the Contributor plans to publish the Contribution as an RFC. Notice 5.2(b) goes together with the Publication Limitation in Section 5.3 when the Contributor does not plan to publish it as an RFC 🦋

These notices can't be used on any standards-track document, or on most working group documents, except as discussed in Section 7.3 below 🙅‍♀️ The reason is that the IETF needs to keep change control over its documents, so it can keep improving, clarifying, and enhancing the original Contribution through the IETF Standards Process. Makes sense, right? 🫶

Notice 5.2(a) can be a good fit when republishing standards that came from other (non-IETF) standards organizations, industry consortia, or companies. These usually end up as Informational RFCs, and they don't need the IETF to take over change control. Basically, this kind of document shares information with the Internet community 🌸

There's a fuller explanation of why these rules exist in Section 7.3 below 💖

5.3. Publication Limitation 🦋

If the Contributor only wants the IETF Contribution to show up in an Internet-Draft (so, not published as an RFC), they can add this notice to the Status of Memo section of the Internet-Draft:

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

This notice is great for IETF Contributions that are meant to give background info and get working group discussions going, but aren't supposed to become RFCs 🧠

(This normally goes at the end of the IETF Document.)

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.

Other copyright notices aren't allowed in IETF Documents, unless the document is a joint project between the IETF and another standards development organization, or it's a republication of another standards organization's work. Those exceptions need individual approval from the IAB, so no freelancing here, bestie 🙅‍♀️

5.5. Disclaimer (required in all IETF Documents) 🙈

(This normally goes at the end of the IETF Document, after the copyright notice.)

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 🧚

Okay, so there are a few special cases where you can use a shorter notice on certain derivative works of IETF Documents, following this Section 5.6. Everything else in Section 5 still applies 🎀

a. For MIB modules, PIB modules, and similar material that's commonly pulled out of IETF Documents, the shorter notice below goes in the body of the material being extracted, instead of the notices Section 5 would normally require. The only exception is material being placed under IANA maintenance ✨

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.

When the MIB or PIB module is the first version of a module that IANA will maintain, use this shorter notice 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 at:
http://www.ietf.org/copyrights/ianamib.html.

For other types of components than "MIB", swap "MIB module" for an appropriate identifier. For MIB and PIB modules, this statement goes in the DESCRIPTION clause of the MODULE-IDENTITY macro 🧁

Variations of these shorter notices aren't allowed, except when the material being extracted is a joint project between the IETF and another standards development organization, or a republication of another standards organization's work. Any variations need individual approval from the IAB 🙏

b. Short excerpts of IETF Documents shown in electronic help systems (for example, the DESCRIPTION clauses for MIB variables) don't need a copyright notice. Slay for convenience 💅

6. Notices and Rights Required in RFC Editor Contributions 🎀

Okay, so the IETF acts as the publisher of Internet-Drafts, even ones that aren't meant to become part of the Standards Process. Because of that, the following are required in all 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 one specified in Section 5.1.

b. Pick one of these three copyright release statements:

A. By submitting this Internet-Draft, I accept the provisions of Section 3 of BCP 78.

B. By submitting this Internet-Draft, I accept the provisions of Section 4 of BCP 78.

C. The Copyright Notice specified in Section 5.4, plus the disclaimer specified in section 5.5.

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

Here's the tea on why all of this works the way it does 🍓

7.1. Rights Granted in IETF Contributions 👑

The IETF/ISOC must get the right to publish an IETF Contribution as an RFC or an Internet-Draft from the Contributors. Super important ✨

A big goal of this policy is to only get the non-exclusive rights that the IETF actually needs 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 the rights listed above from the IETF/ISOC 🌈

7.2. Rights to use Contributed Material 🌈

Okay, so under the laws of most countries and applicable international treaties, copyright rights come into existence the moment a work of authorship is created (but see Section 8 below about public domain documents). If the IETF doesn't have enough rights over those copyrights, it can't use IETF Contributions at all. 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 way more exposed to liability claims from 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, though 🙈 (See Section 1(l))

7.3. Right to Produce Derivative Works ✨

okay so the IETF has to be able to evolve IETF Documents 🔄 based on what people learn from actually deploying the technologies, new research, and whatever the Internet and other IP networks are doing. 💅 That means the IETF has to be able to make derivatives of its docs, so it must get the right from Contributors to produce derivative works. ngl this is the whole vibe. 🫶

Note though: the IETF only needs this right for derivative works made within the IETF Standards Process. It does not need, and does not get, the right to let derivative works be created outside the IETF Standards Process, other than as noted in Section 3.3 (E). 🙈

The right to produce derivative works is required 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 must be granted in order for an IETF working group to accept an IETF Contribution as a working group document or otherwise work on it. For non-working group IETF Contributions where the Contributor requests publication as a standards track RFC, the right must be granted before the IESG will issue an IETF Last-Call. For most non-standards track non-working group IETF Contributions, it must be granted before the IESG will consider the Internet-Draft for publication. 📝

Sometimes a Contributor may not want to grant publication rights or the right to produce derivative works before finding out whether an IETF Contribution has been accepted for development in the IETF Standards Process. 🫣 In that case, the Contributor may 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 discuss the Internet-Draft to 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. If the IETF Contribution is accepted for development, the Contributor must then 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 developing new technology. 🧚 But organizations that publish info about proprietary technologies are often not down to have the IETF produce revisions of those technologies and then claim the IETF version is the "new version" of the organization's technology. 🙅‍♀️ Organizations that feel this way can specify that an IETF Contribution can be published with the other rights granted under this document, but may withhold the right to produce derivative works other than translations. The right to produce translations is required before any IETF Contribution can be published as an RFC, so the material gets the widest possible distribution in RFCs. 🌈

Also, IETF Documents frequently 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 better understand what they're 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 must include a special legend in the IETF Contribution, as specified in Section 5.2, to notify IETF participants about this restriction. ⚠️

7.4. Rights to Use Trademarks 🎀

Contributors may want to seek trademark or service mark protection on any terms that are coined or used in their IETF Contributions. 💼 The IETF makes no judgment about the validity of any such trademark rights. However, the IETF requires each Contributor, under the licenses described in Section 3.3 above, to grant the IETF 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 authorize any IETF participant to use any trademark or service mark in connection with any product or service offering. It only applies in 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 are granted to all individuals noted in Section 1(a), regardless of their employment or institutional affiliation. 🫶 However, these licenses do not extend broadly to the employers, sponsors or institutions of those individuals, and they don't let the individuals exercise any rights outside the specific context of the IETF Standards Process. Boundaries, bestie. 🔒

Some documents, including those produced by the U.S. government and those 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 though the Contributor could be able to grant those rights.

We only ask for these grants and representations to the extent the Contribution may be protected. We believe they're necessary 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 make any independent investigation into the actual proprietary status of any document submitted to it. 🔍

9. Security Considerations 🔐

🚨 This memo relates to IETF process, not any particular technology. There are security considerations when adopting any technology, but there are no known issues of security with IETF Contribution rights policies. 🚨

10. References 📚

10.1. Normative References

[RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, October 1996.

[RFC2028]  Hovey, R. and S. Bradner, "The Organizations Involved in
           the IETF Standards Process", BCP 11, RFC 2028, October
           1996.

[RFC3979]  Bradner, S., Ed, "Intellectual Property Rights in IETF
           Technology", BCP 79, RFC 3979, March 2005.

10.2. Informative References

[Berne]    "Berne Convention for the Protection of Literary and
           Artistic Work",
           http://www.wipo.int/edocs/trtdocs/en/wo/wo001en.htm

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, who provided extensive help during the development of the document. 🌸

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 (2005). 🌈

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.

This document and the information contained herein are provided on an basis, and the disclaimers below apply:

"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 pertain to the implementation or use of 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 identify any such rights. 🕵️‍♀️ Info on 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, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be found in the IETF on-line 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 required to implement this standard. Please send that info 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