diff options
Diffstat (limited to 'doc/rfc/rfc3667.txt')
| -rw-r--r-- | doc/rfc/rfc3667.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc3667.txt b/doc/rfc/rfc3667.txt new file mode 100644 index 0000000..65d660c --- /dev/null +++ b/doc/rfc/rfc3667.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group S. Bradner +Request for Comments: 3667 Harvard University +BCP: 78 February 2004 +Updates: 2026 +Category: Best Current Practice + + + IETF Rights in Contributions + +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) The Internet Society (2004). All Rights Reserved. + +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 + updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC + 2026. + +Table of Contents + + 1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Rights in IETF Contributions . . . . . . . . . . . . . . . . . 5 + 3.1. General Policy . . . . . . . . . . . . . . . . . . . . . 5 + 3.2. Confidentiality Obligations. . . . . . . . . . . . . . . 5 + 3.3. Granting of Rights and Permissions . . . . . . . . . . . 6 + 3.4. Representations and Warranties . . . . . . . . . . . . . 7 + 3.5. No Duty to Publish . . . . . . . . . . . . . . . . . . . 7 + 3.6. Trademarks . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Rights in RFC Editor Contributions . . . . . . . . . . . . . . 8 + 4.1. Requirements from Section 3. . . . . . . . . . . . . . . 8 + 4.2. Granting of Rights and Permissions . . . . . . . . . . . 8 + 5. Notices Required in IETF Documents . . . . . . . . . . . . . . 9 + 5.1. IPR Disclosure Acknowledgement . . . . . . . . . . . . . 10 + 5.2. Derivative Works Limitation. . . . . . . . . . . . . . . 10 + 5.3. Publication Limitation . . . . . . . . . . . . . . . . . 11 + + + +Bradner Best Current Practice [Page 1] + +RFC 3667 IETF Rights in Submissions February 2004 + + + 5.4. Copyright Notice . . . . . . . . . . . . . . . . . . . . 11 + 5.5. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.6. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Notices and Rights Required in RFC Editor Contributions. . . . 13 + 7. Exposition of why these procedures are the way they are. . . . 13 + 7.1. Rights Granted in IETF Contributions . . . . . . . . . . 13 + 7.2. Rights to use Contributed Material . . . . . . . . . . . 14 + 7.3. Right to Produce Derivative Works. . . . . . . . . . . . 14 + 7.4. Rights to use Trademarks . . . . . . . . . . . . . . . . 16 + 7.5. Who Does This Apply To?. . . . . . . . . . . . . . . . . 16 + 8. Contributions Not Subject to Copyright . . . . . . . . . . . . 16 + 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 16 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 10.2. Informative References . . . . . . . . . . . . . . . . . 17 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 + 12. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 17 + 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 + +1. Definitions + + 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 [RFC 2028]. + + a. "IETF": In the context of this document, the IETF includes all + individuals who participate in meetings, working groups, mailing + lists, functions and other activities which are organized or + initiated by ISOC, the IESG or the IAB under the general + designation of the Internet Engineering Task Force or IETF, but + solely to the extent of such participation. + + b. "IETF Standards Process": the activities undertaken by the IETF in + any of the settings described in 1(c) below. + + c. "IETF 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 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, + which are addressed to: + + o the IETF plenary session, + o any IETF working group or portion thereof, + o the IESG, or any member thereof on behalf of the IESG, + o the IAB or any member thereof on behalf of the IAB, + + + + +Bradner Best Current Practice [Page 2] + +RFC 3667 IETF Rights in Submissions February 2004 + + + 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 described 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. + + d. "Internet-Draft": temporary documents used in the IETF and RFC + Editor processes. Internet-Drafts are posted on the IETF web site + by the IETF Secretariat and have a nominal maximum lifetime in the + Secretariat's public directory of 6 months, after which they are + removed. Note that Internet-Drafts are archived many places on + the Internet, and not all of these places remove expired + Internet-Drafts. Internet-Drafts that are under active + consideration by the IESG are not removed from the Secretariat's + public directory until that consideration is complete. In + addition, the author of an Internet-Draft can request that the + lifetime in the Secretariat's public directory be extended before + the expiration. + + e. "RFC": the basic publication series for the IETF. RFCs are + published by the RFC Editor and once published are never modified. + (See [RFC 2026] Section 2.1) + + f. "RFC Editor Contribution": An Internet-Draft intended by the + Contributor to be submitted to the RFC Editor for publication as + an Informational or Experimental RFC but not intended to be part + of the IETF Standards Process. + + g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor + Contributions. Note that under Section 3.3(a) the grant of rights + in regards to IETF Internet-Drafts as specified in this document + is perpetual and irrevocable and thus survives the Secretariat's + removal of an Internet-Draft from the public directory, except as + limited by Section 3.3(a)(C). (See [RFC 2026] Sections 2.2 and 8) + + h. "IETF Documents": RFCs and Internet-Drafts except for Internet- + Drafts that are RFC Editor Contributions and the RFCs that are + published from them. + + i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC + Editor Contributions and the RFCs that may be published from them. + + j. "Contribution": IETF Contributions and RFC Editor Contributions. + + + +Bradner Best Current Practice [Page 3] + +RFC 3667 IETF Rights in Submissions February 2004 + + + k. "Contributor": an individual submitting a Contribution. + + l. "Reasonably and personally known": means something an individual + knows personally or, because of the job the individual holds, + would reasonably be expected to know. This wording is used to + indicate that an organization cannot purposely keep an individual + in the dark about patents or patent applications just to avoid the + disclosure requirement. But this requirement should not be + interpreted as requiring the IETF Contributor or participant (or + his or her represented organization, if any) to perform a patent + search to find applicable IPR. + +2. Introduction + + 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.) + + This document details the rights that the IETF requires in IETF + Contributions and rights the IETF, as publisher of Internet-Drafts, + requires in all such Drafts including RFC Editor Contributions. The + RFC Editor may also define additional rights required for RFC Editor + Contributions. + + In order for works to be used within the IETF Standards Process or to + be published as Internet-Drafts, certain limited rights in all + Contributions must be granted to the IETF and Internet Society + (ISOC). In addition, Contributors must make representations to IETF + and ISOC regarding their ability to grant these rights. These + necessary rights and representations have until now been laid out in + Section 10 of [RFC 2026]. In the years since [RFC 2026] was + published there have been a number of times when the exact intent of + Section 10 has been the subject of vigorous debate within the IETF + community. The aim of this document is to clarify various + ambiguities in Section 10 of [RFC 2026] that led to these debates and + to amplify the policy in order to clarify what the IETF is currently + doing. + + Section 1 gives definitions used in describing these policies. + Sections 3, 4, 5 and 6 of this document address the rights in + Contributions previously covered by Section 10 of [RFC 2026] and the + + + +Bradner Best Current Practice [Page 4] + +RFC 3667 IETF Rights in Submissions February 2004 + + + "Note Well" explanatory text presented at many IETF activities. + Sections 7 and 8 then explain the rationale for these provisions, + including some of the clarifications that have become understood + since the adoption of [RFC 2026]. The rules and procedures set out + in this document are not intended to substantially modify or alter + the IETF's current policy toward Contributions. + + A companion document [RFC 3668] deals with rights in technologies + developed or specified as part of the IETF Standards Process. This + document is not intended to address those issues. + + The rights addressed in this document fall into the following + categories: + + o rights to make use of contributed material + o copyrights in IETF documents + o rights to produce derivative works + o rights to use trademarks + + 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 in any + Contributions they make. + +3. Rights in IETF Contributions + + The following are the rights the IETF requires in all IETF + Contributions: + +3.1. General Policy + + In all matters of copyright and document procedures, the intent is to + benefit the Internet community and the public at large, while + respecting the legitimate rights of others. + +3.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. + + + + + +Bradner Best Current Practice [Page 5] + +RFC 3667 IETF Rights in Submissions February 2004 + + +3.3. Granting of Rights and Permissions + + By submission of a Contribution, each person actually submitting the + Contribution, and each named co-Contributor, is deemed to agree to + the following terms and conditions, and to grant the following + rights, on his or her own behalf and on behalf of the organization + the Contributor represents or is sponsored by (if any) when + submitting the Contribution. + + a. To the extent that a Contribution or any portion thereof is + protected by copyright and other rights of authorship, the + Contributor, and each named co-Contributor, and the organization + he or she represents or is sponsored by (if any) grant a + perpetual, irrevocable, non-exclusive, royalty-free, world-wide + right and license to the ISOC and the IETF under all intellectual + property rights in the Contribution: + + (A) to copy, publish, display and distribute the Contribution as + part of the IETF Standards Process or in an Internet-Draft, + + (B) to prepare or allow the preparation of translations of the + Contribution into languages other than English, + + (C) unless explicitly disallowed in the notices contained in a + Contribution [as per Section 5.2 below], to prepare + derivative works (other than translations) that are based on + or incorporate all or part of the Contribution, or comment + upon it, within the IETF Standards Process. The license to + such derivative works not granting the ISOC and the IETF any + more rights than the license to the original Contribution, + + (D) to reproduce any trademarks, service marks or trade names + which are included in the Contribution solely in connection + with the reproduction, distribution or publication of the + Contribution and derivative works thereof as permitted by + this paragraph. When reproducing Contributions, the IETF + will preserve trademark and service mark identifiers used by + the Contributor of the Contribution, including (TM) and (R) + where appropriate, and + + (E) to extract, copy, publish, display, distribute, modify and + incorporate into other works, for any purpose (and not + limited to use within the IETF Standards Process) any + executable code or code fragments that are included in any + IETF Document (such as MIB and PIB modules), subject to the + requirements of Section 5 (it also being understood that the + licenses granted under this paragraph (E) shall not be deemed + to grant any right under any patent, patent application or + + + +Bradner Best Current Practice [Page 6] + +RFC 3667 IETF Rights in Submissions February 2004 + + + other similar intellectual property right disclosed by the + Contributor under [IETF IPR]). + + b. The Contributor grants the IETF and ISOC permission to reference + the name(s) and address(es) of the Contributor(s) and of the + organization(s) s/he represents or is sponsored by (if any). + +3.4. Representations and Warranties + + 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 major Contributors. A + major Contributor is any person who has materially or + substantially contributed to the IETF Contribution. + + b. No information in the Contribution is confidential and the IETF, + ISOC, and its affiliated organizations may freely disclose any + information in the Contribution. + + c. There are no limits to the Contributor's ability to make the + grants, acknowledgments and agreements herein that are reasonably + and personally known to the Contributor. + + d. The Contributor has not intentionally included in the Contribution + any material which is defamatory or untrue or which is illegal + under the laws of the jurisdiction in which the Contributor has + his or her principal place of business or residence. + + e. All trademarks, trade names, service marks and other proprietary + names used in the Contribution that are reasonably and personally + known to the Contributor are clearly designated as such where + reasonable. + +3.5. No Duty to Publish + + The Contributor, and each named co-Contributor, acknowledges that the + IETF has no duty to publish or otherwise use or disseminate any + Contribution. The IETF reserves the right to withdraw or cease using + any Contribution that does not comply with the requirements of + Section 3.4 and Section 3.3 or 4.2. + +3.6. Trademarks + + Contributors, and each named co-Contributor, who claim trademark + rights in terms used in their IETF Contributions are requested to + state specifically what conditions apply to implementers of + + + + +Bradner Best Current Practice [Page 7] + +RFC 3667 IETF Rights in Submissions February 2004 + + + 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 [RFC 3668] Section 6.) + +4. Rights in RFC Editor Contributions + + The following are the rights the IETF, as the publisher of Internet- + Drafts, requires in all RFC Editor Contributions: + +4.1. Requirements from Section 3 + + All RFC Editor Contributions must meet the requirements of Sections + 3.1, 3.2, 3.4, 3.5 and 3.6. + +4.2. Granting of Rights and Permissions + + By submission of an RFC Editor Contribution, each person actually + submitting the RFC Editor Contribution, and each named co- + Contributor, is deemed to agree to the following terms and + conditions, and to grant the following rights, on his or her own + behalf and on behalf of the organization the Contributor represents + or is sponsored by (if any) when submitting the RFC Editor + Contribution. + + a. To the extent that an RFC Editor Contribution or any portion + thereof is protected by copyright and other rights of authorship, + the Contributor, and each named co-Contributor, and the + organization he or she represents or is sponsored by (if any) + grant a perpetual, irrevocable, non-exclusive, royalty-free, + world-wide right and license to the ISOC and the IETF under all + intellectual property rights in the RFC Editor Contribution for at + least the life of the Internet-Draft: + + (A) to copy, publish, display and distribute the RFC Editor + Contribution as an RFC, and + + (B) to prepare or allow the preparation of translations of the RFC + into languages other than English. + + (C) unless explicitly disallowed in the notices contained in an + RFC Editor Contribution (as per Section 5.2 below), to prepare + derivative works (other than translations) that are based on + or incorporate all or part of the RFC Editor Contribution, or + comment upon it. The license to such derivative works not + granting the ISOC and the IETF any more rights than the + license to the original RFC Editor Contribution, and + + + + + +Bradner Best Current Practice [Page 8] + +RFC 3667 IETF Rights in Submissions February 2004 + + + (D) to reproduce any trademarks, service marks or trade names + which are included in the RFC Editor Contribution solely in + connection with the reproduction, distribution or publication + of the RFC Editor Contribution and derivative works thereof as + permitted by this paragraph. When reproducing RFC Editor + Contributions, the IETF will preserve trademark and service + mark identifiers used by the Contributor of the RFC Editor + Contribution, including (TM) and (R) where appropriate. + + b. The Contributor grants the IETF and ISOC permission to reference + the name(s) and address(es) of the Contributor(s) and of the + organization(s) s/he represents or is sponsored by (if any). + +5. Notices Required in IETF Documents + + The IETF requires that certain notices and disclaimers described in + this Section 5 be reproduced verbatim in all IETF Documents + (including copies, derivative works and translations of IETF + Documents, but subject to the limited exceptions noted in Section + 5.2). This requirement protects IETF and its participants from + liabilities connected with these documents. The copyright notice + also alerts readers that the document is an IETF Document, and that + ISOC claims copyright rights to certain aspects of the document, such + as its layout, the RFC numbering convention and the prefatory + language of the document. This legend is not intended to imply that + ISOC has obtained ownership of the IETF Contribution itself, which is + retained by the author(s) or remains in the public domain, as + applicable. + + Each IETF Document must include the required notices described in + this Section 5. The required notices are the following: + + a. The IPR Disclosure Acknowledgement described in Section 5.1 + (required in all Internet-Drafts). + b. The Derivative Works Limitation described in Section 5.2 (for + specific IETF Documents only). + c. The Publication Limitation described in Section 5.3 (for specific + types of Internet-Drafts only). + d. The Copyright Notice described in Section 5.4 (for all IETF + Documents). + e. The Disclaimer described in Section 5.5 (for all IETF Documents). + + + + + + + + + + +Bradner Best Current Practice [Page 9] + +RFC 3667 IETF Rights in Submissions February 2004 + + +5.1. IPR Disclosure Acknowledgement (required in all Internet-Drafts + only) + + "By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668." + +5.2. Derivative Works Limitation + + If the Contributor desires to eliminate the IETF's right to make + modifications and derivative works of an IETF Contribution (other + than translations), one of the two of the following notices may be + included in the Status of Memo section of an Internet-Draft and + included in a published RFC: + + a. "This document may not be modified, and derivative works of it may + not be created, except to publish it as an RFC and to translate it + into languages other than English." + + b. "This document may not be modified, and derivative works of it may + not be created." + + In the cases of MIB or PIB modules and in other cases where the + Contribution includes material that is meant to be extracted in order + to be used, the following should be appended to statement 5.2 (a) or + 5.2 (b): + + "other than to extract section XX as-is for separate use." + + Notice 5.2(a) is used if the Contributor intends for the IETF + Contribution to be published as an RFC. Notice 5.2(b) is used along + with the Publication Limitation in Section 5.3 when the Contributor + does not intend for the IETF Contribution to be published as an RFC. + + These notices may not be used with any standards-track document or + with most working group documents, except as discussed in Section 7.3 + below, since the IETF must retain change control over its documents + and the ability to augment, clarify and enhance the original IETF + Contribution in accordance with the IETF Standards Process. + + Notice 5.2(a) may be appropriate when republishing standards produced + by other (non-IETF) standards organizations, industry consortia or + companies. These are typically published as Informational RFCs, and + do not require that change control be ceded to the IETF. Basically, + documents of this type convey information for the Internet community. + + + + + +Bradner Best Current Practice [Page 10] + +RFC 3667 IETF Rights in Submissions February 2004 + + + A fuller discussion of the rationale behind these requirements is + contained in Section 7.3 below. + +5.3. Publication Limitation + + If the Contributor only wants the IETF Contribution to be made + available in an Internet-Draft (i.e., does not want the IETF + Contribution to be published as an RFC) then the Contributor may + include the following notice in the Status of Memo section of the + Internet-Draft. + + "This document may only be posted in an Internet-Draft." + + This notice can be used on IETF Contributions that are intended to + provide background information to educate and to facilitate + discussions within IETF working groups but are not intended to be + published as an RFCs. + +5.4. Copyright Notice (required for all IETF Documents) + + (Normally placed at the end of the IETF Document.) + + "Copyright (C) The Internet Society (year). This document is + subject to the rights, licenses and restrictions contained in BCP + 78, and except as set forth therein, the authors retain all their + rights." + + 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 the document is a republication of the work of + another standards organization. Such exceptions must be approved on + an individual basis by the IAB. + +5.5. Disclaimer (required in all IETF Documents) + + (Normally placed at the end of the IETF Document after the copyright + notice.) + + "This document and the information contained herein are provided + on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR + ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE." + + + + +Bradner Best Current Practice [Page 11] + +RFC 3667 IETF Rights in Submissions February 2004 + + +5.6 Exceptions + + Notwithstanding the provisions of this Section 5, in certain limited + cases an abbreviated notice may be placed on certain types of + derivative works of IETF Documents in accordance with this Section + 5.6. + + a. in MIB modules, PIB modules and similar material commonly + extracted from IETF Documents, except for material that is being + placed under IANA maintenance, the following abbreviated notice + shall be included in the body of the material that will be + extracted in lieu of the notices otherwise required by Section 5: + + "Copyright (C) The Internet Society <year> . This version of + this MIB module is part of RFC XXXX; see the RFC itself for + full legal notices." + + When the MIB or PIB module is the initial version of a module that + is to be maintained by the IANA, the following abbreviated notice + shall be included: + + "Copyright (C) The Internet Society <year>. The initial + version of this MIB module was published in RFC XXXX; for full + legal notices see the RFC itself. Supplementary information + may be available on + http://www.ietf.org/copyrights/ianamib.html." + + For other types of components than "MIB", substitute "MIB module" + with an appropriate identifier. In the case of MIB and PIB + modules this statement should be placed in the DESCRIPTION clause + of the MODULE-IDENTITY macro. + + Variations of these abbreviated notices are not permitted except + in cases where the material to be extracted 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 organization. Such variations must be approved + on an individual basis by the IAB. + + b. short excerpts of IETF Documents presented in electronic help + systems, for example, the DESCRIPTION clauses for MIB variables, + do not need to include a copyright notice. + + + + + + + + + +Bradner Best Current Practice [Page 12] + +RFC 3667 IETF Rights in Submissions February 2004 + + +6. Notices and Rights Required in RFC Editor Contributions + + Since the IETF acts as publisher of Internet Drafts, even for + Internet Drafts that are not intended to become part of the Standards + Process, the following are required in all such drafts to protect the + IETF and its processes. The RFC Editor may require additional + notices. + + a. An IPR Disclosure Acknowledgement, identical to that specified in + Section 5.1. + + b. One of the following two copyright release statements: + + A. "By submitting this Internet-Draft, I accept the provisions of + Section 3 of RFC 3667." + + B. "By submitting this Internet-Draft, I accept the provisions of + Section 4 of RFC 3667." + +7. Exposition of Why These Procedures Are the Way They Are + +7.1. Rights Granted in IETF Contributions + + The IETF/ISOC 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 the IETF Contributions in the IETF + Standards Process while leaving all other rights with the authors. + + The non-exclusive rights that the IETF needs are: + + a. the right to publish the document + b. the right to let the document be freely reproduced in the formats + that the IETF publishes it in + c. the right to let third parties translate it into languages other + than English + d. except where explicitly excluded (see Section 5.2), the right to + make derivative works within the IETF process. + e. the right to let third parties extract some logical parts, for + example MIB modules + + The authors retain all other rights, but cannot withdraw the above + rights from the IETF/ISOC. + + + + + + +Bradner Best Current Practice [Page 13] + +RFC 3667 IETF Rights in Submissions February 2004 + + +7.2. Rights to use Contributed Material + + Because, under the laws of most countries and applicable + international treaties, copyright rights come into existence whenever + a work of authorship is created (but see Section 8 below regarding + public domain documents), and IETF cannot make use of IETF + Contributions if it does not have sufficient rights with respect to + these copyright rights, 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. Without this + assurance, IETF and its participants would run a greater risk of + liability to the owners of these rights. + + To this end, IETF asks Contributors to give the assurances in Section + 3.4 above. These assurances are requested, however, only to the + extent of the Contributor's reasonable and personal knowledge. (See + Section 1(l)) + +7.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 + react to changing conditions on the Internet and other IP networks. + 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 though that the IETF only requires + this right for the production of derivative works within the IETF + Standards Process. The IETF does not need, nor does it obtain, the + right to let derivative works be created outside of the IETF + Standards Process other than as noted in Section 3.3 (E). + + The right to produce derivative works is required for all IETF + standards track documents and for most IETF non-standards track + documents. There are two exceptions 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 an IETF Contribution as a working group + document or otherwise work on it. For non-working group IETF + Contributions where the Contributor requests publication as a + standards track RFC the right 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 IETF Contributions, before the + IESG will consider the Internet-Draft for publication. + + + + + +Bradner Best Current Practice [Page 14] + +RFC 3667 IETF Rights in Submissions February 2004 + + + Occasionally a Contributor may not want to grant publication rights + or the right to produce derivative works before finding out if an + IETF Contribution has been accepted for development in the IETF + Standards Process. In these cases the Contributor may include the + Derivative Works Limitation described in Section 5.2 and the + Publication Limitation described in Section 5.3 in their IETF + Contribution. A working group can discuss the Internet-Draft 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 IETF + Contribution as an RFC has not yet been granted. If the IETF + Contribution is accepted for development the Contributor must then + resubmit the IETF Contribution without the limitation notices before + a working group can formally adopt the IETF Contribution as a working + group document. + + 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 claim + that the IETF version is the "new version" of the organization's + technology. Organizations that feel this way can specify that an IETF + Contribution can be published with the other rights granted under + this document but may withhold the right to produce derivative works + other than translations. The right to produce translations is + required before any IETF Contribution can be published as an RFC to + ensure the widest possible distribution of the material in RFCs. + + 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 IETF Contribution, as specified in Section 5.2, in order to + notify IETF participants about this restriction. + + + + + + + + +Bradner Best Current Practice [Page 15] + +RFC 3667 IETF Rights in Submissions February 2004 + + +7.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 IETF Contributions. IETF + makes no judgment about the validity of any such trademark rights. + However, the IETF requires each Contributor, under the licenses + described in Section 3.3 above, to grant IETF a perpetual license to + use any such trademarks or service marks solely in exercising its + rights to reproduce, publish and modify the IETF Contribution. This + license does not authorize any IETF participant to use any trademark + or service mark in connection with any product or service offering, + but only in the context of IETF Documents and discussions. + +7.5. Who Does This Apply To? + + Rights and licenses granted to the IETF under this document are + granted to all individuals noted in Section 1(a), irrespective of + their employment or institutional affiliation. However, these + licenses do not extend broadly to the employers, sponsors or + institutions of such individuals, nor do they authorize the + individuals to exercise any rights outside the specific context of + the IETF Standards Process. + +8. 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 as 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, the IETF Standards Process and all IETF participants, and + also 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. + +9. Security Considerations + + This memo relates to IETF process, not any particular technology. + There are security considerations when adopting any technology, but + there are no known issues of security with IETF Contribution rights + policies. + + + + + +Bradner Best Current Practice [Page 16] + +RFC 3667 IETF Rights in Submissions February 2004 + + +10. References + +10.1. Normative References + + [RFC 2026] Bradner, S., Ed, "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996. + + [RFC 3668] Bradner, S., Ed., "Intellectual Property Rights in IETF + Technology", BCP 79, RFC 3668, February 2004. + +10.2. Informative References + + [Berne] "Berne Convention for the Protection of Literary and + Artistic Work", + http://www.wipo.int/treaties/ip/berne/index.html + +11. Acknowledgements + + The editor would like to acknowledge the help of the IETF IPR Working + Group and, in particular the help of Jorge Contreras of Hale and Dorr + for his careful legal reviews of this and other IETF IPR-related and + process documents. The editor would also like to acknowledge the + extensive help John Klensin provided during the development of the + document. + +12. Editor's Address + + Scott Bradner + Harvard University + 29 Oxford St. + Cambridge MA, 02138 + + Phone: +1 617 495 3864 + EMail: sob@harvard.edu + + + + + + + + + + + + + + + + + +Bradner Best Current Practice [Page 17] + +RFC 3667 IETF Rights in Submissions February 2004 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78 and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Bradner Best Current Practice [Page 18] + |