diff options
Diffstat (limited to 'doc/rfc/rfc5378.txt')
| -rw-r--r-- | doc/rfc/rfc5378.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc5378.txt b/doc/rfc/rfc5378.txt new file mode 100644 index 0000000..cc24d42 --- /dev/null +++ b/doc/rfc/rfc5378.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group S. Bradner, Ed. +Request for Comments: 5378 Harvard University +BCP: 78 J. Contreras, Ed. +Obsoletes: 3978, 4748 WilmerHale +Updates: 2026 November 2008 +Category: Best Current Practice + + + Rights Contributors Provide to the IETF Trust + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2008 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Abstract + + The IETF policies about rights in Contributions to the IETF are + designed to ensure that such Contributions can be made available to + the IETF and Internet communities while permitting the authors to + retain as many rights as possible. This memo details the IETF + policies on rights in Contributions to the IETF. It also describes + the objectives that the policies are designed to meet. This memo + obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces + Section 10 of RFC 2026. + + + + + + + + + + + + + +Bradner & Contreras Best Current Practice [Page 1] + +RFC 5378 RFC 3978-incoming November 2008 + + +Table of Contents + + 1. Definitions .....................................................3 + 2. Introduction ....................................................5 + 2.1. No Retroactive Effect ......................................5 + 3. Exposition of Why These Procedures Are the Way They Are .........6 + 3.1. Rights Granted in Contributions ............................6 + 3.2. Rights to Use Contributions ................................6 + 3.3. Right to Produce Derivative Works ..........................6 + 3.4. Rights to Use Trademarks ...................................8 + 3.5. Contributions Not Subject to Copyright .....................8 + 3.6. Copyright in RFCs ..........................................9 + 4. Non-IETF Documents ..............................................9 + 5. Rights in Contributions .........................................9 + 5.1. General Policy .............................................9 + 5.2. Confidentiality Obligations ...............................10 + 5.3. Rights Granted by Contributors to the IETF Trust ..........10 + 5.4. Sublicenses by the IETF Trust .............................11 + 5.5. No Patent License .........................................11 + 5.6. Representations and Warranties ............................11 + 5.7. No Duty to Publish ........................................12 + 5.8. Trademarks ................................................12 + 5.9. Copyright in RFCs .........................................12 + 5.10. Contributors' Retention of Rights ........................12 + 6. Legends, Notices and Other Standardized Text in IETF + Documents ......................................................13 + 7. Security Considerations ........................................13 + 8. References .....................................................14 + 8.1. Normative References ......................................14 + 8.2. Informative References ....................................14 + 9. Acknowledgments ................................................15 + 10. Changes since RFC 3978 ........................................15 + 11. Declaration from the IAB ......................................16 + + + + + + + + + + + + + + + + + + +Bradner & Contreras Best Current Practice [Page 2] + +RFC 5378 RFC 3978-incoming November 2008 + + +1. Definitions + + The following definitions are for terms used in the context of this + document. Other terms, including "IESG", "ISOC", "IAB", and "RFC + Editor" are defined in [RFC2028]. + + a. "Contribution": any submission to the IETF intended by the + Contributor for publication as all or part of an Internet-Draft or + RFC (except for RFC Editor Contributions described in Section 4 + below) and any statement made within the context of an IETF + activity. Such statements include oral statements in IETF + sessions as well as written and electronic communications, made at + any time or place, that are addressed to: + + o the IETF plenary session, + o any IETF working group or portion thereof, + o any Birds of a Feather (BOF) session, + o the IESG, or any member thereof on behalf of the IESG, + o the IAB, or any member thereof on behalf of the IAB, + o any IETF mailing list, including the IETF list itself, any + working group or design team list, or any other list functioning + under IETF auspices, + o the RFC Editor or the Internet-Drafts function (except for RFC + Editor Contributions, as described in Section 4 below). + + Statements made outside of an IETF session, mailing list, or other + function, that are clearly not intended to be input to an IETF + activity, group, or function are not IETF Contributions in the + context of this document. + + b. "Contributor": an individual submitting a Contribution. + + c. "Indirect Contributor": any person who has materially or + substantially contributed to a Contribution without being + personally involved in its submission to the IETF. + + d. "Copyright": the legal right granted to an author in a document or + other work of authorship under applicable law. A "copyright" is + not equivalent to a "right to copy". Rather a copyright + encompasses all of the exclusive rights that an author has in a + work, such as the rights to copy, publish, distribute and create + derivative works of the work. An author often cedes these rights + to his or her employer or other parties as a condition of + employment or compensation. + + e. "IETF": in the context of this document, the IETF includes all + individuals who participate in meetings, working groups, mailing + lists, functions, and other activities that are organized or + + + +Bradner & Contreras Best Current Practice [Page 3] + +RFC 5378 RFC 3978-incoming November 2008 + + + initiated by ISOC, the IESG, or the IAB under the general + designation of the Internet Engineering Task Force (IETF), but + solely to the extent of such participation. + + f. "IETF Documents": RFCs and Internet-Drafts that are used in the + IETF Standards Process as defined in 1(g). This is identical to + the "IETF stream" defined in [RFC4844]. + + g. "IETF Standards Process": the activities undertaken by the IETF in + any of the settings described in 1(a) above. + + h. "IETF Trust": a trust established under the laws of the + Commonwealth of Virginia, USA, in order to hold and administer + intellectual property rights for the benefit of the IETF. + + i. "Internet-Draft": temporary documents used in the IETF Standards + Process. Internet-Drafts are posted on the IETF web site by the + IETF Secretariat. As noted in Section 2.2 of RFC 2026, Internet- + Drafts have a nominal maximum lifetime of six months in the IETF + Secretariat's public directory. + + j. "Legend Instructions": the standardized text that is maintained by + the IETF Trust and is included in IETF Documents and the + instructions and requirements for including that standardized text + in IETF Documents. The text and instructions are posted from time + to time at http://trustee.ietf.org/license-info. + + k. "RFC": the publication series used by the IETF among others. RFCs + are published by the RFC Editor. Although RFCs may be superseded + in whole or in part by subsequent RFCs, the text of an RFC is not + altered once published in RFC form. (See [RFC2026] Section 2.1.) + + l. "Reasonably and personally known": something an individual knows + personally or, because of the job the individual holds, would + reasonably be expected to know. This wording is used to indicate + that an organization cannot purposely keep an individual in the + dark about certain information just to avoid the disclosure + requirement. + + m. "Non-IETF documents": Internet-Drafts that are submitted to the + RFC Editor independently of the IETF Standards Process. (See + Section 4.) + + + + + + + + + +Bradner & Contreras Best Current Practice [Page 4] + +RFC 5378 RFC 3978-incoming November 2008 + + +2. Introduction + + In all matters of copyright and document procedures, the intent is to + benefit the Internet community and the public at large, while + respecting the legitimate rights of others. + + 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 obtain numerous rights in the works + they produce automatically upon producing them. These rights include + copyrights, moral rights, and other rights. In many cases, if the + author produces a work within the scope of his or her employment, + most of those rights are usually assigned to the employer, either by + operation of law or, in many cases, under contract. (The Berne + Convention names some rights as "inalienable", which means that the + author retains them in all cases.) + + In order for Contributions to be used within the IETF Standards + Process, including when they are published as Internet-Drafts or + RFCs, certain limited rights must be granted to the IETF Trust, which + then grants the necessary rights to the IETF. In addition, + Contributors must make representations to the IETF Trust and the IETF + regarding their ability to grant these rights. + + Section 1 provides definitions used in these policies. Sections 3 + and 4 of this document explain the rationale for these provisions. + Sections 1, 2, 5, and 6 of this document are normative, the other + sections are informative. RFC 3979 (BCP 79) [RFC3979] deals with + rights, including possible patent rights, in technologies developed + or specified as part of the IETF Standards Process. This document is + not intended to address those issues. This memo obsoletes RFCs 3978 + [RFC3978] and 4748 [RFC4748] and, with RFC 3979 (BCP 79) and + [RFC5377], replaces Section 10 of RFC 2026 [RFC2026]. + + This document is not intended as legal advice. Readers are advised + to consult their own legal advisors if they would like a legal + interpretation of their rights or the rights of the IETF Trust + [RFC4371] in any Contributions they make. + +2.1. No Retroactive Effect + + This memo does not retroactively obtain additional rights from + Contributions that predate the date that the IETF Trust announces the + adoption of these procedures. + + + + + + + +Bradner & Contreras Best Current Practice [Page 5] + +RFC 5378 RFC 3978-incoming November 2008 + + +3. Exposition of Why These Procedures Are the Way They Are + +3.1. Rights Granted in Contributions + + The IETF Trust and the IETF must obtain the right to publish an IETF + Contribution as an RFC or an Internet-Draft from the Contributors. + + A primary objective of this policy is to obtain from the document + authors only the non-exclusive rights that are needed to develop and + publish IETF Documents and to use IETF Contributions in the IETF + Standards Process and potentially elsewhere. + + The authors retain all other rights, but cannot withdraw the above + rights from the IETF Trust and the IETF. + + It is important to note that under this document, Contributors are + required to grant certain rights to the IETF Trust (see Section + 5.3.), which holds all IETF-related intellectual property on behalf + of the IETF community. The IETF Trust will, in turn, grant a + sublicense of these rights to all IETF participants for use in the + IETF Standards Process (see Section 5.4.). This sublicense is + necessary for the standards development work of the IETF to continue. + In addition, the IETF Trust may grant certain other sublicenses of + the rights that it is granted under this document. In granting such + other sublicenses, the IETF Trust will be guided and bound by + documents such as [RFC5377]. + +3.2. Rights to Use Contributions + + It is important that the IETF receive assurances from all + Contributors that they have the authority to grant the IETF the + rights that they claim to grant because, under the laws of most + countries and applicable international treaties, copyright rights + come into existence when a work of authorship is created (but see + Section 3.5 below regarding public domain documents), and the IETF + cannot make use of IETF Contributions if it does not have sufficient + rights with respect to these copyright rights. The IETF and its + participants would run a greater risk of liability to the owners of + these rights without this assurance. To this end, the IETF asks + Contributors to give the assurances in Section 5.6 below. These + assurances are requested, however, only to the extent of the + Contributor's reasonable and personal knowledge. (See Section 1(l).) + +3.3. Right to Produce Derivative Works + + The IETF needs to be able to evolve IETF Documents in response to + experience gained in the deployment of the technologies described in + such IETF Documents, to incorporate developments in research, and to + + + +Bradner & Contreras Best Current Practice [Page 6] + +RFC 5378 RFC 3978-incoming November 2008 + + + react to changing conditions on the Internet and other IP networks. + The IETF may also decide to permit others to develop derivative works + based on Contributions. In order to do this, the IETF must be able + to produce derivatives of its documents; thus, the IETF must obtain + the right from Contributors to produce derivative works. Note that + the right to produce translations is required before any Contribution + can be published as an RFC, to ensure the widest possible + distribution of the material in RFCs. The right to produce + derivative works, in addition to translations, is required for all + IETF Standards Track documents and for most IETF non-Standards Track + documents. There are two exceptions to this requirement: 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 a Contribution as a working group + document or otherwise work on it. For non-working group + Contributions where the Contributor requests publication as a + Standards Track RFC, the right to produce derivative works must be + granted before the IESG will issue an IETF Last Call and, for most + non-Standards Track, non-working group Contributions, before the IESG + will consider the Internet-Draft for publication. Occasionally a + Contributor may not want to grant publication rights or the right to + produce derivative works before finding out if a Contribution has + been accepted for development in the IETF Standards Process. In + these cases, the Contributor may include a limitation on the right to + make derivative works in the form specified in the Legend + Instructions. A working group can discuss the Contribution with the + aim to decide if it should become a working group document, even + though the right to produce derivative works or to publish the + Contribution as an RFC has not yet been granted. However, if the + Contribution is accepted for development, the Contributor must + resubmit the Contribution without the limitation notices before a + working group can formally adopt the Contribution as a working group + document. The IETF Trust may establish different policies for + granting sublicenses with respect to different types of Contributions + and content within Contributions (such as executable code versus + descriptive text or references to third-party materials). The IETF + Trust's policies concerning the granting of sublicenses to make + derivative works will be guided by RFC [RFC5377]. + + The IETF has historically encouraged organizations to publish details + of their technologies, even when the technologies are proprietary, + because understanding how existing technology is being used helps + when developing new technology. But organizations that publish + information about proprietary technologies are frequently not willing + to have the IETF produce revisions of the technologies and then + possibly claim that the IETF version is the "new version" of the + + + +Bradner & Contreras Best Current Practice [Page 7] + +RFC 5378 RFC 3978-incoming November 2008 + + + organization's technology. Organizations that feel this way can + specify that a Contribution be published with the other rights + granted under this document but may withhold the right to produce + derivative works other than translations. + + In addition, IETF Documents frequently make normative references to + standards or recommendations developed by other standards + organizations. Since the publications of some standards + organizations are not public documents, it can be quite helpful to + the IETF to republish, with the permission of the other standards + organization, some of these documents as RFCs so that the IETF + community can have open access to them to better understand what they + are referring to. In these cases, the RFCs can be published without + the right for the IETF to produce derivative works. In both of the + above cases, in which the production of derivative works is excluded, + the Contributor must include a special legend in the Contribution, as + specified in the Legend Instructions, in order to notify IETF + participants about this restriction. + +3.4. Rights to Use Trademarks + + Contributors may wish to seek trademark or service mark protection on + any terms that are coined or used in their 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 5.3 below, to grant the IETF Trust a perpetual + license to use any such trademarks or service marks solely in + exercising rights to reproduce, publish, discuss, and modify the IETF + Contribution. This license does not authorize the IETF or others to + use any trademark or service mark in connection with any product or + service offering. + +3.5. Contributions Not Subject to Copyright + + Certain documents, including those produced by the U.S. government + and those which are in the public domain, may not be protected by the + same copyright and other legal rights as other documents. + Nevertheless, we ask each Contributor to grant to the IETF the same + rights he or she would grant, and to make the same representations, + as though the IETF Contribution were protected by the same legal + rights as other documents, and as though the Contributor could be + able to grant these rights. We ask for these grants and + representations only to the extent that the Contribution may be + protected. We believe they are necessary to protect the ISOC, the + IETF Trust, the IETF, the IETF Standards Process, and all IETF + participants, and because the IETF does not have the resources or + wherewithal to make any independent investigation as to the actual + proprietary status of any document submitted to it. + + + +Bradner & Contreras Best Current Practice [Page 8] + +RFC 5378 RFC 3978-incoming November 2008 + + +3.6. Copyright in RFCs + + As noted above, Contributors to the IETF (or their employers) retain + ownership of the copyright in their Contributions. This includes + Internet-Drafts and all other Contributions made within the IETF + Standards Process (e.g., via e-mail, oral comment, and otherwise). + However, it is important that the IETF (through the IETF Trust) own + the copyright in documents that are published as RFCs (other than + Informational RFCs and RFCs that are submitted as RFC Editor + Contributions). Ownership of the copyright in an RFC does not + diminish the Contributors' rights in their underlying contributions, + but it does prevent anyone other than the IETF Trust (and its + licensees) from republishing or modifying an RFC in RFC format. In + this respect, Contributors are treated the same as anybody else: + though they may extract and republish their own Contributions without + limitation, they may not do so in the RFC format used by the IETF. + And while this principle (which is included in Section 5.9 below) may + appear to be new to the IETF, it actually reflects historical + practice and has been observed for many years through the inclusion + of an ISOC or IETF Trust copyright notice on all RFC documents since + the publication of RFC 2026. + +4. Non-IETF Documents + + This document only relates to Contributions made as part of the IETF + Processes. Other documents that are referred to as Internet-Drafts + and RFCs may be submitted to and published by the RFC Editor + independently of the IETF Standards Process. Such documents are not + covered by this document, unless the controlling entity for that + document stream, as described in [RFC4844] chooses to apply these + rules. Non-IETF Contributions must be marked appropriately as + described in the Legend Instructions. See the RFC Editor web page + for information about the policies concerning rights in RFC Editor + Documents; for other document streams, the controlling entity must be + contacted. See Section 11 for a declaration from the IAB on this + matter. + +5. Rights in Contributions + +5.1. General Policy + + By submission of a Contribution, each person actually submitting the + Contribution and each named co-Contributor is deemed to have read and + understood the rules and requirements set forth in this document. + Each Contributor is deemed, by the act of submitting a Contribution, + to enter into a legally-binding agreement to comply with the terms + and conditions set forth in this document. + + + + +Bradner & Contreras Best Current Practice [Page 9] + +RFC 5378 RFC 3978-incoming November 2008 + + + The Contributor is further deemed to have agreed that he/she has + obtained the necessary permissions to enter into such an agreement + from any party that the Contributor reasonably and personally knows + may have rights in the Contribution, including, but not limited to, + the Contributor's sponsor or employer. + + No further acknowledgment, signature, or other action is required to + bind a Contributor to these terms and conditions. The operation of + the IETF and the work conducted by its many participants is dependent + on such agreement by each Contributor, and each IETF participant + expressly relies on the agreement of each Contributor to the terms + and conditions set forth in this document. + +5.2. Confidentiality Obligations + + No information or document that is subject to any requirement of + confidentiality or any restriction on its dissemination 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 + generated automatically or otherwise, that states or implies that the + Contribution is confidential or subject to any privilege, can be + disregarded for all purposes, and will be of no force or effect. + +5.3. Rights Granted by Contributors to the IETF Trust + + To the extent that a Contribution or any portion thereof is protected + by copyright or other rights of authorship, the Contributor and each + named co-Contributor grant a perpetual, irrevocable, non-exclusive, + royalty-free, world-wide, sublicensable right and license to the IETF + Trust under all such copyrights and other rights in the Contribution: + + a. to copy, publish, display, and distribute the Contribution, in + whole or in part, + + b. to prepare translations of the Contribution into languages other + than English, in whole or in part, and to copy, publish, display, + and distribute such translations or portions thereof, + + c. to modify or prepare derivative works (in addition to + translations) that are based on or incorporate all or part of the + Contribution, and to copy, publish, display, and distribute such + derivative works, or portions thereof unless explicitly disallowed + in the notices contained in a Contribution (in the form specified + by the Legend Instructions), and + + + + + +Bradner & Contreras Best Current Practice [Page 10] + +RFC 5378 RFC 3978-incoming November 2008 + + + 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 Section 5.3, + provided that when reproducing Contributions, trademark and + service mark identifiers used in the Contribution, including TM + and (R), will be preserved. + +5.4. Sublicenses by the IETF Trust + + The IETF Trust will sublicense the rights granted to it under Section + 5.3 to all IETF participants for use within the IETF Standards + Process. This license is expressly granted under a license agreement + issued by the IETF Trust, which can be found at + http://trustee.ietf.org/license-info. + + This license is expressly granted under a license agreement issued by + the IETF Trust and must contain a pointer to the full IETF Trust + agreement. + + In addition, the IETF Trust may grant additional sublicenses of the + licenses granted to it hereunder. In doing so, the IETF Trust will + comply with the guidance provided under RFC 5377 [RFC5377]. + +5.5. No Patent License + + The licenses granted in Section 5.3 shall not be deemed to grant any + right under any patent, patent application, or other similar + intellectual property right disclosed by the Contributor under BCP 79 + [RFC3979] or otherwise. + +5.6. Representations and Warranties + + With respect to each Contribution, each Contributor represents that, + to the best of his or her knowledge and ability: + + a. The Contribution properly acknowledges all Contributors, including + Indirect Contributors. + + b. No information in the Contribution is confidential, and the IETF, + IETF Trust, 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. + + + + + +Bradner & Contreras Best Current Practice [Page 11] + +RFC 5378 RFC 3978-incoming November 2008 + + + d. The Contributor has not intentionally included in the Contribution + any material that 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. + +5.7. 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 this + Section 5. + +5.8. Trademarks + + Contributors 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.) + +5.9. Copyright in RFCs + + Subject to each Contributor's (or its sponsor's) ownership of its + underlying Contributions as described in Section 5.6 (which ownership + is qualified by the irrevocable licenses granted under Section 5.3), + each Contributor hereby acknowledges that the copyright in any RFC in + which such Contribution is included, other than an RFC that is an RFC + Editor Contribution, shall be owned by the IETF Trust. Such + Contributor shall be deemed to assign to the IETF Trust such + Contributor's copyright interest in the collective work constituting + + such RFC upon the submission of such RFC for publication, and + acknowledges that a copyright notice acknowledging the IETF Trust's + ownership of the copyright in such RFC will be included in the + published RFC. + +5.10. Contributors' Retention of Rights + + Although Contributors provide specific rights to the IETF, it is not + intended that this should deprive them of their right to exploit + their Contributions. To underscore this principle, the IETF Trust is + + + +Bradner & Contreras Best Current Practice [Page 12] + +RFC 5378 RFC 3978-incoming November 2008 + + + directed to issue a license or assurance to Contributors, which + confirms that they may each make use of their Contributions as + published in an RFC in any way they wish, subject only to the + restriction that no Contributor has the right to represent any + document as an RFC, or equivalent of an RFC, if it is not a full and + complete copy or translation of the published RFC. + +6. Legends, Notices and Other Standardized Text in IETF Documents + + The IETF requires that certain standardized text be reproduced + verbatim in certain IETF Documents (including copies, derivative + works, and translations of IETF Documents). Some of this + standardized text may be mandatory (e.g., copyright notices and + disclaimers that must be included in all RFCs) and some may be + optional (e.g., limitations on the right to make derivative works). + The text itself, as well as the rules that explain when and how it + must be used, is contained in the Legend Instructions. The Legend + Instructions may be updated from time to time, and the version of the + standardized text that must be included in IETF Documents is that + which was posted in the Legend Instructions on the date of + publication. + + The IETF reserves the right to refuse to publish Contributions that + do not include the legends and notices required by the Legend + Instructions. + + It is important to note that each Contributor grants the IETF Trust + rights pursuant to this document and the policies described herein. + The legends and notices included in certain written Contributions + such as Internet-Drafts do not themselves convey any rights. They + are simply included to inform the reader (whether or not part of the + IETF) about certain legal rights and limitations associated with such + documents. + + It is also important to note that additional copyright notices are + not permitted in IETF Documents except in the case where such + document is the product of a joint development effort between the + IETF and another standards development organization or is a + republication of the work of another standards development + organization. Such exceptions must be approved on an individual + basis by the IAB. + +7. Security Considerations + + This memo relates to the 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. + + + +Bradner & Contreras Best Current Practice [Page 13] + +RFC 5378 RFC 3978-incoming November 2008 + + +8. References + +8.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. + + [RFC4371] Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for + IPR Trust", BCP 101, RFC 4371, January 2006. + +8.2. Informative References + + [RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78, + RFC 3978, March 2005. + + [RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the IETF + Trust", BCP 78, RFC 4748, October 2006. + + [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC + Series and RFC Editor", RFC 4844, July 2007. + + [RFC5377] Halpern, J., Ed., "Advice to the Trustees of the IETF Trust + on Rights to be Granted in IETF Documents", RFC 5377, + November 2008. + + [Berne] "Berne Convention for the Protection of Literary and + Artistic Work", http://www.wipo.int/treaties/en/ip/berne/ + trtdocs_wo001.html. + + + + + + + + + + + + + + + + +Bradner & Contreras Best Current Practice [Page 14] + +RFC 5378 RFC 3978-incoming November 2008 + + +9. Acknowledgments + + The editors would like to acknowledge the help the IETF IPR Working + Group provided during the development of the document. + +10. Changes since RFC 3978 + + This document represents a significant reorganization and rewording + of RFC 3978, along with a number of substantive changes. + + The most basic change is to limit this document to the rights that a + Contributor grants to the IETF Trust when making a Contribution. All + sublicenses of rights for the use of IETF Documents must be provided + by the IETF Trust. (See Section 5.4.) + + Material added from RFC 4748 that recognized the IETF Trust. + + Most of the material relating to RFC Editor documents has been + removed since the RFC Editor maintains their own rules and processes + for RFC Editor documents. Renamed these documents to "non-IETF + documents". Added section 11 from the IAB discussing this topic. + + Changes in the definitions section include defining the terms + "Contribution", "Indirect Contributor", "Copyright", "IETF Trust", + and "Legend Instructions", as well as minor tweaks to some of the + other definitions. + + The responsibility for the text of notices has been given to the IETF + Trust and removed from this document. (See Section 6.) + + Clarified that Contributors enter into a legally binding contract + when they submit a Contribution. (See Section 5.1.) + + The right to produce derivative works provided by the Contributor to + the IETF Trust is not limited to being within the IETF Standards + Process. + + Made it clear that this document does not deal with patent licenses. + (See Section 5.5.) + + Clarified the ownership of the Copyrights to IETF Documents. (See + Section 5.9.) + + Clarified the rights retained by authors of IETF Contributions. (See + Section 5.10.) + + + + + + +Bradner & Contreras Best Current Practice [Page 15] + +RFC 5378 RFC 3978-incoming November 2008 + + +11. Declaration from the IAB + + The IAB discussed the IPR documents during its most recent call. It + unanimously decided that the IAB stream is to be covered by the + incoming IPR document. It is our understanding that IAB stream + documents' IPR are then automatically covered by the outbound rights + that the IETF Trust will establish based on the advice in [RFC5377]. + + We also want to stress that, for any change in the inbound rights for + streams other than the IETF and IAB streams, there needs to be a + stream-dependent discussion and approval process, as indicated in RFC + 4844, "The RFC Series and RFC Editor" [RFC4844], section 4.2.3. + + To that extent, section 4 of the document should explicitly mention + that the IRTF, the Independent, and any possible future streams are + not covered by the document. + + For the IAB, + + Olaf Kolkman + April 4, 2008 + +Editors' Addresses + + Scott Bradner + Harvard University + 29 Oxford St. + Cambridge MA, 02138 USA + + Phone: +1 617 495 3864 + EMail: sob@harvard.edu + + + Jorge L. Contreras + WilmerHale + 1875 Pennsylvania Avenue NW + Washington, DC 20006 USA + + Phone: +1 202 663 6872 + EMail: jorge.contreras@wilmerhale.com + + + + + + + + + + + +Bradner & Contreras Best Current Practice [Page 16] + |