idnits 2.17.1 draft-ietf-ipr-rules-update-05.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 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 371. ** 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.) 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 6496 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 312, but no explicit reference was found in the text == Unused Reference: 'BCP 101' is defined on line 315, 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: 8 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 3. Rights Granted By Contributors to IETF Trust - New Section 3.3 152 The following text describes the rights that are granted by each 153 Contributor to the IETF Trust and replaces Section 3.3 of RFC 3978 in 154 full: 156 "3.3. Rights Granted by Contributors to IETF Trust 158 To the extent that a Contribution or any portion thereof is 159 protected by copyright or other rights of authorship, the 160 Contributor, and each named co-Contributor, and the organization 161 he or she represents or is sponsored by (if any) grants a 162 perpetual, irrevocable, non-exclusive, royalty-free, world-wide 163 right and license to the IETF Trust under all such copyrights and 164 other rights in the Contribution: 166 (A) to copy, publish, display, and distribute the Contribution as 167 part of the IETF Standards Process or in an Internet-Draft, 169 (B) to prepare or allow the preparation of translations of the 170 Contribution into languages other than English, 172 (C) unless explicitly disallowed in the notices contained in a 173 Contribution [as per Section 5.2 below], 175 (1) to modify or prepare derivative works (in addition to 176 translations) that are based on or incorporate all or part 177 of the Contribution or comment upon it, within the IETF 178 Standards Process, and 180 (2) as determined by the IETF Trust, to grant third parties the 181 right to modify or prepare derivative works of the 182 Contribution outside of the IETF Standards Process, and to 183 copy, publish, display and distribute such modifications or 184 derivative works outside the IETF Standards Process, subject 185 to a requirement to properly acknowledge the IETF (it being 186 understood that neither consent of, nor notice to, the 187 Contributor shall be required for any such grant), 189 provided that in each case the license to such modification or 190 derivative works does not grant any more rights than the 191 license to the original Contribution, and 193 (D) to reproduce any trademarks, service marks or trade names 194 which are included in the Contribution solely in connection 195 with the reproduction, distribution or publication of the 196 Contribution and derivative works thereof as permitted by this 197 Section 3.3, provided that when reproducing Contributions, 198 trademark and service mark identifiers used in the 199 Contribution, including (TM) and (R) will be preserved, and 201 (E) to extract, copy, publish, display, distribute and incorporate 202 into other works, for any purpose (and not limited to use 203 within the IETF Standards Process), all or any portion of the 204 Contribution without modification (other than non-substantive 205 modifications such as reformatting, translation into languages 206 other than English or compilation of source code statements 207 into executable code), and further provided that the notices 208 required by Sections 5.4 or 5.6 below, as applicable, are 209 included, and 211 (F) to permit third parties to copy, publish, display and 212 distribute the Contribution without modification, as part of a 213 full, unmodified RFC and to permit third parties to translate 214 the Contribution as part of a full, unmodified RFC into 215 languages other than English, for any purpose, whether or not 216 within the IETF Standards Process. 218 (G) to permit the IETF Trust to sublicense these rights to the 219 extent of the original grant of right and license, including 220 its use in a working collection or collective work. 222 The licenses granted in this Section 3.3 shall not be deemed to 223 grant any right under any patent, patent application or other 224 similar intellectual property right disclosed by the 225 Contributor under BCP 79." 227 4. Legends and Notifications 229 The legends and notifications required by RFC 3978 are hereby updated 230 as set forth below to reflect the other provisions of this document. 232 4.1 The first paragraph of Section 5 of RFC 3978 explains the 233 requirement for applying certain notices and legends to IETF 234 documents. There has been considerable confusion in the past 235 regarding the meaning of the copyright notice on these documents. 236 Accordingly, the first paragraph of Section 5 is hereby amended as 237 follows to explain the purpose and meaning of this copyright notice 238 requirement, as well as to substitute "IETF Trust" for "ISOC": 240 "The IETF requires that certain notices and disclaimers described 241 in this Section 5 be reproduced verbatim in all IETF Documents 242 (including copies, derivative works and translations of IETF 243 Documents, but subject to the limited exceptions noted in Section 244 5.2). This requirement protects the IETF Trust, IETF and IETF 245 Participants from liabilities connected with these documents. 247 The copyright notice also alerts readers that the document is an 248 IETF Document, and that the IETF Trust owns certain aspects of the 249 document, such as its layout, the RFC numbering convention and the 250 prefatory language of the document. This legend is not, however, 251 intended to imply that IETF or the IETF Trust owns the text of any 252 Contribution included in an IETF Document. Rather, ownership of 253 such Contributions is retained by the author(s) or remains in the 254 public domain, as applicable, subject only to the licenses granted 255 to IETF and the IETF Trust under Section 3.3 above." 257 4.2 Update copyright statement and clarify text about additional 258 copyright statements 260 The creation of the IETF Trust to hold IETF-related IPR requires that 261 the copyright statement in Section 5.4 be changed. Since it has been 262 established practice to include a one-line copyright statement near 263 the beginning of IETF Documents this should be mentioned. 265 The text in Section 5.4 about multiple copyright statements has 266 occasionally been misinterpreted so should be clarified. 268 4.2.1 Revised Section 5.4 270 5.4. Copyright Notices (required for all IETF Documents) 272 (Normally placed at the end of the IETF Document.) 274 "Portions Copyright (C) The IETF Trust (year). 276 This document is subject to the rights, licenses and 277 restrictions contained in BCP 78, and except as set forth 278 therein, the authors retain all their rights." 280 Only copyright notices for the IETF Trust are permitted in IETF 281 Documents except in the case where such a document is the product 282 of a joint development effort between the IETF and another 283 standards development organization or the document is a 284 republication of the work of another standards organization. Such 285 exceptions must be approved on an individual basis by the IAB. 287 4.3 In Section 5.6 of RFC 3978, all occurrences of "Internet Society" 288 or "ISOC" are replaced by "IETF Trust". 290 to reduce confusion the note about multiple copyright notices 292 4.4 In Section 5.5 of RFC 3978, ", THE IETF TRUST" is inserted after 293 "INTERNET SOCIETY". 295 5. Errata 297 5.1 The two sentences of Section 4.2(a)(C) are combined into a single 298 sentence separated by a comma. 300 5.2 In Section 7.1, all occurrences of "Internet Society" or "ISOC" are 301 replaced by "IETF Trust". 303 5.3 The section reference at the end of the first paragraph of Section 304 7.3 is changed from 3.3(E) to 3.3(C). 306 5.4. In Section 8, ", the IETF Trust" is inserted after "ISOC". 308 6. References 310 6.1. Normative References 312 [RFC 3978] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78, 313 RFC 3978, March 2005. 315 [BCP 101] Austein, R., and B. Wijnen, "Structure of the IETF 316 Administrative Support Activity (IASA)," BCP 101, RFC 4071, April 317 2005. 319 [IETF Trust Agreement?] 321 7. Acknowledgements 323 Thanks to Jorge Contreras from Wilmer, Cutler, Pickering, Hale and 324 Dorr LLP who provided a significant rewrite of my material. 326 8. Editor's Address 328 Scott Bradner 329 Harvard University 330 29 Oxford St. 331 Cambridge MA, 02138 333 Phone: +1 617 495 3864 334 EMail: sob@harvard.edu 336 9. Full copyright statement 338 Copyright (C) The Internet Society (2006). This document is subject 339 to the rights, licenses and restrictions contained in BCP 78, and 340 except as set forth therein, the authors retain all their rights. 342 This document and the information contained herein are provided on an 343 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 344 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 346 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 347 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 348 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 349 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 351 Intellectual Property 353 The IETF takes no position regarding the validity or scope of any 354 Intellectual Property Rights or other rights that might be claimed to 355 pertain to the implementation or use of the technology described in 356 this document or the extent to which any license under such rights 357 might or might not be available; nor does it represent that it has 358 made any independent effort to identify any such rights. Information 359 on the procedures with respect to rights in RFC documents can be 360 found in BCP 78 and BCP 79. 362 Copies of IPR disclosures made to the IETF Secretariat and any 363 assurances of licenses to be made available, or the result of an 364 attempt made to obtain a general license or permission for the use of 365 such proprietary rights by implementers or users of this 366 specification can be obtained from the IETF on-line IPR repository at 367 http://www.ietf.org/ipr. The IETF invites any interested party to 368 bring to its attention any copyrights, patents or patent 369 applications, or other proprietary rights that may cover technology 370 that may be required to implement this standard. Please address the 371 information to the IETF at ietf-ipr@ietf.org. 373 Acknowledgement 375 Funding for the RFC Editor function is currently provided by the 376 Internet Society.