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