RFC5378 日本語訳
5378 Rights Contributors Provide to the IETF Trust. S. Bradner, Ed.,J. Contreras, Ed.. November 2008. (Format: TXT=37980 bytes) (Obsoletes RFC3978, RFC4748) (Updates RFC2026) (Also BCP0078) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
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
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
Rights Contributors Provide to the IETF Trust
Status of This Memo
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.
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 Notice
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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
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.
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
Bradner & Contreras Best Current Practice [Page 1] RFC 5378 RFC 3978-incoming November 2008
Table of Contents
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
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
Bradner & Contreras Best Current Practice [Page 2] RFC 5378 RFC 3978-incoming November 2008
1. Definitions
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].
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:
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).
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.
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.
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.
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.
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
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
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.
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].
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.
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.
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.
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.
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.)
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.
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.)
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
Bradner & Contreras Best Current Practice [Page 4] RFC 5378 RFC 3978-incoming November 2008
2. Introduction
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.
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.)
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.
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].
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.
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
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.
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
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. Exposition of Why These Procedures Are the Way They Are
3.1. Rights Granted in Contributions
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.
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.
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.
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].
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
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).)
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
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
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
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.
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 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
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
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.
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.
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
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.
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
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.
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
Bradner & Contreras Best Current Practice [Page 8] RFC 5378 RFC 3978-incoming November 2008
3.6. Copyright in RFCs
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.
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
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.
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. Rights in Contributions
5.1. General Policy
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.
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
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.
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.
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
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.
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
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:
Contributionかそれのどんな部分も著述業の著作権か他の権利によって保護されるという範囲に、Contributorとそれぞれの命名された共同貢献者はContributionのそのようなすべての著作権と他の権利の下で永久の、そして、呼び戻せなくて、非排他的で、ロイヤリティのいらなくて、世界的な「副-許可でき」権利とライセンスをIETF Trustに与えます:
a. to copy, publish, display, and distribute the Contribution, in
whole or in part,
a. 全体か一部コピーするために、発行してください、そして、表示してください、そして、Contributionを分配してください。
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,
b. Contributionに関する翻訳を英語以外の言語に準備するために、全体か一部、コピーに発行してください、そして、表示してください、そして、そのような翻訳かそれの部分を広げてください。
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
そしてc. Contribution(Legend Instructionsによって指定されたフォームでの)に含まれた通知で明らかに禁じられない場合、Contributionについて基づいている派生している作品(翻訳に加えた)を変更するか、準備する、またはすべてか部分を組み込んで、コピーするために、発行してくださいといって、表示してくださいといって、そのような派生している作品、またはそれの部分を配布してください。
Bradner & Contreras Best Current Practice [Page 10] RFC 5378 RFC 3978-incoming November 2008
3978年について入って来るRFCブラドナーとコントレラス最も良い現在の習慣[10ページ]RFC5378 2008年11月
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.
d. 再生するために、どんな商標(TMと(R)を含んでいて、Contributionsを再生させるとき、商標とサービスがContributionで使用される識別子をマークすればこのセクション5.3によって受入れられるようにContributionに唯一Contributionと派生している作品の再現、分配、または公表に関してそれについて含まれているサービスマーク、または商号)も、保存されるでしょう。
5.4. Sublicenses by the IETF Trust
5.4. IETF信用による二次認可
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.
IETF TrustはIETF Standards Processの中の使用のためにすべてのIETF関係者へのセクション5.3の下でそれに与えられた権利を二次認可に望んでいます。 明白に http://trustee.ietf.org/license-info で見つけることができるIETF Trustによって発行された許諾契約でこのライセンスを与えます。
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.
このライセンスは、明白にIETF Trustによって発行された許諾契約で与えられて、完全なIETF Trust協定にポインタを含まなければなりません。
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].
さらに、IETF Trustは以下にそれに与えられたライセンスの追加二次認可を与えるかもしれません。 そうする際に、IETF TrustはRFC5377[RFC5377]の下で提供する指導に応じるでしょう。
5.5. No Patent License
5.5. 特許ライセンスがありません。
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.3で与えられたライセンスは、どんな特許直下におけるいずれ、特許出願、またはBCP79[RFC3979]の下でContributorによって明らかにされた他の同様の知的所有権も承諾すると考えられて、そうでなくならないでしょう。
5.6. Representations and Warranties
5.6. 表明保証条項
With respect to each Contribution, each Contributor represents that, to the best of his or her knowledge and ability:
各Contributionに関して、各Contributorはその人の最善な知識と能力にそれを表します:
a. The Contribution properly acknowledges all Contributors, including
Indirect Contributors.
a。 Contributionは適切にIndirect Contributorsを含むすべての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.
b。 Contributionでどんな情報も秘密ではありません、そして、IETF、IETF Trust、ISOC、およびその系統機関は自由に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.
c。 ここに交付金、承認、および協定をするContributorの性能へのContributorにおいて合理的に個人的に知られている限界が全くありません。
Bradner & Contreras Best Current Practice [Page 11] RFC 5378 RFC 3978-incoming November 2008
3978年について入って来るRFCブラドナーとコントレラス最も良い現在の習慣[11ページ]RFC5378 2008年11月
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.
d。 Contributorは故意にContributionに少しの中傷的であるか、虚偽であることの、または、Contributorがその人の主要な営業所か住居を持っている管轄の法の下で不法な材料も含んでいません。
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.
e。 Contributorにおいて合理的に個人的に知られているContributionで使用されるすべての商標、商号、サービスマーク、および他の商標名は妥当であるところで明確にそういうものとして指定されます。
5.7. No Duty to Publish
5.7. 発行しない義務全く
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.
Contributor、およびそれぞれの命名された共同貢献者は、そうでなければ、どんなContributionも発行するか、使用するか、または広めるためにIETFには義務が全くないと認めます。 IETFはこのセクション5の要件に従わないどんなContributionも使用することで引き下がるか、またはやむ権利を保有します。
5.8. Trademarks
5.8. 商標
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.)
それらのIETF Contributionsで使用される用語で商標権を要求する貢献者が、どんな状態がそのような商標の使用に比例して技術のimplementersに適用されるかを明確に述べるよう要求されています。 他の知的所有権クレームのために行われるのと同じようにそのような声明を提出するべきです。([RFC3979]セクション6を見てください。)
5.9. Copyright in RFCs
5.9. 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
各Contributor(または、スポンサーのもの)のセクション5.6(その所有権はセクション5.3の下で与えられた呼び戻せないライセンスによって資格があります)で説明されるようにContributionsの基礎となる所有権を条件として、各Contributorは、RFC Editor ContributionであるRFCを除いて、そのようなContributionが含まれているどんなRFCの著作権もIETF Trustによって所有されているだろうとこれにより認めます。 そのようなContributorが集合著作物構成へのそのようなContributorの著作権関心をIETF Trustに割り当てると考えられるものとします。
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.
公表のためのそのようなRFCの服従でのそのようなRFC、そのようなRFCでIETF Trustの著作権の所有権を承認するのがそうする版権情報が発行されたRFCに含まれていると認めます。
5.10. Contributors' Retention of Rights
5.10. 貢献者の権利の保有
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
ContributorsはIETFへの特定の権利を提供しますが、これがそれらからそれらのContributionsを利用するそれらの権利を奪うべきであることを意図しません。 この原則を強調するために、IETF Trustはそうです。
Bradner & Contreras Best Current Practice [Page 12] RFC 5378 RFC 3978-incoming November 2008
3978年について入って来るRFCブラドナーとコントレラス最も良い現在の習慣[12ページ]RFC5378 2008年11月
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.
それであるならRFCで彼らが願うどんな方法、どんなContributorにもRFCとしてどんなドキュメントも表す権利がないという制限だけへの対象、またはRFCの同等物でも発行されるように彼らがそれぞれ自分達のContributionsを利用するかもしれないと確認するContributorsにライセンスか保証を発行するよう指示されているのは、発行されたRFCに関する完全で完全なコピーか翻訳です。
6. Legends, Notices and Other Standardized Text in IETF Documents
6. IETFドキュメントのレジェンズ、通知、および他の標準化されたテキスト
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.
IETFは、ある標準化されたテキストが、あるIETF Documentsで逐語的に複製されるのを必要とします(IETF Documentsに関するコピー、派生している作品、および翻訳を含んでいて)。 この標準化されたテキストのいくつかが義務的であるかもしれません、そして、(すべてのRFCsに含まなければならない例えば、版権情報と注意書き)或るものは任意であるかもしれません(例えば、派生している作品を作る権利における制限)。 テキスト自体、およびいつ、どのようにそれを使用しなければならないかがわかる規則はLegend Instructionsに含まれています。 時々Legend Instructionsをアップデートするかもしれません、そして、IETF Documentsに含まなければならない標準化されたテキストのバージョンは公表の日付にLegend Instructionsに掲示されたそれです。
The IETF reserves the right to refuse to publish Contributions that do not include the legends and notices required by the Legend Instructions.
IETFは伝説を含んでいないContributionsを発行するのを拒否する権利を保有します、そして、通知が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.
このドキュメントとここに説明された方針に応じて各Contributorが権利をIETF Trustに与えることに注意するのは重要です。 確信するところにインターネット草稿などの書かれたContributionsが自分たちをするというわけではないのを含まれていた伝説と通知はどんな権利も伝えます。 それらは、ある法的権利とそのようなドキュメントに関連している制限に関して読者(IETFを離れさせてくださいか否かに関係なく)に知らせるために単に含まれています。
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.
また、そのようなドキュメントがIETFと別の規格開発組織の間の共同開発の努力の成果であるか別の規格開発組織の仕事の再刊であるケースにおける、追加版権情報がIETF Documentsで受入れられないことに注意するのも重要です。 個別的にIABはそのような例外を承認しなければなりません。
7. Security Considerations
7. セキュリティ問題
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.
このメモはどんな特定の技術ではなく、IETFの過程にも関連します。 どんな技術も採用するとき、セキュリティ問題がありますが、IETF Contribution権利方針があるセキュリティの問題は知られていません。
Bradner & Contreras Best Current Practice [Page 13] RFC 5378 RFC 3978-incoming November 2008
3978年について入って来るRFCブラドナーとコントレラス最も良い現在の習慣[13ページ]RFC5378 2008年11月
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October
1996.
[RFC2028] ハービとR.とS.ブラドナー、「IETF標準化過程にかかわる組織」、BCP11、RFC2028、1996年10月。
[RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC3979] ブラドナー、S.、エド、「IETF技術による知的所有権」、BCP79、RFC3979、3月2005日
[RFC4371] Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for
IPR Trust", BCP 101, RFC 4371, January 2006.
[RFC4371]が大工仕事をする、B.、エド、L.リンチ、エド、「IPRのためのアップデートが信じるBCP101」、BCP101、RFC4371、1月2006日
8.2. Informative References
8.2. 有益な参照
[RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78,
RFC 3978, March 2005.
[RFC3978] ブラドナー、S.、エド、「貢献におけるIETF権利」、BCP78、RFC3978、3月2005日
[RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the IETF
Trust", BCP 78, RFC 4748, October 2006.
[RFC4748] ブラドナー、S.、エド、「RFC3978は、IETF信用を認識するのをアップデートする」BCP78、RFC4748、10月2006日
[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
[RFC4844]Daigle、L.、エド、そして、インターネット・アーキテクチャ委員会、「RFCシリーズとRFCエディタ、」、RFC4844、7月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.
[RFC5377]アルペルン、J.(エド)、「IETF DocumentsのGrantedであるというIETF TrustのTrusteesへのRightsに関するアドバイス」、RFC5377(2008年11月)
[Berne] "Berne Convention for the Protection of Literary and
Artistic Work", http://www.wipo.int/treaties/en/ip/berne/
trtdocs_wo001.html.
[ベルン] 「文学的、そして、芸術的な仕事の保護のためのベルヌ条約」、 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
3978年について入って来るRFCブラドナーとコントレラス最も良い現在の習慣[14ページ]RFC5378 2008年11月
9. Acknowledgments
9. 承認
The editors would like to acknowledge the help the IETF IPR Working Group provided during the development of the document.
エディタはIETF IPR作業部会がドキュメントの開発の間に提供した助けを承諾したがっています。
10. Changes since RFC 3978
10. RFC3978以来の変化
This document represents a significant reorganization and rewording of RFC 3978, along with a number of substantive changes.
このドキュメントは重要な再編成と多くの実質的な変化に伴うRFC3978の言い換えを表します。
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.)
最も基本的な変化はこのドキュメントをContributionを作るときContributorがIETF Trustに与える権利に制限することになっています。 IETF TrustはIETF Documentsの使用への権利のすべての二次認可を提供しなければなりません。 (セクション5.4を見てください。)
Material added from RFC 4748 that recognized the IETF Trust.
材料は、RFC4748からそれが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.
RFC EditorがRFC Editorドキュメントのためにそれら自身の規則と過程を維持するので、RFC Editorドキュメントに関係する材料の大部分を取り除きました。 「非IETFドキュメント」へのこれらのドキュメントに改名されます。 この話題について議論しながら、IABからセクション11を加えました。
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.
定義部の変化は、用語「貢献」、「間接的な貢献者」、「著作権」、「IETF信用」、および「伝説の指示」を定義するのを含んでいます、他の定義のいくつかへの小さい方のひねりと同様に。
The responsibility for the text of notices has been given to the IETF Trust and removed from this document. (See Section 6.)
通知のテキストへの責任は、IETF Trustに与えられていて、このドキュメントから移されました。 (セクション6を見てください。)
Clarified that Contributors enter into a legally binding contract when they submit a Contribution. (See Section 5.1.)
彼らがContributionを提出するとき、はっきりさせられて、そのContributorsは法的に拘束力がある契約に入ります。 (セクション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.
ContributorによってIETF Trustに提供された派生している作品を製作する権利はIETF Standards Processの中にあるのに制限されません。
Made it clear that this document does not deal with patent licenses. (See Section 5.5.)
このドキュメントが特許ライセンスに対処しないと断言しました。 (セクション5.5を見てください。)
Clarified the ownership of the Copyrights to IETF Documents. (See Section 5.9.)
Copyrightsの所有権をIETF Documentsにはっきりさせました。 (セクション5.9を見てください。)
Clarified the rights retained by authors of IETF Contributions. (See Section 5.10.)
IETF Contributionsの作者によって保有された権利をはっきりさせました。 (セクション5.10を見てください。)
Bradner & Contreras Best Current Practice [Page 15] RFC 5378 RFC 3978-incoming November 2008
3978年について入って来るRFCブラドナーとコントレラス最も良い現在の習慣[15ページ]RFC5378 2008年11月
11. Declaration from the IAB
11. 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].
IABは最新の呼び出しの間、IPRドキュメントについて議論しました。 IABの流れが入って来るIPRドキュメントで覆われていることであることは満場一致して決めました。 私たちは、次に、IAB流れのドキュメントのIPRがIETF Trustが[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.
また、私たちは、RFC4844と、「RFCシリーズとRFCエディタ」[RFC4844]にみられるようにセクション4.2.3が欲しいと流れの依存する議論があるのがIETFとIABの流れ以外の流れへの本国行きの権利におけるどんな変化にも必要である圧力と承認審査方式と思います。
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.
その程度まで、ドキュメントのセクション4は、IRTF、無党派、およびどんな可能な今後の流れもドキュメントで含まれていないと明らかに言及するべきです。
For the IAB,
IABのために
Olaf Kolkman April 4, 2008
2008年4月4日のオラフKolkman
Editors' Addresses
エディタのアドレス
Scott Bradner Harvard University 29 Oxford St. Cambridge MA, 02138 USA
スコットブラドナーハーバード大学29オックスフォードケンブリッジの聖02138MA(米国)
Phone: +1 617 495 3864 EMail: sob@harvard.edu
以下に電話をしてください。 +1 3864年の617 495メール: sob@harvard.edu
Jorge L. Contreras WilmerHale 1875 Pennsylvania Avenue NW Washington, DC 20006 USA
NWワシントン、ホルヘL.コントレラスWilmerHale1875DC20006米国ペンシルベニア通り
Phone: +1 202 663 6872 EMail: jorge.contreras@wilmerhale.com
以下に電話をしてください。 +1 6872年の202 663メール: jorge.contreras@wilmerhale.com
Bradner & Contreras Best Current Practice [Page 16]
ブラドナーとコントレラスBest現在の習慣[16ページ]
一覧
スポンサーリンク
