Frequently Asked Questions

Like all IETF intellectual property, they are owned by the IETF Trust.

Usage of the IETF acronym and logo for any purpose beyond what is described below is strictly prohibited by the IETF trust without a specific grant of license. The form to request a license can be found here. Each license is subject to approval and acceptance by the IETF Trust.

Every use of the IETF logo or name must be in compliance with the Trademark Usage Guidelines.

The Internet Society, the IETF Secretariat, IETF meeting hosts and sponsors, and associated organizations such as the IRTF, are or will be licensed.

The acronym “IETF” may be used factually in any online or traditional publication, in presentations and documents, and in press and media reports, as a descriptive term for the Internet Engineering Task Force.

The same applies to other phrases such as “IETF Secretariat”, “IETF Trust”, “IETF Standard” or “IETF RFC”.

The IETF logo may be used, without modification, to accompany descriptive text to refer specifically to the IETF organization itself or its work. The logo must be reproduced in the exact format, scale and colors displayed here.

Neither the IETF name nor logo alone or in combination with other words may be used to claim support or endorsement for, or as an indication of origin of, any goods or services.

Derivatives of the IETF logo may not be created or used without approval of and license from the IETF Trust, which will include assigning the rights in the derivative to the Trust. The IETF trust only grants the right to make derivatives of its logo on rare occasions, and only subject to strict terms and conditions.

The standard IETF logo can be found here.

The general rule is that original authors retain copyright unless they make an explicit transfer of their rights. The IETF and the RFC Editor have never required this. Hence the underlying copyright in RFCs remains with the original authors (or their employers, if their employment conditions so stipulate).

It means that the Internet Society originally owned the copyright on behalf of the IETF in those parts of RFCs that are the result of collective work, the standard material (“boilerplate”) included in all RFCs, and the RFC numbering series. As part of the IETF Administrative Support Activity realignment, the Internet Society has formally transferred its rights to the IETF Trust.

The IETF’s rules on copyright issues are in BCP 78, whose current version (as of May 2020) is RFC 5378.

Yes. Since the beginning of the RFC series, reproduction of whole RFCs (including translation into a language other than English) has been allowed and encouraged. The IETF Trust and the RFC Editor place no restrictions on this. Most RFCs include the standard phrase “Distribution of this memo is unlimited” to indicate this.

The policy just described is well known to RFC authors. However, it is a matter of courtesy to contact them if formal republication is planned (as opposed to usage for educational purposes and the like). It has been known for original authors to object to certain types of commercial republication.

It is common to use extracts from RFCs that are in the form of computer code by incorporating them in software. This is the only usage formally allowed by the current IETF rules (RFC 5378). Generally speaking the IETF Trust will tolerate fair use of other extracts, but you must indicate the source of the extract and you must mention the original copyright statement if present.

It is acceptable under the current IETF rules (RFC 5378) to modify extracted code if necessary. Modification of other extracts requires the permission of the original authors. The IETF Trust does not in general grant the right to create derivative works of RFCs; in fact it does not have the right to do so, under the current IETF rules (RFC 5378). The IETF is currently discussing various possible modifications of its rules to permit the publishing of modified extracts in certain circumstances.

This is a complex issue, but an important part of the reason is that the IETF historically wished to retain change control of its technical specifications, unless it consciously decides to hand it over to another standards body.

We haven’t found a legally perfect answer to this question. However, the IETF Trust has no intention of taking any action that will cause difficulty for open source software containing code from RFCs.

Not all RFCs originate in the IETF. A minority come from other sources (the IAB, the IRTF, and independent submissions reviewed directly by the RFC Editor). Also, numerous RFCs were published prior to the existence of the IETF (i.e. prior to January 1986). The IETF Trust cannot offer definitive advice in these cases. If in doubt, please seek independent legal advice.

Copyright law protects all forms of creative expression, including written documents, images, diagrams, audio recordings, software code and even designs printed on t-shirts. Almost all countries have some form of copyright law, and most developed countries adhere to the so-called Berne Convention on Artistic and Literary Works, which normalizes copyright protection among member countries.

Copyright is relevant to IETF because almost all written documents are protected by copyright. This includes Internet-Drafts, RFCs and all code that is included in these documents.

This FAQ addresses copyright and licensing issues relating to IETF Documents (Internet- Drafts and RFCs) and other contributions to the IETF standards process, as well as documents published as Internet-Drafts and RFCs in the Independent Stream, IAB Stream and IRTF Stream.

The IETF copyright policy is currently set out in two documents: RFC 5378 and the IETF Trust’s Legal Provisions Relating to IETF Documents which we sometimes refer to as the “TLP”. For reference, superseded versions of the TLP are also cataloged here.

IETF’s current copyright policy in RFC 5378 became effective on November 10, 2008 and applies to all IETF Contributions submitted on or after that date and to all IETF Documents published on or after that date.

Below is a brief chronology of IETF copyright policies and their dates of effectiveness:

RFC 5378 is an IETF BCP that has been adopted pursuant to the IETF standards-track process. It describes the rights that everyone who participates in IETF activities grants to the IETF Trust in documents, drafts, comments, e-mail messages and other “contributions” made within the context of IETF activities. In the past, RFC 5378 has been referred to informally as an “Inbound Rights” document, because it describes the rights that are granted “into” the IETF Trust by participants in the IETF process.

The TLP has been referred to as an “Outbound Rights” document, because it describes the rights that the IETF Trust grants to others, including participants in the IETF standards process. The TLP is based on the suggestions given to the Trust by the community in RFC 5377.

Thus, RFC 5378 and the TLP work together to obtain necessary rights from contributors and then to grant necessary rights to IETF participants, and to those outside the IETF standards process.

RFC 8721 expresses the IETF community’s instructions to the IETF Trust regarding the granting of rights. The IETF Trust, in developing the TLP and when granting rights outside the IETF standards process, carefully considers and implements the community’s instructions as outlined in RFC 8721.

The “Note Well” notifies participants in IETF activities of some of the important rules that apply to their participation in the IETF. In particular, participants are reminded of the copyright rules in RFC 5378, the patent disclosure rules in RFC 8179 and other rules relating, for example, to recording IETF meetings. The “Note Well” text itself does not constitute a set of rules, but is only a pointer to the rules that are currently in force within the IETF.

As defined in RFC 5378, an IETF Contribution is any submission to the IETF intended by the contributor for publication as all or part of an Internet-Draft or RFC, and any statement made within the context of an IETF activity, such as an email to an IETF mail list or a statement made at an IETF meeting session.

The “author” of an IETF Contribution retains his or her ownership of the copyright in that IETF contribution. The author is the person or persons who created the contribution. For copyright purposes, a company can be an author. Note, however, that even if the author(s) retain ownership of this copyright, they still must grant a license to the IETF Trust on the terms set forth in RFC 5378.

Yes. Copyright law generally provides that any person who substantially contributed to the creation of a copyrighted work jointly owns the work. In the case of IETF Contributions, this means that a document with multiple authors would be jointly owned by those authors.

In the U.S., any work prepared by an employee within the scope of his or her employment is a “work made for hire”, and the employer is considered its “author” for copyright purposes. This may not always be the case, however, in other countries or where independent contractors, academic faculty, students, or people from multiple jurisdictions are concerned. Because of the variability in employment and copyright ownership rules, the IETF does not differentiate between types of participants. Rather, it requires every IETF participant, individually, to ensure that he or she is capable of granting to the IETF all rights that are required under RFC 5378. This means that, in some cases, an employer must, explicitly or implicitly, grant some rights back to its employees to ensure that the IETF Trust gets the licenses that are required.

Note that when an author submits his or her Contribution to the IETF, the author warrants that he or she has the authority to grant all necessary rights under RFC 5378, so the author must ensure that all appropriate arrangements are in place with his or her employer.

Yes. Some documents are not protected by copyright. This means that they can generally be copied, modified and distributed without restriction.

Documents in the public domain include all documents created by or for the U.S. Federal Government and documents whose copyright has expired. Copyright expiration is quite complex and varies country-by-country. Suffice it to say, however, that most documents created within the past 50 years are still protected by copyright.

It is important to note that a document is not necessarily in the “public domain” for legal purposes simply because it is publicly-accessible (e.g., published on the Web) or because it is available under an “open source” license agreement. In both of these cases, somebody still owns and controls the copyright in the document, even if that person has granted relatively broad rights to the public.

No license is needed to use or modify public domain documents. However, given the complexity of determining whether or not a particular document is in the public domain, the IETF Trust does not seek to differentiate between public domain and non-public domain documents. Thus, the same assurances are requested, and the same licenses are granted, for all documents. In the case of public domain documents, however, your rights may be greater than those granted under the IETF Trust’s outbound license.

“Fair Use” is a concept in copyright law that varies from country to country. In the U.S., “fair use” is defined in Section 107 of the Copyright Act and has been interpreted by courts over many years. In general, the principle of fair use allows limited use of copyrighted materials for purposes such as criticism, comment, news reporting, teaching, scholarship, research and parody.

Because the doctrine of fair use has been interpreted rather narrowly in many cases, and because its application varies from country to country, the IETF seeks to obtain all necessary rights through the express license grants described in RFC 5378 rather than attempting to rely on the fair use doctrine.

Under RFC 5378, each Contributor grants the IETF Trust a broad (worldwide, royaltyfree) license to copy, publish, display, translate and distribute his or her IETF Contributions. In addition, unless certain legends are included in a Contribution, the IETF Trust also obtains the right to modify and create derivative works of these Contributions and to grant sublicenses of those rights to others.

The license to the IETF Trust is non-exclusive. This means that the author can grant a similar license to any other organization or entity without violating the license granted to the IETF Trust, so long as the license to the IETF Trust is not thereby constrained.

No. The licenses that Contributors grant to the IETF Trust are intended to be perpetual and irrevocable.

No. The license granted under RFC 5378 covers copyrights and trademarks that are included in the Contribution. Patent rights are not licensed. For the IETF’s rules regarding patents, see RFC 8179.

Under the TLP, the IETF Trust grants each IETF participant the right to copy, publish, display, translate and distribute all IETF Documents and Contributions, and (unless certain legends are included) to modify and make derivative works of them, within the IETF standards process. These are the rights needed to enable IETF work to be conducted as it always has been.

Yes. Anyone can publish and translate unmodified IETF Documents and Contributions for any purpose, even outside the IETF Standards Process.

In addition, Code Components included in IETF Documents can be used for any purpose pursuant to an open source license.

However, additional rights to modify and make derivative works (other than translations) of IETF Documents and Contributions outside the IETF Standards Process are not granted by the Trust. Rather, these rights are only granted by the IETF Trust on a case-by- case basis, after consultation with the community.

Before March, 2005, Code Components and textual portions of IETF Documents and Contributions were not differentiated (see RFC 2026 Sec. 10.3.1.1). This means that there were essentially no restrictions on re-use or modification of Code Components unless a no-derivatives legend was included in the document.

If you are an author of the material, then you retain your copyright in the material and may modify it without permission.

If the material was written by someone else, then you can either ask the copyright holder for permission or apply to the IETF Trust for permission. The IETF Trust will consider all such requests on a case-by-case basis. To make such a request to the IETF Trust, send an email, explaining the request as fully as possible, to the Trustees at [email protected].

Yes. For quite some time IETF has allowed the submission of documents that bear a legend limiting the right to make derivative works and the right to publish as an RFC (see the legends contained in TLP Sections 6.c.i and ii). Documents published with these legends are typically not standards-track documents, and are distributed as Internet-Drafts or Experimental RFCs for informational purposes only.

Yes. Code Components that are embedded or included in IETF Documents published on or after November 10, 2008, can be used, copied, distributed and modified by anyone in any manner under the open source Revised BSD License. This is true even if the 6.c.iii Legend described in the next question is present in the IETF Document where the Code Component originates.

Code Components that are embedded or included in IETF Documents published during the period of RFC 5378 effectiveness, March 2005 to November 10, 2008, can be used, copied, distributed and modified in any manner under the license grant contained in 3.3.a.E. The IETF takes the position that the code license granted under RFC 5378 is compatible with most other open source licenses, thought it has not formally been recognized by the Open Source Foundation.

Under the TLP, “Code Components” are any components intended to be directly processed by a computer. This means that all forms of software code are Code Components.

The IETF Trust maintains a list of common code components. The items on this list are automatically treated as “Code Components” for purposes of the TLP, but this list is illustrative only. That is, a type of code can still be a “Code Component”, even if it is not listed. If you feel that a particular type of code that is commonly used in IETF Documents should be added to this list, please e-mail the IETF Trust).

If you include a Code Component in an IETF Contribution, you are encouraged to label it with markers such as < CODE BEGINS > and < CODE ENDS >, though these markers are not strictly required (See the TLP section 4b.).

If you take code from an IETF Document or Contribution published on or after November 10, 2008, you must follow the instructions contained in Section 4 of the TLP. In particular, in the program that contains the Code Component, you must either reproduce the exact license text that is included in Section 4.c of the TLP in the document or program that includes this code, or the legend contained in Section 6.d. This is a requirement of the open source Revised BSD License.

In addition, you are requested to attribute such code to the IETF and identify the RFC or other IETF Document or Contribution from which it was taken.

If you take code from an IETF Document or Contribution published during the effectiveness of RFC 5378 (March 2005 to November 10, 2008), you must include the abbreviated notices that are set forth in Section 5.6 of RFC 5378.

The rules described apply no matter how small a Code Component may be. This being said, copyright law does not generally protect small fragments of text or code that, in themselves, do not evidence creative expression. Thus, if the statement “x = 0” is included in an IETF Document, and one wished to use “x = 0” in a program without including the various copyright statements described, it is likely that such use would not violate any recognizable copyright interest of the IETF Trust or others.

The IETF Trust chose the Revised BSD License for Code Components after consultation with the IETF community, including open source code developers within the community. The Revised BSD license is widely-recognized within the open source community and has been recognized and approved by the Open Source Initiative (OSI) (opensource.org) and is thus compatible with a wide variety of open source software.

The version of the BSD license contained in the TLP is the “Revised BSD License” (as defined by OSI in https://opensource.org/licenses/BSD-3-Clause) and contains a few minor customizations such as the names of relevant IETF entities.

Some trust documents mistakenly refer to the two-clause Simplified BSD license, rather than the Revised BSD license.  The three clause Revised BSD license is the one that the Trust uses.

No. The BSD license provisions described in Section 4 of the TLP apply only to Code Components in an IETF Document. The rest of the IETF Document is subject to the license provisions contained in Section 3 of the TLP.

As noted above RFC 5378 requires Contributors to grant broad rights to the IETF Trust. The previous copyright policy (RFC 3978) did not require the grant of so many rights. In particular, RFC 3978 did not require the Contributor to grant the right to modify his or her Contribution outside the IETF Standards Process, whereas RFC 5378 does require the Contributor to grant this right (though the IETF Trust may rarely exercise it).

In addition, RFC 5378 requires Contributors to warrant to the IETF Trust that they can actually grant all the rights they are supposed to be granting. This requirement arose from a desire to make Contributors think carefully about what they are submitting to IETF and to assure IETF that they have “cleared” all rights from relevant employers and co-authors.

A problem arises, however, when a new Contribution includes material from IETF Documents or Contributions that pre-date RFC 5378’s effectiveness, November 10, 2008 (“Pre-5378 Materials”). These materials, when they were originally submitted to IETF, did not come with all the rights required by RFC 5378, but only the smaller set of rights associated with RFC 3978 and prior policies. Thus, if these Pre-5378 Materials are included in a new Contribution, the Contributor may not always be able to grant the IETF Trust the full scope of rights that are required by RFC 5378 in his or her entire Contribution because his or her rights in the Pre-5378 Materials may be more limited.

The IETF Trust, not wishing to place any IETF Contributor in the position of breaching his or her warranties, modified the TLP to allow Contributors of IETF Contributions that include Pre-5378 Materials to add a new legend to these Contributions. This new legend is contained in Section 6.c.iii of the TLP, and is referred to in this FAQ as the “6.c.iii Legend” (you may also hear it referred to as the “5378 Disclaimer”). If the 6.c.iii Legend is included in an IETF Contribution, the right to modify the Pre-5378 Materials in that Contribution is withheld. Thus, the Contributor would not be granting rights in these pre- 5378 materials beyond the rights that their original contributors granted.

The IETF Trust cannot grant a license to parties outside the IETF standards process to Pre-5378 Materials contained in an IETF Contribution that bears the 6.c.iii Legend unless it has obtained all necessary rights from the persons controlling the copyrights in the Pre-5378 Materials.

You should use the 6.c.iii legend if your IETF Contribution contains material from IETF Documents or Contributions that were published prior to November 10, 2008 (“Pre-5378 Material”), and the IETF Trust has not been granted, or may not have been granted, the necessary permissions to allow modification of such pre-5378 Material outside the IETF Standards Process. However, you need not use the legend if you are the author of and own the rights in the Pre-5378 material.

Yes.

No, unless there is some reason that you or your company do not wish to grant the full scope of 5378 rights to the IETF Trust with respect to those Pre-5378 Materials.

If your former employer has not granted the IETF full 5378 rights, then you should probably treat this Pre-5378 Material as you would treat Pre-5378 Material written by somebody else and apply the 6.c.iii Legend.

No. For purposes of this discussion, Pre-5378 Materials only include IETF Documents (i.e., Internet-Drafts and RFCs) and IETF Contributions published before November 10, 2008. A Contributor must take full responsibility for licensing any other materials included in his or her IETF Contributions, regardless of its date.

The IAB Document Stream, the IRTF Document Stream and the Independent Submission Stream, each as defined in Section 5.1 of RFC 4844, are referred to as “Alternate Streams”.

Partially. Each Alternate Document Stream is managed by an Alternate Stream Manager, as defined in RFC 4844. The Alternate Stream Manager has the authority to establish rules relating to its Alternate Stream Documents. Currently, each of the Alternate Stream Managers has requested that the IETF Trust act as “license administrator” for its Alternate Stream Documents, and to establish and administer rules relating to these Alternate Stream Documents in accordance with the instructions and guidance provided by the Alternate Stream Manager. The current rules relating to the different Alternate Streams are discussed in the following questions.

The RFC Editor publishes certain Internet-Drafts and RFCs that are submitted to it outside of the IETF Standards Process in the so-called “Independent Document Stream”. These submissions, which are sometimes called “RFC Editor Contributions” do not reflect the work of the IETF and are not IETF Documents, even though their format resembles that of IETF Documents.

Under RFC 3978 (Section 4), RFC Editor Contributions were treated in a manner comparable to ordinary IETF Contributions. Under RFC 5378 however, RFC Editor Contributions were excluded.

On December 17, 2009 the RFC Editor published RFC 5744, formally requesting that the IETF Trust act as license administrator for Independent Stream Documents. The IETF Trust formally established rules and procedures for Independent Stream Documents in the version of the TLP that became effective on December 28, 2009. Accordingly, after December 28, 2009, all Independent Stream Documents are subject to the rules and procedures established by RFC 5378 and the TLP.

The TLP rules established for Independent Stream Documents are identical to those established for IETF Documents, except that there is no restriction on the creation of modifications and derivative works of Independent Stream Documents unless the contributor specifically includes a legend prohibiting the making of derivative works as described in Section 6.c.i and ii of the TLP. That is, the making of derivative works is not limited to the IETF standards process.

Under Section 11 of RFC 5378, the IAB states that all IAB stream documents are subject to the rules set forth in RFC 5378 and the TLP. In addition, on December 21, 2009 the IAB published RFC 5745, formally requesting that the IETF Trust act as license administrator for IAB Stream Documents. The IETF Trust formally established rules and procedures for IAB Stream Documents in the version of the TLP that became effective on December 28, 2009. Accordingly, between November 10, 2008 and December 28, 2009, all IAB Stream Documents were subject to the rules and procedures established by RFC 5378 and the TLP for IETF Documents, and after December 28, 2009 IAB Stream Documents are subject to the new rules and procedures that became effective in the TLP on that date.

The December 28, 2009 TLP rules established for IAB Stream Documents are identical to those established for IETF Documents, except that there is no restriction on the creation of modifications and derivative works of IAB Stream Documents unless the contributor specifically includes a legend prohibiting the making of derivative works as described in Section 6.c.i and ii of the TLP. That is, the making of derivative works is not limited to the IETF standards process.

For questions regarding rights with respect to IAB Stream Documents published before November 10, 2008, please consult the IAB.

IRTF Stream Documents have not historically been covered by IETF policies. On December 24 2009 the IRSG published RFC 5743, formally requesting that the IETF Trust act as license administrator for IRTF Stream Documents. The IETF Trust formally established rules and procedures for IRTF Stream Documents in the version of the TLP that became effective on December 28, 2009. Accordingly, after December 28, 2009, all IRTF Stream Documents are subject to the rules and procedures established by RFC 5378 and the TLP.

The TLP rules established for IRTF Stream Documents are identical to those established for IETF Documents, except that there is no restriction on the creation of modifications and derivative works of IRTF Stream Documents unless the contributor specifically includes a legend prohibiting the making of derivative works as described in Section 6.c.i and ii of the TLP. That is, the making of derivative works is not limited to the IETF standards process.

For questions regarding rights with respect to IRTF Stream Documents published before December 28, 2009, please consult the IRSG.

Except for April 1 RFCs, all of these documents are IETF Documents and are subject to the rules in RFC 5378 and the TLP.

April 1 RFCs are Independent Submission Stream documents and are subject to the rules as stated above.

As noted above, ownership of the copyright in each IETF Contribution is retained by its author(s). Once an IETF Document is published as an RFC, however, it includes contributions beyond those made by the original Contributors. In particular, the IETF Trust itself, through its contractor the RFC Editor and others, edits, combines, facilitates, formats, shapes and augments each RFC before it is published. Accordingly, the IETF Trust claims a joint ownership interest in the copyright in RFCs, in addition to the copyright held by individual Contributors in their Contributions.

The IETF Trust’s copyright notice began to be applied to IETF Documents with RFC 4748. The notice required by RFC 4748 is similar, but not identical, to that required by RFC 5378.

Before the IETF Trust was formed, many intellectual property rights in IETF Documents were held by the Internet Society (ISOC). When the IETF Trust was formed, ISOC assigned all of its copyrights and other intellectual property rights in IETF Documents to the IETF Trust. RFC 4748 makes it clear that the IETF Trust, rather than ISOC, has a copyright in IETF Documents published after October 2006.

Because of ISOC’s initial transfer of copyright to the IETF Trust when it was formed in December 2005, subsequent transfer made after formation, and the revision of the copyright legend under RFC 4748, ISOC no longer holds any copyright or other intellectual property interest in IETF Documents.

However, neither the ISOC nor the IETF Trust copyright notices eliminate the authors’ copyright interest in their original IETF Contributions and the IETF Documents that include those Contributions.

Section 6 of RFC 5378 and earlier IETF copyright policies have prohibited the inclusion of additional copyright notices in IETF Documents except in very limited cases. Such additional copyright notices would be confusing and would not themselves convey any additional rights. The copyright notice required by RFC 5378 acknowledges both the IETF Trust and individual authors, and is thus sufficient to protect all interested parties.

Additional copyright notices may only be included in IETF Documents with pre-approval of the IAB, and is appropriate only when the IETF Document is the product of joint work between IETF and another standards group, or in similar limited circumstances.

Copyright notice is not required under U.S. law to obtain a copyright. However, there are certain legal benefits that derive from the use of copyright notices.

The U.S. Copyright Act only requires that a copyright notice be placed in “such manner and location as to give reasonable notice of the claim of copyright.” The Registrar of Copyrights has specified that, for books and periodicals, the first page, title page and last page of the work are appropriate places for the notice, though other locations may also be appropriate.

The TLP specifies that the IESG will determine the placement of the copyright notice on IETF Internet-Drafts, and the RFC Editor will determine the placement of the copyright notice on RFCs. The appropriate Alternate Stream manager will determine placement for Alternate Stream Documents.

Yes, though in some cases there may be a slight delay in updating these tools to include the precise wording required by the most current version of the TLP. In these cases, the IETF Trust will offer a “grace period” for compliance with the latest notice and legend requirements. The duration of this “grace period” will be posted either with the latest version of the TLP or in the release notes accompanying the posting of the TLP.