[フレーム] Skip to main content
Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Rights Contributors Provide to the IETF Trust
draft-ietf-ipr-3978-incoming-09

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5378.
Authors Scott O. Bradner , Jorge Contreras
Last updated 2022年01月28日 (Latest revision 2008年05月05日)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Best Current Practice
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5378 (Best Current Practice)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Russ Housley
Send notices to (None)
Email authors Email WG IPR References Referenced by Nits Search email archive
draft-ietf-ipr-3978-incoming-09
Network Working Group S. Bradner
Internet-Draft Harvard University
Intended status: BCP Jorge Contreras
 WilmerHale
 Editors
 5 May 2008
 Rights Contributors provide to the IETF Trust
 <draft-ietf-ipr-3978-incoming-09.txt>
Status of this Memo
 By submitting this Internet-Draft, each author represents that any
 applicable patent or other IPR claims of which he or she is aware
 have been or will be disclosed, and any of which he or she becomes
 aware will be disclosed, in accordance with Section 6 of BCP 79.
 Internet-Drafts are working documents of the Internet Engineering
 Task Force (IETF), its areas, and its working groups. Note that
 other groups may also distribute working documents as Internet-
 Drafts.
 Internet-Drafts are draft documents valid for a maximum of six months
 and may be updated, replaced, or obsoleted by other documents at any
 time. It is inappropriate to use Internet-Drafts as reference
 material or to cite them other than as "work in progress."
 The list of current Internet-Drafts can be accessed at
 http://www.ietf.org/ietf/1id-abstracts.txt.
 The list of Internet-Draft Shadow Directories can be accessed at
 http://www.ietf.org/shadow.html.
 This Internet-Draft will expire on October 5, 2008.
Copyright (C) The IETF Trust (2008).
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 RFC 3978 and 4748 and, with BCP 79 and RFC xxx (rfc editor
 - replace with the RFC # of -outgoing), replaces Section 10 of RFC
 2026.
Bradner & Contreras [Page 1]
Internet-Draft RFC 3978-incoming 5 May 2008
Table of Contents
 1. Definitions
 2. Introduction
 2.1 No Retroactive Effect
 3. Exposition of why these procedures are the way they are
 3.1. Rights Granted in Contributions
 3.2. Rights to use Contributions
 3.3. Right to Produce Derivative Works
 3.4. Rights to use Trademarks
 3.5. Contributions Not Subject to Copyright
 3.6. Copyright in RFCs
 4. RFC Editor Documents
 5. Rights in Contributions
 5.1. General Policy
 5.2. Confidentiality Obligations
 5.3. Rights Granted by Contributors to the IETF Trust
 5.4. Sublicenses by IETF Trust
 5.5. No Patent License
 5.6. Representations and Warranties
 5.7. No Duty to Publish
 5.8. Trademarks
 5.9. Copyright in RFCs
 6. Legends, Notices and Other Standardized Text in IETF Documents
 7. Security Considerations
 8. References
 8.1. Normative References
 8.2. Informative References
 9. Acknowledgements
 10. Changes since RFC 3978
 11. Declaration from the IAB
 12. Editors' Addresses
 Full Copyright Statement
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, which are addressed to:
 o the IETF plenary session,
 o any IETF working group or portion thereof,
 o any Birds of a Feather (BOF) session,
Bradner & Contreras [Page 2]
Internet-Draft RFC 3978-incoming 5 May 2008
 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 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" means 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 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.
 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 [RFC 4844].
 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" means 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, each as posted from time to time at
 http://www.ietf.org/legends.
Bradner & Contreras [Page 3]
Internet-Draft RFC 3978-incoming 5 May 2008
 k. "RFC": the basic publication series for the IETF. 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": 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 certain information just to avoid the disclosure
 requirement.
 m. "Non-IETF documents": means Internet-Drafts that are submitted to
 the RFC Editor independently of the IETF Standards Process. (See
 Section 4.)
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 Convention]), 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. A companion document RFC 3979 (BCP 79)
 [BCP79] 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 RFC 3978 [RFC3978] and 4748 [RFC4748] and, with RFC
 3979 (BCP 79) and [-outgoing], replaces Section 10 of RFC 2026
 [RFC2026].
Bradner & Contreras [Page 4]
Internet-Draft RFC 3978-incoming 5 May 2008
 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.
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 [-outgoing].
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
Bradner & Contreras [Page 5]
Internet-Draft RFC 3978-incoming 5 May 2008
 assurances are requested, however, only to the extent of the
 Contributor's reasonable and personal knowledge. (See Section 1(k))
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
 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 [-outbound].
Bradner & Contreras [Page 6]
Internet-Draft RFC 3978-incoming 5 May 2008
 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
 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 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 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
Bradner & Contreras [Page 7]
Internet-Draft RFC 3978-incoming 5 May 2008
 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 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.
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
 Standards Process 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 [RFC 4844] 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.
Bradner & Contreras [Page 8]
Internet-Draft RFC 3978-incoming 5 May 2008
 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.
 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 acknowledgement, 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
 (D) to reproduce any trademarks, service marks or trade names which
 are included in the Contribution solely in connection with the
Bradner & Contreras [Page 9]
Internet-Draft RFC 3978-incoming 5 May 2008
 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 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 xxx [-outbound].
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
 [BCP79] 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.
 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.
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
Bradner & Contreras [Page 10]
Internet-Draft RFC 3978-incoming 5 May 2008
 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 [BCP79] 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
 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, are
 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.
Bradner & Contreras [Page 11]
Internet-Draft RFC 3978-incoming 5 May 2008
 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 the document
 is a republication of the work of another standards development
 organization. Such exceptions must be approved on an individual
 basis by the IAB.
IANA Considerations (RFC Editor - please remove this section when
 publishing)
 This document presents no issues that should be considered by the
 IANA (this section is here to mollify the ID-nits checker)
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.
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.
 [BCP79] Bradner, S., Ed, "Intellectual Property Rights in IETF
 Technology", BCP 79, RFC 3979, March 2005.
 [RFC4371] Carpenter, B. and L. Lynch, "BCP 101 Update for IPR Trust",
 RFC 4371, January 2006.
8.2. Informative References
 [RFC3978] Bradner, S. Ed., "IETF Rights in Contributions", RFC 3978,
 March 2005.
 [RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF Trust",
 RFC 4748, October 2006.
Bradner & Contreras [Page 12]
Internet-Draft RFC 3978-incoming 5 May 2008
 [RFC4844] Daigle, L. and IAB, "The RFC Series and RFC Editor", RFC
 4844, July 2007
 [-outgoing] Halpern, J., "Advice to the Trustees of the IETF Trust on
 Rights to be Granted in IETF Documents", RFC XXXX, date.
 [Berne Convention] "Berne Convention for the Protection of Literary
 and Artistic Work",
 http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html.
9. Acknowledgements
 The editors would like to acknowledge the help of the IETF IPR
 Working Group provided during the development of the document.
10. Changes since RFF 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.)
Bradner & Contreras [Page 13]
Internet-Draft RFC 3978-incoming 5 May 2008
 Clarified the rights retained by authors of IETF Contributions. (See
 Section 5.10.)
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 the iab-stream
 documents IPR are then automatically covered by the outbound rights
 that the IETF trust will establish based on the advice in
 [-outbound].
 We also want to stress that for any change in the inbound rights for
 streams other than the ietf- and iab-stream 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 draft should explicitly mention that
 the irtf-, the independent- and any possible future streams are not
 covered by the draft.
 For the IAB,
 Olaf Kolkman
 April 4, 2008
12. 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
Full Copyright Statement
 Copyright (C) The IETF Trust (2008).
 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.
Bradner & Contreras [Page 14]
Internet-Draft RFC 3978-incoming 5 May 2008
 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, THE IETF TRUST 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.
changes - to be removed before publication
 version 01 ->02
 misc grammar fixes
 added BOF to sec 1(a)
 added 1(l)
 reorder 3.2
 moved sentence about translations within sec 3.3
 reorder 5.3 (C)
 added section 5.10
 removed "an Informational RFC" from section 5.9
 added text about assigning rights and acknowledging that a
 copyright notice will be added to section 5.9
 added 2nd pp to section 3.6 from RFC 3978
 added pp on multiple copyright notices to sec 6
 version 02 ->03
 replaced the text in section 5.10
Bradner & Contreras [Page 15]
Internet-Draft RFC 3978-incoming 5 May 2008
 version 03 -> 04
 change "requested" to "directed" in section 5.10
 add sections 1 & 2 to the list of normative sections in section 2
 sec 5.7 - replace last sentence
 sec 5.3 preface - add "sublicensable"
 sec 1 i - add that the IETF Trust maintains the Legend
 Instructions
 open issues
 a/ the use of the terms Contribution and Contributors -
 for example in section 5.6
 b/ do we need specific mention of work for hire in sec 3.2
 version 04 -> 05
 replaced section 5.1 & the 1st pp of section 5.3
 replaced section 5.6 a
 version 05 -> 06 - input from Jorge
 fix various typos in document
 add definition of "Indirect Contributor"
 fix definition of "Reasonably and personally known" to be
 copyright-related rather than patent-related
 reword sec 5.6 a and remove definition of "Indirect Contributor"
 add pointer to section 5.6 to section 5.9
 tweak the wording on section 5.10
 add "development" to the next to last sentence of section 6
 version 06 -> 07
 fix references etc to mollify the ID nits checker
 version 07 -> 08
 change "the IETF's RFC format" to "the RFC format used by the
 IETF" in section 3.6
 tweak definition of IETF Documents
 change "[TRUST LICENSE AGREEMENT]" to "a license agreement issued
 by the IETF Trust" and add a requirement that licenses must point
 to the full trust agreement in section 5.4
 added "changes from 3987" section 10
 version 08 -> 09 - last call comments & IAB requests
 fix punctuation and the lack of the word "the" in front of "IETF"
 and "IETF Trust" in a number of places
 clean up references to RFC 3979/BCP 79
 add note to 1(f)
 rename section 1(m)
 replace section 4
 
Bradner & Contreras [Page 16]

AltStyle によって変換されたページ (->オリジナル) /