idnits 2.17.1 draft-ietf-ipr-rules-update-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 481. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 156: '... All I-Ds MUST include the exact ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 2006) is 6518 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3978' is mentioned on line 59, but not defined ** Obsolete undefined reference: RFC 3978 (Obsoleted by RFC 5378) == Unused Reference: 'RFC 3978' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'BCP 101' is defined on line 425, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 4071 (ref. 'BCP 101') (Obsoleted by RFC 8711) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bradner 3 Internet-Draft Harvard University 4 Editor 5 June 2006 7 RFC 3978 Update 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on August 25, 2006. 36 Abstract 37 This document modifies RFC 3978 "IETF Rights in Contributions" as 38 follows: (1) recognizing that the IETF Trust is now the proper 39 custodian of all IETF-related intellectual property rights, (2) 40 giving IETF Trust the right to permit extraction of material from 41 RFCs, and (3) giving IETF Trust the right to permit others to create 42 derivative works outside the IETF Standards Process. 44 This document does not constrain how the IETF Trust exercises those 45 rights. 47 Copyright Notice 48 Copyright (C) The Internet Society. (2006) 50 1. Introduction 52 1.1 IETF Trust 54 Currently the IETF requires that authors of Contributions to the IETF 55 grant to the IETF (meaning the full set of participants in the IETF 56 Standards Process) a limited set of non-exclusive rights and 57 permissions as part of the process of submitting such Contribution. 58 These rights and permissions are detailed in "IETF Rights in 59 Contributions" (RFC 3978 - BCP 78) [RFC3978]. 61 The IETF Trust was recently formed to act as the administrative 62 custodian of all copyrights and other intellectual property rights 63 relating to the IETF Standards Process that had previously been held 64 by ISOC and CNRI (See [reference to IETF Trust Agreement]). This 65 document modifies RFC 3978 in order to implement this structure. 66 Most importantly, it alters the license-grant path as follows: 67 whereas previously authors of Contributions to the IETF would grant a 68 license both to ISOC and to all IETF participants, it is now proposed 69 that such authors grant a license to the IETF Trust (in Section 3.3). 70 This document concerns itself only with "inbound" rights - those 71 rights to be granted to the IETF Trust by relevant Contributors. A 72 separate document will deal with "outbound" rights - those rights 73 granted by the IETF Trust to others. 75 This introductory section is to provide context for the reader. 76 Sections 2 and 3 of this document are intended to be normative. 78 1.2. Extractions from RFCs 80 Many people have expressed a desire to extract material from IETF 81 RFCs for use in documentation, textbooks, on-line help systems, and 82 for similar uses. In addition, some IETF RFCs contain MIBs and other 83 types of program code that could be compiled. 85 1.3 Right to reprint RFCs 87 Since the start of the RFC series, third parties have been free to 88 reproduce RFCs as-is or as translations. The permission to do so was 89 not specifically noted in early RFCs (other than a note to say that 90 the distribution of the RFC was unlimited). The copyright notice 91 introduced with RFC 1602 specifically granted these permissions. But 92 an unintended byproduct of the attempt in BCP 78 to simplify the 93 copyright statement in published RFCs was the lack of any specific 94 statement of these permissions in the RFC copyright notice or in BCP 95 78. A new Section 3.3(F) should be added to RFC 3978 to clarify that 96 the Contributor permits the IETF Trust to grant this right to third 97 parties. 99 1.4 Derivative Works 101 Currently the IETF obtains from Contributors the right to prepare 102 derivative works of their Contributions within the IETF Standards 103 Process. This is done in RFC 3978 Section 3.3 (a) (C). That 104 paragraph should be modified to grant the IETF Trust the ability to 105 authorize the preparation of derivative works without limiting such 106 development to the IETF Standards Process. Such a paragraph would 107 not, by itself, grant any additional permissions outside of the IETF, 108 but would empower the IETF Trust to authorize the development of 109 derivative works outside of the IETF Standards Process. One example 110 of where the IETF Trust might grant such a right is the case where 111 another standards development organization (SDO) wants to update or 112 extend an IETF technology (which would normally be done by the SDO 113 sending their requirements to the IETF) but the IETF no longer has a 114 working group focused on the particular technology and the IETF does 115 not have the interest to create a new working group. 117 1.5 No Retroactive Effect 119 The addition of these rights to those granted by Contributors under 120 RFC 3978 starts with the publication of this memo as a RFC. This 121 memo does not retroactively obtain these rights from Contributions 122 that predate the publication of this memo as a RFC. Accordingly, the 123 legends and other text accompanying this memo still reflect the 124 provisions of RFC 3978, even though those provisions will be amended 125 once this memo is published as an RFC. However, nothing prevents the 126 Contributors of such Contributions voluntarily granting these rights 127 retroactively. 129 2. General Statements 131 2.1 In order to clarify that Contributors are bound by all provisions 132 of RFC 3978 upon submission of a Contribution to the IETF, the 133 following paragraph is moved from Section 3.3 to the end of Section 134 3.1, with clarifying adjustments: 136 "By submission of a Contribution, each person actually submitting 137 the Contribution, and each named co-Contributor, is deemed to 138 agree to the terms and conditions set forth in this document, on 139 his or her own behalf and on behalf of the organization the 140 Contributor represents or is sponsored by (if any), when 141 submitting the Contribution." 143 2.2 Because it is necessary in this document to refer to individual 144 IETF participants, the following sentence is added at the end of the 145 definition of "IETF" in Section 1(a) of RFC 3978: 147 "An "IETF Participant" shall mean any such individual 148 participant." 150 2.3 To make it easier to change the ID boilerplate when needed Sections 151 5.1 to 5.6 are replaced with the following: 153 "5.1. IPR Disclosure Acknowledgement (required in all Internet- 154 Drafts but not in RFCs) 156 All I-Ds MUST include the exact text for an IPR Disclosure 157 Acknowledgement from http://www.ietf.org/ipr-boilerplate- 158 derivworks 160 5.2. Derivative Works Limitation 162 If the Contributor desires to eliminate the IETF's right to make 163 modifications and derivative works of an IETF Contribution (other 164 than translations), one of the two Derivative Works Limitation 165 notices from http://www.ietf.org/ipr-boilerplate-derivworks may be 166 included in the Status of Memo section of an Internet-Draft and 167 included in a published RFC. 169 In the cases of MIB or PIB modules and in other cases where the 170 Contribution includes material that is meant to be extracted in 171 order to be used, the text of the MIB extraction notice from 172 http://www.ietf.org/ipr-boilerplate-derivworks should be appended 173 to the Derivative Works Limitation. 175 These notices may not be used with any standards-track document or 176 with most working group documents, except as discussed in Section 177 7.3 below, since the IETF must retain change control over its 178 documents and the ability to augment, clarify and enhance the 179 original IETF Contribution in accordance with the IETF Standards 180 Process. A fuller discussion of the rationale behind these 181 requirements is contained in Section 7.3 below. 183 5.3. Publication Limitation 185 If the Contributor only wants the IETF Contribution to be made 186 available in an Internet-Draft (i.e., does not want the IETF 187 Contribution to be published as an RFC) then the Contributor may 188 include the Publication Limitation notice from 189 http://www.ietf.org/ipr-boilerplate-derivworks in the Status of 190 Memo section of the Internet-Draft. 192 This notice can be used on IETF Contributions that are intended to 193 provide background information to educate and to facilitate 194 discussions within IETF working groups but are not intended to be 195 published as an RFCs. 197 5.4. Copyright Notice (required for all IETF Documents) 199 (Normally placed at the end of the IETF Document.) 201 The Copyright notice from http://www.ietf.org/ipr-boilerplate- 202 derivworks must be included in all Internet-Drafts. 204 Additional copyright notices are not permitted in IETF Documents 205 except in the case where such document is the product of a joint 206 development effort between the IETF and another standards 207 development organization or the document is a republication of the 208 work of another standards organization. Such exceptions must be 209 approved on an individual basis by the IAB. 211 5.5. Disclaimer (required in all IETF Documents) 213 (Normally placed at the end of the IETF Document after the 214 copyright notice.) 216 The Disclaimer notice from http://www.ietf.org/ipr-boilerplate- 217 derivworks must be included in all Internet-Drafts. 219 5.6. Exceptions 221 Notwithstanding the provisions of this Section 5, in certain 222 limited cases an abbreviated notice may be placed on certain types 223 of derivative works of IETF Documents in accordance with this 224 Section 5.6. 226 a. in MIB modules, PIB modules and similar material commonly 227 extracted from IETF Documents, except for material that is 228 being placed under IANA maintenance, the abbreviated MIB notice 229 from http://www.ietf.org/ipr-boilerplate-derivworks shall be 230 included in the body of the material that will be extracted in 231 lieu of the notices otherwise required by Section 5. 233 When the MIB or PIB module is the initial version of a module 234 that is to be maintained by the IANA, the abbreviated MIB 235 Copyright Notice from http://www.ietf.org/ipr-boilerplate- 236 derivworks notice shall be included: 238 Variations of these abbreviated notices are not permitted 239 except in cases where the material to be extracted is the 240 product of a joint development effort between the IETF and 241 another standards development organization or is a 242 republication of the work of another standards organization. 243 Such variations must be approved on an individual basis by the 244 IAB. 246 b. short excerpts of IETF Documents presented in electronic help 247 systems, for example, the DESCRIPTION clauses for MIB 248 variables, do not need to include a copyright notice. 250 3. Rights Granted By Contributors to IETF Trust - New Section 3.3 252 The following text describes the rights that are granted by each 253 Contributor to the IETF Trust and replaces Section 3.3 of RFC 3978 in 254 full: 256 "3.3. Rights Granted by Contributors to IETF Trust 258 To the extent that a Contribution or any portion thereof is 259 protected by copyright or other rights of authorship, the 260 Contributor, and each named co-Contributor, and the organization 261 he or she represents or is sponsored by (if any) grants a 262 perpetual, irrevocable, non-exclusive, royalty-free, world-wide 263 right and license to the IETF Trust under all such copyrights and 264 other rights in the Contribution: 266 (A) to copy, publish, display, and distribute the Contribution as 267 part of the IETF Standards Process or in an Internet-Draft, 269 (B) to prepare or allow the preparation of translations of the 270 Contribution into languages other than English, 272 (C) unless explicitly disallowed in the notices contained in a 273 Contribution [as per Section 5.2 below], 275 (1) to modify or prepare derivative works (in addition to 276 translations) that are based on or incorporate all or part 277 of the Contribution or comment upon it, within the IETF 278 Standards Process, and 280 (2) as determined by the IETF Trust, to grant third parties the 281 right to modify or prepare derivative works of the 282 Contribution outside of the IETF Standards Process, and to 283 copy, publish, display and distribute such modifications or 284 derivative works outside the IETF Standards Process, subject 285 to a requirement to properly acknowledge the IETF (it being 286 understood that neither consent of, nor notice to, the 287 Contributor shall be required for any such grant), 289 provided that in each case the license to such modification or 290 derivative works does not grant any more rights than the 291 license to the original Contribution, and 293 (D) to reproduce any trademarks, service marks or trade names 294 which are included in the Contribution solely in connection 295 with the reproduction, distribution or publication of the 296 Contribution and derivative works thereof as permitted by this 297 Section 3.3, provided that when reproducing Contributions, 298 trademark and service mark identifiers used in the 299 Contribution, including (TM) and (R) will be preserved, and 301 (E) to extract, copy, publish, display, distribute and incorporate 302 into other works, for any purpose (and not limited to use 303 within the IETF Standards Process), all or any portion of the 304 Contribution without modification (other than non-substantive 305 modifications such as reformatting, translation into languages 306 other than English or compilation of source code statements 307 into executable code), and further provided that the notices 308 required by Sections 5.4 or 5.6 below, as applicable, are 309 included, and 311 (F) to permit third parties to copy, publish, display and 312 distribute the Contribution without modification, as part of a 313 full, unmodified RFC and to permit third parties to translate 314 the Contribution as part of a full, unmodified RFC into 315 languages other than English, for any purpose, whether or not 316 within the IETF Standards Process. 318 (G) to permit the IETF Trust to sublicense these rights to the 319 extent of the original grant of right and license, including 320 its use in a working collection or collective work. 322 The licenses granted in this Section 3.3 shall not be deemed to 323 grant any right under any patent, patent application or other 324 similar intellectual property right disclosed by the 325 Contributor under BCP 79." 327 4. Instruct IETF Trust to grant rights to IETF participants 329 [ NOTE: this section has been added at the request of the General 330 Area AD. This direction may be better placed in another document.] 332 The following to be inserted between sections 8 and 9 of RFC 3978. 334 "The IETF Trust is hereby instructed to grant the rights granted 335 in section 3.3 above to all participants in the IETF process as 336 needed for the operation of the IETF standards process." 338 5. Legends and Notifications 340 The legends and notifications required by RFC 3978 are hereby updated 341 as set forth below to reflect the other provisions of this document. 343 5.1 The first paragraph of Section 5 of RFC 3978 explains the 344 requirement for applying certain notices and legends to IETF 345 documents. There has been considerable confusion in the past 346 regarding the meaning of the copyright notice on these documents. 347 Accordingly, the first paragraph of Section 5 is hereby amended as 348 follows to explain the purpose and meaning of this copyright notice 349 requirement, as well as to substitute "IETF Trust" for "ISOC": 351 "The IETF requires that certain notices and disclaimers described 352 in this Section 5 be reproduced verbatim in all IETF Documents 353 (including copies, derivative works and translations of IETF 354 Documents, but subject to the limited exceptions noted in Section 355 5.2). This requirement protects the IETF Trust, IETF and IETF 356 Participants from liabilities connected with these documents. 358 The copyright notice also alerts readers that the document is an 359 IETF Document, and that the IETF Trust owns certain aspects of the 360 document, such as its layout, the RFC numbering convention and the 361 prefatory language of the document. This legend is not, however, 362 intended to imply that IETF or the IETF Trust owns the text of any 363 Contribution included in an IETF Document. Rather, ownership of 364 such Contributions is retained by the author(s) or remains in the 365 public domain, as applicable, subject only to the licenses granted 366 to IETF and the IETF Trust under Section 3.3 above." 368 5.2 Update copyright statement and clarify text about additional 369 copyright statements 371 The creation of the IETF Trust to hold IETF-related IPR requires that 372 the copyright statement in Section 5.4 be changed. Since it has been 373 established practice to include a one-line copyright statement near 374 the beginning of IETF Documents this should be mentioned. 376 The text in Section 5.4 about multiple copyright statements has 377 occasionally been misinterpreted so should be clarified. 379 5.2.1 Revised Section 5.4 380 5.4. Copyright Notices (required for all IETF Documents) 382 (Normally placed at the end of the IETF Document.) 384 "Portions Copyright (C) The IETF Trust (year). 386 This document is subject to the rights, licenses and 387 restrictions contained in BCP 78, and except as set forth 388 therein, the authors retain all their rights." 390 Only copyright notices for the IETF Trust are permitted in IETF 391 Documents except in the case where such a document is the product 392 of a joint development effort between the IETF and another 393 standards development organization or the document is a 394 republication of the work of another standards organization. Such 395 exceptions must be approved on an individual basis by the IAB. 397 5.3 In Section 5.6 of RFC 3978, all occurrences of "Internet Society" 398 or "ISOC" are replaced by "IETF Trust". 400 to reduce confusion the note about multiple copyright notices 402 5.4 In Section 5.5 of RFC 3978, ", THE IETF TRUST" is inserted after 403 "INTERNET SOCIETY". 405 6. Errata 407 6.1 The two sentences of Section 4.2(a)(C) are combined into a single 408 sentence separated by a comma. 410 6.2 In Section 7.1, all occurrences of "Internet Society" or "ISOC" are 411 replaced by "IETF Trust". 413 6.3 The section reference at the end of the first paragraph of Section 414 7.3 is changed from 3.3(E) to 3.3(C). 416 6.4. In Section 8, ", the IETF Trust" is inserted after "ISOC". 418 7. References 420 7.1. Normative References 422 [RFC 3978] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78, 423 RFC 3978, March 2005. 425 [BCP 101] Austein, R., and B. Wijnen, "Structure of the IETF 426 Administrative Support Activity (IASA)," BCP 101, RFC 4071, April 427 2005. 429 [IETF Trust Agreement?] 431 8. Acknowledgements 433 Thanks to Jorge Contreras from Wilmer, Cutler, Pickering, Hale and 434 Dorr LLP who provided a significant rewrite of my material. 436 9. Editor's Address 438 Scott Bradner 439 Harvard University 440 29 Oxford St. 441 Cambridge MA, 02138 443 Phone: +1 617 495 3864 444 EMail: sob@harvard.edu 446 10. Full copyright statement 448 Copyright (C) The Internet Society (2006). This document is subject 449 to the rights, licenses and restrictions contained in BCP 78, and 450 except as set forth therein, the authors retain all their rights. 452 This document and the information contained herein are provided on an 453 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 454 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 456 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 457 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 458 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 459 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 461 Intellectual Property 463 The IETF takes no position regarding the validity or scope of any 464 Intellectual Property Rights or other rights that might be claimed to 465 pertain to the implementation or use of the technology described in 466 this document or the extent to which any license under such rights 467 might or might not be available; nor does it represent that it has 468 made any independent effort to identify any such rights. Information 469 on the procedures with respect to rights in RFC documents can be 470 found in BCP 78 and BCP 79. 472 Copies of IPR disclosures made to the IETF Secretariat and any 473 assurances of licenses to be made available, or the result of an 474 attempt made to obtain a general license or permission for the use of 475 such proprietary rights by implementers or users of this 476 specification can be obtained from the IETF on-line IPR repository at 477 http://www.ietf.org/ipr. The IETF invites any interested party to 478 bring to its attention any copyrights, patents or patent 479 applications, or other proprietary rights that may cover technology 480 that may be required to implement this standard. Please address the 481 information to the IETF at ietf-ipr@ietf.org. 483 Acknowledgement 485 Funding for the RFC Editor function is currently provided by the 486 Internet Society. 488 Changes 490 Note to RFC Editor - remove this section if this document is 491 published as an RFC 493 version 3 to version 4 494 major rewrite based on input from Jorge 496 version 4 to version 5 497 various places cleaned up removal of outbound rights 499 version 5 to version 6 500 added section 2.3 501 added a new section 4 and renumbered the old section 4 and the 502 sections following