idnits 2.17.00 (12 Aug 2021) /tmp/idnits62487/draft-ietf-ipr-outbound-rights-07.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 364. -- 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 377. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 12, 2008) is 5054 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'InboundRights' -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 4371 (Obsoleted by RFC 8714) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPR J. Halpern, Ed. 3 Internet-Draft Self 4 Expires: January 13, 2009 July 12, 2008 6 Advice to the Trustees of the IETF Trust on Rights to be Granted in IETF 7 Documents 8 draft-ietf-ipr-outbound-rights-07 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 13, 2009. 35 Abstract 37 Contributors grant intellectual property rights to the IETF. The 38 IETF Trust holds and manages those rights on behalf of the IETF. The 39 Trustees of the IETF Trust are responsible for that management. This 40 management includes granting the licenses to copy, implement and 41 otherwise use IETF contributions, among them Internet-Drafts and 42 RFCs. The Trustees of the IETF Trust accepts direction from the IETF 43 regarding the rights to be granted. This document describes the 44 desires of the IETF regarding outbound rights to be granted in IETF 45 contributions. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Purpose in Granting Rights . . . . . . . . . . . . . . . . . . 3 51 3. Powers and Authority . . . . . . . . . . . . . . . . . . . . . 4 52 4. Recommended Grants of Right to Copy . . . . . . . . . . . . . . 5 53 4.1. Rights Granted for Reproduction of RFCs . . . . . . . . . . 5 54 4.2. Rights Granted for Quoting from IETF Contributions . . . . 5 55 4.3. Rights Granted for Implementing based on IETF 56 Contributions . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.4. Rights Granted for use of text from IETF Contributions . . 7 58 4.5. Additional Licenses for IETF Contributions . . . . . . . . 7 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . . . 9 67 1. Introduction 69 Under the current operational and administrative structures, IETF 70 intellectual property rights are vested in the IETF Trust 71 administered by a board of trustees made up of the members of the 72 IAOC [RFC4371]. This includes the right to make use of IETF 73 contributions, as granted by contributors under the rules laid out in 74 [InboundRights]. The Trustees of the IETF Trust are therefore 75 responsible for defining the rights to copy granted by the IETF to 76 people who wish to make use of the material in these documents. 78 For consistency and clarity, this document uses the same terminology 79 laid out in [InboundRights] and uses the same meanings as defined in 80 that document. 82 The IETF Trust, by way of its Trustees, has indicated, as is 83 consistent with the IETF structure, that it will respect the wishes 84 of the IETF in regard to what these granted rights ought to be. It 85 is therefore the IETF's responsibility to articulate those wishes. 86 This document represents the wishes of the IETF regarding the rights 87 granted to all users in regard to IETF contributions, until it is 88 superseded. 90 2. Purpose in Granting Rights 92 In providing a description of the wishes of the IETF with regard to 93 rights granted in RFCs, it is helpful to keep in mind the purpose of 94 granting such rights. 96 The mission of the IETF is to produce documents that make the 97 Internet work better (see [RFC3935] for more details). These 98 documents, when completed, are published as RFCs. 100 An important subclass of RFCs is standards describing protocols; for 101 these, the primary value to the Internet is the ability of 102 implementors to build solutions (products, software, etc) which 103 interoperate using these standards. Hence, the IETF has a strong 104 interest in seeing accurate, interoperable implementations of the 105 material the IETF publishes. The IETF Trust grants rights to copy to 106 people to make use of the text in the RFCs in order to encourage 107 accurate and interoperable implementations. 109 As early implementations from Internet-Drafts make use of 110 descriptions in those Internet-Drafts, similar desires apply to 111 Internet-Drafts. 113 Similar considerations also apply to non-standard, non-protocol 114 documents such as BCPs and informational documents; in this document, 115 we recommend a common approach to the issue of right-to-use licenses 116 for all IETF documents. 118 Previous documents regarding rights in IETF documents have included 119 in the RFC text specific text to be used to achieve the stated goals. 120 This has proved problematic. When problems are found with such text, 121 even when the problem is not a change in intent, it is necessary to 122 revise the RFC to fix the problem. At best this delays fixing legal 123 issues which need prompt attention. As such, this document describes 124 the IETF desires to the Trustees of the IETF Trust, but does not 125 provide the specific legal wording to address the goals. The 126 selection, and updating as necessary, of legal wording is left to the 127 Trustees of the IETF Trust. Appeals of the actions of the Trustees 128 of the IETF Trust are governed by other documents. As the Trustees 129 are the members of the IAOC, the appeals procedure documented in BCP 130 101 (currently [RFC4371]) is applicable. 132 3. Powers and Authority 134 As described in the introduction, and formally specified in 135 [InboundRights], the legal authority for determining and granting 136 users rights to copy material in RFCs and other IETF contributions 137 rests with the Trustees for the IETF Trust, which is made up of the 138 members of the IAOC, as described in [RFC4071] and [RFC4371]. This 139 document provides guidance to that body, based on the rough consensus 140 of the IETF. The trustees of the IETF Trust have the authority and 141 responsibility to determine the exact text insertions (or other 142 mechanisms), if any, needed in Internet-Drafts, RFCs, and all IETF 143 Contributions to meet these goals. 145 The rough consensus described in this document reflects the agreement 146 of the IETF as of the IETF Last call, and the Trustees of the IETF 147 Trust are to begin drafting license text and other materials to act 148 on these instructions upon IESG approval of this document for RFC 149 publication. Changes to the IETF documentation, and document 150 policies themselves, take effect as determined by the Trustees of the 151 IETF Trust. 153 This document does not specify what rights the IETF Trust receives 154 from others in IETF contributions. That is left to another document 155 ([InboundRights]). While care has been taken the working group in 156 developing this document, and care will be taken by the Trustees of 157 the IETF Trust, to see that sufficient rights are granted to the IETF 158 Trust in IETF contributions, it is also the case that the trust can 159 not grant rights it has not or does not receive, and it is expected 160 that policies will be in line with that fact. Similarly, the rights 161 granted for pre-existing documents can not be expanded unless the 162 holders of rights in those contributions choose to grant expanded 163 rights. Nonetheless, to the degree it can, and without embarking on 164 a massive effort, it is desirable if similar rights to those 165 described below can be granted in older RFCs. 167 4. Recommended Grants of Right to Copy 169 The IETF grants rights to copy and modify parts of IETF contributions 170 in order to meet the objectives described earlier. As such, 171 different circumstances and different parts of documents may need 172 different grants. This section contains subsections for each such 173 different grant that is currently envisioned. Each section is 174 intended to describe a particular usage, to describe how that usage 175 is recognizable, and to provide guidance to the Trustees of the IETF 176 Trust as to what rights the IETF would like to see granted in that 177 circumstances, and what limitations should be put on such granting. 179 These recommendations for outgoing rights are structured around the 180 assumptions documented in [InboundRights]. Thus, this document is 181 about granting rights derived from those granted to the IETF Trust. 182 The recommendations below are how those granted rights should in turn 183 be passed on to others using IETF documents in ways and for purposes 184 that fit with the goals of the IETF. This discussion is also 185 separate from discussion of the rights the IETF itself requires in 186 documents to do its job, as those are not "outbound" rights. It is 187 expected that the rights granted to the IETF will be a superset of 188 those copying rights we wish to grant to others. 190 4.1. Rights Granted for Reproduction of RFCs 192 It has long been IETF policy to encourage copying of RFCs in full. 193 This permits wide dissemination of the material, without risking loss 194 of context or meaning. The IETF wishes to continue to permit anyone 195 to make full copies and translations of RFCs. 197 4.2. Rights Granted for Quoting from IETF Contributions 199 There is rough consensus that it is useful to permit the quoting 200 without modification of excerpts from IETF Contributions. Such 201 excerpts may be of any length and in any context. Translation of 202 quotations is also to be permitted. All such quotations should be 203 attributed properly to the IETF and the IETF contribution from which 204 they are taken. 206 4.3. Rights Granted for Implementing based on IETF Contributions 208 IETF contributions often include components intended to be directly 209 processed by a computer. Examples of these include ABNF definitions, 210 XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, 211 MIBs, ASN.1, or classical programming code. These are included in 212 IETF contributions for clarity and precision in specification. It is 213 clearly beneficial, when such items are included in IETF 214 contributions, to permit the inclusion of such code components in 215 products which implement the contribution. It has been pointed out 216 that in several important contexts use of such code requires the 217 ability to modify the code. One common example of this is simply the 218 need to adapt code for use in specific contexts (languages, 219 compilers, tool systems, etc.) Such use frequently requires some 220 changes to the text of the code from the IETF contribution. Another 221 example is that code included in open source products is frequently 222 licensed to permit any and all of the code to be modified. Since we 223 want this code included in such products, it follows that we need to 224 permit such modification. While there has been discussion of 225 restricting the rights to make such modifications in some way, the 226 rough consensus of the IETF is that such restrictions are likely a 227 bad idea, and are certainly very complex to define. 229 As such, the rough consensus is that the IETF Trust is to grant 230 rights such that code components of IETF contributions can be 231 extracted, modified, and used by anyone in any way desired. To 232 enable the broadest possible extraction, modification and usage, the 233 IETF Trust should avoid adding software license obligations beyond 234 those already present in a contribution. The granted rights to 235 extract, modify and use code should allow creation of derived works 236 outside the IETF that may carry additional license obligations. As 237 the IETF Trust can not grant rights it does not receive, the rights 238 to extract, modify and use code described in this paragraph can not 239 be granted in IETF contributions that are explicitly marked as not 240 permitting derivative works. 242 While it is up to the Trustees of the IETF Trust to determine the 243 best way of meeting this objective, two mechanisms are suggested here 244 that are believed to be helpful in documenting the intended grant to 245 readers and users of IETF contributions. 247 Firstly, the Trustees of the IETF Trust should maintain, in a 248 suitable, easily accessible fashion, a list of common RFC components 249 which will be considered to be code. To start, this list should 250 include at least the items listed above. The Trustees of the IETF 251 Trust will add to this list as they deems suitable or as it is 252 directed by the IETF. 254 Additionally, the Trustees of the IETF Trust should define a textual 255 representation to be included in an IETF contribution to indicate 256 that a portion of the document is considered by the authors (and 257 later the working group, and upon approval the IETF) to be code, and 258 to be subject to the permissions granted to use code. 260 4.4. Rights Granted for use of text from IETF Contributions 262 There is no consensus at this time to permit the use of text from 263 RFCs in contexts where the right to modify the text is required. The 264 authors of IETF contributions may be able and willing to grant such 265 rights independently of the rights they have granted to the IETF by 266 making the contribution. 268 4.5. Additional Licenses for IETF Contributions 270 There have been contexts where the material in an IETF contribution 271 is also available under other license terms. The IETF wishes to be 272 able to include content which is available under such licenses. It 273 is desirable to indicate in the IETF contribution that other licenses 274 are available. It would be inappropriate and confusing if such 275 additional licenses restricted the rights the IETF intends to grant 276 in the content of RFCS. 278 However, the IETF does not wish to have IETF Contributions contain 279 additional licenses, as that introduces a number of additional 280 difficulties. Specifically, additional text in the document, and any 281 additional license referred to by permitted additional text must not 282 in any way restrict the rights the IETF intends to grant to others 283 for using the contents of IETF contributions. 285 Authors of contributions retain all rights in their contributions. 286 As such, an author may directly grant any rights they wish separately 287 from what the IETF grants. However, a reader wishing to determine or 288 make use of such grants will need to consult external sources of 289 information, including possibly open source code and documents, or 290 contact the author directly. 292 5. IANA Considerations 294 No values are assigned in this document, no registries are created, 295 and there is no action assigned to the IANA by this document. One 296 list (of kinds of code sections) is anticipated, to be created and 297 maintained by the Trustees of the IETF Trust. It is up to the 298 Trustees of the IETF Trust whether they create such a list and 299 whether they choose to involve the IANA in maintaining that list. 301 6. Security Considerations 303 This document introduces no new security considerations. It is a 304 process document about the IETFs IPR rights being granted to other 305 people. While there may be attacks against the integrity or 306 effectiveness of the IETF processes, this document does not address 307 such issues. 309 7. References 311 7.1. Normative References 313 [InboundRights] 314 Bradner, S. and J. Contreras, "I-D.ietf-ipr-3978-incoming- 315 09.txt", 2006. 317 7.2. Informative References 319 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 320 BCP 95, RFC 3935, October 2004. 322 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 323 Administrative Support Activity (IASA)", BCP 101, 324 RFC 4071, April 2005. 326 [RFC4371] Carpenter, B. and L. Lynch, "BCP 101 Update for IPR 327 Trust", BCP 101, RFC 4371, January 2006. 329 Author's Address 331 Joel M. Halpern (editor) 332 Self 333 P. O. Box 6049 334 Leesburg, VA 20178 335 US 337 Email: jmh@joelhalpern.com 339 Full Copyright Statement 341 Copyright (C) The IETF Trust (2008). 343 This document is subject to the rights, licenses and restrictions 344 contained in BCP 78, and except as set forth therein, the authors 345 retain all their rights. 347 This document and the information contained herein are provided on an 348 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 349 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 350 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 351 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 352 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 353 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 355 Intellectual Property 357 The IETF takes no position regarding the validity or scope of any 358 Intellectual Property Rights or other rights that might be claimed to 359 pertain to the implementation or use of the technology described in 360 this document or the extent to which any license under such rights 361 might or might not be available; nor does it represent that it has 362 made any independent effort to identify any such rights. Information 363 on the procedures with respect to rights in RFC documents can be 364 found in BCP 78 and BCP 79. 366 Copies of IPR disclosures made to the IETF Secretariat and any 367 assurances of licenses to be made available, or the result of an 368 attempt made to obtain a general license or permission for the use of 369 such proprietary rights by implementers or users of this 370 specification can be obtained from the IETF on-line IPR repository at 371 http://www.ietf.org/ipr. 373 The IETF invites any interested party to bring to its attention any 374 copyrights, patents or patent applications, or other proprietary 375 rights that may cover technology that may be required to implement 376 this standard. Please address the information to the IETF at 377 ietf-ipr@ietf.org.