idnits 2.17.1 draft-ietf-ipr-submission-rights-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 updates RFC2026, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 2003) is 7498 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: 'RFC 2028' is mentioned on line 87, but not defined ** Obsolete undefined reference: RFC 2028 (Obsoleted by RFC 9281) == Unused Reference: 'RFC 2418' is defined on line 766, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2518 (ref. 'RFC 2418') (Obsoleted by RFC 4918) == Outdated reference: A later version (-12) exists of draft-ietf-ipr-technology-rights-11 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 Editor 5 October 2003 7 IETF Rights in Contributions 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 33 The IETF policies about rights in Contributions to the IETF are 34 designed to ensure that such Contributions can be made available to 35 the IETF and Internet communities while permitting the authors to 36 retain as many rights as possible. This memo details the IETF 37 policies on rights in Contributions to the IETF. It also describes 38 the objectives that the policies are designed to meet. This memo 39 updates RFC 2026, and, with RFC XXXY, replaces Section 10 of RFC 40 2026. [note to RFC editor: replace XXXY with number of IETF IPR] 42 Copyright (C) The Internet Society. (2003) 44 Table of Contents 46 Status of this Memo ................................................1 47 Abstract ...........................................................1 48 1. Definitions ....................................................1 49 2. Introduction ...................................................1 50 3. Rights in IETF Contributions ...................................1 51 3.1 General Policy ..............................................1 52 3.2 Confidentiality Obligations .................................1 53 3.3 Granting of Rights and Permissions ..........................1 54 3.4 Representations and Warranties ..............................1 55 3.5 No Duty to Publish ..........................................1 56 3.6 Trademarks ..................................................1 57 4. Rights in RFC Editor Contributions ..............................1 58 4.1 Requirements from Section 3 ................................1 59 4.2 Granting of Rights and Permissions .........................1 60 5. Notices Required in IETF Documents .............................1 61 5.1 IPR Disclosure Acknowledgement ...............................1 62 5.2 Derivative Works Limitation ..................................1 63 5.3 Publication Limitation .......................................1 64 5.4 Copyright Notice .............................................1 65 5.5 Disclaimer ...................................................1 66 5.6 Exceptions ...................................................1 67 6. Notices and Rights Required in RFC Editor Contributions ........1 68 7. Exposition of why these procedures are the way they are ........1 69 7.1 Rights Granted in IETF Contributions .........................1 70 7.2 Rights to use Contributed Material ...........................1 71 7.3 Right to Produce Derivative Works ............................1 72 7.4 Rights to use Trademarks .....................................1 73 7.5 Who Does This Apply To? ......................................1 74 8. Contributions Not Subject to Copyright .........................1 75 9. Security Considerations ........................................1 76 10. References .....................................................1 77 10.1 Normative References ........................................1 78 10.1 Informative References ......................................1 79 11. Acknowledgements ...............................................1 80 12. Editor's Address ...............................................1 81 13. Full copyright statement .......................................1 83 1. Definitions 85 The following definitions are for terms used in the context of this 86 document. Other terms, including "IESG," "ISOC," "IAB" and "RFC 87 Editor," are defined in [RFC 2028]. 89 a. "IETF": In the context of this document, the IETF includes all 90 individuals who participate in meetings, working groups, mailing 91 lists, functions and other activities which are organized or 92 initiated by ISOC, the IESG or the IAB under the general 93 designation of the Internet Engineering Task Force or IETF, but 94 solely to the extent of such participation. 96 b. "IETF Standards Process": the activities undertaken by the IETF in 97 any of the settings described in 1(c) below. 99 c. "IETF Contribution": any submission to the IETF intended by the 100 Contributor for publication as all or part of an Internet-Draft or 101 RFC (except for RFC Editor Contributions described below) and any 102 statement made within the context of an IETF activity. Such 103 statements include oral statements in IETF sessions, as well as 104 written and electronic communications made at any time or place, 105 which are addressed to: 106 o the IETF plenary session, 107 o any IETF working group or portion thereof, 108 o the IESG, or any member thereof on behalf of the IESG, 109 o the IAB or any member thereof on behalf of the IAB, 110 o any IETF mailing list, including the IETF list itself, any 111 working group or design team list, or any other list 112 functioning under IETF auspices, 113 o the RFC Editor or the Internet-Drafts function (except for RFC 114 Editor Contributions described below). 116 Statements made outside of an IETF session, mailing list or other 117 function, that are clearly not intended to be input to an IETF 118 activity, group or function, are not IETF Contributions in the 119 context of this document. 121 d. "Internet-Draft": temporary documents used in the IETF and RFC 122 Editor processes. Internet-Drafts are posted on the IETF web site 123 by the IETF Secretariat and have a nominal maximum lifetime in the 124 Secretariat's public directory of 6 months, after which they are 125 removed. Note that Internet-Drafts are archived many places on 126 the Internet, and not all of these places remove expired Internet- 127 Drafts. Internet-Drafts that are under active consideration by 128 the IESG are not removed from the Secretariat's public directory 129 until that consideration is complete. In addition, the author of 130 an Internet-Draft can request that the lifetime in the 131 Secretariat's public directory be extended before the expiration. 133 e. "RFC": the basic publication series for the IETF. RFCs are 134 published by the RFC Editor and once published are never modified. 135 (See [RFC 2026] Section 2.1) 137 f. "RFC Editor Contribution": An Internet-Draft intended by the 138 Contributor to be submitted to the RFC Editor for publication as 139 an Informational or Experimental RFC but not intended to be part 140 of the IETF Standards Process. 142 g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor 143 Contributions. Note that under Section 3.3(a) the grant of rights 144 in regards to IETF Internet-Drafts as specified in this document 145 is perpetual and irrevocable and thus survives the Secretariat's 146 removal of an Internet-Draft from the public directory, except as 147 limited by Section 3.3(a)(C). (See [RFC 2026] Sections 2.2 and 8) 149 h. "IETF Documents": RFCs and Internet-Drafts except for Internet- 150 Drafts that are RFC Editor Contributions and the RFCs that are 151 published from them. 153 i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC 154 Editor Contributions and the RFCs that may be published from them. 156 j. "Contribution": IETF Contributions and RFC Editor Contributions 158 k. "Contributor": an individual submitting a Contribution 160 l. "Reasonably and personally known": means something an individual 161 knows personally or, because of the job the individual holds, 162 would reasonably be expected to know. This wording is used to 163 indicate that an organization cannot purposely keep an individual 164 in the dark about patents or patent applications just to avoid the 165 disclosure requirement. But this requirement should not be 166 interpreted as requiring the IETF Contributor or participant (or 167 his or her represented organization, if any) to perform a patent 168 search to find applicable IPR. 170 2. Introduction 172 Under the laws of most countries and current international treaties 173 (for example the "Berne Convention for the Protection of Literary and 174 Artistic Work" [Berne]), authors obtain numerous rights in the works 175 they produce automatically upon producing them. These rights include 176 copyrights, moral rights and other rights. In many cases, if the 177 author produces a work within the scope of his or her employment, 178 most of those rights are usually assigned to the employer, either by 179 operation of law or, in many cases, under contract. (The Berne 180 Convention names some rights as "inalienable", which means that the 181 author retains them in all cases.) 183 This document details the rights that the IETF requires in IETF 184 Contributions and rights the IETF, as publisher of Internet-Drafts, 185 requires in all such Drafts including RFC Editor Contributions. The 186 RFC Editor may also define additional rights required for RFC Editor 187 Contributions. 189 In order for works to be used within the IETF Standards Process or to 190 be published as Internet-Drafts, certain limited rights in all 191 Contributions must be granted to the IETF and Internet Society 192 (ISOC). In addition, Contributors must make representations to IETF 193 and ISOC regarding their ability to grant these rights. These 194 necessary rights and representations have until now been laid out in 195 Section 10 of [RFC 2026]. In the years since [RFC 2026] was published 196 there have been a number of times when the exact intent of Section 10 197 has been the subject of vigorous debate within the IETF community. 198 The aim of this document is to clarify various ambiguities in Section 199 10 of [RFC 2026] that led to these debates and to amplify the policy 200 in order to clarify what the IETF is currently doing. 202 Section 1 gives definitions used in describing these policies. 203 Sections 3, 4, 5 and 6 of this document address the rights in 204 Contributions previously covered by Section 10 of [RFC 2026] and the 205 "Note Well" explanatory text presented at many IETF activities. 206 Sections 7 and 8 then explain the rationale for these provisions, 207 including some of the clarifications that have become understood 208 since the adoption of [RFC 2026]. The rules and procedures set out 209 in this document are not intended to substantially modify or alter 210 the IETF's current policy toward Contributions. 212 A companion document [IETF IPR] will deal with rights in technologies 213 developed or specified as part of the IETF Standards Process. This 214 document is not intended to address those issues. 216 The rights addressed in this document fall into the following 217 categories: 219 o rights to make use of contributed material 220 o copyrights in IETF documents 221 o rights to produce derivative works 222 o rights to use trademarks 224 This document is not intended as legal advice. Readers are advised 225 to consult their own legal advisors if they would like a legal 226 interpretation of their rights or the rights of the IETF in any 227 Contributions they make. 229 3. Rights in IETF Contributions 231 The following are the rights the IETF requires in all IETF 232 Contributions: 234 3.1 General Policy 236 In all matters of copyright and document procedures, the intent is to 237 benefit the Internet community and the public at large, while 238 respecting the legitimate rights of others. 240 3.2 Confidentiality Obligations 242 No information or document that is subject to any requirement of 243 confidentiality or any restriction on its dissemination may be 244 submitted as a Contribution or otherwise considered in any part of 245 the IETF Standards Process, and there must be no assumption of any 246 confidentiality obligation with respect to any Contribution. Each 247 Contributor agrees that any statement in a Contribution, whether 248 generated automatically or otherwise, that states or implies that the 249 Contribution is confidential or subject to any privilege, can be 250 disregarded for all purposes, and will be of no force or effect. 252 3.3 Granting of Rights and Permissions 254 By submission of a Contribution, each person actually submitting the 255 Contribution, and each named co-Contributor, is deemed to agree to 256 the following terms and conditions, and to grant the following 257 rights, on his or her own behalf and on behalf of the organization 258 the Contributor represents or is sponsored by (if any) when 259 submitting the Contribution. 261 a. To the extent that a Contribution or any portion thereof is 262 protected by copyright and other rights of authorship, the 263 Contributor, and each named co-Contributor, and the organization 264 he or she represents or is sponsored by (if any) grant a 265 perpetual, irrevocable, non-exclusive, royalty-free, world-wide 266 right and license to the ISOC and the IETF under all intellectual 267 property rights in the Contribution: 269 (A) to copy, publish, display and distribute the Contribution as 270 part of the IETF Standards Process or in an Internet-Draft, 272 (B) to prepare or allow the preparation of translations of the 273 Contribution into languages other than English, 275 (C) unless explicitly disallowed in the notices contained in a 276 Contribution [as per Section 5.2 below], to prepare derivative 277 works (other than translations) that are based on or 278 incorporate all or part of the Contribution, or comment upon 279 it, within the IETF Standards Process. The license to such 280 derivative works not granting the ISOC and the IETF any more 281 rights than the license to the original Contribution, 283 (D) to reproduce any trademarks, service marks or trade names 284 which are included in the Contribution solely in connection 285 with the reproduction, distribution or publication of the 286 Contribution and derivative works thereof as permitted by this 287 paragraph. When reproducing Contributions, the IETF will 288 preserve trademark and service mark identifiers used by the 289 Contributor of the Contribution, including (TM) and (R) where 290 appropriate, and 292 (E) to extract, copy, publish, display, distribute, modify and 293 incorporate into other works, for any purpose (and not limited 294 to use within the IETF Standards Process) any executable code 295 or code fragments that are included in any IETF Document (such 296 as MIB and PIB modules), subject to the requirements of Section 297 5 (it also being understood that the licenses granted under 298 this paragraph (E) shall not be deemed to grant any right under 299 any patent, patent application or other similar intellectual 300 property right disclosed by the Contributor under [IETF IPR]). 302 b. The Contributor grants the IETF and ISOC permission to reference 303 the name(s) and address(es) of the Contributor(s) and of the 304 organization(s) s/he represents or is sponsored by (if any). 306 3.4 Representations and Warranties 308 With respect to each Contribution, each Contributor represents that 309 to the best of his or her knowledge and ability: 311 a. The Contribution properly acknowledges all major Contributors. A 312 major Contributor is any person who has materially or 313 substantially contributed to the IETF Contribution. 315 b. No information in the Contribution is confidential and the IETF, 316 ISOC, and its affiliated organizations may freely disclose any 317 information in the Contribution. 319 c. There are no limits to the Contributor's ability to make the 320 grants, acknowledgments and agreements herein that are reasonably 321 and personally known to the Contributor. 323 d. The Contributor has not intentionally included in the Contribution 324 any material which is defamatory or untrue or which is illegal 325 under the laws of the jurisdiction in which the Contributor has 326 his or her principal place of business or residence. 328 e. All trademarks, trade names, service marks and other proprietary 329 names used in the Contribution that are reasonably and personally 330 known to the Contributor are clearly designated as such where 331 reasonable. 333 3.5 No Duty to Publish 335 The Contributor, and each named co-Contributor, acknowledges that the 336 IETF has no duty to publish or otherwise use or disseminate any 337 Contribution. The IETF reserves the right to withdraw or cease using 338 any Contribution that does not comply with the requirements of 339 Section 3.4 and Section 3.3 or 4.2. 341 3.6 Trademarks 343 Contributors, and each named co-Contributor, who claim trademark 344 rights in terms used in their IETF Contributions are requested to 345 state specifically what conditions apply to implementers of the 346 technology relative to the use of such trademarks. Such statements 347 should be submitted in the same way as is done for other intellectual 348 property claims. (See [IETF IPR] Section 6.) 350 4. Rights in RFC Editor Contributions 352 The following are the rights the IETF, as the publisher of Internet- 353 Drafts, requires in all RFC Editor Contributions: 355 4.1 Requirements from Section 3 357 All RFC Editor Contributions must meet the requirements of Sections 358 3.1, 3.2, 3.4, 3.5 and 3.6. 360 4.2 Granting of Rights and Permissions 362 By submission of an RFC Editor Contribution, each person actually 363 submitting the RFC Editor Contribution, and each named co- 364 Contributor, is deemed to agree to the following terms and 365 conditions, and to grant the following rights, on his or her own 366 behalf and on behalf of the organization the Contributor represents 367 or is sponsored by (if any) when submitting the RFC Editor 368 Contribution. 370 a. To the extent that an RFC Editor Contribution or any portion 371 thereof is protected by copyright and other rights of authorship, 372 the Contributor, and each named co-Contributor, and the 373 organization he or she represents or is sponsored by (if any) 374 grant a non-exclusive, royalty-free, world-wide right and license 375 to the ISOC and the IETF under all intellectual property rights in 376 the RFC Editor Contribution for at least the life of the Internet- 377 Draft: 379 (A) to copy, publish, display and distribute the RFC Editor 380 Contribution as an Internet-Draft, 382 (B) unless explicitly disallowed in the notices contained in an 383 RFC Editor Contribution (as per Section 5.2 below), to prepare 384 derivative works (other than translations) that are based on or 385 incorporate all or part of the RFC Editor Contribution, or 386 comment upon it. The license to such derivative works not 387 granting the ISOC and the IETF any more rights than the license 388 to the original RFC Editor Contribution, and 390 (C) to reproduce any trademarks, service marks or trade names 391 which are included in the RFC Editor Contribution solely in 392 connection with the reproduction, distribution or publication 393 of the RFC Editor Contribution and derivative works thereof as 394 permitted by this paragraph. When reproducing RFC Editor 395 Contributions, the IETF will preserve trademark and service 396 mark identifiers used by the Contributor of the RFC Editor 397 Contribution, including (TM) and (R) where appropriate. 399 b. The Contributor grants the IETF and ISOC permission to reference 400 the name(s) and address(es) of the Contributor(s) and of the 401 organization(s) s/he represents or is sponsored by (if any). 403 5. Notices Required in IETF Documents 405 The IETF requires that certain notices and disclaimers described in 406 this Section 5 be reproduced verbatim in all IETF Documents 407 (including copies, derivative works and translations of IETF 408 Documents, but subject to the limited exceptions noted in Section 409 5.2). This requirement protects IETF and its participants from 410 liabilities connected with these documents. The copyright notice 411 also alerts readers that the document is an IETF Document, and that 412 ISOC claims copyright rights to certain aspects of the document, such 413 as its layout, the RFC numbering convention and the prefatory 414 language of the document. This legend is not intended to imply that 415 ISOC has obtained ownership of the IETF Contribution itself, which is 416 retained by the author(s) or remains in the public domain, as 417 applicable. 419 Each IETF Document must include the required notices described in 420 this Section 5. The required notices are the following: 422 a. The IPR Disclosure Acknowledgement described in Section 5.1 423 (required in all Internet-Drafts). 424 b. The Derivative Works Limitation described in Section 5.2 (for 425 specific IETF Documents only). 426 c. The Publication Limitation described in Section 5.3 (for specific 427 types of Internet-Drafts only). 428 d. The Copyright Notice described in Section 5.4 (for all IETF 429 Documents). 431 e. The Disclaimer described in Section 5.5 (for all IETF Documents). 433 5.1 IPR Disclosure Acknowledgement (required in all Internet-Drafts 434 only) 436 "By submitting this Internet-Draft, I certify that any applicable 437 patent or other IPR claims of which I am aware have been 438 disclosed, and any of which I become aware will be disclosed, in 439 accordance with RFC XXXY." 441 5.2 Derivative Works Limitation 443 If the Contributor desires to eliminate the IETF's right to make 444 modifications and derivative works of an IETF Contribution (other 445 than translations), one of the two the following notices may be 446 included in the Status of Memo section of an Internet-Draft and 447 included in a published RFC: 449 a. "This document may not be modified, and derivative works of it may 450 not be created, except to publish it as an RFC and to translate it 451 into languages other than English." 453 b. "This document may not be modified, and derivative works of it may 454 not be created." 456 In the cases of MIB or PIB modules and in other cases where the 457 Contribution includes material that is meant to be extracted in order 458 to be used, the following should be appended to statement 5.2 (a) or 459 5.2 (b): 461 "other than to extract section XX as-is for separate use." 463 Notice 5.2(a) is used if the Contributor intends for the IETF 464 Contribution to be published as an RFC. Notice 5.2(b) is used along 465 with the Publication Limitation in Section 5.3 when the Contributor 466 does not intend for the IETF Contribution to be published as an RFC. 468 These notices may not be used with any standards-track document or 469 with most working group documents, except as discussed in Section 7.3 470 below, since the IETF must retain change control over its documents 471 and the ability to augment, clarify and enhance the original IETF 472 Contribution in accordance with the IETF Standards Process. 474 Notice 5.2(a) may be appropriate when republishing standards produced 475 by other (non-IETF) standards organizations, industry consortia or 476 companies. These are typically published as Informational RFCs, and 477 do not require that change control be ceded to the IETF. Basically, 478 documents of this type convey information for the Internet community. 480 A fuller discussion of the rationale behind these requirements is 481 contained in Section 7.3 below. 483 5.3 Publication Limitation 485 If the Contributor only wants the IETF Contribution to be made 486 available in an Internet-Draft (i.e. does not want the IETF 487 Contribution to be published as an RFC) then the Contributor may 488 include the following notice in the Status of Memo section of the 489 Internet-Draft. 491 "This document may only be posted in an Internet-Draft." 493 This notice can be used on IETF Contributions that are intended to 494 provide background information to educate and to facilitate 495 discussions within IETF working groups but are not intended to be 496 published as an RFCs. 498 5.4 Copyright Notice (required for all IETF Documents) 500 (Normally placed at the end of the IETF Document.) 502 "Copyright (C) The Internet Society (year). This document is 503 subject to the rights, licenses and restrictions contained in RFC 504 XXXX and except as set forth therein, the authors retain all their 505 rights." 507 [note to the RFC Editor - XXXX above to be replaced with the number 508 of this document] 510 Additional copyright notices are not permitted in IETF Documents 511 except in the case where such document is the product of a joint 512 development effort between the IETF and another standards development 513 organization or the document is a republication of the work of 514 another standards organization. Such exceptions must be approved on 515 an individual basis by the IAB. 517 5.5 Disclaimer (required in all IETF Documents) 519 (Normally placed at the end of the IETF Document after the copyright 520 notice.) 522 "This document and the information contained herein are provided 523 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 524 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 525 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 526 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 527 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 528 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 529 PARTICULAR PURPOSE." 531 5.6 Exceptions 533 Notwithstanding the provisions of this Section 5, in certain limited 534 cases an abbreviated notice may be placed on certain types of 535 derivative works of IETF Documents in accordance with this Section 536 5.6. 538 a. in MIB modules, PIB modules and similar material commonly 539 extracted from IETF Documents, except for material that is being 540 placed under IANA maintenance, the following abbreviated notice 541 shall be included in the body of the material that will be 542 extracted in lieu of the notices otherwise required by Section 5: 544 "Copyright (C) The Internet Society . This version of 545 this MIB module is part of RFC XXXX; see the RFC itself for 546 full legal notices." 548 When the MIB or PIB module is the initial version of a module that 549 is to be maintained by the IANA, the following abbreviated notice 550 shall be included: 552 "Copyright (C) The Internet Society . The initial 553 version of this MIB module was published in RFC XXXX; for full 554 legal notices see the RFC itself or see: 555 http://www.ietf.org/copyrights/ianamib.html." 557 Substitute "PIB" for "MIB" in the statement for PIB modules. In 558 the case of MIB and PIB modules this statement should be placed in 559 the DESCRIPTION clause of the MODULE-IDENTITY macro. 561 Variations of these abbreviated notices are not permitted except 562 in cases where the material to be extracted is the product of a 563 joint development effort between the IETF and another standards 564 development organization or is a republication of the work of 565 another standards organization. Such variations must be approved 566 on an individual basis by the IAB. 568 [ note to RFC Editor - leave the "XXXX" in the above ] 570 b. short excerpts of IETF Documents presented in electronic help 571 systems, for example, the DESCRIPTION clauses for MIB variables, 572 do not need to include a copyright notice. 574 6. Notices and Rights Required in RFC Editor Contributions 576 Since the IETF acts as publisher of Internet Drafts, even for 577 Internet Drafts that are not intended to become part of the Standards 578 Process, the following are required in all such drafts to protect the 579 IETF and its processes. The RFC Editor may require additional 580 notices. 582 a. An IPR Disclosure Acknowledgement, identical to that specified in 583 Section 5.1. 585 b. One of the following two copyright release statements: 587 A. "By submitting this Internet-Draft, I accept the provisions of 588 Section 3 of RFC XXXX." 590 B. "By submitting this Internet-Draft, I accept the provisions of 591 Section 4 of RFC XXXX." 593 [note to RFC Editor - replace XXXX above with the number of this RFC] 595 7. Exposition of Why These Procedures Are the Way They Are 597 7.1 Rights Granted in IETF Contributions 599 The IETF/ISOC must obtain the right to publish an IETF Contribution 600 as an RFC or an Internet-Draft from the Contributors. 602 A primary objective of this policy is to obtain from the document 603 authors only the non-exclusive rights that are needed to develop and 604 publish IETF Documents and to use the IETF Contributions in the IETF 605 Standards Process while leaving all other rights with the authors. 607 The non-exclusive rights that the IETF needs are: 609 a. the right to publish the document 610 b. the right to let the document be freely reproduced in the formats 611 that the IETF publishes it in 612 c. the right to let third parties translate it into languages other 613 than English 614 d. except where explicitly excluded (see Section 5.2), the right to 615 make derivative works within the IETF process. 616 e. the right to let third parties extract some logical parts, for 617 example MIB modules 619 The authors retain all other rights, but cannot withdraw the above 620 rights from the IETF/ISOC. 622 7.2 Rights to use Contributed Material 624 Because, under the laws of most countries and applicable 625 international treaties, copyright rights come into existence whenever 626 a work of authorship is created (but see Section 8 below regarding 627 public domain documents), and IETF cannot make use of IETF 628 Contributions if it does not have sufficient rights with respect to 629 these copyright rights, it is important that the IETF receive 630 assurances from all Contributors that they have the authority to 631 grant the IETF the rights that they claim to grant. Without this 632 assurance, IETF and its participants would run a greater risk of 633 liability to the owners of these rights. 635 To this end, IETF asks Contributors to give the assurances in Section 636 3.4 above. These assurances are requested, however, only to the 637 extent of the Contributor's reasonable and personal knowledge. (See 638 Section 1(l)) 640 7.3 Right to Produce Derivative Works 642 The IETF needs to be able to evolve IETF Documents in response to 643 experience gained in the deployment of the technologies described in 644 such IETF Documents, to incorporate developments in research and to 645 react to changing conditions on the Internet and other IP networks. 646 In order to do this the IETF must be able to produce derivatives of 647 its documents; thus the IETF must obtain the right from Contributors 648 to produce derivative works. Note though that the IETF only requires 649 this right for the production of derivative works within the IETF 650 Standards Process. The IETF does not need, nor does it obtain, the 651 right to let derivative works be created outside of the IETF 652 Standards Process other than as noted in Section 3.3 (E). 654 The right to produce derivative works is required for all IETF 655 standards track documents and for most IETF non-standards track 656 documents. There are two exceptions to this requirement: documents 657 describing proprietary technologies and documents that are 658 republications of the work of other standards organizations. 660 The right to produce derivative works must be granted in order for an 661 IETF working group to accept an IETF Contribution as a working group 662 document or otherwise work on it. For non-working group IETF 663 Contributions where the Contributor requests publication as a 664 standards track RFC the right to produce derivative works must be 665 granted before the IESG will issue an IETF Last-Call and, for most 666 non-standards track non-working group IETF Contributions, before the 667 IESG will consider the Internet-Draft for publication. 669 Occasionally a Contributor may not want to grant publication rights 670 or the right to produce derivative works before finding out if an 671 IETF Contribution has been accepted for development in the IETF 672 Standards Process. In these cases the Contributor may include the 673 Derivative Works Limitation described in Section 5.2 and the 674 Publication Limitation described in Section 5.3 in their IETF 675 Contribution. A working group can discuss the Internet-Draft with the 676 aim to decide if it should become a working group document, even 677 though the right to produce derivative works or to publish the IETF 678 Contribution as an RFC has not yet been granted. If the IETF 679 Contribution is accepted for development the Contributor must then 680 resubmit the IETF Contribution without the limitation notices before 681 a working group can formally adopt the IETF Contribution as a working 682 group document. 684 The IETF has historically encouraged organizations to publish details 685 of their technologies, even when the technologies are proprietary, 686 because understanding how existing technology is being used helps 687 when developing new technology. But organizations that publish 688 information about proprietary technologies are frequently not willing 689 to have the IETF produce revisions of the technologies and then claim 690 that the IETF version is the "new version" of the organization's 691 technology. Organizations that feel this way can specify that an 692 IETF Contribution can be published with the other rights granted 693 under this document but may withhold the right to produce derivative 694 works other than translations. The right to produce translations is 695 required before any IETF Contribution can be published as an RFC to 696 ensure the widest possible distribution of the material in RFCs. 698 In addition, IETF Documents frequently make normative references to 699 standards or recommendations developed by other standards 700 organizations. Since the publications of some standards 701 organizations are not public documents, it can be quite helpful to 702 the IETF to republish, with the permission of the other standards 703 organization, some of these documents as RFCs so that the IETF 704 community can have open access to them to better understand what they 705 are referring to. In these cases the RFCs can be published without 706 the right for the IETF to produce derivative works. 708 In both of the above cases in which the production of derivative 709 works is excluded, the Contributor must include a special legend in 710 the IETF Contribution, as specified in Section 5.2, in order to 711 notify IETF participants about this restriction. 713 7.4 Rights to Use Trademarks 715 Contributors may wish to seek trademark or service mark protection on 716 any terms that are coined or used in their IETF Contributions. IETF 717 makes no judgment about the validity of any such trademark rights. 718 However, the IETF requires each Contributor, under the licenses 719 described in Section 3.3 above, to grant IETF a perpetual license to 720 use any such trademarks or service marks solely in exercising its 721 rights to reproduce, publish and modify the IETF Contribution. This 722 license does not authorize any IETF participant to use any trademark 723 or service mark in connection with any product or service offering, 724 but only in the context of IETF Documents and discussions. 726 7.5 Who Does This Apply To? 728 Rights and licenses granted to the IETF under this document are 729 granted to all individuals noted in Section 1(a), irrespective of 730 their employment or institutional affiliation. However, these 731 licenses do not extend broadly to the employers, sponsors or 732 institutions of such individuals, nor do they authorize the 733 individuals to exercise any rights outside the specific context of 734 the IETF Standards Process. 736 8. Contributions Not Subject to Copyright 738 Certain documents, including those produced by the U.S. government 739 and those which are in the public domain, may not be protected by the 740 same copyright and other legal rights as other documents. 741 Nevertheless, we ask each Contributor to grant to the IETF the same 742 rights as he or she would grant, and to make the same 743 representations, as though the IETF Contribution were protected by 744 the same legal rights as other documents, and as though the 745 Contributor could be able to grant these rights. We ask for these 746 grants and representations only to the extent that the Contribution 747 may be protected. We believe they are necessary to protect the ISOC, 748 the IETF, the IETF Standards Process and all IETF participants, and 749 also because the IETF does not have the resources or wherewithal to 750 make any independent investigation as to the actual proprietary 751 status of any document submitted to it. 753 9. Security Considerations 755 This memo relates to IETF process, not any particular technology. 756 There are security considerations when adopting any technology, but 757 there are no known issues of security with IETF Contribution rights 758 policies. 760 10. References 761 10.1 Normative references 763 [RFC 2026] Bradner, S.(ed), "The Internet Standards Process -- 764 Revision 3", RFC 2026, October 1996 766 [RFC 2418] Bradner, S. (ed), "Working Group Guidelines and 767 Procedures", RFC 2518, September 1998 769 [IETF IPR] Bradner, S. (ed), "Intellectual Property Rights in IETF 770 Technology", work in progress: draft-ietf-ipr-technology- 771 rights-11.txt 773 10.2 Informative references 775 [Berne] "Berne Convention for the Protection of Literary and Artistic 776 Work", http://www.wipo.int/treaties/ip/berne/index.html 778 11. Acknowledgements 780 The editor would like to acknowledge the help of the IETF ipr Working 781 Group and, in particular the help of Jorge Contreras of Hale and Dorr 782 for his careful legal reviews of this and other IETF IPR-related and 783 process documents. The editor would also like to acknowledge the 784 extensive help John Klensin provided during the development of the 785 document. 787 12. Editor's Address 789 Scott Bradner 790 Harvard University 791 29 Oxford St. 792 Cambridge MA, 02138 794 sob@harvard.edu 795 +1 617 495 3864 797 13. Full copyright statement 799 Copyright (C) The Internet Society (2003). Except as set forth 800 below, authors retain all their rights. 802 This document and translations of it may be copied and furnished to 803 others, and derivative works that comment on or otherwise explain it 804 or assist in its implementation may be prepared, copied, published 805 and distributed, in whole or in part, without restriction of any 806 kind, provided that the above copyright notice and this paragraph are 807 included on all such copies and derivative works. However, this 808 document itself may not be modified in any way, such as by removing 809 the copyright notice or references to the Internet Society or other 810 Internet organizations, except as needed for the purpose of 811 developing Internet standards in which case the procedures for rights 812 in submissions defined in the IETF Standards process must be 813 followed, or as required to translate it into languages other than 814 English. 816 The limited permissions granted above are perpetual and will not be 817 revoked by the Internet Society or its successors or assigns. 819 This document and the information contained herein is provided on an 820 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 821 REPRESENTS (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 822 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 823 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 824 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 825 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 827 14. change log 829 note to RFC Editor - remove this section before publication 831 ver 00 to ver 01 832 misc grammar changes throughout text 833 sec 2.2 - add note about automatic disclaimers 834 sec 2.3a - add "or is sponsored by" remove "unlimited" 835 sec 2.3 B - reword to 'of a scope no wider than the license" 836 sec 2.4a - add deff of major contributor 837 sec 2.6 - 2nd paragraph from sec 5.4 moved here 838 sec 3 - truncate heading 839 sec 3.1 5th pp - add OR IS SPONSORED BY 840 sec 3.1.2 - new section with copyright notice for use where 841 derivative works right are withheld 842 sec 3.2 - added usage guidelines for boilerplates 843 sec 4.1 - add "intended by the contributor" 844 sec 4.6 - add "actual" before lifetime 845 sec 4.8 - reword 846 sec 5.3 - insert "standards" in front of "process" last pp - 847 add "with permission" phrase after "republish" 848 sec 5.4 - change "we require" to "the IETF requires" 849 sec 7/a - add PIBs 850 sec 8 - redo security considerations 851 sec 9.1 - remove IPR ID as normative reference 852 sec 9.2 - add IPR ID as informative reference 853 sec 12 - add changes section 855 ver 01 to 02 856 abstract - add note about updating 2026 857 sec 3.2 - add patent pledge 859 ver 02 to 03 860 misc copy edits throughout document 861 sec 4 - "personally and reasonably known" - remove detail 863 ver 03 to 04 864 sec 4 - added note to the definition of Internet-Draft 866 ver 04 to 05 867 added ToC 868 moved definitions to front 869 change "Submissions" to "Contributions" 870 change MIBs & PIBs to "MIB modules" and "PIB modules" 871 fixes to make sure MIB & PIB modules etc could be extracted 872 misc grammar edits through out document 873 sec 1 - rearranged definitions split IETF and RFC Editor 874 Documents & Contributions changed "Contribution" in rest of 875 document to be consistent with new definitions - added 876 section XX and YY as part of this split 877 sec 3.3 - (a) (B) break out translations from other derivative 878 works add (a) (E) remove (b) as redundant 879 sec 5 - reorganized 881 ver 05 to 06 882 sec 5.6(a) - fix text 884 ver 06 to ver 07 885 misc typos 887 ver 07 to ver 8 888 IESG editorial tweaks