idnits 2.17.1 draft-carpenter-5378-old-text-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5378, but the abstract doesn't seem to directly say this. It does mention RFC5378 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5378, updated by this document, for RFC5378 checks: 2007-03-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 11, 2009) is 5464 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3667 (Obsoleted by RFC 3978) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Updates: 5378 (if approved) H. Alvestrand 5 Intended status: BCP Google 6 Expires: November 12, 2009 May 11, 2009 8 Including text under former copyright conditions 9 draft-carpenter-5378-old-text-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 12, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies a procedure for including text in an IETF 48 document for which the current copyright conditions defined in RFC 49 5378 cannot readily be met. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Mandatory Procedure . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Voluntary Procedures . . . . . . . . . . . . . . . . . . . . . 4 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 61 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 62 Appendix A. Non-normative initial version of disclaimer . . . . . 5 63 Appendix B. Non-normative explanation of background . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 [[ Note to be removed by the RFC Editor: This version of the draft 69 describes a completely modified procedure compared to the one 70 presented at IETF74, which did not obtain consensus. It contains 71 small and large changes throughout. Discussion is invited on the 72 ipr-wg@ietf.org list. ]] 74 Terminology: In this document, the phrases "prior to RFC 5378" and 75 "pre-5378" refer to IETF Contributions made before November 10, 2008, 76 when RFC 5378 became effective. The phrase "Original Contributor" 77 refers to an Indirect Contributor in the sense of [RFC5378], whose 78 Contribution was prior to RFC 5378. Other terminology is defined in 79 RFC 5378. 81 RFC 5378 failed to describe one case that has practical consequences. 83 The case is this: a new IETF Contribution contains material derived 84 from one or more pre-5378 Contributions, but the Original 85 Contributors have not agreed to the specific additional rights 86 granted to the IETF under RFC 5378 compared to previous IETF rules. 87 In this case, the Contributor cannot accurately make the warranties 88 required by RFC 5378 with respect to the pre-5378 material included 89 in his or her Contribution. 91 This can arise when the Original Contributors, or their assigns, are 92 unwilling, unresponsive, unfindable, deceased, no longer in business, 93 or simply too numerous. 95 This document is intended to specify the simplest possible solution 96 for such cases. Additional background information is given in 97 Appendix B below. 99 2. Mandatory Procedure 101 It should be noted that Section 5.6 of [RFC5378] already requires 102 that Indirect Contributors must be acknowledged in all IETF 103 documents. This continues a requirement previously specified in 104 section 3.4 (a) of [RFC3978] and [RFC3667], and in section 10.3.1 (4) 105 of [RFC2026]. The present document extends this requirement in 106 certain cases. 108 Contributors of Internet-Drafts that contain text originally 109 contributed to the IETF by other persons prior to RFC 5378 have 110 certain responsibilities, to be exercised to the best of their 111 knowledge and ability. 113 Unless the Contributor(s) know that the Original Contributors have 114 agreed to their text being contributed under the terms of RFC 5378, 115 the Internet-Draft and any resulting RFC must include an appropriate 116 legend of disclaimer. The current text of this legend will be 117 specified by the IETF Trust's "Legend Instructions" as defined in 118 [RFC5378]. The initial version of this text is given for 119 informational purposes in Appendix A below. 121 If and only if this legend is included: 122 o The acknowledgement required by Section 5.6 of [RFC5378] should 123 identify the source(s) of pre-5378 text, such as RFCs and 124 Internet-Drafts. This requirement does not extend to small 125 fragments of text culled from IETF discussions. 126 o The acknowledgement should also identify which Original 127 Contributors contributed which sections of pre-5378 text. This 128 requirement does not apply if the text concerned is scattered 129 throughout the document. 131 The IETF Trust is directed to ensure that its policies and licenses 132 allow for documents including the disclaimer. 134 3. Voluntary Procedures 136 [[ Discussion invited: is it appropriate and useful to include these 137 voluntary procedures? The BOF at IETF74 seemed to accept a "MAY" 138 approach, but there was no clear consensus call on that point. ]] 140 All Contributors to the IETF prior to RFC 5378 are invited to provide 141 retroactively to the IETF Trust the rights in their Contributions 142 required by RFC 5378. 144 The IETF Trust may provide a public register of pre-5378 documents 145 for which the rights required by RFC 5378 have been provided 146 retroactively, and a public register of rights holders who have 147 retroactively provided such rights for all their pre-5378 148 Contributions. 150 Contributors of Internet-Drafts including pre-5378 material who wish 151 to avoid also including the disclaimer may take any steps they wish, 152 or ask helpers to take such steps, to contact the Original 153 Contributors and obtain their agreement to their text being 154 contributed under the terms of RFC 5378. 156 4. Security Considerations 158 This document does not affect the security of the Internet. 160 5. IANA Considerations 162 This document requires no action by the IANA. 164 6. Acknowledgements 166 Much mailing list discussion by the IETF community, and private email 167 discussions with Scott Bradner, Jorge Contreras, Russ Housley, John 168 Klensin, and others, have led to this document. The discussions at 169 IETF74 in San Francisco led a significant rewrite. 171 This document was produced using the xml2rfc tool [RFC2629]. 173 7. References 175 7.1. Normative References 177 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 178 to the IETF Trust", BCP 78, RFC 5378, November 2008. 180 7.2. Informative References 182 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 183 3", BCP 9, RFC 2026, October 1996. 185 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 186 June 1999. 188 [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, 189 February 2004. 191 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, 192 March 2005. 194 Appendix A. Non-normative initial version of disclaimer 196 The current valid version should be taken from the IETF Trust's 197 "Legal Provisions Relating to IETF Documents", originally located at 198 . The initial 199 version was: 201 [[ Note to RFC Editor: please make sure this is the Trust's current 202 disclaimer text at the time of publication. ]] 204 "This document may contain material from IETF Documents or IETF 205 Contributions published or made publicly available before November 206 10, 2008. The person(s) controlling the copyright in some of this 207 material may not have granted the IETF Trust the right to allow 208 modifications of such material outside the IETF Standards Process. 209 Without obtaining an adequate license from the person(s) controlling 210 the copyright in such materials, this document may not be modified 211 outside the IETF Standards Process, and derivative works of it may 212 not be created outside the IETF Standards Process, except to format 213 it for publication as an RFC or to translate it into languages other 214 than English." 216 Appendix B. Non-normative explanation of background 218 This Appendix is not part of the formal rules of the IETF and does 219 not purport to offer legal advice. Contributors to the IETF who are 220 in any doubt as to how to proceed are advised to take appropriate 221 legal advice. 223 Copyright provisions for IETF documents were first defined in 224 [RFC2026] and were subsequently refined in [RFC3667] and [RFC3978]. 225 Their effect has always been to allow free use of contributions to 226 the IETF process in IETF discussions, IETF drafts and IETF 227 publications. Even prior to RFC 2026, such free use was considered 228 the norm by all participants. RFC 5378 makes no difference to the 229 IETF's right to use contributions freely within the IETF process. 230 However, use of contributions outside the IETF process has always 231 been subject to some limitations. The IETF does not require 232 copyright transfers, and as a result contributors retain control 233 except to the extent that the IETF rules applicable at the time of 234 submission indicate otherwise. 236 IETF and RFC Editor rules and practices have always allowed RFCs to 237 be reproduced as complete documents, in English or in translation. 238 This has not changed. 240 The particular point at issue is the use of IETF contributions in 241 works derived from IETF documents by third parties outside the IETF 242 process. The rules in RFC 2026, RFC 3667 and RFC 3978 do not allow 243 this without the contributors' permission, except for limited 244 exceptions. 246 The exception defined in RFC 2026 is that "derivative works that 247 comment on or otherwise explain it [the IETF document] or assist in 248 its implmentation [sic] may be prepared, copied, published and 249 distributed, in whole or in part, without restriction of any kind..." 250 This has been generally interpreted to allow extracts to be used in 251 software implementations, user manuals, text books, and the like. 253 RFC 3667 and RFC 3978 added explicit wording to further clarify that 254 code extracts may be freely used by anybody: "(E) to extract, copy, 255 publish, display, distribute, modify and incorporate into other 256 works, for any purpose (and not limited to use within the IETF 257 Standards Process) any executable code or code fragments that are 258 included in any IETF Document...". However, RFC 3667 and RFC 3978 do 259 not mention the category of "derivative works that comment on or 260 otherwise explain..." For contributions made when they were in 261 force, use of non-code extracts for commentary and explanation 262 outside the IETF process appears formally to require explicit 263 permission from the original contributors. In many jurisdictions, 264 this might fall under the "fair use" provisions of copyright law or 265 their local equivalent, and in any case most RFC authors would be 266 glad of such use. 268 [RFC5378] extends the rights granted by contributors to the IETF (in 269 practice, the IETF Trust) such that the IETF itself (via the Trust) 270 can grant the right to make derivative works to third parties. Short 271 of a full copyright transfer to the IETF, this cleans up the 272 situation for new documents. It allows the IETF to grant rights to 273 third parties to make use of new IETF documents in any way the IETF 274 is happy with, and it leaves the original contributors free to do 275 what they want with their own work (even in ways the IETF is unhappy 276 with). 278 As noted in the Introduction, there is an issue if a current IETF 279 contribution, submitted under the new rules of RFC 5378, includes 280 material originally submitted by a different contributor under one of 281 the previous rules (including prior to RFC 2026 when there was no 282 rule). Suppose Alice plans to submit a draft under RFC 5378 283 containing a modified version of a section of an RFC originally 284 submitted by Bob under one of the older rules. This is a very common 285 situation, for example when a protocol needs clarification or 286 correction, or a new version is most conveniently documented by 287 revising the old text. There are several possible approaches, all of 288 which appear to fully respect Bob's rights without significantly 289 delaying publication: 290 1. Alice realises that the old material was written by a large 291 number of "Bobs", or by people no longer active in the IETF and 292 possibly even deceased, or by people who no longer work for the 293 employer to whom their copyright was assigned by their conditions 294 of employment, or any other situation where obtaining their 295 agreement is a substantial effort or a practical impossibility. 296 In this case, Alice includes acknowledgments and the disclaimer, 297 and we are done. The acknowledgment will look something like 298 "Significant amounts of text in sections X, Y and Z have been 299 adapted from RFCxxxx written by Bob." 301 2. Alice looks at the IETF Trust web site, and finds that the 302 previous RFC is listed as already being OK for use under RFC 5378 303 conditions, or that Bob and his employer are listed as allowing 304 any of their contributions to be so used. Alice submits a draft 305 using the normal RFC 5378 boilerplate, and includes an 306 acknowledgement of Bob's contribution, such as: "Significant 307 amounts of text have been adapted from RFCxxxx written by Bob, 308 who has agreed to the text being submitted under the IETF's 309 current copyright provisions". 310 3. Alice can easily find Bob's email address and he rapidly agrees 311 that his old contribution may be used under current IETF rules. 312 Alice submits a draft with the same acknowledgment as Option 2. 313 4. Similar, except that Bob prefers to be listed as a co-author. 314 Again, the normal RFC 5378 boilerplate will be used. 315 5. Similar, except that this would increase the number of listed 316 authors above the limit preferred by the RFC Editor. In this 317 case, a list of fully identified Contributors would be used, as 318 defined in the RFC Editor's Editorial Guidelines. 319 6. Bob doesn't reply in a reasonable period of time, or says he 320 doesn't agree, or says that his previous employer actually owns 321 the rights, and it would take months of discussion with their 322 lawyers to get agreement. In such cases, Alice has wasted her 323 time, and she reverts to Option 1 above. 325 The same possibilities would apply to text from an Internet-Draft 326 submitted prior to RFC 5378, or to text posted as email as part of an 327 IETF discussion prior to RFC 5378. 329 There is scope for judgment and common sense when using small 330 fragments of text, whether taken from speech, email, a draft, or an 331 RFC. This Appendix doesn't define rules or offer legal advice about 332 the copyright status of odd phrases and sentences culled from normal 333 ongoing IETF discussion prior to RFC 5378. However, the originators 334 of such fragments have the chance to complain about their use during 335 Working Group or IETF Last Call. Of course, when in doubt, it is 336 always safe to include the disclaimer. 338 Note that for jointly written drafts, all direct and indirect 339 contributors take responsibility for identifying pre-5378 text from 340 other contributors. If Alice submits a draft written by herself, 341 Alicia and Alize, all three are responsible for verifying that any 342 old text from other contributions that they have re-used is handled 343 according to this document. 345 What amounts to a reasonable amount of time to wait for Bob to reply, 346 when trying Options 3 through 6 above? There is normally no reason 347 to wait more than a few days. If the issue is considered unusually 348 important for some reason, it will be a matter of judgment how hard 349 to work on getting agreement from Bob and possibly his previous 350 employer. The WG Chair, the Area Director, or the IETF Trust might 351 be asked to assist. However, it seems likely that in most cases, 352 that much effort will seem excessive, and it will be fine to include 353 the disclaimer. It should be remembered that the IETF's ability to 354 do its own work is absolutely unaffected by this result. 356 What amounts to sufficient agreement from Bob? The IETF process 357 takes place mainly on-line, so a clear email agreeing to RFC 5378 358 conditions should be enough. However, it would be better if Bob also 359 provides the hard-copy general non-exclusive license suggested by the 360 IETF Trust. If Bob writes that he is replying on behalf of his co- 361 contributors, that should also be enough. But if Bob states that he 362 cannot speak for his previous employers, that is not enough on its 363 own. In many cases, employment laws or contracts do not leave Bob 364 with copyright in his own writings, so the previous employer's 365 agreement is needed. The best way for that to happen is for the 366 employer concerned to sign the Trust's general license. In most 367 cases, it probably isn't reasonable for Alice to pursue this option 368 herself. 370 It should be noted that when the disclaimer is included, the 371 situation for a third party wishing to re-use the old text is exactly 372 as it always has been: the third party has to identify the legitimate 373 copyright holder(s) ("Bob") and get their permission. The IETF, the 374 IETF Trust, and the recent contributors ("Alice") are not concerned. 376 The procedure defined in the main body of this document is intended 377 to ensure that in the case of affected documents, the contributors do 378 not waste their time. They, or people acting on their behalf, may 379 choose to make a modest and reasonable effort to gain agreement from 380 earlier contributors that RFC 5378 rules may be applied (basically, 381 checking the IETF Trust web site, and if necessary, sending "Bob" an 382 email). But they have a simple and straightforward default choice - 383 the disclaimer - which leaves all parties no worse off than under the 384 old rules. And in all cases, normal good practice is followed by 385 including an acknowledgment. 387 Authors' Addresses 389 Brian Carpenter 390 Department of Computer Science 391 University of Auckland 392 PB 92019 393 Auckland 1142 394 New Zealand 396 Email: brian.e.carpenter@gmail.com 398 Harald Alvestrand 399 Beddingen 10 400 Trondheim 7013 401 Norway 403 Email: harald@alvestrand.no