does not intend for the IETF Contribution to be published as an RFC.
These notices may not be used with any standards-track document or
with most working group documents, except as discussed in Section 7.3
below, since the IETF must retain change control over its documents
and the ability to augment, clarify and enhance the original IETF
Contribution in accordance with the IETF Standards Process.
Notice 5.2(a) may be appropriate when republishing standards produced
by other (non-IETF) standards organizations, industry consortia or
companies. These are typically published as Informational RFCs, and
do not require that change control be ceded to the IETF. Basically,
documents of this type convey information for the Internet community.
A fuller discussion of the rationale behind these requirements is
contained in Section 7.3 below.
5.3. Publication Limitation
If the Contributor only wants the IETF Contribution to be made
available in an Internet-Draft (i.e., does not want the IETF
Contribution to be published as an RFC) then the Contributor may
include the following notice in the Status of Memo section of the
Internet-Draft.
"This document may only be posted in an Internet-Draft."
This notice can be used on IETF Contributions that are intended to
provide background information to educate and to facilitate
discussions within IETF working groups but are not intended to be
published as an RFCs.
5.4. Copyright Notice (required for all IETF Documents)
(Normally placed at the end of the IETF Document.)
"Copyright (C) The Internet Society (year). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights."
Additional copyright notices are not permitted in IETF Documents
except in the case where such document is the product of a joint
development effort between the IETF and another standards development
organization or the document is a republication of the work of
another standards organization. Such exceptions must be approved on
an individual basis by the IAB.
5.5. Disclaimer (required in all IETF Documents)
(Normally placed at the end of the IETF Document after the copyright
notice.)
"This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
5.6 Exceptions
Notwithstanding the provisions of this Section 5, in certain limited
cases an abbreviated notice may be placed on certain types of
derivative works of IETF Documents in accordance with this Section
5.6.
a. in MIB modules, PIB modules and similar material commonly
extracted from IETF Documents, except for material that is being
placed under IANA maintenance, the following abbreviated notice
shall be included in the body of the material that will be
extracted in lieu of the notices otherwise required by Section 5:
"Copyright (C) The Internet Society <year> . This version of
this MIB module is part of RFC XXXX; see the RFC itself for
full legal notices."
When the MIB or PIB module is the initial version of a module that
is to be maintained by the IANA, the following abbreviated notice
shall be included:
"Copyright (C) The Internet Society <year>. The initial
version of this MIB module was published in RFC XXXX; for full
legal notices see the RFC itself. Supplementary information
may be available on
http://www.ietf.org/copyrights/ianamib.html."
For other types of components than "MIB", substitute "MIB module"
with an appropriate identifier. In the case of MIB and PIB
modules this statement should be placed in the DESCRIPTION clause
of the MODULE-IDENTITY macro.
Variations of these abbreviated notices are not permitted except
in cases where the material to be extracted is the product of a
joint development effort between the IETF and another standards
development organization or is a republication of the work of
another standards organization. Such variations must be approved
on an individual basis by the IAB.
b. short excerpts of IETF Documents presented in electronic help
systems, for example, the DESCRIPTION clauses for MIB variables,
do not need to include a copyright notice.
6. Notices and Rights Required in RFC Editor Contributions
Since the IETF acts as publisher of Internet Drafts, even for
Internet Drafts that are not intended to become part of the Standards
Process, the following are required in all such drafts to protect the
IETF and its processes. The RFC Editor may require additional
notices.
a. An IPR Disclosure Acknowledgement, identical to that specified in
Section 5.1.
b. One of the following two copyright release statements:
A. "By submitting this Internet-Draft, I accept the provisions of
Section 3 of RFC 3667."
B. "By submitting this Internet-Draft, I accept the provisions of
Section 4 of RFC 3667."
7. Exposition of Why These Procedures Are the Way They Are
7.1. Rights Granted in IETF Contributions
The IETF/ISOC must obtain the right to publish an IETF Contribution
as an RFC or an Internet-Draft from the Contributors.
A primary objective of this policy is to obtain from the document
authors only the non-exclusive rights that are needed to develop and
publish IETF Documents and to use the IETF Contributions in the IETF
Standards Process while leaving all other rights with the authors.
The non-exclusive rights that the IETF needs are:
a. the right to publish the document
b. the right to let the document be freely reproduced in the formats
that the IETF publishes it in
c. the right to let third parties translate it into languages other
than English
d. except where explicitly excluded (see Section 5.2), the right to
make derivative works within the IETF process.
e. the right to let third parties extract some logical parts, for
example MIB modules
The authors retain all other rights, but cannot withdraw the above
rights from the IETF/ISOC.
7.2. Rights to use Contributed Material
Because, under the laws of most countries and applicable
international treaties, copyright rights come into existence whenever
a work of authorship is created (but see Section 8 below regarding
public domain documents), and IETF cannot make use of IETF
Contributions if it does not have sufficient rights with respect to
these copyright rights, it is important that the IETF receive
assurances from all Contributors that they have the authority to
grant the IETF the rights that they claim to grant. Without this
assurance, IETF and its participants would run a greater risk of
liability to the owners of these rights.
To this end, IETF asks Contributors to give the assurances in Section
3.4 above. These assurances are requested, however, only to the
extent of the Contributor’s reasonable and personal knowledge. (See
Section 1(l))
7.3. Right to Produce Derivative Works
The IETF needs to be able to evolve IETF Documents in response to
experience gained in the deployment of the technologies described in
such IETF Documents, to incorporate developments in research and to
react to changing conditions on the Internet and other IP networks.
In order to do this the IETF must be able to produce derivatives of
its documents; thus the IETF must obtain the right from Contributors
to produce derivative works. Note though that the IETF only requires
this right for the production of derivative works within the IETF
Standards Process. The IETF does not need, nor does it obtain, the
right to let derivative works be created outside of the IETF
Standards Process other than as noted in Section 3.3 (E).
The right to produce derivative works is required for all IETF
standards track documents and for most IETF non-standards track
documents. There are two exceptions to this requirement: documents
describing proprietary technologies and documents that are
republications of the work of other standards organizations.
The right to produce derivative works must be granted in order for an
IETF working group to accept an IETF Contribution as a working group
document or otherwise work on it. For non-working group IETF
Contributions where the Contributor requests publication as a
standards track RFC the right to produce derivative works must be
granted before the IESG will issue an IETF Last-Call and, for most
non-standards track non-working group IETF Contributions, before the
IESG will consider the Internet-Draft for publication.
Occasionally a Contributor may not want to grant publication rights
or the right to produce derivative works before finding out if an
IETF Contribution has been accepted for development in the IETF
Standards Process. In these cases the Contributor may include the
Derivative Works Limitation described in Section 5.2 and the
Publication Limitation described in Section 5.3 in their IETF
Contribution. A working group can discuss the Internet-Draft with
the aim to decide if it should become a working group document, even
though the right to produce derivative works or to publish the IETF
Contribution as an RFC has not yet been granted. If the IETF
Contribution is accepted for development the Contributor must then
resubmit the IETF Contribution without the limitation notices before
a working group can formally adopt the IETF Contribution as a working
group document.
The IETF has historically encouraged organizations to publish details
of their technologies, even when the technologies are proprietary,
because understanding how existing technology is being used helps
when developing new technology. But organizations that publish
information about proprietary technologies are frequently not willing
to have the IETF produce revisions of the technologies and then claim
that the IETF version is the "new version" of the organization’s
technology. Organizations that feel this way can specify that an IETF
Contribution can be published with the other rights granted under
this document but may withhold the right to produce derivative works
other than translations. The right to produce translations is
required before any IETF Contribution can be published as an RFC to
ensure the widest possible distribution of the material in RFCs.
In addition, IETF Documents frequently make normative references to
standards or recommendations developed by other standards
organizations. Since the publications of some standards organizations
are not public documents, it can be quite helpful to the IETF to
republish, with the permission of the other standards organization,
some of these documents as RFCs so that the IETF community can have
open access to them to better understand what they are referring to.
In these cases the RFCs can be published without the right for the
IETF to produce derivative works.
In both of the above cases in which the production of derivative
works is excluded, the Contributor must include a special legend in
the IETF Contribution, as specified in Section 5.2, in order to
notify IETF participants about this restriction.
7.4. Rights to Use Trademarks
Contributors may wish to seek trademark or service mark protection on
any terms that are coined or used in their IETF Contributions. IETF
makes no judgment about the validity of any such trademark rights.
However, the IETF requires each Contributor, under the licenses
described in Section 3.3 above, to grant IETF a perpetual license to
use any such trademarks or service marks solely in exercising its
rights to reproduce, publish and modify the IETF Contribution. This
license does not authorize any IETF participant to use any trademark
or service mark in connection with any product or service offering,
but only in the context of IETF Documents and discussions.
7.5. Who Does This Apply To?
Rights and licenses granted to the IETF under this document are
granted to all individuals noted in Section 1(a), irrespective of
their employment or institutional affiliation. However, these
licenses do not extend broadly to the employers, sponsors or
institutions of such individuals, nor do they authorize the
individuals to exercise any rights outside the specific context of
the IETF Standards Process.
8. Contributions Not Subject to Copyright
Certain documents, including those produced by the U.S. government
and those which are in the public domain, may not be protected by the
same copyright and other legal rights as other documents.
Nevertheless, we ask each Contributor to grant to the IETF the same
rights as he or she would grant, and to make the same
representations, as though the IETF Contribution were protected by
the same legal rights as other documents, and as though the
Contributor could be able to grant these rights. We ask for these
grants and representations only to the extent that the Contribution
may be protected. We believe they are necessary to protect the ISOC,
the IETF, the IETF Standards Process and all IETF participants, and
also because the IETF does not have the resources or wherewithal to
make any independent investigation as to the actual proprietary
status of any document submitted to it.
9. Security Considerations
This memo relates to IETF process, not any particular technology.
There are security considerations when adopting any technology, but
there are no known issues of security with IETF Contribution rights
policies.
10. References
10.1. Normative References
[RFC 2026] Bradner, S., Ed, "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
10.2. Informative References
[Berne] "Berne Convention for the Protection of Literary and
Artistic Work",
http://www.wipo.int/treaties/ip/berne/index.html
11. Acknowledgements
The editor would like to acknowledge the help of the IETF IPR Working
Group and, in particular the help of Jorge Contreras of Hale and Dorr
for his careful legal reviews of this and other IETF IPR-related and
process documents. The editor would also like to acknowledge the
extensive help John Klensin provided during the development of the
document.
12. Editor’s Address
Scott Bradner
Harvard University
29 Oxford St.
Cambridge MA, 02138
Phone: +1 617 495 3864
EMail: sob@harvard.edu
13. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.