Network Working Group J. Klensin
Internet-Draft December 15, 2008
Updates: 5378, 3978, 4748
(if approved)
Intended status: BCP
Expires: June 18, 2009
A Workable Variation on Rights Contributors Provide to the IETF Trust
draft-klensin-rfc5378var-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 June 18, 2009.
Copyright Notice
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.
Klensin Expires June 18, 2009 [Page 1]
Internet-Draft RFC 5378 Variation December 2008
Abstract
RFC 5378, "Rights Contributors Provide to the IETF Trust", has been
interpreted in a way that is unworkable in practice for updates to
documents created before it came into effect, and for other documents
that derive significant amounts of text from such earlier documents.
It requires, as a condition of Internet Draft posting or RFC
publication or even as a condition of posting of Internet Drafts,
that authors or editors obtain rights from people who may be
unavailable or uncooperative. This specification modifies the RFC
5378 rules to permit the IETF to continue to do work in an orderly
fashion when documents containing earlier text are involved and
permission is not easily obtained.
Table of Contents
1. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Older Documents and Older Text . . . . . . . . . . . . . . . . 4
4. Update to RFC 5378 -- Variant Procedure . . . . . . . . . . . 6
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Directions . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. A Better Plan . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
A.1. Changes for -01 . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Klensin Expires June 18, 2009 [Page 2]
Internet-Draft RFC 5378 Variation December 2008
1. Author's Note
[[Comment.1: This section will be removed if a -02 of this document
is posted.]]
This document is provided in the interest of being constructive and
specifically of creating a meaningful focus for a serious and, I
hope, rapid and efficient, discussion in the IETF about the
implications of RFC 5378 to IETF work on documents containing older
text, specifically text for which 5378 releases to the IETF Trust are
neither already on file nor very readily available. The proposal it
makes --to create a variant procedure for older documents that
essentially restores the previous rules for them -- is not the
author's preferred long-term choice but, since it appears that the
only way to get things unstuck is with a BCP, this document is
offered as the foundation for a transitional BCP. An additional
note, in Section 7 below, proposes a better choice and mechanisms for
getting there.
Some of the discussion on the IETF list about RFC 5378 indicates that
the Trustees of the IETF Trust simply implemented the instructions of
the IETF. Some of the discussions in the IPR WG assumed that the
draft that became RFC 5378 would simply be, and was, an
implementation in legal language of principles laid out in the WG.
At least some participants in the WG did not believe that those
principles would include the restrictions and requirements on
revisions of older documents that 5378 now appears to imply. In the
hope of avoiding further iterations of those misunderstandings, this
draft is much more explicit than is usual in the IETF about
responsibility and authority for making various types of decisions.
Those provisions can, of course, be changed if the community decides
it wants something else, but the author hopes that such changes will
not [re-]introduce ambiguity and that no one will take any of the
current specifications and directions as anything other than a
constructive attempt to avoid such ambiguity.
2. Introduction
In November 2008, the IETF published "Rights Contributors Provide to
the IETF Trust" [1]. That document changed the IETF's IPR model from
one in which authors granted full rights to modify and derive
material for IETF purposes to the IETF to one in which authors were
expected to grant the IETF Trust a broad range of rights to license
use of the documents for other purposes. While not problematic for
newly-written documents, that change in model poses significant
challenges for revisions of older specifications and for new
specifications that reuse text from older ones (See Section 3). The
Klensin Expires June 18, 2009 [Page 3]
Internet-Draft RFC 5378 Variation December 2008
difficulty arises because 5378 requires that document submitters make
strong assertions that they can actually transfer those broader
rights. Those assertions require that authors/ Contributors obtain
permission from those who hold those rights, whether legal
(copyright) or moral. That permission may not be able to be easily
obtained, especially from authors who have ceased participation in
the IETF due to death or other reasons. The requirement for that
assertion and transfer as a condition for posting would, in turn,
prevent posting Internet Drafts (I-Ds) and working in the IETF on
documents containing older text even though rules in effect since the
beginning of the contemporary IETF standards process [2] would have
permitted that work to be done in the IETF.
In order to permit the IETF to continue to do work, rather than
having posting blocked when permissions from authors of earlier text
cannot be readily obtained, this document modifies RFC 5378 to permit
the older license grants and intellectual property rights to continue
to be applied to older text in new documents and postings.
References to RFC 3978 [3] in this document explicitly assume that
the changes specified in RFC 4748 [4] are incorporated; all
references to RFC 3978 are to be treated as references to both
documents.
3. Older Documents and Older Text
One complication about interpretation of RFC 5378 is that there
appears to be controversy about what text is old enough to require
obtaining authorization from earlier contributors for posting, rather
than being able to assume the necessary permissions from earlier
Contributions to the IETF. The relevant transition dates have been
assumed, by different parties, to be:
o The date on which the Internet Draft that became RFC 5378 was
approved by the IESG.
o The date on which RFC 5378 was published.
o The date on which the IETF Trust approved policies and text
relevant to RFC 5378 and announced them to the community.
Presumably this is the 10 November 2008 date shown on the
Trustee's "Policies and Procedures" web page [6].
o The date on which the IETF Trust "announces the adoption of these
procedures" (referring to the procedures in RFC 5378 and quoting
from Section 2.1 of that document). This may or may not also be
the 10 November 2008 date.
Klensin Expires June 18, 2009 [Page 4]
Internet-Draft RFC 5378 Variation December 2008
o The date on which the new policies were widely enough publicized
to the community as applying to to all IETF Contributions that it
is reasonable to assume that all of those who might make
Contributions to the IETF were aware of them. Some who are
convinced that this is the relevant date believe that it
intrinsically coincides with one of the dates above, presumably
the 10 November 2008 one. Others note that the IETF has a history
of widely-disseminated announcements to obtain agreement to IPR
policies (the "Note Well"), and that very recent versions of those
announcements still point to earlier policies (See, e.g., the IETF
73 version of that announcement [7] or, as of 14 December 2008,
the IETF's announcement to mailing list subscribers [8]). They
believe that continuing use of the old "Note Well" for more than a
month after the 10 November 2008 date makes that date untenable as
the basis for assuming that subsequent IETF participation
constitutes agreement to RFF 5378's terms and consequent transfer
of rights.
In any event, to the extent to which the critical date is
determined by the Note Well or similar widespread announcements,
it appears fairly clear that intent to update those announcements
doesn't count; only the wide availability of the revised forms do.
o For a given document, the date on which a reference to RFC 5378
was incorporated into its text by the person responsible for
posting it or otherwise contributing it to the IETF.
The author has no reason to believe that list of possible cutoff
dates is comprehensive or that there are no other theories which
would establish different dates. While RFC 5378 might reasonably
have contained language to establish that boundary, it does not
appear to do so. Should the differences among the various dates
become significant, it appears likely that the issue would need to be
settled through some judicial process external to the IETF. In this
document, the author, not being a lawyer, takes no position on which
interpretation is correct but merely notes the ambiguity as an
additional complication in interpreting RFC 5378 with regard to older
documents and Contributions.
The term "new text" is used in this document to refer to text that
unambiguously falls under the RFC 5378 rules, i.e., text that was
first written after RFC 5378 became effective and that, when posted
or published, contains the RFC 5378-derived language in the
associated copyright notice.
Klensin Expires June 18, 2009 [Page 5]
Internet-Draft RFC 5378 Variation December 2008
4. Update to RFC 5378 -- Variant Procedure
This specification modifies the provisions of RFC 5378 with respect
to documents containing text that, in the informed opinion and best
judgment of the Contributor, meets all of the following criteria:
o The text is a significant excerpt or copy of older text or text
from an older document under any of the definitions above that the
Contributor believes to be applicable.
o The text was made available to the IETF under circumstances that
would make the provisions of RFC 3978 [3] or relevant and
consistent predecessor documents and "Note Well" statements
applicable.
o The text is being used strictly for IETF purposes consistent with
provisions of RFC 3978 or relevant and consistent predecessor
documents.
o A transfer of rights for the text to the IETF Trust that would
give the IETF Trust all of the rights called for by RFC 5377 has
not been made by the author (or other rights-holder) of the
relevant text.
o Such a transfer cannot be readily obtained within a period of time
that is satisfactory for consideration or progression of the
Contribution within the IETF.
If those criteria are met, the Contributor may incorporate the
"boilerplate" text called for by RFC 3978 in the new document rather
than the copyright notice and associated "boilerplate" text specified
by the IETF Trust and IAB pursuant to RFC 5378. If the RFC 3978 text
is incorporated, the IETF Trust will acquire only those rights
historically granted and summarized in RFC 2026 [2] and the specific
provisions of RFC 3978. Those rights can be informally summarized as
unlimited permission for the copying, extracts, or reuse within the
IETF for purposes connected to its Standards Process and permission
to the broader community to reproduce and distribute that document.
Because this document creates a new dependency on RFC 3978 (and
4748), the action taken by RFC 5378 to identify them as obsolete is
formally nullified. In order to make the threads as clear as
possible, those documents should be shown in the various indexes as
updated, but not obsoleted, by both 5378 and this document.
Klensin Expires June 18, 2009 [Page 6]
Internet-Draft RFC 5378 Variation December 2008
5. Applicability
The net effect of this suggested change is to make RFC 5378 apply
only to:
o Documents newly-written after its applicability date and
containing no older text.
o Documents containing older text for which text the IETF Trust has
obtained RFC 5378-compatible rights through spontaneous action of
original Contributors, efforts of contemporary authors or
Contributors, or its own activities.
All other Contribution and documents remain covered only by the
provisions of RFC 3978 or, if published earlier, by the policies
relevant at the time of publication. To the degree it is relevant,
the reader's attention is called to Section 2.1 of RFC 5378.
It is perhaps worth noting that, if Contributors are able to obtain
rights from prior Contributors as RFC 5378 anticipates, this
specification has no net effect on RFC 5378 and its provisions.
Conversely, the IETF Trust's ability to manage newly-posted documents
for which rights cannot be easily obtained is no different from the
situation that exists with documents published prior to RFFC 5378.
Section 4 above puts the decisions as to significance of copied or
excerpted text, the ability to obtain transfers of rights that are
not already on file, and the urgency with which those transfers must
be obtained, strictly in the hands of the Contributor who is
compiling a document. That is necessary because of the burdens of
responsibility and risk that RFC 5378 places on the Contributor who
incorporates older material. Neither the IETF Trust nor the IESG are
empowered to place additional restrictions or burdens on the
Contributor in respect to that decision-making. For example, this
specification prohibits an IESG or Trustee-imposed requirement that
the Contributor document efforts to contact prior Contributors and
obtain releases from them.
This document does not update or alter the advice given to the
Trustees on Rights to be Granted [5]. It is worth repeating from
other documents the observation that the Trustees cannot grant any
rights that they do not have, so they will not be able to grant any
rights to documents published in accordance with this specification
and RFC 3978 provisions that they could not grant to pre-RFC 5378
documents for which they have not obtained the additional RFC 5378
rights.
Klensin Expires June 18, 2009 [Page 7]
Internet-Draft RFC 5378 Variation December 2008
6. Directions
To the extent permitted under RFC 2026 and subsequent procedures
approved by IETF consensus, the IETF directs that:
1. The Trustees of the IETF Trust prepare appropriate guidelines,
boilerplate, legal language, etc., to implement the provisions of
this specification and present them to the community for review
and approval. This is to be done on an expedited basis with the
reasons for any delays reported to the community on an ongoing
basis. The intent is to make the window in which RFC 5378 is
considered to be in effect without the variant procedure
specified by this document as short as possible.
2. The Trustees, with the advice of Counsel as needed, devise and
implement mechanisms to prevent the provisions of RFC 5378 from
impeding IETF work while the procedural and legal details called
for by this document are sorted out. If, in the judgment of the
IESG or Counsel, the only way to accomplish that end is for this
document to obsolete RFC 5378 in its entirety, restoring the RFC
3978/RFC 4748 status quo ante, then approval of this document is
to be considered as indicating IETF consensus for taking that
action.
3. To avoid the appearance of conflicts of interest or
responsibilities, any Trustee of the IETF Trust who is also a
member of a review or approving body for this document shall
recuse himself or herself from all voting, and isolate him or
herself from all considerations or discussion, of this document
in that review or approving body.
[[Comment.2: Note in initial draft only: This text is motivated
by the recognition that there is an inherent conflict between the
implicit requirement on the IETF Trust and its Trustees to
provide the IETF with as clear and unambiguous an intellectual
property environment as possible and the implicit requirement on
IAB and IESG members to make the work of the IETF as efficient as
possible. It is unreasonable for the community to expect anyone
to provide both roles in a situation that has become highly
controversial. While this text could have been written in either
direction (i.e., excluding Trust participation rather than
approving body participation) the author believes that it is more
important to have IETF leadership represent the IETF's position
and needs to the Trust than vice versa.]]
Klensin Expires June 18, 2009 [Page 8]
Internet-Draft RFC 5378 Variation December 2008
7. A Better Plan
The solution proposed here is probably less satisfactory than one
that would apply the old rules exclusively to the old text, bringing
new text, text created by the author of the new document, or text for
which the IETF Trust has specific releases on file under the RFC 5378
rules or their successors under the new rules. Some of the
definitions and other elements of RFC 5378 might be helpful even in
combination with the general theory of rights grants and transfers
that prevailed historically and with the procedures documented in RFC
3978. However, the drafting of such hybrid rules and definitions is
clearly a matter for expert legal counsel, not amateurs, and
experience indicates that it would take some time to obtain that text
and properly review the details and implications. Consequently, the
Trustees of the IETF Trust are strongly encouraged to view this
specification as a temporary patch and to follow its adoption by
preparing a replacement for it and RFC 5378. That replacement should
provide for a hybrid strategy and should be presented to the IETF
community for review and approval.
8. Acknowledgments
Thanks are due to Sam Hartman for finally bringing part of this issue
to the attention of the IETF in a way that was generally understood
and that opened up consideration of the broader issues involved and
to several people who commented on, or offered encouragement about,
an early version of this draft (their names will be included in later
drafts if they prefer). Alfred Hoenes found several typographical
errors in the initial draft that made the document harder to follow
than necessary; his corrections are gratefully acknowledged.
9. IANA Considerations
[[Comment.3: RFC Editor: Please remove this section before
publication.]]
This memo includes no requests to or actions for IANA.
10. Security Considerations
The security considerations associated with RFC 5378 also apply to
this document and are incorporated by reference.
11. References
Klensin Expires June 18, 2009 [Page 9]
Internet-Draft RFC 5378 Variation December 2008
11.1. Normative References
[1] Bradner, S. and J. Contreras, "Rights Contributors Provide to
the IETF Trust", BCP 78, RFC 5378, November 2008.
[2] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[3] Bradner, S., "IETF Rights in Contributions", RFC 3978,
March 2005.
[4] Bradner, S., "RFC 3978 Update to Recognize the IETF Trust",
RFC 4748, October 2006.
11.2. Informative References
[5] Halpern, J., "Advice to the Trustees of the IETF Trust on Rights
to Be Granted in IETF Documents", RFC 5377, November 2008.
URIs
[6]
[7]
[8]
Appendix A. Change Log
A.1. Changes for -01
o Added an explicit statement that this un-obsoletes 3978 and 4748,
where were obsoleted by 5378.
o Corrected several typographic errors that escaped my proofreading
but that were caught and reported by Alfred Hoenes.
Klensin Expires June 18, 2009 [Page 10]
Internet-Draft RFC 5378 Variation December 2008
Author's Address
John C Klensin
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
USA
Phone: +1 617 245 1457
Email: john+ietf@jck.com
Klensin Expires June 18, 2009 [Page 11]