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]