Network Working Group                                       B. Carpenter
Internet-Draft                                         Univ. of Auckland
Updates: 5378 (if approved)                                H. Alvestrand
Intended status: BCP                                              Google
Expires: November 12, 2009                                  May 11, 2009


            Including text under former copyright conditions
                    draft-carpenter-5378-old-text-02

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 November 12, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.








Carpenter & Alvestrand  Expires November 12, 2009               [Page 1]

Internet-Draft             Including old text                   May 2009


Abstract

   This document specifies a procedure for including text in an IETF
   document for which the current copyright conditions defined in RFC
   5378 cannot readily be met.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Mandatory Procedure . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Voluntary Procedures  . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Non-normative initial version of disclaimer  . . . . . 5
   Appendix B.  Non-normative explanation of background  . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9






























Carpenter & Alvestrand  Expires November 12, 2009               [Page 2]

Internet-Draft             Including old text                   May 2009


1.  Introduction

   [[ Note to be removed by the RFC Editor: This version of the draft
   describes a completely modified procedure compared to the one
   presented at IETF74, which did not obtain consensus.  It contains
   small and large changes throughout.  Discussion is invited on the
   ipr-wg@ietf.org list. ]]

   Terminology: In this document, the phrases "prior to RFC 5378" and
   "pre-5378" refer to IETF Contributions made before November 10, 2008,
   when RFC 5378 became effective.  The phrase "Original Contributor"
   refers to an Indirect Contributor in the sense of [RFC5378], whose
   Contribution was prior to RFC 5378.  Other terminology is defined in
   RFC 5378.

   RFC 5378 failed to describe one case that has practical consequences.

   The case is this: a new IETF Contribution contains material derived
   from one or more pre-5378 Contributions, but the Original
   Contributors have not agreed to the specific additional rights
   granted to the IETF under RFC 5378 compared to previous IETF rules.
   In this case, the Contributor cannot accurately make the warranties
   required by RFC 5378 with respect to the pre-5378 material included
   in his or her Contribution.

   This can arise when the Original Contributors, or their assigns, are
   unwilling, unresponsive, unfindable, deceased, no longer in business,
   or simply too numerous.

   This document is intended to specify the simplest possible solution
   for such cases.  Additional background information is given in
   Appendix B below.


2.  Mandatory Procedure

   It should be noted that Section 5.6 of [RFC5378] already requires
   that Indirect Contributors must be acknowledged in all IETF
   documents.  This continues a requirement previously specified in
   section 3.4 (a) of [RFC3978] and [RFC3667], and in section 10.3.1 (4)
   of [RFC2026].  The present document extends this requirement in
   certain cases.

   Contributors of Internet-Drafts that contain text originally
   contributed to the IETF by other persons prior to RFC 5378 have
   certain responsibilities, to be exercised to the best of their
   knowledge and ability.




Carpenter & Alvestrand  Expires November 12, 2009               [Page 3]

Internet-Draft             Including old text                   May 2009


   Unless the Contributor(s) know that the Original Contributors have
   agreed to their text being contributed under the terms of RFC 5378,
   the Internet-Draft and any resulting RFC must include an appropriate
   legend of disclaimer.  The current text of this legend will be
   specified by the IETF Trust's "Legend Instructions" as defined in
   [RFC5378].  The initial version of this text is given for
   informational purposes in Appendix A below.

   If and only if this legend is included:
   o  The acknowledgement required by Section 5.6 of [RFC5378] should
      identify the source(s) of pre-5378 text, such as RFCs and
      Internet-Drafts.  This requirement does not extend to small
      fragments of text culled from IETF discussions.
   o  The acknowledgement should also identify which Original
      Contributors contributed which sections of pre-5378 text.  This
      requirement does not apply if the text concerned is scattered
      throughout the document.

   The IETF Trust is directed to ensure that its policies and licenses
   allow for documents including the disclaimer.


3.  Voluntary Procedures

   [[ Discussion invited: is it appropriate and useful to include these
   voluntary procedures?  The BOF at IETF74 seemed to accept a "MAY"
   approach, but there was no clear consensus call on that point. ]]

   All Contributors to the IETF prior to RFC 5378 are invited to provide
   retroactively to the IETF Trust the rights in their Contributions
   required by RFC 5378.

   The IETF Trust may provide a public register of pre-5378 documents
   for which the rights required by RFC 5378 have been provided
   retroactively, and a public register of rights holders who have
   retroactively provided such rights for all their pre-5378
   Contributions.

   Contributors of Internet-Drafts including pre-5378 material who wish
   to avoid also including the disclaimer may take any steps they wish,
   or ask helpers to take such steps, to contact the Original
   Contributors and obtain their agreement to their text being
   contributed under the terms of RFC 5378.


4.  Security Considerations

   This document does not affect the security of the Internet.



Carpenter & Alvestrand  Expires November 12, 2009               [Page 4]

Internet-Draft             Including old text                   May 2009


5.  IANA Considerations

   This document requires no action by the IANA.


6.  Acknowledgements

   Much mailing list discussion by the IETF community, and private email
   discussions with Scott Bradner, Jorge Contreras, Russ Housley, John
   Klensin, and others, have led to this document.  The discussions at
   IETF74 in San Francisco led a significant rewrite.

   This document was produced using the xml2rfc tool [RFC2629].


7.  References

7.1.  Normative References

   [RFC5378]  Bradner, S. and J. Contreras, "Rights Contributors Provide
              to the IETF Trust", BCP 78, RFC 5378, November 2008.

7.2.  Informative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3667]  Bradner, S., "IETF Rights in Contributions", RFC 3667,
              February 2004.

   [RFC3978]  Bradner, S., "IETF Rights in Contributions", RFC 3978,
              March 2005.


Appendix A.  Non-normative initial version of disclaimer

   The current valid version should be taken from the IETF Trust's
   "Legal Provisions Relating to IETF Documents", originally located at
   <http://trustee.ietf.org/policyandprocedures.html>.  The initial
   version was:

   [[ Note to RFC Editor: please make sure this is the Trust's current
   disclaimer text at the time of publication. ]]

   "This document may contain material from IETF Documents or IETF



Carpenter & Alvestrand  Expires November 12, 2009               [Page 5]

Internet-Draft             Including old text                   May 2009


   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English."


Appendix B.  Non-normative explanation of background

   This Appendix is not part of the formal rules of the IETF and does
   not purport to offer legal advice.  Contributors to the IETF who are
   in any doubt as to how to proceed are advised to take appropriate
   legal advice.

   Copyright provisions for IETF documents were first defined in
   [RFC2026] and were subsequently refined in [RFC3667] and [RFC3978].
   Their effect has always been to allow free use of contributions to
   the IETF process in IETF discussions, IETF drafts and IETF
   publications.  Even prior to RFC 2026, such free use was considered
   the norm by all participants.  RFC 5378 makes no difference to the
   IETF's right to use contributions freely within the IETF process.
   However, use of contributions outside the IETF process has always
   been subject to some limitations.  The IETF does not require
   copyright transfers, and as a result contributors retain control
   except to the extent that the IETF rules applicable at the time of
   submission indicate otherwise.

   IETF and RFC Editor rules and practices have always allowed RFCs to
   be reproduced as complete documents, in English or in translation.
   This has not changed.

   The particular point at issue is the use of IETF contributions in
   works derived from IETF documents by third parties outside the IETF
   process.  The rules in RFC 2026, RFC 3667 and RFC 3978 do not allow
   this without the contributors' permission, except for limited
   exceptions.

   The exception defined in RFC 2026 is that "derivative works that
   comment on or otherwise explain it [the IETF document] or assist in
   its implmentation [sic] may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind..."
   This has been generally interpreted to allow extracts to be used in
   software implementations, user manuals, text books, and the like.



Carpenter & Alvestrand  Expires November 12, 2009               [Page 6]

Internet-Draft             Including old text                   May 2009


   RFC 3667 and RFC 3978 added explicit wording to further clarify that
   code extracts may be freely used by anybody: "(E) to extract, copy,
   publish, display, distribute, modify and incorporate into other
   works, for any purpose (and not limited to use within the IETF
   Standards Process) any executable code or code fragments that are
   included in any IETF Document...".  However, RFC 3667 and RFC 3978 do
   not mention the category of "derivative works that comment on or
   otherwise explain..."  For contributions made when they were in
   force, use of non-code extracts for commentary and explanation
   outside the IETF process appears formally to require explicit
   permission from the original contributors.  In many jurisdictions,
   this might fall under the "fair use" provisions of copyright law or
   their local equivalent, and in any case most RFC authors would be
   glad of such use.

   [RFC5378] extends the rights granted by contributors to the IETF (in
   practice, the IETF Trust) such that the IETF itself (via the Trust)
   can grant the right to make derivative works to third parties.  Short
   of a full copyright transfer to the IETF, this cleans up the
   situation for new documents.  It allows the IETF to grant rights to
   third parties to make use of new IETF documents in any way the IETF
   is happy with, and it leaves the original contributors free to do
   what they want with their own work (even in ways the IETF is unhappy
   with).

   As noted in the Introduction, there is an issue if a current IETF
   contribution, submitted under the new rules of RFC 5378, includes
   material originally submitted by a different contributor under one of
   the previous rules (including prior to RFC 2026 when there was no
   rule).  Suppose Alice plans to submit a draft under RFC 5378
   containing a modified version of a section of an RFC originally
   submitted by Bob under one of the older rules.  This is a very common
   situation, for example when a protocol needs clarification or
   correction, or a new version is most conveniently documented by
   revising the old text.  There are several possible approaches, all of
   which appear to fully respect Bob's rights without significantly
   delaying publication:
   1.  Alice realises that the old material was written by a large
       number of "Bobs", or by people no longer active in the IETF and
       possibly even deceased, or by people who no longer work for the
       employer to whom their copyright was assigned by their conditions
       of employment, or any other situation where obtaining their
       agreement is a substantial effort or a practical impossibility.
       In this case, Alice includes acknowledgments and the disclaimer,
       and we are done.  The acknowledgment will look something like
       "Significant amounts of text in sections X, Y and Z have been
       adapted from RFCxxxx written by Bob."




Carpenter & Alvestrand  Expires November 12, 2009               [Page 7]

Internet-Draft             Including old text                   May 2009


   2.  Alice looks at the IETF Trust web site, and finds that the
       previous RFC is listed as already being OK for use under RFC 5378
       conditions, or that Bob and his employer are listed as allowing
       any of their contributions to be so used.  Alice submits a draft
       using the normal RFC 5378 boilerplate, and includes an
       acknowledgement of Bob's contribution, such as: "Significant
       amounts of text have been adapted from RFCxxxx written by Bob,
       who has agreed to the text being submitted under the IETF's
       current copyright provisions".
   3.  Alice can easily find Bob's email address and he rapidly agrees
       that his old contribution may be used under current IETF rules.
       Alice submits a draft with the same acknowledgment as Option 2.
   4.  Similar, except that Bob prefers to be listed as a co-author.
       Again, the normal RFC 5378 boilerplate will be used.
   5.  Similar, except that this would increase the number of listed
       authors above the limit preferred by the RFC Editor.  In this
       case, a list of fully identified Contributors would be used, as
       defined in the RFC Editor's Editorial Guidelines.
   6.  Bob doesn't reply in a reasonable period of time, or says he
       doesn't agree, or says that his previous employer actually owns
       the rights, and it would take months of discussion with their
       lawyers to get agreement.  In such cases, Alice has wasted her
       time, and she reverts to Option 1 above.

   The same possibilities would apply to text from an Internet-Draft
   submitted prior to RFC 5378, or to text posted as email as part of an
   IETF discussion prior to RFC 5378.

   There is scope for judgment and common sense when using small
   fragments of text, whether taken from speech, email, a draft, or an
   RFC.  This Appendix doesn't define rules or offer legal advice about
   the copyright status of odd phrases and sentences culled from normal
   ongoing IETF discussion prior to RFC 5378.  However, the originators
   of such fragments have the chance to complain about their use during
   Working Group or IETF Last Call.  Of course, when in doubt, it is
   always safe to include the disclaimer.

   Note that for jointly written drafts, all direct and indirect
   contributors take responsibility for identifying pre-5378 text from
   other contributors.  If Alice submits a draft written by herself,
   Alicia and Alize, all three are responsible for verifying that any
   old text from other contributions that they have re-used is handled
   according to this document.

   What amounts to a reasonable amount of time to wait for Bob to reply,
   when trying Options 3 through 6 above?  There is normally no reason
   to wait more than a few days.  If the issue is considered unusually
   important for some reason, it will be a matter of judgment how hard



Carpenter & Alvestrand  Expires November 12, 2009               [Page 8]

Internet-Draft             Including old text                   May 2009


   to work on getting agreement from Bob and possibly his previous
   employer.  The WG Chair, the Area Director, or the IETF Trust might
   be asked to assist.  However, it seems likely that in most cases,
   that much effort will seem excessive, and it will be fine to include
   the disclaimer.  It should be remembered that the IETF's ability to
   do its own work is absolutely unaffected by this result.

   What amounts to sufficient agreement from Bob?  The IETF process
   takes place mainly on-line, so a clear email agreeing to RFC 5378
   conditions should be enough.  However, it would be better if Bob also
   provides the hard-copy general non-exclusive license suggested by the
   IETF Trust.  If Bob writes that he is replying on behalf of his co-
   contributors, that should also be enough.  But if Bob states that he
   cannot speak for his previous employers, that is not enough on its
   own.  In many cases, employment laws or contracts do not leave Bob
   with copyright in his own writings, so the previous employer's
   agreement is needed.  The best way for that to happen is for the
   employer concerned to sign the Trust's general license.  In most
   cases, it probably isn't reasonable for Alice to pursue this option
   herself.

   It should be noted that when the disclaimer is included, the
   situation for a third party wishing to re-use the old text is exactly
   as it always has been: the third party has to identify the legitimate
   copyright holder(s) ("Bob") and get their permission.  The IETF, the
   IETF Trust, and the recent contributors ("Alice") are not concerned.

   The procedure defined in the main body of this document is intended
   to ensure that in the case of affected documents, the contributors do
   not waste their time.  They, or people acting on their behalf, may
   choose to make a modest and reasonable effort to gain agreement from
   earlier contributors that RFC 5378 rules may be applied (basically,
   checking the IETF Trust web site, and if necessary, sending "Bob" an
   email).  But they have a simple and straightforward default choice -
   the disclaimer - which leaves all parties no worse off than under the
   old rules.  And in all cases, normal good practice is followed by
   including an acknowledgment.














Carpenter & Alvestrand  Expires November 12, 2009               [Page 9]

Internet-Draft             Including old text                   May 2009


Authors' Addresses

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland  1142
   New Zealand

   Email: brian.e.carpenter@gmail.com


   Harald Alvestrand
   Beddingen 10
   Trondheim  7013
   Norway

   Email: harald@alvestrand.no

































Carpenter & Alvestrand  Expires November 12, 2009              [Page 10]