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