June 22, 2010
1. Copyright and the IETF Copyright Policies
1.1 Why are copyrights relevant to the IETF?
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 (see Topic 5).
1.2 Where can I find the IETF’s policy regarding copyrights?
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” (http://trustee.ietf.org/IETF-Trust-License-Policy.pdf). For reference, superseded versions of the TLP are also cataloged at http://trustee.ietf.org/trust-legal-provisions.html
1.3 When did the current policy go into effect, and what about documents that were published or submitted before that?
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:
| RFCs | Effective |
| 5978
Obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026 |
November 10, 2008 |
| 4748 (updated 3978) | October 2006 |
| 3978 | March 2005 |
| 3667 | February 2004 |
| 2026 (Section 10) | October 1996 |
| 1602 (Section 5) | March 1994 |
1.4 Why do we need two documents to describe the IETF copyright policy (i.e., RFC 5378 and the TLP)? What is the difference between these two documents?
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 (see Question 2.5).
1.5 I thought that RFC 5377 was the “Outbound Rights” document. What does it do?
RFC 5377 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 5377.
1.6 What is the “Note Well” wording that is distributed at IETF meetings and appears on the IETF web site?
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 3979 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.
1.7 What is an IETF Contribution?
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.
1.8 Who owns the copyright in Internet-Drafts and other IETF Contributions?
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 (see Question 1.10). 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 (see Question 2.1).
Ownership of the copyright in RFCs is discussed in Questions 6.1-6.2.
1.9 Can IETF Contributions be jointly owned?
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.
1.10 What about my employer? Doesn’t it own everything I create, and doesn’t this make my licenses to the IETF meaningless?
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.
1.11 Aren’t some documents in the “public domain”? What does that mean?
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.
1.12 What is “fair use”? Can materials be used in the IETF on the basis of fair use principles?
“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.
2. IETF Copyright Licenses
2.1 What rights are granted to the IETF Trust under RFC 5378?
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 (see Question 2.7), 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.
2.2 Can I ever revoke a license that has been granted to the IETF Trust?
No. The licenses that Contributors grant to the IETF Trust are intended to be perpetual and irrevocable.
2.3 Do the licenses I grant under RFC 5378 also include patent rights?
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 3979.
2.4 What rights does the IETF Trust grant to IETF participants within the IETF standards process?
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, see Question 2.7) 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.
2.5 Are any rights granted by the IETF Trust outside the IETF standards process?
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 (see Topic 3 and especially Question 3.1 for license details).
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 caseby- 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.
2.6 How can I get permission to modify an IETF Document or portion thereof outside the IETF standards process (other than for translation)?
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 IETF Administrative Director (IAD) at iad@ietf.org.
2.7 Are there some IETF Documents that cannot be modified, even within the IETF Standards Process?
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.
3. Rights Relating to Code
3.1 Can I use code that is included in IETF Documents in my software?
Yes. Code Components (see Question 3.2) 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 Simplified BSD License, as described in Questions 3.2 and 3.3. This is true even if the 6.c.iii Legend described in Question 4.2 s 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 3978 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 3978 is compatible with most other open source licenses, thought it has not formally been recognized by the Open Source Foundation.
3.2 What is meant by “Code Components”?
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 at http://trustee.ietf.org/license-info/. 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 IAD iad@ietf.org).
3.3 Must I do anything special in my IETF Contribution if I include Code Components in it?
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.).
3.4 What must I do if I want to take code from an IETF Document and use it in a program or elsewhere?
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 Simplified 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 3978 (March 2005 to November 10, 2008), you must include the abbreviated notices that are set forth in Section 5.6 of RFC 3978.
3.5 What if I only want to use a small amount of code from an IETF Document?
The rules described in Question 3.4 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 in Question 3.4, it is likely that such use would not violate any recognizable copyright interest of the IETF Trust or others.
3.6 Why did the IETF Trust elect to use the Simplified BSD License?
The IETF Trust chose the Simplified BSD License for Code Components after consultation with the IETF community, including open source code developers within the community. The Simplified BSD license is widely-recognized within the open source community and has been recognized and approved by the Open Source Initiative (OSI) (www.osi.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 “Simplified BSD License” (as defined by OSI in http://www.opensource.org/licenses/bsd-license.php) and contains a few minor customizations such as the names of relevant IETF entities.
3.7 Can I choose to use or distribute non-Code portions of an IETF Document under the Simplified BSD License?
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.
4. TLP Modification of February 15, 2009
4.1 On February 15, 2009, the IETF Trust updated the TLP to address a problem where Pre-5378 material was included in a post-5378 contribution. What was the problem?
As noted above (see Question 2.1) 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 (see Questions 4.2 to 4.4).
4.2 How did the TLP Modification of February 2009 address the pre-5378 problem?
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.
4.3 What is the effect of this withholding of rights on the IETF Trust?
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.
4.4 When should I apply the 6.c.iii Legend to my IETF Contributions?
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. (see Questions 4.6 and 4.7).
4.5 If I am not sure whether the Contributor of Pre-5378 Material granted full 5378 rights to the IETF Trust, should I use the 6.c.iii Legend?
Yes.
4.6 If all Pre-5378 Material included in my Contribution was authored by me or other employees of my current company, should I use the 6.c.iii legend?
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.
4.7 What if I changed employers and now want to use Pre-5378 Material that I authored while working for my former employer in an IETF Contribution?
If your former employer has not granted the IETF full 5378 rights (see Question 4.10), 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.
4.8 Do “Pre-5378 Materials” include non-IETF materials written or published before November 10, 2008?
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.
5. Treatment of Alternate Stream Documents
5.1 What are “Alternate Stream Documents”?
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”.
5.2 Do the IETF copyright rules apply to Alternate Stream Documents?
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 Questions 5.3 to 5.5.
5.3 What rules apply to “Independent Stream Documents”?
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 (see Question 2.7). That is, the making of derivative works is not limited to the IETF standards process.
5.4 What rules apply to IAB Stream Documents?
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 (see Question 2.7). 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.
5.5 What rules apply to IRTF Stream Documents?
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 (see Question 2.7). 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.
5.6 What rules apply to “Experimental RFCs”, “April 1 RFCs” and other non-WG IETF Documents?
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 in Question 5.3.
6. Copyright and Other Notices in IETF Documents
6.1 The copyright notice on every RFC published under the rules in RFC 5378 states “Copyright IETF Trust and the persons identified as the document authors”. What does that mean?
As noted above (see Questions 1.7-1.9) 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.
6.2 Some IETF Documents published before RFC 4748 came into effect carry a copyright notice stating “Copyright ISOC”. What does this mean?
Before the IETF Trust was formed, many intellectual property rights in IETF Documents (including the copyright described in Question 6.1) 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.
6.3 The IETF copyright policy prohibits the inclusion of additional copyright notices in IETF Contributions and IETF Documents. Why?
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.
6.4 Where should the copyright notice be placed in an IETF Document. Does placement have any legal effect?
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.
6.5 Will the document formatting tools made available by IETF automatically include the correct legends in my submission?
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.