idnits 2.17.1 draft-ietf-iasa2-rfc5377bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 21, 2019) is 1707 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5377 (Obsoleted by RFC 8721) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IASA2 J. Halpern, Ed. 3 Internet-Draft Ericsson 4 Obsoletes: 5377 (if approved) August 21, 2019 5 Intended status: Informational 6 Expires: February 22, 2020 8 Advice to the Trustees of the IETF Trust 9 on Rights to Be Granted in IETF Documents 10 draft-ietf-iasa2-rfc5377bis-03 12 Abstract 14 Contributors grant intellectual property rights to the IETF. The 15 IETF Trust holds and manages those rights on behalf of the IETF. The 16 Trustees of the IETF Trust are responsible for that management. This 17 management includes granting the licenses to copy, implement, and 18 otherwise use IETF Contributions, among them Internet-Drafts and 19 RFCs. The Trustees of the IETF Trust accept direction from the IETF 20 regarding the rights to be granted. This document describes the 21 desires of the IETF regarding outbound rights to be granted in IETF 22 Contributions. This document obsoletes RFC 5377 solely for the 23 purpose of removing references to the IAOC which was part of IASA. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 22, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Purpose in Granting Rights . . . . . . . . . . . . . . . . . 3 61 3. Powers and Authority . . . . . . . . . . . . . . . . . . . . 3 62 4. Recommended Grants of Right to Copy . . . . . . . . . . . . . 4 63 4.1. Rights Granted for Reproduction of RFCs . . . . . . . . . 5 64 4.2. Rights Granted for Quoting from IETF Contributions . . . 5 65 4.3. Rights Granted for Implementing Based on IETF 66 Contributions . . . . . . . . . . . . . . . . . . . . . . 5 67 4.4. Rights Granted for Use of Text from IETF Contributions . 6 68 4.5. Additional Licenses for IETF Contributions . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 7.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 Under the current operational and administrative structures, IETF 79 intellectual property rights are vested in the IETF Trust 80 administered by a board of trustees. This includes the right to make 81 use of IETF Contributions, as granted by Contributors under the rules 82 laid out in [RFC5378]. The Trustees of the IETF Trust are therefore 83 responsible for defining the rights to copy granted by the IETF to 84 people who wish to make use of the material in these documents. 86 For consistency and clarity, this document uses the same terminology 87 laid out in [RFC5378] and uses the same meanings as defined in that 88 document. 90 The IETF Trust, by way of its Trustees, has indicated, as is 91 consistent with the IETF structure, that it will respect the wishes 92 of the IETF in regard to what these granted rights ought to be. It 93 is therefore the IETF's responsibility to articulate those wishes. 94 This document represents the wishes of the IETF regarding the rights 95 granted to all users in regard to IETF Contributions, until it is 96 superseded. 98 2. Purpose in Granting Rights 100 In providing a description of the wishes of the IETF with regard to 101 rights granted in RFCs, it is helpful to keep in mind the purpose of 102 granting such rights. 104 The mission of the IETF is to produce documents that make the 105 Internet work better (see [RFC3935] for more details). These 106 documents, when completed, are published as RFCs. 108 An important subclass of RFCs is standards describing protocols; for 109 these, the primary value to the Internet is the ability of 110 implementors to build solutions (products, software, etc.) that 111 interoperate using these standards. Hence, the IETF has a strong 112 interest in seeing accurate, interoperable implementations of the 113 material the IETF publishes. The IETF Trust grants rights to copy to 114 people to make use of the text in the RFCs in order to encourage 115 accurate and interoperable implementations. 117 As early implementations from Internet-Drafts make use of 118 descriptions in those Internet-Drafts, similar desires apply to 119 Internet-Drafts. 121 Similar considerations also apply to non-standard, non-protocol 122 documents such as BCP (Best Current Practice) and Informational 123 documents; in this document, we recommend a common approach to the 124 issue of right-to-use licenses for all IETF documents. 126 Previous documents regarding rights in IETF documents have included 127 in the RFC text specific text to be used to achieve the stated goals. 128 This has proved problematic. When problems are found with such text, 129 even when the problem is not a change in intent, it is necessary to 130 revise the RFC to fix the problem. At best, this delays fixing legal 131 issues that need prompt attention. As such, this document describes 132 the IETF desires to the Trustees of the IETF Trust, but does not 133 provide the specific legal wording to address the goals. The 134 selection, and updating as necessary, of legal wording is left to the 135 Trustees of the IETF Trust. 137 3. Powers and Authority 139 As described in the introduction, and formally specified in 140 [RFC5378], the legal authority for determining and granting users 141 rights to copy material in RFCs and other IETF Contributions rests 142 with the Trustees for the IETF Trust. This document provides 143 guidance to that body, based on the rough consensus of the IETF. The 144 Trustees of the IETF Trust have the authority and responsibility to 145 determine the exact text insertions (or other mechanisms), if any, 146 needed in Internet-Drafts, RFCs, and all IETF Contributions to meet 147 these goals. The IETF Trust License Policy is available from 148 [TRUST-LEGAL] https://trustee.ietf.org/docs/IETF-Trust-License- 149 Policy.pdf 151 To ensure continuity, the starting point for license text and other 152 materials will be that previously created by the Trustees of the IETF 153 under the authority of [RFC5377] which this document supersedes. 154 Changes to the IETF documentation, and document policies themselves, 155 take effect as determined by the Trustees of the IETF Trust. 157 This document does not specify what rights the IETF Trust receives 158 from others in IETF Contributions. That is left to another document 159 ([RFC5378]). While care has been taken by the working group in 160 developing this document, and care will be taken by the Trustees of 161 the IETF Trust, to see that sufficient rights are granted to the IETF 162 Trust in IETF Contributions, it is also the case that the Trust can 163 not grant rights it has not or does not receive, and it is expected 164 that policies will be in line with that fact. Similarly, the rights 165 granted for pre-existing documents can not be expanded unless the 166 holders of rights in those Contributions choose to grant expanded 167 rights. Nonetheless, to the degree it can, and without embarking on 168 a massive effort, it is desirable if similar rights to those 169 described below can be granted in older RFCs. 171 4. Recommended Grants of Right to Copy 173 The IETF grants rights to copy and modify parts of IETF Contributions 174 in order to meet the objectives described earlier. As such, 175 different circumstances and different parts of documents may need 176 different grants. This section contains subsections for each such 177 different grant that is currently envisioned. Each section is 178 intended to describe a particular usage, to describe how that usage 179 is recognizable, and to provide guidance to the Trustees of the IETF 180 Trust as to what rights the IETF would like to see granted in that 181 circumstance and what limitations should be put on such granting. 183 These recommendations for outgoing rights are structured around the 184 assumptions documented in [RFC5378]. Thus, this document is about 185 granting rights derived from those granted to the IETF Trust. The 186 recommendations below are how those granted rights should in turn be 187 passed on to others using IETF documents in ways and for purposes 188 that fit with the goals of the IETF. This discussion is also 189 separate from discussion of the rights the IETF itself requires in 190 documents to do its job, as those are not "outbound" rights. It is 191 expected that the rights granted to the IETF will be a superset of 192 those copying rights we wish to grant to others. 194 4.1. Rights Granted for Reproduction of RFCs 196 It has long been IETF policy to encourage copying of RFCs in full. 197 This permits wide dissemination of the material, without risking loss 198 of context or meaning. The IETF wishes to continue to permit anyone 199 to make full copies and translations of RFCs. 201 4.2. Rights Granted for Quoting from IETF Contributions 203 There is rough consensus that it is useful to permit quoting without 204 modification of excerpts from IETF Contributions. Such excerpts may 205 be of any length and in any context. Translation of quotations is 206 also to be permitted. All such quotations should be attributed 207 properly to the IETF and the IETF Contribution from which they are 208 taken. 210 4.3. Rights Granted for Implementing Based on IETF Contributions 212 IETF Contributions often include components intended to be directly 213 processed by a computer. Examples of these include ABNF definitions, 214 XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, 215 MIBs, ASN.1, and classical programming code. These are included in 216 IETF Contributions for clarity and precision in specification. It is 217 clearly beneficial, when such items are included in IETF 218 Contributions, to permit the inclusion of such code components in 219 products that implement the Contribution. It has been pointed out 220 that in several important contexts, use of such code requires the 221 ability to modify the code. One common example of this is simply the 222 need to adapt code for use in specific contexts (languages, 223 compilers, tool systems, etc.) Such use frequently requires some 224 changes to the text of the code from the IETF Contribution. Another 225 example is that code included in open source products is frequently 226 licensed to permit any and all of the code to be modified. Since we 227 want this code included in such products, it follows that we need to 228 permit such modification. While there has been discussion of 229 restricting in some way the rights to make such modifications, the 230 rough consensus of the IETF is that such restrictions are likely a 231 bad idea, and are certainly very complex to define. 233 As such, the rough consensus is that the IETF Trust is to grant 234 rights such that code components of IETF Contributions can be 235 extracted, modified, and used by anyone in any way desired. To 236 enable the broadest possible extraction, modification, and usage, the 237 IETF Trust should avoid adding software license obligations beyond 238 those already present in a Contribution. The granted rights to 239 extract, modify, and use code should allow creation of derived works 240 outside the IETF that may carry additional license obligations. As 241 the IETF Trust can not grant rights it does not receive, the rights 242 to extract, modify, and use code described in this paragraph can not 243 be granted in IETF Contributions that are explicitly marked as not 244 permitting derivative works. 246 While it is up to the Trustees of the IETF Trust to determine the 247 best way of meeting this objective, two mechanisms are suggested here 248 that are believed to be helpful in documenting the intended grant to 249 readers and users of IETF Contributions. 251 Firstly, the Trustees of the IETF Trust should maintain, in a 252 suitable, easily accessible fashion, a list of common RFC components 253 that will be considered to be code. To start, this list should 254 include at least the items listed above. The Trustees of the IETF 255 Trust will add to this list as they deem suitable or as they are 256 directed by the IETF. 258 Additionally, the Trustees of the IETF Trust should define a textual 259 representation to be included in an IETF Contribution to indicate 260 that a portion of the document is considered by the authors (and 261 later, the working group, and upon approval, the IETF) to be code and 262 thus subject to the permissions granted to use code. 264 4.4. Rights Granted for Use of Text from IETF Contributions 266 There is no consensus at this time to permit the use of text from 267 RFCs in contexts where the right to modify the text is required. The 268 authors of IETF Contributions may be able and willing to grant such 269 rights independently of the rights they have granted to the IETF by 270 making the Contribution. 272 4.5. Additional Licenses for IETF Contributions 274 There have been contexts where the material in an IETF Contribution 275 is also available under other license terms. The IETF wishes to be 276 able to include content that is available under such licenses. It is 277 desirable to indicate in the IETF Contribution that other licenses 278 are available. It would be inappropriate and confusing if such 279 additional licenses restricted the rights the IETF intends to grant 280 in the content of RFCS. 282 However, the IETF does not wish to have IETF Contributions contain 283 additional licenses, as that introduces a number of additional 284 difficulties. Specifically, additional text in the document, and any 285 additional license referred to by permitted additional text, must not 286 in any way restrict the rights the IETF intends to grant to others 287 for using the contents of IETF Contributions. 289 Authors of Contributions retain all rights in their Contributions. 290 As such, an author may directly grant any rights they wish separately 291 from what the IETF grants. However, a reader wishing to determine or 292 make use of such grants will need to either consult external sources 293 of information, possibly including open source code and documents, or 294 contact the author directly. 296 5. IANA Considerations 298 No values are assigned in this document, no registries are created, 299 and there is no action assigned to the IANA by this document. One 300 list (of kinds of code sections) is anticipated, to be created and 301 maintained by the Trustees of the IETF Trust. It is up to the 302 Trustees of the IETF Trust whether they create such a list and 303 whether they choose to involve the IANA in maintaining that list. 305 6. Security Considerations 307 This document introduces no new security considerations. It is a 308 process document about the IETF's IPR rights being granted to other 309 people. While there may be attacks against the integrity or 310 effectiveness of the IETF processes, this document does not address 311 such issues. 313 7. References 315 7.1. Normative References 317 [RFC5377] Halpern, J., Ed., "Advice to the Trustees of the IETF 318 Trust on Rights to Be Granted in IETF Documents", 319 RFC 5377, DOI 10.17487/RFC5377, November 2008, 320 . 322 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights 323 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 324 October 2008. 326 7.2. Informative References 328 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 329 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 330 . 332 [TRUST-LEGAL] 333 IETF Trust, "Legal Provisions Relating to IETF Documents", 334 March 2015. 336 http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf 338 Author's Address 340 Joel M. Halpern (editor) 341 Ericsson 342 P. O. Box 6049 343 Leesburg, VA 20178 344 US 346 EMail: joel.halpern@ericsson.com