idnits 2.17.1 draft-ietf-ipr-wg-guidelines-03.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: ---------------------------------------------------------------------------- == 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 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 (April 22, 2003) is 7674 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) == Outdated reference: A later version (-12) exists of draft-ietf-ipr-technology-rights-04 == Outdated reference: A later version (-08) exists of draft-ietf-ipr-submission-rights-04 -- Obsolete informational reference (is this intentional?): RFC 1602 (ref. '5') (Obsoleted by RFC 2026) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPR Working Group S. Brim 3 Internet-Draft Cisco Systems, Inc. 4 Expires: October 21, 2003 April 22, 2003 6 Guidelines for Working Groups on Intellectual Property Issues 7 draft-ietf-ipr-wg-guidelines-03 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on October 21, 2003. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This memo lays out a conceptual framework and rules of thumb useful 38 for working groups dealing with IPR issues. It documents specific 39 examples of how IPR issues have been dealt with in the IETF. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 3 45 3. The Approach . . . . . . . . . . . . . . . . . . . . . . . . 4 46 4. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . 5 47 4.1 PPP CCP and ECP . . . . . . . . . . . . . . . . . . . . . . 5 48 4.2 IPS WG (IP Storage) . . . . . . . . . . . . . . . . . . . . 5 49 4.3 PEM and PKI issues . . . . . . . . . . . . . . . . . . . . . 6 50 4.4 CDI WG (Content Distribution Internetworking) . . . . . . . 7 51 4.5 VRRP (Virtual Router Redundancy Protocol) . . . . . . . . . 7 52 4.6 Secure Shell (SecSH) . . . . . . . . . . . . . . . . . . . . 8 53 4.7 IDN (Internationalized Domain Name) . . . . . . . . . . . . 8 54 5. General Principles . . . . . . . . . . . . . . . . . . . . . 9 55 5.1 Types of IPR . . . . . . . . . . . . . . . . . . . . . . . . 9 56 5.2 When to think about IPR . . . . . . . . . . . . . . . . . . 10 57 5.3 IPR as a Technology Evaluation Factor . . . . . . . . . . . 10 58 5.4 Patents versus Pending Patents Applied For . . . . . . . . . 11 59 5.5 Applicability: It's Hard to Prove a Negative . . . . . . . . 12 60 5.6 Licensing Terms . . . . . . . . . . . . . . . . . . . . . . 13 61 5.7 Third-Party Disclosure of IPR Claims . . . . . . . . . . . . 15 62 5.7.1 Third-Party Disclosure Advice . . . . . . . . . . . . . . . 15 63 6. Security Considerations . . . . . . . . . . . . . . . . . . 16 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 65 Normative References . . . . . . . . . . . . . . . . . . . . 16 66 Informative References . . . . . . . . . . . . . . . . . . . 17 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 68 Intellectual Property and Copyright Statements . . . . . . . 18 70 1. Introduction 72 This memo lays out a conceptual framework and rules of thumb to 73 assist working groups dealing with IPR issues. The goal is to 74 achieve a balance between the needs of IPR claimants and the 75 implementers of the Internet which is appropriate to current times. 76 As part of trying to distill out principles for dealing with IPR in 77 IETF working groups, it provides case studies of working group IPR 78 treatment. In other words, it documents the running code of the IETF 79 process. 81 This memo does not describe IPR procedures for document authors or 82 IPR claimants. Those are covered in two other memos, on IPR in the 83 IETF [3] and submission rights [4]. Rather, this memo is for working 84 groups that are trying to decide what to do about technology 85 contributions which have associated IPR claims. 87 2. The Problem 89 Traditionally the IETF has tried to avoid technologies which were 90 "protected" through IPR claims. However, compromises have been made 91 since before the IETF was born. The "common knowledge" of the IETF, 92 that IPR-impacted technology was anathema, has never recognized that 93 the Internet has run on IPR-impacted technologies from the beginning. 94 Nowadays the majority of the useful technologies brought to the IETF 95 have some sort of IPR claim associated with them. 97 It will always be better for the Internet to develop standards based 98 on technology which can be used without concern about selective or 99 costly licensing. However, increasingly, choosing a technology which 100 is not impacted by IPR over an alternative that is may produce a 101 weaker Internet. Sometimes there simply isn't any technology in an 102 area that is not IPR-impacted. It is not always the wrong decision to 103 select IPR-impacted technology, if the choice is made knowingly, 104 after considering the alternatives and taking the IPR issues into 105 account. 107 The IETF is not a membership organization. Other standards making 108 bodies may have membership agreements that member organizations must 109 sign and adhere to in order to participate. Membership agreements 110 may include strict procedures for dealing with IPR, or perhaps a 111 requirement that technology must be licensed royalty-free. This is 112 currently not possible in the IETF. 114 Even if the IETF had membership agreements, they would be difficult 115 to formulate in a way that covered IPR issues, because the IETF's 116 work includes technology from other sources and because the IETF 117 collaborates with organizations that work with different approaches 118 to intellectual property. The IETF can encounter four different IPR 119 situations, at almost any time during the life of a document: 121 o A document submitter notes their IPR claim regarding the contents 122 of the document. 124 o A non-submitter IETF participant claims that the contents of a 125 document are covered by their (or their represented 126 organization's) own IPR. 128 o An IETF participant notes IPR that is claimed by an individual or 129 organization with which neither an author of the document, nor the 130 participant noting the IPR, have an affiliation. 132 o An individual or organization that does not participate in the 133 IETF, but that monitors its activities, discovers that a document 134 intersects that individual's or organization's established or 135 pending intellectual property claims. It may come forward right 136 away, or wait and let the IETF work progress. 138 In working group activities, the IETF does not have detailed rules 139 for each situation. Working groups have essentially only one rule 140 they can invoke -- about individuals not participating in activities 141 related to a technology if they do not disclose known IPR. Beyond 142 that a working group can only make recommendations and requests. 144 Since every case is unique, and there are close to no general rules, 145 working groups need a great deal of freedom in dealing with IPR 146 issues. However, some amount of consistency is important so that 147 both contributors and users of eventual standards can know what to 148 expect. 150 3. The Approach 152 The goal of this memo is not to make rules. The goal is to give 153 working groups as much information as possible to make informed 154 decisions, and then step out of the way. The other IPR working group 155 memos [3][4] lay out what needs to be done once a particular piece of 156 technology is selected as a working group draft. However, this 157 doesn't help when a working group is trying to decide whether or not 158 to select a technology in the first place. This third memo is written 159 to help in making that decision. We want to build a conceptual 160 framework, a new set of "common knowledge", to make it easier for 161 working groups to deal with intellectual property issues. 163 To do so, we first present a number of "case studies" in Section 4 -- 164 real events that have happened in recent years, and how different 165 working groups dealt with them -- plus notes on possible lessons to 166 be learned. In Section 5, we expand on these lessons and try to 167 extract general principles. 169 4. Case Studies 171 The best way to know what works in dealing with IPR is to look at 172 past attempts to do so. The following are selected as cases from 173 which general lessons might be extracted. Other lessons might be 174 extracted from other cases, but the cases below cover all of the 175 important ones. 177 4.1 PPP CCP and ECP 179 The PPP Working Group adopted technology for PPP's Connection Control 180 Protocol and Encryption Control Protocol which it knew was patented. 181 They indicated to the IESG that they believed the patented technology 182 was the best approach, and was better than no standards at all. 184 At that time, under the policies documented in RFC 1602 [5] (the 185 precursor to RFC 2026), progress on any standard was to stop at the 186 Proposed Standard phase until specific assurances about licensing 187 terms could be obtained from all IPR claimants. However, as 188 described in RFC 1915 [1], in the case of PPP ECP and CCP, the IPR 189 claimant balked at the requirement for specific assurances. 191 Finally, with support from the working group, a variance was granted 192 to the RFC 1602 procedures. If it hadn't been granted, the ECP and 193 CCP standards could have been blocked permanently. 195 Lessons: 197 o IPR claimants, even when their intentions are good, may strongly 198 resist being forced to make specific public statements about 199 licensing terms. If explicit statements of licensing terms are 200 required, then the publicly stated terms will probably be 201 "worst-case", which would provide little useful information. 203 4.2 IPS WG (IP Storage) 205 The IPS (IP Storage) Working Group evaluated technology developed 206 outside of the working group, "secure remote password" (SRP, RFC 2945 207 [6]). At the time, there was one known IPR claim, and the proposed 208 licensing terms were apparently reasonable. SRP had become a 209 proposed standard without going through any working group, so IETF 210 participants may have been less likely to notice it in order to make 211 statements about IPR. In any case, two more possible IPR claims were 212 uncovered after the IPS working group had already decided to make SRP 213 required. One of the possible IPR claimants did not make a strong 214 IPR claim itself, and did not want to take the time to determine 215 whether it actually had a claim, though it acknowledged it might have 216 a claim. In both cases it was difficult to obtain concrete 217 information on possible licensing terms, even though words like 218 "reasonable" and "non-discriminatory" were used in the IPR 219 statements. Rumors of what they might be like did not sound good. 220 The working group participants took the claims, potential and 221 otherwise, very seriously, and decided not to use SRP after all, even 222 though they had already chosen it based on other criteria. 224 Lessons: 226 o IPR claims may appear at any time in the standards process. 228 o Take impreciseness seriously. Attempt to get clarification on 229 both IPR claims and licensing terms. 231 4.3 PEM and PKI issues 233 PEM (Privacy-Enhanced Mail) wanted to use public key technology. In 234 the mid-90s, the basic principles of public key infrastructure had 235 been patented for years. The patent holder had shown a tendency to 236 actively enforce its rights, and to prefer software sales to 237 licensing. This was seen as a significant potential issue, one which 238 could possibly interfere with the easy deployment of Internet 239 technology. However, there was no alternative technology that came 240 close to its capabilities. Adopting an alternative would have 241 damaged the standard's usefulness even more than adopting a 242 technology with IPR claims. The case was so compelling that the 243 working group participants decided to move forward on standardizing 244 it and even requiring it. 246 One factor which was noted was that the patents were mature, and 247 would expire within a few years. That meant that although the patents 248 might be significant to start with, they would not be in the long 249 run. This lowered the perceived risk of using the IPR-impacted 250 technology. 252 Lessons: 254 o IPR is just one issue in deciding whether to adopt a technology. 256 o IPR is not an all or nothing issue. There are different types and 257 levels of IPR protection. 259 o The IPR's lifecycle phase can be a consideration. 261 4.4 CDI WG (Content Distribution Internetworking) 263 The CDI (Content Distribution Internetworking) Working Group laid out 264 an overall architecture and found that a number of included 265 technologies had IPR claims associated with them, based on work done 266 before the working group was started. The working group participants 267 decided there was little chance of producing alternative technologies 268 which were as useful and which did not run up against these IPR 269 claims. As usual, there was no good way to evaluate claims and 270 possible licensing terms until after the technology had been 271 completely specified (at the earliest). 273 However, working group participants generally thought they had a good 274 idea what to expect from each other with regard to licensing, and in 275 fact expected few if any problems. The expected risks were low 276 enough that they thought the ultimate benefits of using the 277 technologies outweighed the expected burden of the IPR issues. The 278 working group participants decided they did not need to consider IPR 279 as an issue in determining which technologies to adopt. 281 Lessons: 283 o Past experience with patent claimants can be used as a significant 284 factor in evaluating the possible impact of IPR. It can lead to 285 enough mutual trust that concerns about licensing terms do not 286 slow the working group down. 288 4.5 VRRP (Virtual Router Redundancy Protocol) 290 The working group was standardizing VRRP based on a protocol 291 developed outside the IETF. The IPR claimant supported that protocol 292 and stated that it would license its IPR for that protocol if it 293 became the standard, but not for the similar protocol the working 294 group was developing. The working group participants decided to go 295 ahead and standardize the protocol developed in the working group 296 anyway. The IPR claimant has only claimed its patent when someone 297 else claimed a patent against it. There is no evidence that the 298 working group participants actually thought about the implications of 299 the IPR claim when it went ahead with its choice of protocol. 301 Lessons: 303 o IPR claims should never be disregarded without good cause. Due 304 diligence should be done to understand the consequences of each 305 claim. 307 4.6 Secure Shell (SecSH) 309 This is primarily an unfinished trademark issue, not a patent issue, 310 since the patent issue has been worked out outside of the IETF. The 311 holder of a trademark wants the IETF to stop using "SSH" in the names 312 and bodies of its proposed standards. The working group participants 313 have thought through the details of the claims, and possible 314 implications and risks, and decided to go ahead and continue using 315 the names as they are now. 317 Lessons: 319 o Working group participants can evaluate IPR claims not only for 320 their possible validity, but also for the risk of misjudging that 321 validity. The impact of honoring the IPR claim may be major or 322 minor. 324 4.7 IDN (Internationalized Domain Name) 326 The IDN working group dealt with a number of IPR claims. Several were 327 made which did not overlap with the technology -- the IPR claimants 328 said the patents were being announced just in case the working group 329 decided to go that way. In one case, even though a patent was 330 announced as purely defensive, many working group participants 331 investigated the claims themselves. They concluded that it did not 332 overlap. 334 In one case, an IPR claimant asserted that the working group's 335 documents, and in fact the IETF as a whole, were infringing on its 336 rights. Individual working group participants consulted with their 337 legal advisers, concluded that the claims would not overlap the 338 working group's developing technology, and decided that they need not 339 be concerned about the claims. This was reflected in the direction 340 the group as a whole decided to take. 342 In another case, patent claims were asserted that appeared to be 343 derived from WG discussion, rather than vice versa (or independent 344 discovery). The claimants were known to be following the WG's work 345 when the ideas were proposed, and their patent filing was 346 considerably subsequent to that time. 348 In 2000 the IDN working group discovered a patent that some 349 participants thought might apply to one of their main drafts. If it 350 did, it could affect their work profoundly -- to the extent that some 351 suggested that if they could not work out reasonable licensing terms 352 with the IPR claimant they might just disband. As a group and 353 individually, participants corresponded with IPR claimant in order to 354 get an explicit statement of licensing terms, preferably 355 royalty-free. By doing so they gained a better understanding of just 356 which WG activities were seen as infringing on the patent, and at 357 least some understanding of the IPR claimant's intentions and 358 philosophy. Since the patent holder seemed to have an interest in 359 using the patent for profit, the group discussed the issues on its 360 mailing list. They overtly talked about how they could change their 361 proposed technology to avoid having to contest the patent, and the 362 extent to which the patent might be countered by claims of prior art. 363 Meanwhile, individually they were talking to their legal advisors. 364 Gradually, a collective opinion formed that the working group 365 documents did not infringe on the patent. Since then, the patent has 366 been ignored. However, they are keeping a watchful eye out for 367 continuation patents which might have already been submitted. 369 Lessons: 371 o It's sometimes beneficial to push IPR claimants to find out what 372 they think their claims cover and what their licensing terms are. 374 o Possibilities of prior art should be considered. 376 o It's all right, and sometimes beneficial, to discuss IPR claims 377 and gather information about possible prior art on the group list. 378 The results of such discussion can be considered when deciding 379 whether to develop a technology (but remember that neither the 380 IETF nor any working group takes a stand on such claims as a body, 381 and the group is not the best place to get legal advice). 383 5. General Principles 385 Given the case studies above, there are a few principles that working 386 groups can start with in dealing with IPR. Of course every working 387 group needs to develop and follow its own consensus, and actual 388 treatments will vary as much as they have in the past. However, every 389 working group also needs to take IPR seriously, and follow these 390 general principles. 392 5.1 Types of IPR 394 A primer on the different types of IPR would be large, unreliable, 395 and redundant with other Working Group documents [2][3][4]. For 396 informal exploration, see those documents and other relevant sources 397 on the web. Readers with more serious concerns should consult their 398 legal advisors. In the United States, briefly: 400 o Trademarks indicate the sources of goods. Service marks indicate 401 the sources of services. They protect the use of particular marks 402 or similar marks. 404 o Copyrights protect the expressions of ideas (not the ideas 405 themselves), in almost any form, and allow "fair use". Copyrights 406 expire but they can be renewed. 408 o Patents protect "inventions". They expire (utility patents expire 409 after 20 years), but follow-on patents can cover similar 410 technologies and can have nearly the same implications for use in 411 the Internet as the original patents. 413 5.2 When to think about IPR 415 This memo does not describe IPR procedures for document authors or 416 IPR claimants. Rather, this memo is for working groups that are 417 trying to decide what to do about IPR claims related to their work. 418 A working group as a whole needs to think about IPR issues: 420 o when examining a technology, and deciding whether to initiate work 421 on it. 423 o when deciding whether to adopt a draft as a working group 424 document. 426 o when choosing between two or more working group drafts that use 427 different technologies. 429 o when deciding whether to depend on a technology developed outside 430 the working group. 432 o when comparing different kinds of IPR protection. 434 At each of these times, the working group is strongly encouraged to 435 solicit disclosure of IPR claims and licensing terms. A working 436 group's job will be a lot easier if IPR details are discovered early, 437 but it should realize that IPR claims may appear at any time. 438 Working groups should anticipate that an IPR claimant might choose 439 not to participate in the IETF, but instead to monitor from a 440 distance while the relevant technology is being discussed and 441 evaluated. Actual knowledge of IPR claims may therefore depend upon 442 when a claimant steps forward during the course of a WG's 443 deliberations. 445 5.3 IPR as a Technology Evaluation Factor 446 How do you weigh IPR claims against other issues when deciding 447 whether to adopt a technology? 449 The ultimate goal of the IETF is to promote the overall health, 450 robustness, flexibility and utility of the Internet infrastructure. 451 We base architectural decisions on our long-term extrapolations of 452 requirements by thinking in these terms. When considering a 453 particular technology, we compare it with other technologies not just 454 for its elegance of design in and of itself, but also for how it fits 455 in the bigger picture. This is done at multiple levels. It is 456 examined for how it fits into the overall design of the working 457 group's output, how it fits into the particular Internet 458 infrastructure area, how it fits with work going on in other areas, 459 and how it fits in the long view of the Internet architecture. 461 Similarly, when evaluating a technology, working group participants 462 consider IPR claims on it (including possible copyright issues with 463 text describing it). The issue is not whether a particular piece of 464 technology is IPR-impacted -- we use IPR-impacted technology every 465 minute. The question is how much the IPR protection will limit the 466 technology's usefulness in building a robust, highly useful Internet. 467 Thus, the only significant questions are: is the IPR claim relevant, 468 and if so what are the terms under which the technology can be used? 469 When technology is free from IPR protection the answer is easy. When 470 it is IPR-impacted, some terms make the IPR issues insignificant 471 compared to the engineering issues. Other terms can make a 472 technology unusable even if it is perfect otherwise. 474 The problem with IPR as a technology evaluation factor is that it is 475 unlikely that a working group, as an entity, can ever claim to have 476 reached consensus on most IPR issues. The IETF as a whole, and a 477 working group as a whole, takes no stance on the validity of any IPR 478 claim. It would be inappropriate for a working group chair to 479 declare that consensus had been reached that, for example, a 480 company's patent was invalid. Individual participants will need to 481 use whatever legal advice resources they have access to in order to 482 form their own individual opinions. Discussions about the validity 483 of IPR can take place under the auspices of the working group, in 484 particular about relative risks of technology choices. Individual 485 participants can take these discussions into account. The working 486 group as a body may not take a stance on validity, but it may make 487 choices based on perceived risk. 489 5.4 Patents versus Pending Patents Applied For 491 The IETF does not (cannot) expect IPR claimants to tell a working 492 group specifically how they think a particular patent applies. If a 493 patent has already been granted, the IETF can reasonably expect 494 disclosure of the patent number and possibly the relevant IETF 495 document sections, which will allow working group participants to 496 explore details of the claims. If a patent has not yet been granted 497 (or if knowledge of the patent is restricted, e.g. for security 498 reasons), significantly less information is available. In most 499 countries patent applications are published 18 months after they are 500 filed, but in the USA that can be avoided if the applicant does not 501 also file outside the USA. In some countries applications are a 502 matter of public record, but details of pending claims can be 503 modified at any time by the claim submitter before the patent is 504 granted. It is not known before then what rights will actually be 505 granted. Finally, rights can be contested in court, and nothing is 506 final until the courts decide -- perhaps not even then. All the IETF 507 can expect regarding a pending patent is disclosure that it exists, 508 the related IETF documents, and possibly the relevant IETF document 509 sections and some statement about licensing terms. 511 5.5 Applicability: It's Hard to Prove a Negative 513 Working group participants must make their own decisions about what 514 level of confidence they need as to whether IPR is applicable. 515 However, perfect knowledge is not a worthwhile goal. 517 In general, a working group should strive to find out about all IPR 518 claims related to technologies it is considering, and at least the 519 general facts about licensing terms for each case -- for example 520 whether the terms will be royalty-free, or perhaps "reasonable and 521 non-discriminatory". Working group participants should also 522 investigate possibilities of prior art which would counter the IPR 523 claims. However, even if the working group participants do 524 exhaustive searches, both externally and internally to their 525 employers, it is impossible to prove that a particular technology is 526 not covered by a particular IPR claim, let alone prove that it is not 527 covered by any IPR claim. Anything a working group adopts may, in 528 the future, turn out to be IPR-impacted, although the IPR claim may 529 not be discovered until years later. Claims are open to 530 interpretation even after rights are granted. Drafts can be very 531 fluid, even up to the time of last call, and IPR issues may 532 unknowingly be taken on at any time. Absolute certainty about IPR 533 claims is extremely rare. 535 However, the level of confidence needed to consider IPR when 536 evaluating a technology is often not hard to get to. There are cases 537 where risk is high (e.g. where licensing terms may be onerous) and 538 thus a high level of confidence about applicability is needed, but 539 history shows that most of the time "rough" confidence is good 540 enough. In any case, perfect confidence is usually impossible. 542 In all cases, licensing terms are a more significant consideration 543 than the validity of the IPR claims. licensing terms often do not 544 limit the usefulness of the technology. It is difficult to be sure 545 about the validity of IPR claims. If the licensing terms can be 546 determined to be reasonable, then the IPR claims become much less 547 important. 549 5.6 Licensing Terms 551 Licensing terms vary across a range from no license required at all 552 to prohibitive. In general, working groups show a preference for 553 technologies with IPR considerations in approximately the following 554 order. This list does not constitute a rule, and every working group 555 needs to take its own circumstances into account. 557 o IPR disclosed and licensed with no restrictions. 559 o IPR licensed with no material restrictions, e.g. no trademark 560 license required. 562 o IPR licensed for a particular field of use but with no other 563 material restrictions, e.g. licensed solely for implementations 564 complying with a standard. 566 o IPR licensed under royalty-free terms and reasonable and 567 non-discriminatory restrictions. 569 o IPR licensed under reasonable and non-discriminatory restrictions. 570 This may include payment of a royalty. 572 o IPR which is otherwise licensable. 574 o IPR which is not licensable, i.e. which is only available as an 575 implementation. 577 o IPR which is not available under any conditions. 579 Many IPR claimants do not like to publish specific terms under which 580 they will issue licenses. They may use standard terms for many 581 licensees, but they prefer to negotiate terms for some. Therefore, 582 do not expect any IPR disclosure statement to lay out detailed 583 blanket terms for licensing. 585 If an IPR disclosure statement lists only vague terms, that doesn't 586 mean the terms that will be offered in individual licenses will be 587 any worse than those offered in an IPR disclosure that makes very 588 specific statements. Obviously, if an IPR claimant refuses to suggest 589 any terms at all, the working group is going to have trouble 590 evaluating the future utility of the technology. 592 There is a class of restriction which involves "reciprocity", in 593 which the IPR claimant's patented technology may be used by an 594 implementer of the IETF standard ("licensee") as long as the licensee 595 allows the IPR claimant to use the licensee's own patented technology 596 covering the standard under comparable terms (this could be called 597 "bilateral" reciprocity). A "general" or "universal" reciprocity 598 restriction is also possible, under which the technology is made 599 available royalty-free as long as the licensee does not enforce any 600 IPR claims against the licenser. 602 Words such as "reasonable", "fair", and "non-discriminatory" have no 603 objective legal or financial definition. The actual licensing terms 604 can vary tremendously. Also, IPR claimants have occasionally 605 asserted that there were already sufficient licenses for a particular 606 technology to meet "reasonable" multisource and competitiveness 607 requirements and, hence, that refusing to grant any licenses to new 608 applicants was both fair and non-discriminatory. The best way to 609 find out what an IPR claimant really means by those terms is to ask, 610 explicitly. It also helps to gather knowledge about licenses actually 611 issued, for that technology or for others, and about other 612 experiences with the IPR claimant. 614 Despite the fact that IPR claimants often don't like to publish 615 explicit terms, there are levels of vagueness, and individuals and 616 even working groups can sometimes successfully push an IPR claimant 617 toward less vagueness. Many employers of IETF participants know that 618 that IETF prefers explicit terms, and do feel pressure to produce 619 them. 621 If working group participants are dissatisfied with the confidence 622 level they can obtain directly about licensing terms for a particular 623 technology, they can possibly extrapolate from history. In order for 624 licensed technology to become a draft standard, at least two 625 independent licenses need to have been issued. If the IPR claimant 626 for the technology the working group is considering has licensed 627 other technology in the past, there is a record of the sorts of terms 628 they are willing to grant, at least in those two specific cases. 629 This sort of thing is weak but everything counts, and it may be of 630 some help. 632 In many jurisdictions that issue patents, inventors are required to 633 file patent applications within 12 months of public disclosure or use 634 of a novel method or process. Since many of these jurisdictions also 635 provide for publication of pending patent applications 18 months 636 after a patent application is filed, the ability to determine whether 637 or not claims have been made at all relating to a particular 638 technology increases 30 months (12 + 18) after the public disclosure 639 or use of that technology. 641 5.7 Third-Party Disclosure of IPR Claims 643 Formal procedures for third-party disclosures are outlined in [3]. 644 However, anyone considering such a disclosure is encouraged to engage 645 in some preliminary exploration with the affected working group(s) 646 beforehand (see Section 5.7.1). third-party disclosure is a potential 647 denial of service threat to the working group, and therefore it is 648 good form to proceed slowly. 650 Working group participants should be aware that third-party 651 disclosure can be used, knowingly or unknowingly, to defocus and 652 distract the working group and hinder its progress. They should 653 evaluate 3rd party disclosures accordingly. WG chairs should be 654 willing and able to discipline those they think are using the 655 third-party disclosure system inappropriately. Those who think they 656 are being unfairly blocked may take the matter up with the Area 657 Directors and/or the IESG. 659 All of the criteria for evaluating IPR claims discussed in the 660 sections above apply in the case of third-party disclosures as well, 661 to the extent they can be practiced. 663 5.7.1 Third-Party Disclosure Advice 665 This subsection provides advice to those considering making 666 third-party disclosures. While not strictly required, the actions 667 described here are encouraged to aid working groups in dealing with 668 the possible implications of third-party disclosures. In evaluating 669 what (if anything) to do in response to a third-party disclosure, a 670 WG may consider the extent to which the discloser has followed this 671 advice (for example, in considering whether a disclosure is intended 672 primarily to defocus and distract the WG). 674 In general a potential discloser should exchange mail with the 675 working group chair(s) first, to open the way for discussion. Also, 676 if the potential discloser is not sure if the IPR claim applies, this 677 is the time to reach some kind of agreement with the working group 678 chair(s) before saying anything publicly. After discussion with the 679 working group chair(s), the potential discloser should bring the 680 issue to the attention of the working group, and to the attention of 681 the IPR claimant if doing so is not too difficult. Such discussion 682 should help the potential discloser to become more sure, one way or 683 the other. If the potential discloser is sure the discovered IPR 684 claim applies, and the IPR claimant does not submit a first party 685 disclosure itself, then the potential disclosure is encouraged to 686 submit a third-party disclosure. 688 Intellectual property often applies to more than one working group. 689 A person thinking of making a third-party disclosure should consider 690 what other working groups might be affected, and communicate with 691 them in the same manner. 693 Don't bring up IPR issues that are unrelated to the areas where the 694 WG is focusing at that time. Don't bring claims to the WG's 695 attention just in case it might go there in a few months, only if it 696 has implications for current work. Messages to the working group list 697 should be substantive, and a single message should focus on a 698 specific issue. They can reference multiple claims or patents 699 related to that issue. 701 6. Security Considerations 703 This memo relates to IETF process, not any particular technology. 704 There are security considerations when adopting any technology, 705 whether IPR claims are asserted against it or not. A working group 706 should take those security considerations into account as one part of 707 evaluating the technology, just as IPR is one part, but they are not 708 issues of security with IPR procedures. 710 7. Acknowledgments 712 The editor would like to acknowledge the help of the IETF IPR Working 713 Group. The editor would also like to thank the following for their 714 extensive comments and suggestions: Robert Barr, David Black, Scott 715 Bradner, Jorge Contreras, Paul Gleichauf, Keith Moore, Russell 716 Nelson, Jon Peterson, Randy Presuhn, Pekka Savola, Valerie See, Bob 717 Wyman, and Joe Zebarth. 719 Normative References 721 [1] Kastenholz, F., "Variance for The PPP Connection Control 722 Protocol and The PPP Encryption Control Protocol", BCP 3, RFC 723 1915, February 1996. 725 [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 726 9, RFC 2026, October 1996. 728 [3] Bradner, S., "Intellectual Property Rights in IETF Technology", 729 draft-ietf-ipr-technology-rights-04 (work in progress), April 730 2003. 732 [4] Bradner, S., "IETF Rights in Submissions", 733 draft-ietf-ipr-submission-rights-04 (work in progress), April 734 2003. 736 Informative References 738 [5] Huitema, C. and P. Gross, "The Internet Standards Process -- 739 Revision 2", RFC 1602, March 1994. 741 [6] Wu, T., "The SRP Authentication and Key Exchange System", RFC 742 2945, September 2000. 744 Author's Address 746 Scott Brim 747 Cisco Systems, Inc. 748 146 Honness Lane 749 Ithaca, NY 14850 750 USA 752 EMail: sbrim@cisco.com 754 Intellectual Property Statement 756 The IETF takes no position regarding the validity or scope of any 757 intellectual property or other rights that might be claimed to 758 pertain to the implementation or use of the technology described in 759 this document or the extent to which any license under such rights 760 might or might not be available; neither does it represent that it 761 has made any effort to identify any such rights. Information on the 762 IETF's procedures with respect to rights in standards-track and 763 standards-related documentation can be found in BCP-11. Copies of 764 claims of rights made available for publication and any assurances of 765 licenses to be made available, or the result of an attempt made to 766 obtain a general license or permission for the use of such 767 proprietary rights by implementors or users of this specification can 768 be obtained from the IETF Secretariat. 770 The IETF invites any interested party to bring to its attention any 771 copyrights, patents or patent applications, or other proprietary 772 rights which may cover technology that may be required to practice 773 this standard. Please address the information to the IETF Executive 774 Director. 776 Full Copyright Statement 778 Copyright (C) The Internet Society (2003). All Rights Reserved. 780 This document and translations of it may be copied and furnished to 781 others, and derivative works that comment on or otherwise explain it 782 or assist in its implementation may be prepared, copied, published 783 and distributed, in whole or in part, without restriction of any 784 kind, provided that the above copyright notice and this paragraph are 785 included on all such copies and derivative works. However, this 786 document itself may not be modified in any way, such as by removing 787 the copyright notice or references to the Internet Society or other 788 Internet organizations, except as needed for the purpose of 789 developing Internet standards in which case the procedures for 790 copyrights defined in the Internet Standards process must be 791 followed, or as required to translate it into languages other than 792 English. 794 The limited permissions granted above are perpetual and will not be 795 revoked by the Internet Society or its successors or assignees. 797 This document and the information contained herein is provided on an 798 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 799 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 800 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 801 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 802 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 804 Acknowledgement 806 Funding for the RFC Editor function is currently provided by the 807 Internet Society.