IPR S. Brim Internet-Draft Cisco Systems, Inc. Expires: April 25, 2003 October 25, 2002 Guidelines for Working Groups on Intellectual Property Issues draft-ietf-ipr-wg-guidelines-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with IPR issues. It documents specific examples of how IPR issues have been dealt with in the IETF. Brim Expires April 25, 2003 [Page 1] Internet-Draft WG IPR Guidelines October 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Approach . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 IPS WG (IP Storage) . . . . . . . . . . . . . . . . . . . . . 5 4.2 PEM and PKI issues . . . . . . . . . . . . . . . . . . . . . . 5 4.3 CDI WG (Content Distribution Internetworking) . . . . . . . . 6 4.4 VRRP (Virtual Router Redundancy Protocol) . . . . . . . . . . 7 4.5 Secure Shell (SecSH) . . . . . . . . . . . . . . . . . . . . . 7 4.6 IDN (Internationalized Domain Name) . . . . . . . . . . . . . 7 5. General Principles . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Types of IPR . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 When to think about IPR . . . . . . . . . . . . . . . . . . . 9 5.3 IPR as a Technology Evaluation Factor . . . . . . . . . . . . 10 5.4 Patents versus Pending Patents . . . . . . . . . . . . . . . . 11 5.5 Applicability: It's Hard to Prove a Negative . . . . . . . . . 11 5.6 No Universal License Terms . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 References (Non-Normative) . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 Brim Expires April 25, 2003 [Page 2] Internet-Draft WG IPR Guidelines October 2002 1. Introduction This memo lays out a conceptual framework and rules of thumb for working groups dealing with IPR issues. The goal is to achieve a balance between the needs of IPR holders and the implementers of the Internet which is appropriate to current times. As part of trying to distill out principles for dealing with IPR in IETF working groups, it provides case studies of treatments of IPR issues that have already been worked out. In other words, it documents the running code of the IETF process. This memo does not describe IPR procedures for document authors or IPR asserters. Those are covered in two other memos coming out of the IPR working group, on IPR in the IETF [5] and submitters' rights [6]. Rather, this memo is for working groups that are trying to decide what to do about IPR-protected technology contributions. 2. The Problem Traditionally the IETF has tried to avoid technologies which were "protected" through IPR assertions. However, compromises have been made since before the IETF was born. The "common knowledge" of the IETF, that IPR-protected technology was anathema, has never dealt with the fact that the Internet has run on IPR-protected technologies from the beginning. Nowadays the majority of the useful technologies brought to the IETF have some sort of IPR assertion associated with them. It will always be better for the Internet to develop standards based on technology which can be used without concern about selective or costly licensing. However, increasingly, choosing a technology which is not protected by IPR over an alternative that is may produce a weaker Internet. Sometimes there simply isn't any technology in an area that is not IPR-protected. It is not always the wrong choice to select IPR-protected technology, if the choice is made knowingly, after considering the alternatives and taking the IPR issues into account. The IETF is not a membership organization. Other standards making bodies may have membership agreements that member organizations must sign and adhere to in order to participate. Membership agreements may include strict procedures for dealing with IPR, or perhaps a requirement that technology must be licensed royalty-free. This is not possible in the IETF. Even if the IETF had membership agreements, they would be difficult to formulate in a way that covered IPR problems, because the IETF's work includes technology from other sources and because the IETF Brim Expires April 25, 2003 [Page 3] Internet-Draft WG IPR Guidelines October 2002 collaborates with organizations that work with different approaches to intellectual property. The IETF can encounter four different IPR situations, at almost any time during the life of a document: o A draft submitter notes its IPR claim regarding the contents of the draft. o An IETF participant asserts that the contents of a draft is covered by their own IPR. o IPR is noted, by the author of a draft or by a different IETF participant, that is claimed by an organization that does not participate in the IETF at all. o An organization that does not participate in the IETF, but that monitors its activities, discovers that a draft intersects that organization's established or pending intellectual property claims. It may come forward right away, or wait and let the IETF work progress. The IETF does not have detailed rules for each situation. The IETF does not force IPR-related behavior on anyone. It only sets criteria for a technology document becoming an Internet standard. Working groups have essentially only one rule they can invoke -- about individuals not participating in activities related to a technology if they do not disclose known IPR. Other than that a working group only has recommendations and requests. Since every case is unique, and there are close to no general rules, working groups need a great deal of freedom in dealing with IPR issues. However, some amount of consistency is important so that both contributors and users of eventual standards can know what to expect. 3. The Approach The organizing principle of this memo is to give working groups as much information as possible to make informed decisions, and then step out of the way. The other IPR working group memos (see the IPR Working Group charter page [1]) lay out what needs to be done once a particular piece of technology is selected as a working group draft. That doesn't help when a working group is trying to decide whether to select a technology or not in the first place. Thus this third memo. We want to build a conceptual framework, a new set of "common knowledge", to make it easier for working groups to deal with intellectual property issues. To do so, we first present "case studies" in Section 4 -- real events Brim Expires April 25, 2003 [Page 4] Internet-Draft WG IPR Guidelines October 2002 that have happened in recent years, and how different working groups dealt with them -- plus notes on possible lessons to be learned. In Section 5, we expand on these lessons to be learned and try to extract general principles. 4. Case Studies The best way to know what works is to look at past attempts at dealing with IPR. The following are selected as cases from which general lessons might be extracted. 4.1 IPS WG (IP Storage) The IPS Working Group evaluated technology developed outside of the working group, "secure remote password" (SRP, RFC2945 [4]). At the time, there was one known IPR assertion, and the proposed licensing terms were apparently reasonable. SRP had become a proposed standard without going through any working group, so IETF participants may have been less likely to notice it in order to make statements about IPR. In any case, two more possible IPR claims were uncovered after the IPS working group had already decided to make SRP required. One of the possible IPR holders did not make a strong IPR assertion itself, and did not want to take the time to determine whether it actually had a claim, though it acknowledged it might have a claim. Also, in both cases it was difficult to obtain information on possible licensing terms, even though words like reasonable and non- discriminatory were used in IPR statements, and rumors of what they might be did like not sound good. The working group participants took the assertions, potential and otherwise, very seriously, and decided not to use SRP after all, even though they had already chosen it based on other criteria. Lessons: o IPR assertions may appear at any time in the standards process. o Take impreciseness seriously. Attempt to get clarification on both IPR claims and licensing terms. 4.2 PEM and PKI issues PEM (Privacy-Enhanced Mail) wanted to use public key technology. In the mid-90s, the basic principles of public key infrastructure had been patented for years. The patent holder had shown a tendency to actively enforce its rights, and to prefer software sales to licensing. This was seen as a significant potential issue, one which could possibly interfere with the easy development of the Internet. Brim Expires April 25, 2003 [Page 5] Internet-Draft WG IPR Guidelines October 2002 However, there was no alternative technology that came close to its capabilities. Adopting an alternative would have damaged the Internet's health and flexibility even more than adopting a technology with IPR assertions. The case was so compelling that the working group participants decided to move forward on standardizing it and even requiring it. One factor which was noted was that the patents were mature, and would expire within a few years. That meant that although the impact might be significant to start with, it would not be in the long run. This lowered the perceived risk of using the IPR-protected technology. Lessons: o IPR is just one issue in deciding whether to adopt a technology. o IPR is not an all or nothing issue. There are different types and levels of IPR protection. o The IPR's lifecycle phase can be a consideration. 4.3 CDI WG (Content Distribution Internetworking) The CDI Working Group laid out an overall architecture and found that a number of included technologies had IPR claims associated with them, based on work done before the working group was started. The working group participants decided there was little chance of producing alternative technologies which were as useful and which did not run up against these IPR assertions. As usual, there was no good way to evaluate assertions and possible licensing terms until after the technology had been completely specified (at the earliest). Working group participants generally thought they had a good idea what to expect from each other, and that the ultimate benefits of using the technologies outweighed the IPR issues. The working group participants decided not to consider IPR as an issue at all in determining which technologies to adopt. Lessons: o Past experience can be used as a significant factor in evaluating the possible impact of IPR. Brim Expires April 25, 2003 [Page 6] Internet-Draft WG IPR Guidelines October 2002 4.4 VRRP (Virtual Router Redundancy Protocol) The working group was standardizing VRRP based on a protocol developed outside the IETF. The IPR holder supported that protocol and stated that it would license its IPR for that protocol if it became the standard, but not for the similar protocol the working group was developing. The working group participants decided to go ahead and standardize its protocol anyway. The IPR holder has only asserted its patent when someone else asserted a patent against it. There is no evidence that the working group participants actually thought about the implications of the IPR when it went ahead with its choice of protocol. Lessons: o IPR assertions should never be disregarded without good cause. Due diligence should be done to understand the consequences of each assertion. 4.5 Secure Shell (SecSH) This was primarily a trademark issue, not a patent issue, since the patent issue had been worked out outside of the IETF. The holder of a trademark wanted the IETF to stop using "SSH" in the names and text of its proposed standards. The working group participants thought through the details of the claims, and possible implications and risks, and decided to go ahead and continue using the names as they are now. This issue is still being worked through. Lessons: o Working group participants can evaluate IPR assertions not only for their possible validity, but also for the risk of misjudging that validity. The impact of honoring the IPR claim may be major or minor. 4.6 IDN (Internationalized Domain Name) The IDN working group dealt with a number of IPR assertions. Several were made which did not overlap with the technology -- the IPR asserters said the patents were being announced just in case the working group decided to go that way. In one case, even though a patent was announced as purely defensive, the working group participants investigated the claims themselves. They concluded that it did not overlap. Brim Expires April 25, 2003 [Page 7] Internet-Draft WG IPR Guidelines October 2002 In one case, an IPR claimer asserted that the working group's documents, and in fact the IETF as a whole, were infringing on its rights. Individual working group participants consulted with their legal advisers, concluded that the claims would not overlap the working group's developing technology, and decided to ignore the claims. This was reflected in the direction the group as a whole decided to take. In another case, patent claims were asserted that appeared to be derived from WG discussion and impact, rather than vice versa (or independent discovery). The claimants were known to be following the WG's work when the ideas were proposed, and their patent filing was considerably subsequent to that time. In 2000 the IDN working group discovered a patent that some participants thought might apply to one of their main drafts. If it did, it could affect their work profoundly -- to the extent that some suggested that if they could not work out reasonable licensing terms with the IPR holder they might just disband. As a group and individually, participants corresponded with IPR holder in order to get an explicit statement of licensing terms, preferably royalty- free. By doing so they gained a better understanding of just which WG activities were seen as infringing on the patent, and at least some understanding of the IPR holder's intentions and philosophy. Since the patent holder seemed to have an interest in using the patent for profit, the group discussed the issues on its mailing list. They overtly talked about how they could change their proposed technology to avoid having to contest the patent, and the extent to which the patent might be countered by claims of prior art. Meanwhile, individually they were talking to their legal advisors. Gradually, a collective opinion formed that the working group documents did not infringe on the patent. Since then, the patent has been ignored. However, they are keeping a watchful eye out for continuation patents which might have already been submitted. Lessons: o It's sometimes beneficial to push IPR claimants to find out what they think their claims cover and what their licensing terms are. o Possibilities of prior art should be considered. o It's all right, and sometimes beneficial, to discuss IPR claims and gather information about possible prior art on the group list (but remember that neither the IETF nor any working group takes a stand on such claims as a body, and the group is not the best place to get legal advice). Brim Expires April 25, 2003 [Page 8] Internet-Draft WG IPR Guidelines October 2002 o 5. General Principles Given the case studies above, here are a few principles that working groups can start with in dealing with IPR. Of course every working group needs to follow its own consensus, and actual treatments will vary as much as they have in the past. 5.1 Types of IPR A primer on the different types of IPR would be large, unreliable, and redundant with other Working Group documents [2][5][6]. For informal exploration, see those documents and other relevant sources on the web. Readers with more serious concerns should consult their legal advisors. In the United States, briefly: o Trademarks indicate the sources of goods. Servicemarks indicate the sources of services. They protect the use of particular marks or similar marks. o Copyrights protect the expressions of ideas (not the ideas themselves), in almost any form, and allow "fair use". Copyrights expire but they can be renewed. o Patents protect "inventions". They expire (utility patents expire after 20 years), but follow-on patents can cover similar technologies and can have nearly the same implications for use in the Internet as the original patents. 5.2 When to think about IPR This memo does not describe IPR procedures for document authors or IPR asserters. Rather, this memo is for working groups that are trying to decide what to do about IPR-protected technology contributions. A working group as a whole (as opposed to individual contributors or IPR holders) needs to think about IPR issues: o when examining a technology, and deciding whether to initiate work on it. o when deciding whether to adopt a draft as a working group document. o when choosing between two or more working group drafts that use different technologies. Brim Expires April 25, 2003 [Page 9] Internet-Draft WG IPR Guidelines October 2002 o when deciding whether to depend on a technology developed outside the working group. o when comparing different kinds of IPR protection. At each of these times, the working group should solicit disclosure of IPR assertions and licensing terms. A working group's job will be a lot easier if IPR details are discovered early, but it should realize that IPR assertions may appear at any time. An IPR holder which does not participate in the IETF may choose to wait, while the relevant technology is being discussed and evaluated, perhaps modifying its claims during this time. 5.3 IPR as a Technology Evaluation Factor How do you weigh IPR assertions against other issues when deciding whether to adopt a technology? The ultimate goal of the IETF is to promote the overall health, robustness, flexibility and utility of the Internet infrastructure. We base architectural decisions on our long-term extrapolations of requirements, by thinking in these terms. When considering a particular technology, we compare it with other technologies not just for its elegance of design in and of itself, but also for how it fits in the bigger picture. This is done at multiple levels. It is examined for how it fits into the overall design of the working group's output, how it fits into the particular Internet infrastructure area, how it fits with work going on in other areas, and how it fits in the long view of the Internet architecture. Similarly, when evaluating a technology, working group participants consider IPR claims on it (including possible copyright issues with text describing it). The issue is not whether a particular piece of technology is IPR-protected -- we use IPR-protected technology every minute. The question is how much the IPR protection will limit the technology's usefulness in building a robust, highly useful Internet. Thus, the only significant questions are: is the IPR claim relevant, and if so what are the terms under which the technology can be used? When technology is free from IPR protection the answer is easy. When it is IPR-protected, some terms make the IPR issues insignificant compared to the engineering issues. Other terms can make a technology unusable even if it is perfect otherwise. The problem with IPR as a technology evaluation factor is that it is unlikely that a working group, as an entity, can ever claim to have reached consensus on most IPR issues. The IETF as a whole, and a working group as a whole, takes no stance on the validity of any IPR claim. It would be inappropriate for a working group chair to Brim Expires April 25, 2003 [Page 10] Internet-Draft WG IPR Guidelines October 2002 declare that consensus had been reached that, for example, a company's patent was invalid. Individual participants will need to use whatever legal advice resources they have access to to form their own individual opinions, but discussions about the validity of IPR should not take place under the auspices of the working group. 5.4 Patents versus Pending Patents The IETF does not (cannot) expect IPR asserters to tell a working group specifically how they think a particular patent applies. If a patent has already been granted, the IETF can reasonably expect disclosure of the patent number, which will allow working group participants to explore details of the claims. If a patent has not yet been granted, significantly less information is available. In most countries patent applications are published 18 months after they are filed, but in the USA that can be avoided if the applicant does not also file outside the USA. Details of pending patent claims can be modified at any time by the claim submitter before the patent is granted. It is not known before then what rights will actually be granted. Finally, rights can be contested in court, and nothing is final until the courts decide. All the IETF can expect regarding a pending patent is disclosure that it exists and possibly some statement about licensing terms. 5.5 Applicability: It's Hard to Prove a Negative Working group participants need to make their own decisions about what level of confidence they need as to whether IPR is applicable. However, perfect knowledge is not a worthwhile goal. In general, a working group should strive to find out about all IPR claims related to technologies it is considering, and at least the general facts about licensing terms for each case -- for example whether the terms will be "reasonable and non-discriminatory". Working group participants should also investigate possibilities of prior art which would counter the IPR claims. However, even if the working group participants do exhaustive searches, both externally and internally to their employers, it is impossible to prove that a particular technology is not covered by a particular IPR claim, let alone proving that it is not covered by any IPR claim. Anything a working group adopts may, in the future, turn out to be IPR- protected, although the IPR assertion may not be discovered until years later. Claims are open to interpretation even after rights are granted. Drafts can be very fluid, even up to the time of last call, and IPR issues may unknowingly be taken on at any time. Absolute certainty about IPR claims is extremely rare. However, the level of confidence needed to consider IPR when Brim Expires April 25, 2003 [Page 11] Internet-Draft WG IPR Guidelines October 2002 evaluating a technology is often not hard to get to. There are cases where risk is high (e.g. where licensing terms may be onerous) and thus a high level of confidence about applicability is needed, but history shows that most of the time "rough" confidence is good enough. In any case, perfect confidence is usually impossible. 5.6 No Universal License Terms Licensing terms vary continuously across a range from prohibitive to no license at all. In general there are four classes of situation which will be encountered. o No license - licenses per se are not available. Local regulations, if any, apply. o Public domain - the technology is explicitly made available to all, without any IPR claims. o General "free" license - the technology is made available free of charge. There may be terms which specify conditions for use of the technology, for example regarding redistribution. There is a form of this license which invokes "reciprocity", in which the technology may be used as long as the licensee allows the IPR holder to use the licensee's technology in the same area under comparable terms. A requirement for general reciprocity is also possible, under which the technology is made available as long as the licensee does not enforce any IPR claims against the licenser. o "Reasonable and non-discriminatory" (RAND) terms - the license is granted based on some terms which may include reciprocity. The terms can vary tremendously. Even when IPR assertions do use words such as "reasonable", "fair", and "non-discriminatory", working groups should keep in mind that these words have no objective legal definition, at least not in this context. Many IPR holders do not like to publish explicit, specific terms under which they will issue licenses. They may use standard terms for many licensees, but they prefer to negotiate terms for some. Therefore, do not expect any IPR claim to lay out detailed blanket terms for licensing. Vaguer terms are not necessarily better or worse than more specific terms. If an IPR assertion lists only vague terms, that doesn't mean the terms that will be offered in individual licenses will be any worse than those offered in an IPR assertion that makes very specific statements. Obviously, if an IPR claimant refuses to suggest any terms at all, the working group is going to have trouble evaluating the future utility of the technology. Brim Expires April 25, 2003 [Page 12] Internet-Draft WG IPR Guidelines October 2002 Recall that words such as "reasonable", "fair", and "non- discriminatory" have no objective legal or financial definition. Also, IPR holders have occasionally asserted that there were already sufficient licenses for a particular technology to meet "reasonable" multisource and competitiveness requirements and, hence, that refusing to grant any licenses to new applicants was both fair and nondiscriminatory. The best way to find out what an IPR holder really means by those terms is to ask, explicitly. It also helps to gather knowledge about licenses actually issued, for that technology or for others, and about other experiences with the IPR holder. Despite the fact that IPR holders often don't like to publish explicit terms, there are levels of vagueness, and individuals and even working groups can sometimes successfully push an IPR holder toward less vagueness. The employers of IETF participants all know that that IETF prefers explicit terms, and do feel pressure to produce them. If working group participants are dissatisfied with the confidence level they can obtain directly about licensing terms for a particular technology, they can possibly extrapolate from history. As part of the standards process as described in RFC2026 [2], in order for licensed technology to become a draft standard, at least two independent licenses need to have been issued. If the IPR holder for the technology the working group is considering has licensed other technology in the past, there is a record of the sorts of terms they are willing to grant, at least in those two specific cases. This sort of thing is weak but if everything counts, it may be some indication. 6. Security Considerations This memo relates to IETF process, not any particular technology. There are security considerations when adopting any technology, whether IPR-protected or not. A working group should take those security considerations into account as one part of evaluating the technology, just as IPR is one part, but they are not issues of security with IPR procedures. There may be security issues with procedures for dealing with IPR, but they are not technical. They have more to do with unintentionally revealing corporate intellectual property through human activity than risking anything when using a protocol. References (Non-Normative) [1] IETF, "IPR Working Group web page", 2002, . Brim Expires April 25, 2003 [Page 13] Internet-Draft WG IPR Guidelines October 2002 [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000. [5] Bradner, S., "Intellectual Property Rights in IETF Technology", draft-bradner-ipr-technology-00 (work in progress), July 2002. [6] Bradner, S., "IETF Rights in Submissions", draft-bradner- submission-rights-00 (work in progress), June 2002. Author's Address Scott Brim Cisco Systems, Inc. 146 Honness Lane Ithaca, NY 14850 USA EMail: sbrim@cisco.com Brim Expires April 25, 2003 [Page 14] Internet-Draft WG IPR Guidelines October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Brim Expires April 25, 2003 [Page 15]