IPR J. Halpern, Ed.
Internet-Draft Self
Expires: July 26, 2007 January 22, 2007
Advice to the IAOC on Rights to be Granted in IETF Documents
draft-ietf-ipr-outbound-rights-02
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 July 26, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The IASA is resposible for managing intellectual property rights on
behalf of the IETF. This includes the license to copy, implement and
otherwise use IETF contributions, among them Internet-Drafts and
RFCs. The IASA accepts direction from the IETF regarding the rights
to be granted. This document describes the desires of the IETF
regarding outbound rights to be granted in IETF contributions.
Halpern Expires July 26, 2007 [Page 1]
Internet-Draft Outbound Rights Advice January 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
3. Purpose in Granting Rights . . . . . . . . . . . . . . . . . . 3
3.1. Specific Issues . . . . . . . . . . . . . . . . . . . . . . 4
4. Powers and Authority . . . . . . . . . . . . . . . . . . . . . 4
5. Recommended Grants of Right to Copy . . . . . . . . . . . . . . 5
5.1. Rights Granted for Reproduction of RFCs . . . . . . . . . . 5
5.2. Rights Granted for Quoting from IETF Contributions . . . . 5
5.3. Rights Granted for Implementing based on IETF
Contributions . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. Rights Granted for use of text from IETF Contributions . . 7
5.5. Additional Licenses for IETF Contributions . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Halpern Expires July 26, 2007 [Page 2]
Internet-Draft Outbound Rights Advice January 2007
1. Introduction
Under the current operational and administrative structures, IETF
intellectual property rights are vested in a trust administered by a
board of trustees made up of the members of the IASA. This includes
the right to make use of IETF contributions, as granted by
contributors under the rules laid out in [5]. The IASA is therefore
responsible for defining the rights to copy granted by the IETF to
people who wish to make use of the material in these documents.
The IASA has indicated, as is consistent with the IETF structure,
that it will respect the wishes of the IETF in regard to what these
rights ought to be. It is therefore the IETFs responsibility to
articulate those wishes. This document represents the wishes of the
IETF regarding the rights granted to all users in regard to IETF
contributions, until it is superceded.
2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
3. Purpose in Granting Rights
In providing a description of the wishes of the IETF with regard to
rights granted in RFCs, it is helpful to keep in mind the purpose of
granting such rights.
The IETF's mission is to write documents that help make the internet
work better (see [2] for more details.) These documents, when
completed, are published as RFCs.
An important subclass of RFCs is standards describing protocols; for
these, the primary value to the Internet is the ability of
implementors to build solutions (products, software, etc) which
interoperate uing these standards. Hence, the IETF has a strong
interest in seeing accurate, interoperable implementations of the
material we publish. We grant rights to copy to people to make use
of the text in the RFCs in order to encourage accurate and
interoperable implementations. As early implementations from
internet drafts make use of descriptions in those internet-drafts,
similar desires apply to internet-drafts.
Similar considerations also apply to non-standard, non-protocol
documents such as BCPs and informational documents; in this document,
Halpern Expires July 26, 2007 [Page 3]
Internet-Draft Outbound Rights Advice January 2007
we recommend a common approach to the issue of right-to-use licenses
for all IETF documents.
3.1. Specific Issues
There are a number of specific concerns that have been raised over
time, which this document acknowledges and addresses.
One issue that has been noted is that the legal wording for rights is
defined in RFCs. As such, if the wording needs modification, without
changing the intent of the IETF, there is still a need to revise the
RFC. this is at best cumbersome, and often much worse than that. It
introduces unnecessary delays in fixing legal matters. And often
opens the door to longer discussions that delay resolving the
immediate matter.
4. Powers and Authority
As stated in the introduction, the legal authority for determining
and granting rights to copy in RFCs rests with the trustees for the
IETF trust, which is made up of the members of the IAOC, as described
in [3] and [4]. This document provides guidance to that body, based
on the rough consensus of the IETF. The IASA, in conjunction with
legal counsel has the authority and responsibility to determine the
exact copyright text needed in Internet-Drafts, RFCs, and all IETF
Contributions to meet these needs.
The rough consensus described in this document reflects the agreement
of the IETF as of the IETF Last call, and the IASA is to begin acting
on these instructions upon IESG approval of this document for RFC
publication. Changes to the iETF documentation, and document
policies themselves take effect as determined by the IASA.
As stated earlier, this document describes the IETFs desires in terms
of granting rights to those who read or make use of material in IETF
contributions. This document does not specify what rights the IETF
Trust receives from others in IETF contributions. That is left to
another document. While care will be taken by both the working group
and the IASA to see that sufficient rights are granted to the IETF
trust in IETF contributions, it is also the case that the trust can
not grant rights it has not or does not receive, and it is expected
that policies will be in line with that fact. Similarly, the text
for pre-existing documents can not be changed. Nonetheless, to the
degree it can, and without embarking on a massive effort, it is
desirable if similar rights to those described below can be granted
in older RFCs.
Halpern Expires July 26, 2007 [Page 4]
Internet-Draft Outbound Rights Advice January 2007
5. Recommended Grants of Right to Copy
The IETF grants rights to copy and modify parts of IETF contributions
in order to meet the objectives described earlier. As such,
different circumstances and different parts of documents may need
different grants. This section contains subsections for each such
different grant that is currently envisioned. Each section is
intended to describe a particular problem / situation / usage, to
describe how that situation is recognizable, and to provide guidance
to the IASA as to what rights the IETF would like to see granted in
that circumstances, and what limitations should be put on such
granting. As stated above, the formulation of legal language for
granting these rights (including the determination of how many sets
of legal language are required is largely left to the IASA.
It is particularly noted that there has been a historical issue where
it is difficult to fix legal wording and boilerplate if the direction
defining that boilerplate is in an RFC, and then it turns out the
wording needs modification. As such, this document does not specify
such wording. Further, it is strongly recommended that all future
RFCs on this topic refrain from defining the precises wording of
boilerplate. Similarly, legal issues of how to indicate usage
restrictions are left to the IASA and legal consel to determine.
In structuring these desires, it is to be kept in mind that the autor
has not given up his copyright in granting rights to the IETF, and
the IETF is not attempting to transfer or relinquish the rights it
has. The purpose is to enable to IASA to grant people the right to
make copies of material in RFCs in ways that fit the goals of the
IETF. This discussion is also separate from the rights the IETF
itself requires in documents to do its job, as those are not
"outbound" rights. It is expected that the rights granted to the
IETF will be a superset of those copying rights we wish to grant to
others.
5.1. Rights Granted for Reproduction of RFCs
It has long been IETF policy to encourage copying of RFCs in full.
This permits wide dissemination of the material, without risking loss
of context or meaning. The IETF wishes to continue to permit anyone
to make full copies and translations of RFCs.
5.2. Rights Granted for Quoting from IETF Contributions
There is rough consensus that it is useful to permit the quoting
without modification of excerpts from IETF Contributions. Such
excerpts may be of any length and in any context. Translation of
quotations is also to be permitted. All such quotations SHOULD be
Halpern Expires July 26, 2007 [Page 5]
Internet-Draft Outbound Rights Advice January 2007
attributed properly to the IETF and the IETF document from which they
are taken.
5.3. Rights Granted for Implementing based on IETF Contributions
IETF contributions often include components intended to be directly
processed by a computer. These may be ABNF definitions, XML Schemas
or DTDs, MIBs, or even classical programming code. These are include
for clarity and precision in specification. It is clearly
beneficial, when such items are included in IETF contributions, to
permit the inclusion of such code fragments in products which
implement the contribution. It has been pointed out that in several
important contexts, use of such code requires the ability to modify
the code. One common example of this is simply the need to adapt
code for use in specific contexts (languages, compilers, tool
systems, etc.) Such use frequently requires some changes to the text
of the code from the IETF contribution. Another example is that code
included in open source products is frequently licensed to permit any
and all of the code to be modified. Since we want this code included
in such products, it follows that we need to permit such
modification. While there has been discussion of restricting the
rights to make such modifications in some way, the rough consensus is
that such restrictions are likely a bad idea, and are certainly very
complex to define.
As such, the rough consensus is that the IETF trust is to grant
rights such that code components of IETF contributions can be
extracted, modified, and used by anyone in any way desired. As the
IETF trust can not grant rights it does not receive, this right to
use code can not be granted in IETF contributions which are
explicitly marked as not permitting derivatives works.
While it is up to the IASA to determine the best way of meeting this
objective, two mechanisms are suggested here that are believed to be
helpful in documenting the intended grant to readers and users of
IETF contributions.
Firstly, the IASA should maintain, in a suitable, easily accessible
fashion, a list of common RFC components which will be considered to
be code. To start, this list should include at least the items
listed above, ABNF definitions, XML Schemas, XML DTDs, and MIBs. The
IASA would add to this list as it deems suitable or as it is directed
by the IETF.
Additionally, the IASA should define a textualy representation to be
included in an IETF contibution to indicate that a portion of the
document is considered by the authors (and later the working group,
and upon approval the IETF) to be code, and to be subject to the
Halpern Expires July 26, 2007 [Page 6]
Internet-Draft Outbound Rights Advice January 2007
permissions granted to use code.
5.4. Rights Granted for use of text from IETF Contributions
There is no consensus at this time to permit the use of text from
RFCs in contexts where the right to modify the text is required. The
authors of IETF contributions may be able and willing to grant such
rights independently of the rights they have granted to the IETF by
making the contribution.
As such, in crafting legal language and boiler plate, the IASA is
also asked to resolve and indicate how code segments of IETF
documents, which can be extracted and subsequently modified, are to
be indicated by authors and editors as distinct from text segments,
which can be extract but not modified.
5.5. Additional Licenses for IETF Contributions
There have been contexts where the material in an IETF contribution
is also available under other license terms. The IETF wishes to be
able to include content which is available under such licenses. It
is desirable to indicate in the IETF contribution that other licenses
are available. It would be inappropriate and confusing if such
additional licenses restricted the rights the IETF intends to grant
in the content of RFCS.
However, the IETF does not wish to have IETF Contributions contain
additional copyright notices and licenses, as that introduces a
number of additional difficulties. Providing the correct legal
approach to such indications is left to the IASA, as all legal
language is. Specifically, additional text in the document, and any
additional license referred to by permitted additional text MUST NOT
in any way restrict the rights the IETF intends to grant to others
for using the contents of IETF contributions.
Authors of contributions retain all rights in their contributions.
As such, an author may directly grant any rights they wish separately
from what the IETF grants. However, a reader wishing to determine or
make use of such grants will need to contact the author directly.
6. IANA Considerations
No values are assigned in this document, no registries are created,
and there is no action assigned to the IANA by this document. One
list (of kinds of code sections) is anticipated, to be created and
maintained by the IASA. It is up to the IASA whether they create
such a list and whether they choose to involve the IANA in
Halpern Expires July 26, 2007 [Page 7]
Internet-Draft Outbound Rights Advice January 2007
maintaining that list.
7. Security Considerations
This document introduces no new security considerations. It is a
process document about the IETFs IPR rights being granted to other
people. While there may be attacks against the integrity or
effectiveness of the IETF processes, this document does not address
such issues.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[2] Alvestrand, H., "A Mission Statement for the IETF", BCP 95,
RFC 3935, October 2004.
[3] Austein, R. and B. Wijnen, "Structure of the IETF Administrative
Support Activity (IASA)", BCP 101, RFC 4071, April 2005.
[4] Carpenter, B. and L. Lynch, "BCP 101 Update for IPR Trust",
BCP 101, RFC 4371, January 2006.
[5] Bradner, S., "I-D.ietf-ipr-rules-update-07.txt", 2006.
Author's Address
Joel M. Halpern (editor)
Self
P. O. Box 6049
Leesburg, VA 20178
US
Email: jmh@joelhalpern.com
Halpern Expires July 26, 2007 [Page 8]
Internet-Draft Outbound Rights Advice January 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Halpern Expires July 26, 2007 [Page 9]
