idnits 2.17.1 draft-bradner-ipr-technology-01.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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 514 has weird spacing: '...for the purpo...' -- 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 2002) is 7863 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 2026' is mentioned on line 434, but not defined == Missing Reference: 'RFC SUB' is mentioned on line 246, but not defined == Missing Reference: 'RFC 1988' is mentioned on line 305, but not defined == Unused Reference: '2026' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'RFC 1790' is defined on line 476, but no explicit reference was found in the text == Unused Reference: '1988' is defined on line 483, but no explicit reference was found in the text -- No information found for draft-iprwg-submission - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IETF SUB' Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 4 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 U. 4 Editor 5 October 2002 7 Intellectual Property Rights in IETF Technology 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 intellectual property rights (IPR), such as 34 patent rights, claimed relative to technologies developed in the IETF 35 are designed to ensure that IETF working groups and participants have 36 as complete information about any IPR constraints on a technical 37 proposal as possible. The policies are also intended to benefit the 38 Internet community and the public at large, while respecting the 39 legitimate rights of IPR holders. This memo details the IETF 40 policies concerning IPR related to technology worked on within the 41 IETF. It also describes the objectives that the policies are designed 42 to meet. 44 Portions Copyright (C) The Internet Society (2002) 46 1. Introduction 47 It is becoming increasingly common for IETF working groups to have to 48 deal with claims of intellectual property rights, such as patent 49 rights, with regards to technology under discussion in the working 50 group. These claims can come at any point in the IETF process from 51 before the first Internet Draft has been submitted to after a RFC has 52 been published and the working group has been closed down. The 53 claims can come from people submitting technical proposals as 54 Internet Drafts, on mailing lists or at meetings, from other people 55 participating in the working group or from 3rd parties who find out 56 that the work is going or has gone on. The claims can be based on 57 granted patents or on patent applications. In some cases IPR claims 58 can be disingenuous, made to affect the standards process rather than 59 to inform. 61 RFC 2026 section 10 established three basic principals regarding the 62 IETF dealing with claims of intellectual property rights: 64 a/ the IETF will make no determination about the validity of any 65 particular IPR claim 66 b/ the IETF can decide to use technology for which IPR claims have 67 been made if it decides that such a use is warranted 68 c/ in order for the working group and the rest of the IETF to have 69 the information needed to make an informed decision about the use 70 of a particular technology, all persons, with certain exceptions, 71 must disclose the existence of any IPR that they believe relates 72 to the working group deliberations in order to participate in any 73 discussions relating to the IPR. This includes copyrights, patents 74 and patent applications. 76 In the years since RFC 2026 was published there have been a number of 77 times when the exact intent of Section 10 has been the subject of 78 vigorous debate within the IETF community. The aim of this document 79 is to clarify various ambiguities in Section 10 of [RFC 2026] that 80 led to these debates and to amplify the policy in order to clarify 81 what the IETF is, or should be, doing. 83 Section 2, 3 and 4 of this document address the intellectual property 84 issues previously covered by Section 10 of RFC 2026. Sections 5 thru 85 13 then explain the rationale for these provisions, including some of 86 the clarifications that have been understood since the adoption of 87 RFC 2026. The rules and procedures set out in this document are not 88 intended to substantially modify or alter IETF's or ISOC's current 89 policy toward IPR in the context of the IETF standards process. 91 A companion document [IETF SUB] deals with rights in the documents 92 that are submitted to the IETF, including the right of IETF and its 93 participants to publish and create derivative works of those 94 documents. This document is not intended to address those issues. 96 This document is not intended as legal advice. If you would like a 97 legal interpretation of your rights or the rights of the IETF in any 98 contributions you make, you are advised to consult your own legal 99 advisor 101 2. Contributions in the IETF 103 2.1. General Policy 104 In all matters of intellectual property rights, the intent is to 105 benefit the Internet community and the public at large, while 106 respecting the legitimate rights of others. 108 2.2. Rights and Permissions 110 2.2.1. All Contributions 111 By submission of a contribution, each person actually submitting the 112 contribution is deemed to agree to the following terms and conditions 113 on their own behalf, on behalf of the organization (if any) the 114 contributor represents and on behalf of the owners of any 115 intellectual property rights claimed in the contribution. Where a 116 submission identifies contributors in addition to the contributor(s) 117 who provide the actual submission, the actual submitter(s) represent 118 that each other named contributor was made aware of and agreed to 119 accept the same terms and conditions on their own behalf, on behalf 120 of any organization s/he may represent and any known owner of any 121 intellectual property rights in the contribution. This agreement 122 must be acknowledged by including in the header of the contribution 123 one of the statements in section 3.2 of [IETF SUB]. 125 A. The contributor represents that he or she has disclosed the 126 existence of any intellectual property rights which cover or may 127 cover the technology, specifications or standards described in the 128 contribution that (1) are owned, controlled or enforceable by the 129 contributor or his or her employer, or any affiliate thereof, and 130 (2) are reasonably and personally known to the contributor. The 131 contributor does not represent that he or she personally knows of 132 all potentially pertinent intellectual property rights owned or 133 claimed by the his or her employer (if any) or by third parties. 135 B. The contributor represents that there are no limits to the 136 contributor's ability to make the grants acknowledgments and 137 agreements above that are reasonably and personally known to the 138 contributor. 140 3. IETF Actions 141 (A) When any intellectual property are known, or claimed, with 142 respect to any technology, specification, or standard described in 143 an IETF document , and such intellectual property rights are 144 brought to the attention of the IESG, the IESG shall not publish 145 the IETF document without including in the document a note 146 indicating the existence of such intellectual property rights, or 147 claimed intellectual property rights. Where implementations are 148 required before advancement of a standards track specification, 149 only implementations that have, by statement of the implementers, 150 taken such intellectual property rights into account shall be 151 considered for the purpose of showing the adequacy of the 152 specification. 154 (B) The IESG disclaims any responsibility for identifying the 155 existence of or for evaluating the applicability of any claimed 156 IPR to any IETF technology, specification or standard, and will 157 take no position on the validity or scope of any such intellectual 158 property rights. 160 (C) Where the IESG has been informed of claimed intellectual 161 property rights under (A), the IETF Executive Director shall 162 request from the claimant of such rights, a written assurance that 163 upon approval by the IESG of the relevant Internet standards track 164 specification(s), all persons will be able to obtain the right to 165 implement, use, distribute and exercise other rights with respect 166 to an Implementing Technology under openly specified, reasonable, 167 non-discriminatory terms unless such a statement has already been 168 submitted. The Working Group proposing the use of the technology 169 with respect to which the intellectual property rights are claimed 170 may assist the IETF Executive Director in this effort. The 171 results of this procedure shall not, in themselves, block 172 advancement of a specification along the standards track. A 173 working group may take into consideration the results of this 174 procedure in evaluating the technology and the IESG may defer 175 approval when a delay may facilitate obtaining such assurances. 176 The results will, however, be recorded by the IETF Executive 177 Director, and be made available. The IESG may also direct that a 178 summary of the results be placed on-line. 180 3.1 Determination of Reasonable and Non-discriminatory Terms 181 The IESG will not make any explicit determination that the assurance 182 of reasonable and non-discriminatory terms for the use of an 183 Implementing Technology has been fulfilled in practice. It will 184 instead use the normal requirements for the advancement of Internet 185 Standards to verify that the terms for use are reasonable. If the 186 two unrelated implementations of the specification that are required 187 to advance from Proposed Standard to Draft Standard have been 188 produced by different organizations or individuals or if the 189 "significant implementation and successful operational experience" 190 required to advance from Draft Standard to Standard has been achieved 191 the IESG will presume that the terms are reasonable and to some 192 degree, non- discriminatory. This presumption may be challenged at 193 any time, including during the Last-Call period by sending email to 194 the IESG. 196 4. Notices to be included in all contributions for publication 197 The following notices should be included in all submissions for 198 publication as an Internet Draft. 200 (A) Disclaimer of validity: 202 "The IETF takes no position regarding the validity or scope of any 203 intellectual property or other rights that might be claimed to 204 pertain to the implementation or use of the technology described 205 in this document or the extent to which any license under such 206 rights might or might not be available; nor does it represent that 207 it has made any independent effort to identify any such rights. 208 Information on the IETF's procedures with respect to rights in 209 standards-track and standards-related documentation can be found 210 in BCP-XX. 212 Copies of claims of rights made available for publication and any 213 assurances of licenses to be made available, or the result of an 214 attempt made to obtain a general license or permission for the use 215 of such proprietary rights by implementers or users of this 216 specification can be obtained from the IETF on-line IPR repository 217 at http://www.ietf.org/ipr or from the IETF Secretariat." 219 (B) The IETF encourages all interested parties to bring to its 220 attention, at the earliest possible time, the existence of any 221 intellectual property rights pertaining to Internet Standards. For 222 this purpose, each standards document shall include the following 223 invitation: 225 "The IETF invites any interested party to bring to its 226 attention any copyrights, patents or patent applications, or 227 other proprietary rights which may cover technology that may be 228 required to practice this standard. Please address the 229 information to the IETF Secretariat at iesg- 230 secretary@ietf.org." 232 (C) Where the IESG has been made aware at the time of publication of 233 intellectual property rights claimed with respect to an IETF 234 document, or the technology described or referenced therein, such 235 document shall contain the following notice: 237 "The IETF has been notified of intellectual property rights 238 claimed in regard to some or all of the specification contained 239 in this document. For more information consult the online list 240 of claimed rights at http://www.ietf.org/ipr." 242 5. Definitions 244 5.1 contribution: See [RFC SUB] section 4.1. 246 5.2 IETF document: See [RFC SUB] sec 4.4. 248 5.3 IPR or intellectual property rights: means any proprietary, 249 intellectual or industrial property rights, including, but not 250 limited to, patent, copyright, trade secret, design, utility model, 251 invention registration, database and data rights, whether such rights 252 arise from a registration or renewal thereof, or an application 253 therefore, in each case anywhere in the world. 255 5.4 Implementing Technology: means a technology which implements an 256 IETF specification or standard. 258 6. Disclosure 259 6.1 How to make a disclosure 260 Disclosure of IPR claims is made by sending an email message to iesg- 261 secretary@ietf.org. It is also a good idea to send a copy of the 262 disclosure to the mailing list of the relevant working group. 264 6.2 Contents of a disclosure 265 The disclosure must be as specific as possible both in the IPR claim 266 that is being made and as to the IETF contributions to which the 267 claim applies. The disclosure should list the registration numbers 268 of any patents and the file numbers of any patent applications which 269 instantiate the IPR claims being made. If the claim is based on 270 unpublished patent applications then that should be stated. The 271 disclosure should also list the specific IETF documents or activity 272 affected and what sections of those documents are affected. Note that 273 this requirement is not is not satisfied by including a blanket 274 statement of possible IPR on every submission since the aim of the 275 disclosure is to provide information about specific IPR claims 276 against specific IETF documents. IT is also not satisfied by a 277 blanket statement of willingness to license all IPR under fair and 278 non-discriminatory terms for the same reason. 280 6.3 Rights detailed in a disclosure 281 Since IPR disclosures will be used by IETF working groups during 282 their evaluation of alternative technical solutions it is desirable, 283 though not required, that an IPR disclosure include information about 284 licensing of the IPR in case implementation of the technology 285 described in the final RFC is judged to require a license. It should 286 be noted that disclosures without licensing statements are likely to 287 discourage a working group from adopting the technology. 289 The following are examples of licensing terms used in past 290 disclosures to the IETF. 292 a/ Free License: The IPR claimant will grant any applicant a non- 293 exclusive, worldwide, perpetual, irrevocable, royalty-free license 294 to make, use, sell, import and exercise all other rights with 295 respect to products or processes covered by the listed IPR. The 296 terms of this license are available for review on the IPR 297 claimant's web site. 299 b/ Restricted open license: The IPR claimant offers a Free License 300 to the IPR under certain constraints. Constraints that have been 301 seen in the past include a restriction of the free licenses to 302 only cover implementations of a specific IETF RFC or that limit 303 the Free Licenses to people or organizations who do not try to 304 limit the ability IPR claimant to implement the specific RFC 305 because of other IPR claims. See [RFC 1822] and [RFC 1988] for 306 examples. 308 c/ fair and non discriminatory terms: The IPR claimant offers to 309 license the technology under fair and non-discriminatory terms. 311 d/ a refusal to license: The IPR claimant will refuse to license the 312 technology. 314 Other licensing terms are possible, the above are included as 315 examples. 317 6.4 When is a disclosure required 318 Disclosures are required whenever enforcement of the claimed IPR in 319 question would directly or indirectly benefit the individual or their 320 employer or sponsor (if any) and where enforcement of the claimed IPR 321 would have any effect on the ability to implement a technology under 322 discussion in the IETF. 324 7. "reasonably and personally known" 325 The phrase "reasonably and personally known" is used in section two 326 above. It should be read to refer to something the individual knows 327 personally or, because of the job the individual holds, would 328 reasonably be expected to know. This wording is used to indicate 329 that an organization cannot purposely keep an individual in the dark 330 about patents or patent applications just to avoid the notification 331 requirement. But this requirement should not be interpreted as 332 requiring an organization to perform a patent search every time one 333 of its employees submits an Internet Draft. 335 8. Failure to provide notice 336 There are cases where individuals are not permitted by their 337 employers to disclose the existence or substance of patent 338 applications or other IPR. Since disclosure is required for anyone 339 submitting documents or participating in IETF discussions, a person 340 who does not disclose IPR for this, or any other reason, must not 341 participate in these IETF activities with respect to technologies 342 that he or she reasonably or personally knows to be covered by IPR 343 which he or she is not permitted to disclose. Participating in IETF 344 discussions about a technology without disclosing relevant IPR that 345 is reasonably or personally known to the individual is a violation of 346 IETF process. 348 9. The timing of providing notice 349 Timely notification of IPR claims is important because working groups 350 need to have as much information as it can while they are evaluating 351 alternative solutions. 353 9.1 IPR claimed in contributions to the IETF 354 If an author, contributor, or editor of a document being submitted 355 for publication as an Internet Draft knows of IPR related to the 356 technology covered by the submission, the author must submit an IPR 357 disclosure at the same time if there is not already such a disclosure 358 on file from the author or his or her employer or sponsor (if any) 359 which specifically covers the new submission. For example, if the 360 submission is an update to one for which an IPR disclosure has 361 already been made and the applicability of the disclosure is not 362 changed by the revision, then no new disclosure needs to be made. 363 But if the document is a new one or if the revision changes the 364 technology, specification or standard such that it would be covered 365 by new or different IPR claims then a disclosure must be made. A 366 disclosure should also be made if the revised contribution negates a 367 previous IPR claim. If the submitter learns of relevant IPR in their 368 organization, for example a new patent application, after the 369 submission he or she must make a disclosure as soon as possible after 370 learning of the IPR. 372 9.2. IPR claimed in contributions by others 373 If an active working group participant believes that IPR owned by the 374 participant or his or her employer or sponsor (if any) affects an 375 IETF contribution submitted by someone else (including already 376 published Internet Drafts or RFCs) then the participant must make an 377 IPR disclosure as soon as possible after the realization. 379 9.3. IPR known by a 3rd party 380 Under section 3(B) of this document 3rd parties that have information 381 about possible IPR related to IETF contributions are invited to 382 notify the IETF by sending an email message to iesg- 383 secretary@ietf.org. Such a notice should be sent as soon as possible 384 after the 3rd party realizes the connection. 386 10. Evaluating alternative technologies in an IETF working group 387 In general, it can be assumed that IETF working groups will prefer 388 technologies with no known IPR claims or, for technologies with 389 claims, an offer of free licensing. But IETF working groups have the 390 discretion to adopt technology with a commitment of fair and non- 391 discriminatory terms, or even with no licensing commitment, if they 392 feel that this technology is superior enough to alternatives with 393 fewer IPR claims or free licensing to outweigh the potential cost of 394 the licenses. 396 It should also be noted that the absence of IPR claims is not the 397 same thing as the knowledge that there will be no such claims in the 398 future. People or organizations not currently involved in the IETF 399 or organizations who discover IPR they feel to be relevant in their 400 patent portfolios can make IPR claims at any time. 402 It should also be noted that the validity and enforceability of any 403 IPR may be challenged for legitimate reasons, and the mere existence 404 of an IPR claim should not automatically be taken to mean that the 405 underlying IPR is valid and enforceable. Although the IETF can make 406 no actual determination of validity or applicability of any 407 particular IPR claim, it is reasonable that a working group will rely 408 on their own opinions of the applicability or validity of 409 intellectual property rights in their evaluation of alternative 410 technologies. 412 11. Change control for technologies 413 The IETF must have change control over the technology described in 414 any standards track documents in order to fix problems that may be 415 discovered or to produce other derivative works. Submissions to the 416 IETF in which the submitters do not grant change control to the IETF 417 must include the appropriate Internet Draft statement from [IETF SUB] 418 section 3.2. 420 In some cases the developer of a proprietary technology may decide to 421 hand over to the IETF the right to evolve the technology (a.k.a 422 "change control"). The implementation of an agreement between the 423 IETF and the developer of the technology can be complex. (See [RFC 424 1790] and [RFC 2339] for examples.) 426 Note that an IETF standards track document can make normative 427 reference to proprietary technology in some cases, for example, when 428 making parameter assignments or encapsulations. (e.g., "parameter 429 value 1234 refers to proprietary technology A" or "proprietary 430 technology B can be encapsulated using the techniques described in 431 RFC XYZ.") 433 12. Licensing requirements to advance standards track documents 434 [RFC 2026] section 4.1.2 states: "If patented or otherwise controlled 435 technology is required for implementation, the separate 436 implementations must also have resulted from separate exercise of the 437 licensing process." A key word in this text is "required." The mere 438 existence of an IPR claim does not necessarily mean that licenses are 439 actually required in order to implement the technology. Section 440 3.3.3 of this document should be taken to cover the case where there 441 are multiple implementations and but none of the implementers have 442 felt that they needed to license the technology and there have are no 443 indications that the IPR claimant will try to enforce its claim. 445 13. Mention of IPR claims in IETF documents 446 Submissions to the IETF where there are known IPR claims must include 447 the appropriate text from section 4 above. They should not contain 448 any mention of specific claims. All specific IPR claims must be 449 submitted as described in section 6. Specific IPR claims should not 450 be in the affected documents because the reader can be mislead. The 451 inclusion of a particular IPR claim in an IETF document could be 452 interpreted to mean that the IETF has formed an opinion on the 453 validity of the IPR claim. The reader could also be mislead to think 454 that the included IPR claims are the only IPR claims the IETF has 455 received concerning the document. Readers should always refer to the 456 on-line web page to get a full list of IPR claims received by the 457 IETF. 459 14 Security Considerations 461 Documents describing IETF processes, such as this one, do not have an 462 impact on the security of the network infrastructure or of Internet 463 applications. 465 15. References 467 15.1 Normative references 469 [2026] Bradner, S. (ed), "The Internet Standards Process -- Revision 470 3", RFC 2026, October 1996 472 [IETF SUB] work in progress: draft-iprwg-submission-00.txt 474 15.2 Informative references 476 [RFC 1790] Cerf, V., "An Agreement between the Internet Society and 477 Sun Microsystems, Inc. in the Matter of ONC RPC and XDR 478 Protocols", RFC 1790, April 1995 480 [RFC 1822] Lowe, J., "A Grant of Rights to Use a Specific IBM patent 481 with Photuris", RFC 1822, August 1995 483 [1988] McAnally, G., D. Gilbert, J. Flick, "Conditional Grant of 484 Rights to Specific Hewlett-Packard Patents In Conjunction With the 485 Internet Engineering Task Force's Internet-Standard Network 486 Management Framework", RFC 1988, August 1996 488 [RFC 2339] The Internet Society, Sun Microsystems, "An Agreement 489 Between the Internet Society, the IETF, and Sun Microsystems, Inc. 490 in the matter of NFS V.4 Protocols" 492 16. Editors Address 494 Scott Bradner 495 Harvard University 496 29 Oxford St. 497 Cambridge MA, 02138 499 sob@harvard.edu +1 617 495 3864 501 17. Full copyright statement: 503 Copyright (C) The Internet Society (2002). Except as set forth 504 below, authors retain all their rights. 506 This document and translations of it may be copied and furnished to 507 others, and derivative works that comment on or otherwise explain it 508 or assist in its implementation may be prepared, copied, published 509 and distributed, in whole or in part, without restriction of any 510 kind, provided that the above copyright notice and this paragraph are 511 included on all such copies and derivative works. However, this 512 document itself may not be modified in any way, such as by removing 513 the copyright notice or references to the Internet Society or other 514 Internet organizations, except as needed for the purpose of 515 developing Internet standards in which case the procedures for rights 516 in submissions defined in the Internet Standards process must be 517 followed, or as required to translate it into languages other than 518 English. 520 The limited permissions granted above are perpetual and will not be 521 revoked by the Internet Society or its successors or assigns. 523 This document and the information contained herein is provided on an 524 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 525 REPRESENTS (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 526 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 527 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 528 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 529 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.