idnits 2.17.1 draft-ietf-ipr-3978-incoming-09.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 699. 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 abstract seems to indicate that this document obsoletes RFC3978, but the header doesn't have an 'Obsoletes:' line to match this. 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 (5 May 2008) is 5834 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) == Missing Reference: 'RFC 4844' is mentioned on line 372, but not defined ** Obsolete undefined reference: RFC 4844 (Obsoleted by RFC 8729) == Missing Reference: '-outbound' is mentioned on line 637, but not defined ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 4371 (Obsoleted by RFC 8714) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 4748 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 11 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 Intended status: BCP Jorge Contreras 5 WilmerHale 6 Editors 7 5 May 2008 9 Rights Contributors provide to the IETF Trust 11 13 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 5, 2008. 37 Copyright (C) The IETF Trust (2008). 39 Abstract 40 The IETF policies about rights in Contributions to the IETF are 41 designed to ensure that such Contributions can be made available to 42 the IETF and Internet communities while permitting the authors to 43 retain as many rights as possible. This memo details the IETF 44 policies on rights in Contributions to the IETF. It also describes 45 the objectives that the policies are designed to meet. This memo 46 obsoletes RFC 3978 and 4748 and, with BCP 79 and RFC xxx (rfc editor 47 - replace with the RFC # of -outgoing), replaces Section 10 of RFC 48 2026. 50 Table of Contents 51 1. Definitions 52 2. Introduction 53 2.1 No Retroactive Effect 54 3. Exposition of why these procedures are the way they are 55 3.1. Rights Granted in Contributions 56 3.2. Rights to use Contributions 57 3.3. Right to Produce Derivative Works 58 3.4. Rights to use Trademarks 59 3.5. Contributions Not Subject to Copyright 60 3.6. Copyright in RFCs 61 4. RFC Editor Documents 62 5. Rights in Contributions 63 5.1. General Policy 64 5.2. Confidentiality Obligations 65 5.3. Rights Granted by Contributors to the IETF Trust 66 5.4. Sublicenses by IETF Trust 67 5.5. No Patent License 68 5.6. Representations and Warranties 69 5.7. No Duty to Publish 70 5.8. Trademarks 71 5.9. Copyright in RFCs 72 6. Legends, Notices and Other Standardized Text in IETF Documents 73 7. Security Considerations 74 8. References 75 8.1. Normative References 76 8.2. Informative References 77 9. Acknowledgements 78 10. Changes since RFC 3978 79 11. Declaration from the IAB 80 12. Editors' Addresses 81 Full Copyright Statement 83 1. Definitions 84 The following definitions are for terms used in the context of this 85 document. Other terms, including "IESG", "ISOC", "IAB", and "RFC 86 Editor" are defined in [RFC2028]. 88 a. "Contribution": any submission to the IETF intended by the 89 Contributor for publication as all or part of an Internet-Draft or 90 RFC (except for RFC Editor Contributions described in Section 4 91 below) and any statement made within the context of an IETF 92 activity. Such statements include oral statements in IETF 93 sessions, as well as written and electronic communications made at 94 any time or place, which are addressed to: 95 o the IETF plenary session, 96 o any IETF working group or portion thereof, 97 o any Birds of a Feather (BOF) session, 98 o the IESG, or any member thereof on behalf of the IESG, 99 o the IAB or any member thereof on behalf of the IAB, 100 o any IETF mailing list, including the IETF list itself, any 101 working group or design team list, or any other list 102 functioning under IETF auspices, 103 o the RFC Editor or the Internet-Drafts function (except for RFC 104 Editor Contributions described in Section 4 below). 106 Statements made outside of an IETF session, mailing list or other 107 function, that are clearly not intended to be input to an IETF 108 activity, group or function, are not IETF Contributions in the 109 context of this document. 110 b. "Contributor": an individual submitting a Contribution. 111 c. "Indirect Contributor": any person who has materially or 112 substantially contributed to a Contribution without being 113 personally involved in its submission to the IETF. 114 d. "Copyright" means the legal right granted to an author in a 115 document or other work of authorship under applicable law. A 116 "copyright" is not equivalent to a "right to copy". Rather a 117 copyright encompasses all of the exclusive rights that an author 118 has in a work, such as the rights to copy, publish, distribute and 119 create derivative works of the work. An author often cedes these 120 rights to his or her employer or other parties as a condition of 121 employment or compensation. 122 e. "IETF": In the context of this document, the IETF includes all 123 individuals who participate in meetings, working groups, mailing 124 lists, functions and other activities which are organized or 125 initiated by ISOC, the IESG or the IAB under the general 126 designation of the Internet Engineering Task Force or IETF, but 127 solely to the extent of such participation. 128 f. "IETF Documents": RFCs and Internet-Drafts that are used in the 129 IETF Standards Process as defined in 1(g). This is identical to 130 the "IETF stream" defined in [RFC 4844]. 131 g. "IETF Standards Process": the activities undertaken by the IETF in 132 any of the settings described in 1(a) above. 133 h. "IETF Trust": A trust established under the laws of the 134 Commonwealth of Virginia, USA, in order to hold and administer 135 intellectual property rights for the benefit of the IETF. 136 i. "Internet-Draft": temporary documents used in the IETF Standards 137 Process. Internet-Drafts are posted on the IETF web site by the 138 IETF Secretariat. As noted in Section 2.2 of RFC 2026, Internet- 139 Drafts have a nominal maximum lifetime of six months in the IETF 140 Secretariat's public directory. 141 j. "Legend Instructions" means the standardized text that is 142 maintained by the IETF Trust and is included in IETF Documents and 143 the instructions and requirements for including that standardized 144 text in IETF Documents, each as posted from time to time at 145 http://www.ietf.org/legends. 147 k. "RFC": the basic publication series for the IETF. RFCs are 148 published by the RFC Editor. Although RFCs may be superseded in 149 whole or in part by subsequent RFCs, the text of an RFC is not 150 altered once published in RFC form. (See [RFC2026] Section 2.1) 151 l. "Reasonably and personally known": means something an individual 152 knows personally or, because of the job the individual holds, 153 would reasonably be expected to know. This wording is used to 154 indicate that an organization cannot purposely keep an individual 155 in the dark about certain information just to avoid the disclosure 156 requirement. 157 m. "Non-IETF documents": means Internet-Drafts that are submitted to 158 the RFC Editor independently of the IETF Standards Process. (See 159 Section 4.) 161 2. Introduction 162 In all matters of copyright and document procedures, the intent is to 163 benefit the Internet community and the public at large, while 164 respecting the legitimate rights of others. 166 Under the laws of most countries and current international treaties 167 (for example the "Berne Convention for the Protection of Literary and 168 Artistic Work" [Berne Convention]), authors obtain numerous rights in 169 the works they produce automatically upon producing them. These 170 rights include copyrights, moral rights and other rights. In many 171 cases, if the author produces a work within the scope of his or her 172 employment, most of those rights are usually assigned to the 173 employer, either by operation of law or, in many cases, under 174 contract. (The Berne Convention names some rights as "inalienable", 175 which means that the author retains them in all cases.) 177 In order for Contributions to be used within the IETF Standards 178 Process, including when they are published as Internet-Drafts or 179 RFCs, certain limited rights must be granted to the IETF Trust, which 180 then grants the necessary rights to the IETF. In addition, 181 Contributors must make representations to the IETF Trust and the IETF 182 regarding their ability to grant these rights. 184 Section 1 provides definitions used in these policies. Sections 3 185 and 4 of this document explain the rationale for these provisions. 186 Sections 1, 2, 5 and 6 of this document are normative, the other 187 sections are informative. A companion document RFC 3979 (BCP 79) 188 [BCP79] deals with rights, including possible patent rights, in 189 technologies developed or specified as part of the IETF Standards 190 Process. This document is not intended to address those issues. This 191 memo obsoletes RFC 3978 [RFC3978] and 4748 [RFC4748] and, with RFC 192 3979 (BCP 79) and [-outgoing], replaces Section 10 of RFC 2026 193 [RFC2026]. 195 This document is not intended as legal advice. Readers are advised to 196 consult their own legal advisors if they would like a legal 197 interpretation of their rights or the rights of the IETF Trust 198 [RFC4371] in any Contributions they make. 200 2.1 No Retroactive Effect 201 This memo does not retroactively obtain additional rights from 202 Contributions that predate the date that the IETF Trust announces the 203 adoption of these procedures. 205 3. Exposition of Why These Procedures Are the Way They Are 207 3.1. Rights Granted in Contributions 208 The IETF Trust and the IETF must obtain the right to publish an IETF 209 Contribution as an RFC or an Internet-Draft from the Contributors. 211 A primary objective of this policy is to obtain from the document 212 authors only the non-exclusive rights that are needed to develop and 213 publish IETF Documents and to use IETF Contributions in the IETF 214 Standards Process and potentially elsewhere. 216 The authors retain all other rights, but cannot withdraw the above 217 rights from the IETF Trust and the IETF. 219 It is important to note that under this document Contributors are 220 required to grant certain rights to the IETF Trust, (See Section 221 5.3.) which holds all IETF-related intellectual property on behalf of 222 the IETF community. The IETF Trust will, in turn, grant a sublicense 223 of these rights to all IETF participants for use in the IETF 224 Standards Process. (See Section 5.4.) This sublicense is necessary 225 for the standards development work of the IETF to continue. In 226 addition, the IETF Trust may grant certain other sublicenses of the 227 rights that it is granted under this document. In granting such 228 other sublicenses, the IETF Trust will be guided and bound by 229 documents such as [-outgoing]. 231 3.2. Rights to use Contributions 232 It is important that the IETF receive assurances from all 233 Contributors that they have the authority to grant the IETF the 234 rights that they claim to grant because, under the laws of most 235 countries and applicable international treaties, copyright rights 236 come into existence when a work of authorship is created (but see 237 Section 3.5 below regarding public domain documents), and the IETF 238 cannot make use of IETF Contributions if it does not have sufficient 239 rights with respect to these copyright rights. The IETF and its 240 participants would run a greater risk of liability to the owners of 241 these rights without this assurance. To this end, the IETF asks 242 Contributors to give the assurances in Section 5.6 below. These 243 assurances are requested, however, only to the extent of the 244 Contributor's reasonable and personal knowledge. (See Section 1(k)) 246 3.3. Right to Produce Derivative Works 247 The IETF needs to be able to evolve IETF Documents in response to 248 experience gained in the deployment of the technologies described in 249 such IETF Documents, to incorporate developments in research and to 250 react to changing conditions on the Internet and other IP networks. 251 The IETF may also decide to permit others to develop derivative works 252 based on Contributions. In order to do this, the IETF must be able 253 to produce derivatives of its documents; thus the IETF must obtain 254 the right from Contributors to produce derivative works. Note that 255 the right to produce translations is required before any Contribution 256 can be published as an RFC to ensure the widest possible distribution 257 of the material in RFCs. The right to produce derivative works, in 258 addition to translations, is required for all IETF standards track 259 documents and for most IETF non-standards track documents. There are 260 two exceptions to this requirement: documents describing proprietary 261 technologies and documents that are republications of the work of 262 other standards organizations. 264 The right to produce derivative works must be granted in order for an 265 IETF working group to accept a Contribution as a working group 266 document or otherwise work on it. For non-working group Contributions 267 where the Contributor requests publication as a standards track RFC, 268 the right to produce derivative works must be granted before the IESG 269 will issue an IETF Last-Call and, for most non-standards track non- 270 working group Contributions, before the IESG will consider the 271 Internet-Draft for publication. Occasionally a Contributor may not 272 want to grant publication rights or the right to produce derivative 273 works before finding out if a Contribution has been accepted for 274 development in the IETF Standards Process. In these cases the 275 Contributor may include a limitation on the right to make derivative 276 works in the form specified in the Legend Instructions. A working 277 group can discuss the Contribution with the aim to decide if it 278 should become a working group document, even though the right to 279 produce derivative works or to publish the Contribution as an RFC has 280 not yet been granted. However, if the Contribution is accepted for 281 development, the Contributor must resubmit the Contribution without 282 the limitation notices before a working group can formally adopt the 283 Contribution as a working group document. The IETF Trust may 284 establish different policies for granting sublicenses with respect to 285 different types of Contributions and content within Contributions 286 (such as executable code versus descriptive text or references to 287 third party materials). The IETF Trust's policies concerning the 288 granting of sublicenses to make derivative works will be guided by 289 RFC [-outbound]. 291 The IETF has historically encouraged organizations to publish details 292 of their technologies, even when the technologies are proprietary, 293 because understanding how existing technology is being used helps 294 when developing new technology. But organizations that publish 295 information about proprietary technologies are frequently not willing 296 to have the IETF produce revisions of the technologies and then 297 possibly claim that the IETF version is the "new version" of the 298 organization's technology. Organizations that feel this way can 299 specify that a Contribution be published with the other rights 300 granted under this document but may withhold the right to produce 301 derivative works other than translations. 303 In addition, IETF Documents frequently make normative references to 304 standards or recommendations developed by other standards 305 organizations. Since the publications of some standards organizations 306 are not public documents, it can be quite helpful to the IETF to 307 republish, with the permission of the other standards organization, 308 some of these documents as RFCs so that the IETF community can have 309 open access to them to better understand what they are referring to. 310 In these cases the RFCs can be published without the right for the 311 IETF to produce derivative works. In both of the above cases in 312 which the production of derivative works is excluded, the Contributor 313 must include a special legend in the Contribution, as specified in 314 the Legend Instructions, in order to notify IETF participants about 315 this restriction. 317 3.4. Rights to Use Trademarks 318 Contributors may wish to seek trademark or service mark protection on 319 any terms that are coined or used in their Contributions. the IETF 320 makes no judgment about the validity of any such trademark rights. 321 However, the IETF requires each Contributor, under the licenses 322 described in Section 5.3 below, to grant the IETF Trust a perpetual 323 license to use any such trademarks or service marks solely in 324 exercising rights to reproduce, publish, discuss and modify the IETF 325 Contribution. This license does not authorize IETF or others to use 326 any trademark or service mark in connection with any product or 327 service offering. 329 3.5. Contributions Not Subject to Copyright 330 Certain documents, including those produced by the U.S. government 331 and those which are in the public domain, may not be protected by the 332 same copyright and other legal rights as other documents. 333 Nevertheless, we ask each Contributor to grant to the IETF the same 334 rights as he or she would grant, and to make the same 335 representations, as though the IETF Contribution were protected by 336 the same legal rights as other documents, and as though the 337 Contributor could be able to grant these rights. We ask for these 338 grants and representations only to the extent that the Contribution 339 may be protected. We believe they are necessary to protect the ISOC, 340 the IETF Trust, the IETF, the IETF Standards Process and all IETF 341 participants, and also because the IETF does not have the resources 342 or wherewithal to make any independent investigation as to the actual 343 proprietary status of any document submitted to it. 345 3.6. Copyright in RFCs. 346 As noted above, Contributors to the IETF (or their employers) retain 347 ownership of the copyright in their Contributions. This includes 348 Internet-Drafts and all other Contributions made within the IETF 349 Standards Process (e.g., via e-mail, oral comment and otherwise). 350 However, it is important that the IETF (through the IETF Trust) own 351 the copyright in documents that are published as RFCs (other than 352 Informational RFCs and RFCs that are submitted as RFC Editor 353 Contributions). Ownership of the copyright in an RFC does not 354 diminish the Contributors' rights in their underlying contributions, 355 but it does prevent anyone other than the IETF Trust (and its 356 licensees) from republishing or modifying an RFC in RFC format. In 357 this respect, Contributors are treated the same as anybody else: 358 though they may extract and republish their own Contributions without 359 limitation, they may not do so in the RFC format used by the IETF. 360 And while this principle (which is included in Section 5.9 below) may 361 appear to be new to the IETF, it actually reflects historical 362 practice and has been observed for many years through the inclusion 363 of an ISOC or IETF Trust copyright notice on all RFC documents since 364 the publication of RFC 2026. 366 4. Non-IETF documents 367 This document only relates to Contributions made as part of the IETF 368 Standards Process Other documents that are referred to as Internet- 369 Drafts and RFCs may be submitted to and published by the RFC Editor 370 independently of the IETF Standards Process. Such documents are not 371 covered by this document, unless the controlling entity for that 372 document stream, as described in [RFC 4844] chooses to apply these 373 rules. Non-IETF Contributions must be marked appropriately as 374 described in the Legend Instructions. See the RFC Editor web page 375 for information about the policies concerning rights in RFC Editor 376 Documents; for other document streams, the controlling entity must be 377 contacted. See Section 11 for a declaration from the IAB on this 378 matter. 380 5. Rights in Contributions 382 5.1. General Policy 383 By submission of a Contribution, each person actually submitting the 384 Contribution, and each named co-Contributor, is deemed to have read 385 and understood the rules and requirements set forth in this document. 387 Each Contributor is deemed, by the act of submitting a Contribution, 388 to enter into a legally-binding agreement to comply with the terms 389 and conditions set forth in this document. 391 The Contributor is further deemed to have agreed that he/she has 392 obtained the necessary permissions to enter into such an agreement 393 from any party that the Contributor reasonably and personally knows 394 may have rights in the Contribution, including, but not limited to, 395 the Contributor's sponsor or employer. 397 No further acknowledgement, signature or other action is required to 398 bind a Contributor to these terms and conditions. The operation of 399 the IETF and the work conducted by its many participants is dependent 400 on such agreement by each Contributor, and each IETF participant 401 expressly relies on the agreement of each Contributor to the terms 402 and conditions set forth in this document. 404 5.2. Confidentiality Obligations 405 No information or document that is subject to any requirement of 406 confidentiality or any restriction on its dissemination may be 407 submitted as a Contribution or otherwise considered in any part of 408 the IETF Standards Process, and there must be no assumption of any 409 confidentiality obligation with respect to any Contribution. Each 410 Contributor agrees that any statement in a Contribution, whether 411 generated automatically or otherwise, that states or implies that the 412 Contribution is confidential or subject to any privilege, can be 413 disregarded for all purposes, and will be of no force or effect. 415 5.3. Rights Granted by Contributors to the IETF Trust 416 To the extent that a Contribution or any portion thereof is protected 417 by copyright or other rights of authorship, the Contributor, and each 418 named co-Contributor grant a perpetual, irrevocable, non-exclusive, 419 royalty-free, world-wide, sublicensable right and license to the IETF 420 Trust under all such copyrights and other rights in the Contribution: 422 (A) to copy, publish, display, and distribute the Contribution, in 423 whole or in part, 424 (B) to prepare translations of the Contribution into languages other 425 than English, in whole or in part, and to copy, publish, display, 426 and distribute such translations or portions thereof, 427 (C) to modify or prepare derivative works (in addition to 428 translations) that are based on or incorporate all or part of the 429 Contribution, and to copy, publish, display, and distribute such 430 derivative works, or portions thereof unless explicitly disallowed 431 in the notices contained in a Contribution (in the form specified 432 by the Legend Instructions), and 433 (D) to reproduce any trademarks, service marks or trade names which 434 are included in the Contribution solely in connection with the 435 reproduction, distribution or publication of the Contribution and 436 derivative works thereof as permitted by this Section 5.3, 437 provided that when reproducing Contributions, trademark and 438 service mark identifiers used in the Contribution, including TM 439 and (R), will be preserved. 441 5.4. Sublicenses by the IETF Trust 442 The IETF Trust will sublicense the rights granted to it under Section 443 5.3 to all IETF participants for use within the IETF Standards 444 Process. This license is expressly granted under a license agreement 445 issued by the IETF Trust and must contain a pointer to the full IETF 446 Trust agreement. 448 In addition, the IETF Trust may grant additional sublicenses of the 449 licenses granted to it hereunder. In doing so, the IETF Trust will 450 comply with the guidance provided under RFC xxx [-outbound]. 452 5.5. No Patent License 453 The licenses granted in Section 5.3 shall not be deemed to grant any 454 right under any patent, patent application or other similar 455 intellectual property right disclosed by the Contributor under BCP 79 456 [BCP79] or otherwise. 458 5.6. Representations and Warranties 459 With respect to each Contribution, each Contributor represents that 460 to the best of his or her knowledge and ability: 462 a. The Contribution properly acknowledges all Contributors including 463 Indirect Contributors. 464 b. No information in the Contribution is confidential and the IETF, 465 IETF Trust, ISOC, and its affiliated organizations may freely 466 disclose any information in the Contribution. 467 c. There are no limits to the Contributor's ability to make the 468 grants, acknowledgments and agreements herein that are reasonably 469 and personally known to the Contributor. 470 d. The Contributor has not intentionally included in the Contribution 471 any material which is defamatory or untrue or which is illegal 472 under the laws of the jurisdiction in which the Contributor has 473 his or her principal place of business or residence. 474 e. All trademarks, trade names, service marks and other proprietary 475 names used in the Contribution that are reasonably and personally 476 known to the Contributor are clearly designated as such where 477 reasonable. 479 5.7. No Duty to Publish 480 The Contributor, and each named co-Contributor, acknowledges that the 481 IETF has no duty to publish or otherwise use or disseminate any 482 Contribution. The IETF reserves the right to withdraw or cease using 483 any Contribution that does not comply with the requirements of this 484 Section 5. 486 5.8. Trademarks 487 Contributors who claim trademark rights in terms used in their IETF 488 Contributions are requested to state specifically what conditions 489 apply to implementers of the technology relative to the use of such 490 trademarks. Such statements should be submitted in the same way as is 491 done for other intellectual property claims. (See [BCP79] Section 6.) 493 5.9. Copyright in RFCs 494 Subject to each Contributor's (or its sponsor's) ownership of its 495 underlying Contributions as described in Section 5.6(which ownership 496 is qualified by the irrevocable licenses granted under Section 5.3), 497 each Contributor hereby acknowledges that the copyright in any RFC in 498 which such Contribution is included, other than an RFC that is an RFC 499 Editor Contribution, shall be owned by the IETF Trust. Such 500 Contributor shall be deemed to assign to the IETF Trust such 501 Contributor's copyright interest in the collective work constituting 502 such RFC upon the submission of such RFC for publication, and 503 acknowledges that a copyright notice acknowledging the IETF Trust's 504 ownership of the copyright in such RFC will be included in the 505 published RFC. 507 5.10. Contributors retention of rights 508 Although Contributors provide specific rights to the IETF, it is not 509 intended that this should deprive them of their right to exploit 510 their Contributions. To underscore this principle, the IETF Trust is 511 directed to issue a license or assurance to Contributors which 512 confirms that they may each make use of their Contributions as 513 published in an RFC in any way they wish, subject only to the 514 restriction that no Contributor has the right to represent any 515 document as an RFC, or equivalent of an RFC, if it is not a full and 516 complete copy or translation of the published RFC. 518 6. Legends, Notices and Other Standardized Text in IETF Documents 519 The IETF requires that certain standardized text be reproduced 520 verbatim in certain IETF Documents (including copies, derivative 521 works and translations of IETF Documents). Some of this standardized 522 text may be mandatory (e.g., copyright notices and disclaimers that 523 must be included in all RFCs) and some may be optional (e.g., 524 limitations on the right to make derivative works). The text itself, 525 as well as the rules that explain when and how it must be used, are 526 contained in the Legend Instructions. The Legend Instructions may be 527 updated from time to time, and the version of the standardized text 528 that must be included in IETF Documents is that which was posted in 529 the Legend Instructions on the date of publication. 531 The IETF reserves the right to refuse to publish Contributions that 532 do not include the legends and notices required by the Legend 533 Instructions. 535 It is important to note that each Contributor grants the IETF Trust 536 rights pursuant to this document and the policies described herein. 537 The legends and notices included in certain written Contributions 538 such as Internet-Drafts do not themselves convey any rights. They 539 are simply included to inform the reader (whether or not part of the 540 IETF) about certain legal rights and limitations associated with such 541 documents. 543 It is also important to note that additional copyright notices are 544 not permitted in IETF Documents except in the case where such 545 document is the product of a joint development effort between the 546 IETF and another standards development organization or the document 547 is a republication of the work of another standards development 548 organization. Such exceptions must be approved on an individual 549 basis by the IAB. 551 IANA Considerations (RFC Editor - please remove this section when 552 publishing) 553 This document presents no issues that should be considered by the 554 IANA (this section is here to mollify the ID-nits checker) 556 7. Security Considerations 557 This memo relates to the IETF process, not any particular technology. 558 There are security considerations when adopting any technology, but 559 there are no known issues of security with IETF Contribution rights 560 policies. 562 8. References 564 8.1. Normative References 565 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 566 3", BCP 9, RFC 2026, October 1996. 567 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 568 the IETF Standards Process", BCP 11, RFC 2028, October 1996. 569 [BCP79] Bradner, S., Ed, "Intellectual Property Rights in IETF 570 Technology", BCP 79, RFC 3979, March 2005. 571 [RFC4371] Carpenter, B. and L. Lynch, "BCP 101 Update for IPR Trust", 572 RFC 4371, January 2006. 574 8.2. Informative References 575 [RFC3978] Bradner, S. Ed., "IETF Rights in Contributions", RFC 3978, 576 March 2005. 577 [RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF Trust", 578 RFC 4748, October 2006. 580 [RFC4844] Daigle, L. and IAB, "The RFC Series and RFC Editor", RFC 581 4844, July 2007 582 [-outgoing] Halpern, J., "Advice to the Trustees of the IETF Trust on 583 Rights to be Granted in IETF Documents", RFC XXXX, date. 584 [Berne Convention] "Berne Convention for the Protection of Literary 585 and Artistic Work", 586 http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html. 588 9. Acknowledgements 589 The editors would like to acknowledge the help of the IETF IPR 590 Working Group provided during the development of the document. 592 10. Changes since RFF 3978 593 This document represents a significant reorganization and rewording 594 of RFC 3978 along with a number of substantive changes. 596 The most basic change is to limit this document to the rights that a 597 Contributor grants to the IETF Trust when making a Contribution. All 598 sublicenses of rights for the use of IETF Documents must be provided 599 by the IETF Trust. (See Section 5.4.) 601 Material added from RFC 4748 that recognized the IETF Trust. 603 Most of the material relating to RFC-Editor documents has been 604 removed since the RFC-Editor maintains their own rules and processes 605 for RFC-Editor documents. Renamed these documents to "non-IETF 606 documents". Added section 11 from the IAB discussing this topic. 608 Changes in the definitions section include defining the terms 609 "Contribution", "Indirect Contributor", "Copyright", "IETF Trust", 610 and "Legend Instructions" as well as minor tweaks to some of the 611 other definitions. 613 The responsibility for the text of notices has been given to the IETF 614 Trust and removed from this document. (See Section 6.) 616 Clarified that Contributors enter into a legally binding contract 617 when they submit a Contribution. (See Section 5.1.) 619 The right to produce derivative works provided by the Contributor to 620 the IETF Trust is not limited to being within the IETF Standards 621 Process. 623 Made it clear that this document does not deal with patent licenses. 624 (See Section 5.5.) 626 Clarified the ownership of the Copyrights to IETF Documents. (See 627 Section 5.9.) 628 Clarified the rights retained by authors of IETF Contributions. (See 629 Section 5.10.) 631 11. Declaration from the IAB 632 The IAB discussed the IPR documents during its most recent call. It 633 unanimously decided that the IAB-stream is to be covered by the 634 incoming IPR document. It is our understanding that the iab-stream 635 documents IPR are then automatically covered by the outbound rights 636 that the IETF trust will establish based on the advice in 637 [-outbound]. 639 We also want to stress that for any change in the inbound rights for 640 streams other than the ietf- and iab-stream there needs to be a 641 stream dependent discussion and approval process as indicated in RFC 642 4844 "The RFC Series and RFC Editor" [RFC4844] section 4.2.3. 644 To that extent section 4 of the draft should explicitly mention that 645 the irtf-, the independent- and any possible future streams are not 646 covered by the draft. 648 For the IAB, 650 Olaf Kolkman 651 April 4, 2008 653 12. Editors' Addresses 654 Scott Bradner 655 Harvard University 656 29 Oxford St. 657 Cambridge MA, 02138 USA 658 Phone: +1 617 495 3864 659 EMail: sob@harvard.edu 661 Jorge L. Contreras 662 WilmerHale 663 1875 Pennsylvania Avenue NW 664 Washington, DC 20006 USA 665 Phone: +1 202 663 6872 666 Email: jorge.contreras@wilmerhale.com 668 Full Copyright Statement 669 Copyright (C) The IETF Trust (2008). 670 This document is subject to the rights, licenses and restrictions 671 contained in BCP 78, and except as set forth therein, the authors 672 retain all their rights. 674 This document and the information contained herein are provided on an 675 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 676 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 677 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 678 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 679 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 680 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 682 Intellectual Property 683 The IETF takes no position regarding the validity or scope of any 684 Intellectual Property Rights or other rights that might be claimed to 685 pertain to the implementation or use of the technology described in 686 this document or the extent to which any license under such rights 687 might or might not be available; nor does it represent that it has 688 made any independent effort to identify any such rights. Information 689 on the procedures with respect to rights in RFC documents can be 690 found in BCP 78 and BCP 79. Copies of IPR disclosures made to the 691 IETF Secretariat and any assurances of licenses to be made available, 692 or the result of an attempt made to obtain a general license or 693 permission for the use of such proprietary rights by implementers or 694 users of this specification can be obtained from the IETF on-line IPR 695 repository at http://www.ietf.org/ipr. The IETF invites any 696 interested party to bring to its attention any copyrights, patents or 697 patent applications, or other proprietary rights that may cover 698 technology that may be required to implement this standard. Please 699 address the information to the IETF at ietf-ipr@ietf.org. 701 Acknowledgement 702 Funding for the RFC Editor function is currently provided by the 703 Internet Society. 705 changes - to be removed before publication 706 version 01 ->02 707 misc grammar fixes 708 added BOF to sec 1(a) 709 added 1(l) 710 reorder 3.2 711 moved sentence about translations within sec 3.3 712 reorder 5.3 (C) 713 added section 5.10 714 removed "an Informational RFC" from section 5.9 715 added text about assigning rights and acknowledging that a 716 copyright notice will be added to section 5.9 717 added 2nd pp to section 3.6 from RFC 3978 718 added pp on multiple copyright notices to sec 6 720 version 02 ->03 721 replaced the text in section 5.10 723 version 03 -> 04 724 change "requested" to "directed" in section 5.10 725 add sections 1 & 2 to the list of normative sections in section 2 726 sec 5.7 - replace last sentence 727 sec 5.3 preface - add "sublicensable" 728 sec 1 i - add that the IETF Trust maintains the Legend 729 Instructions 730 open issues 731 a/ the use of the terms Contribution and Contributors - 732 for example in section 5.6 733 b/ do we need specific mention of work for hire in sec 3.2 735 version 04 -> 05 736 replaced section 5.1 & the 1st pp of section 5.3 737 replaced section 5.6 a 739 version 05 -> 06 - input from Jorge 740 fix various typos in document 741 add definition of "Indirect Contributor" 742 fix definition of "Reasonably and personally known" to be 743 copyright-related rather than patent-related 744 reword sec 5.6 a and remove definition of "Indirect Contributor" 745 add pointer to section 5.6 to section 5.9 746 tweak the wording on section 5.10 747 add "development" to the next to last sentence of section 6 749 version 06 -> 07 750 fix references etc to mollify the ID nits checker 752 version 07 -> 08 753 change "the IETF's RFC format" to "the RFC format used by the 754 IETF" in section 3.6 755 tweak definition of IETF Documents 756 change "[TRUST LICENSE AGREEMENT]" to "a license agreement issued 757 by the IETF Trust" and add a requirement that licenses must point 758 to the full trust agreement in section 5.4 759 added "changes from 3987" section 10 761 version 08 -> 09 - last call comments & IAB requests 762 fix punctuation and the lack of the word "the" in front of "IETF" 763 and "IETF Trust" in a number of places 764 clean up references to RFC 3979/BCP 79 765 add note to 1(f) 766 rename section 1(m) 767 replace section 4