EGYEDI LAYOUT

5 downloads 2822 Views 84KB Size Report
used as an illustration throughout this article, the first box briefly ..... Java name and Java Compatibility logo, which had business value. During ..... started creating Java development tools and a Java runtime environment in a manner that ...
STANDARDS AND INNOVATION IN TELECOMMUNICATIONS AND INFORMATION TECHNOLOGY

IPR Paralysis in Standardization: Is Regulatory Symmetry Desirable? Tineke M. Egyedi, Delft University of Technology

ABSTRACT Fear of legal claims on intellectual property rights (IPRs) sometimes paralyzes standards processes. IPR procedures of standards bodies address such problems. However, by default unresolved problems will be addressed by the legal regime. The process of Java‘ standardization, which is a red thread in this article, well illustrates what may happen. In case of conflict between IPRs and compatibility interests, the legal regime is such that mostly IPR interests preside. Should we strive for more symmetry between IPRs and compatibility interests? The usual rationale for IPR regulation is that it stimulates innovation. I argue that the public is equally served by compatibility. I analyze to what degree the public interest in compatibility is institutionalized in European, United States, and international regulation and end with questions that are meant to fuel policy debate.

INTRODUCTION

This article is based on research for which the European Commission and Verdonck Holding B.V. graciously provided extra funding. They need not agree with and are in no way responsible for the views expressed here.

108

The difficulty of developing standards for information and communication technology (ICT) where companies claim intellectual property rights (IPRs) has been well documented. Cases include the development of the standard for Global System for Mobile Communications (GSM) in the European Telecommunications Standards Institute (ETSI) [1], the third-generation International Mobile Telecommunications (IMT) 2000 standards series in the International Telecommunication Union (ITU) [2], and formalization of Sun Microsystems’ Java de facto standard in ECMA, an international industry association for standardizing information and communication systems [3]. All three examples concern key areas in ICT, where the economic stakes are high and the possible impact on future networking is significant. Sometimes IPR problems can be solved. In the case of GSM, the main problems were overcome by cross-licensing Motorola’s essential IPRs with essential and

0163-6804/01/$10.00 © 2001 IEEE

nonessential IPRs of other companies. In the case of IMT 2000, the conflict between Qualcomm and Ericsson was solved by giving each other access to patents and Ericsson’s takeover of Qualcomm’s unprofitable production unit for mobile code-division multiple access (CDMA) devices. But in the case of Java, the standards process was disbanded. Sun withdrew because its copyright on the Java specifications was not properly safeguarded by ECMA’s IPR rules, according to Sun. Because the Java case will be used as an illustration throughout this article, the first box briefly indicates what was at stake.

PUBLIC INTEREST: IPRS AND INNOVATION In these and other cases, the main problem is how to strike the right balance between interests of compatibility and IPR interests. (The term compatibility refers here to interoperability; or, more precisely, to “the suitability of products, processes or services for use together under specific conditions to fulfil relevant requirements without causing unacceptable interactions,” according to the ISO/IEC Guide 2 of 1991. For practical reasons, I restrict the discussion of IPR interests to patents and copyrights, although in the Java case Sun’s trademarks are also important.) Both concern a mix of public and company interests. Focusing on the public interest, the rationale for IP law is that it stimulates researchers and inventors to put intellectual property in the public domain [5] and thereby encourages innovation. Researchers from the Massachusetts Institute of Technology therefore use intellectual property as a direct index for innovation [6]. Revenues from R&D needs to be protected by IPR law to safeguard R&D investments. Society at large benefits from the innovations that result from these investments; so the reasoning goes. Although the assumed relationship is disputable and lacks clear evidence [7], sometimes IPRs may work out that way. But IPRs are not a

IEEE Communications Magazine • April 2001

prerequisite for innovation, as proponents of the open source movement would argue. Moreover, IPRs may also paralyze technology development. Increasingly, large ICT companies are settling market disputes in lawsuits. The latter are often based on intellectual property claims. In March 1999, for example, Xerox and Hewlett-Packard were involved in six lawsuits on patent infringement. Although potential IPR infringement seems to be part of strategic risk taking among multinationals, there is also some fear of inadvertent IPR infringement. For example, during standardization of Java, an ECMA committee member hesitated whether he should distribute certain information because having knowledge of it might work against the participating companies in a possible lawsuit. At stake was knowledge of the Java source code. Related, Hewlett-Packard had earlier cloned Sun’s Java Compatibility Kit tests in order to test its own “clean-room” version of Java (i.e., a version that avoids using Java source code to circumvent Sun’s IPRs). Any sign of having previous knowledge of the code could imply copyright infringement. Moreover, under Sun’s Community Source license any developer could look at the source code, which made cloning of Java an even touchier business from the legal standpoint. Thus, to a certain degree fear of IPR infringement stilted the standardization and diffusion of Java technology.

PROBLEM: REGULATORY ASYMMETRY? Let us, for the sake of argument, accept the legal rationale that underlies IPRs. Then, like IPRs, compatibility could also be argued to benefit technology development. Compatibility leads to network and other externalities, which spur innovation. Examples are GSM and IMT 2000. They illustrate how ex ante standardization may open new markets. And, if ECMA technical committee 41 had met its aim to “develop a standard for a cross-platform computing environment based upon the Java 2‘ Standard Edition (J2SE) Version 1.2.2 specification,” platform-independent computing — and the reallocation of R&D resources — could have been one step nearer. In other words, there is a clear public interest involved in achieving compatibility, an interest that is closely tied to technology innovation. Since a similar innovation rationale applies to IPR and compatibility, in this respect one would expect a similar judicial framework. However, are they similar? Of interest are which ideas underlie intellectual property protection in law and standards procedures, whether compatibility aims have a law-based status, and how current political developments address innovative technology development in relation to IPR and compatibility.

JURIDIFICATION OF THE STANDARDS REGIME Before continuing, the term regime refers to the way an actor network or an organization governs a particular field of interest [8]. By standards

IEEE Communications Magazine • April 2001

JAVA TECHNOLOGY AND COMPATIBILITY Java started as a programming language. One of Sun’s maxims is “Write Once Run Anywhere” (WORA). That is, a Java software developer should not need to rewrite his or her software program for different platforms. Java programs are to be portable and scalable. In order to achieve cross-platform compatibility, Sun has created a standardized application programming environment. Each system and browser provider must fully implement the specifications of the Java Virtual Machine (JVM)1 and application programming interfaces (APIs)2 of the standardized Java environment if WORA is to be achieved. Several system providers such as IBM and Hewlett-Packard have done so. Thus, Java has evolved into a programming environment. Java became popular because - platform-independent — small Java programs could be downloaded and executed by web browsers. These moving, colorful applets triggered its breakthrough on the Internet. Java was well on its way to become a de facto standard when Sun Microsystems approached JTC1 to formally standardize the Java‘ Technology. (JTC1 is short for the Joint Technical Committee 1 of the International Standardization Organization, ISO, and the International Electrotechnical Committee, IEC.) Sun became a recognized submitter of Publicly Available Specifications (PAS) late 1997. However, it refrained from using its submitter status because there was a likelihood that its Java specs would be significantly changed during the PAS-approval procedure. In April 1999, Sun approached ECMA, an international industry association for standardizing information and communication systems, for the same purpose. Once an ECMA standard, the Java specs could be submitted to JTC1 by way of the Fast Track process (usually a yes/no decision in JTC1). However, after the first meeting of the ECMA standards committee Sun withdrew. This time ECMA’s IPR rules were not elaborate enough, according to Sun. Sun preferred to evolve its own procedures for the Java Community Process toward a more open multiparty development of the Java specifications [4]. 1

That is, software that runs on proprietary operating systems and is capable of interpreting compiled Java byte code. 2

APIs comprise the standard packages, classes, methods and fields made available to software developers to write programs.

regime I mean the values, beliefs, rationales, rules, and agreements that govern consortium and formal standardization (e.g., the ideal of a democratic standards process; decisions should reflect consensus [9]). Three interrelated regimes have immediate bearing on the questions raised above: the legal, the market, and the standards regime. The standards arena is not solely governed by the standards regime. It is part of the market and is thus also subject to the “rules” of the market. In the standards arena market strategies are evident that are tolerated by the standards regime in question. For example, the IPR strategies companies use to protect their market will also be used in the standards setting. Because there is a tension between the compatibility aims of standards bodies on the one hand, and IPR protection of contributions to draft standards on the other, most standards bodies have installed special IPR procedures. If conflicts remain, the legal regime will be invoked to solve them. The legal regime is the default regime for handling IPR issues in standardization. The IPR code of conduct, to which standards participants must comply in some standards bodies, aims to prevent the legal regime from being invoked. But, since the standards arena is part of the market arena, juridification of market conflicts also affects standardization. To an increasing extent, legal matters have permeated the standards setting arena (Fig. 1).

109

Juridification

Standards regime

IPR RULES OF STANDARDS BODIES Market governance

Legal regime

■ Figure 1. Juridification of the standards regime.

IPR MARKET STRATEGIES Bekkers and Liotard [1] provide an overview of IPR strategies which companies use and standards bodies must deal with. They mention: • The licensing with a general declaration strategy (i.e., announcing ownership of the IPR and declaring that licenses will be available on fair, reasonable, and nondiscriminatory terms) • The licensing without a general declaration strategy • The withholding strategy (i.e., not licensing the IPR) • The nondisclosure or late disclosure strategy (i.e., not informing other parties of the existence of the IPR) The impact of these IPR strategies on standardization is large if essential IPRs are involved. That is, when “on technical (but not commercial) grounds it is not possible to produce, sell, import, use or operate products that conform to a certain standard without infringing on that IPR” [1, p.117]. Essential IPRs may cover patents (e.g., in the GSM and IMT 2000 case) as well as copyrights (e.g., Sun’s copyright on the Java specifications). Figure 2 conceptualizes IPR strategies and compatibility strategies as market strategies. (I prefer to speak of compatibility strategies rather than standardization strategies, since there are also other ways to achieve compatibility [4]. Where I mention standardization strategies, I refer to multiparty consensus processes in standards consortia and formal standards bodies.) Companies use both — sometimes in combination — to further their interests. Most salient is the “misuse” of market strategies based on IPR ownership in standards development (e.g., GSM

Market strategies Compatibility strategies Standardization strategies

IPR strategies

■ Figure 2. IPR and compatibility strategies as market strategies.

110

and IMT 2000). Nevertheless, in some cases IPR strategies are used to safeguard compatibility (e.g., Java). Theoretically, the formal standards bodies of ISO and IEC have become more susceptible to direct company interests and their IPR strategies since the installment of the Fast-Track procedure for A-liaison members and the JTC1 PAS procedure. Both procedures allow externally developed specifications to be fed into the JTC1 process as a draft international standard, that is, without going through the prior stages of committee standardization. The Java case, however, suggests that in practice no real changes have taken place. Sun approached JTC1 in 1997 and ECMA in 1999. Both times IPR problems arose. Below, their IPR rules are examined to determine the way intellectual ownership — here, patents and copyright — has been institutionalized therein. (Notably, the ECMA is an A-liaison member of JTC1. This means that it can fast-track ECMA standards to JTC1, and that therefore ECMA and JTC1 procedures are likely to be similar.) Patents — Typically, standards bodies try to avoid the inclusion of patents in standards. The ISO/IEC rules treat their inclusion as an exception. This refers back to the idea that the standards process is itself an innovative technology development process and need not depend on other sources. It also echoes the belief that technical alternatives are generally available. The inclusion of patents is seen to be foremost in the interest of the IPR owners themselves (i.e., a standard results that makes the company’s R&D investment worthwhile and gives it a head start vis-a-vis competitors). Standards bodies therefore request that IPR owners provide patents under fair and reasonable terms. A statement to this intent is requested of the patent holder. If this is withheld, the technical committee will not include the patented item. If a technical committee is not aware of any relevant patents during the standards process or if patents claims are made after publication of the international standard, the ISO/IEC procedures disclaim authority on these matters[10]. The ECMA has a code of conduct on patent matters. Partly ECMA deals with patent claims on work covered by draft standards in the usual way, namely that such patents should be licensed on a reasonable and nondiscriminatory basis, or else the standard will not be approved. However, if the patent belongs to an ECMA member, company participation in an ECMA technical committee and a yes vote to the standard automatically imply compliance to reasonable licensing terms. Copyright — The copyright on draft international standards (DISs) and international standards (ISs) belongs to ISO and IEC. In respect to contributions, JTC1 has a procedure for normative referencing [10]. That is, a standards committee may want to incorporate specifications from sources outside ISO, IEC, or ITU into an emerging standard by way of reference. Normative referencing differs from informative referenc-

IEEE Communications Magazine • April 2001

ing, to which no restrictions apply. With normative referencing, the originator of the referenced specification must give written consent; or else, the reference shall not be made. ECMA standards and technical reports are available to all interested parties without restriction and without charge [11]. However, ECMA retains the copyright on ECMA standards. The copyright status of documents leading up to an ECMA standard is as follows. The owner of a document is, in respect to • A contribution from members of an ECMA group, the contributor • The drafts of formal documents, the ECMA group responsible for the document • Contributions to external organizations, the ECMA group responsible for the document • Final drafts submitted to the ECMA General Assembly, ECMA When a contributor submits a document as input to an ECMA committee, the document is assigned a number by the ECMA secretariat for the purpose of referencing and archiving. Once this occurs, the contribution becomes an ECMA working document. (A working document is a “document … used by an ECMA Group, … distributed by the ECMA Secretariat and [that carries] one or more ECMA numbers” [11].) Then the copyright changes hands from the contributor to the ECMA Group. Alternatively, should the document on which a technical committee works be understood to be owned by both the contributor (extending its initial status) and the committee (if viewed as an early version of the draft formal document)? The unclear copyright status of Sun’s contribution was one of reasons to withdraw its Java specifications from the standards process (box 2). Sun subsequently also refused to agree with an ECMA standard that would be based on normative referencing to its Java specifications, something which posed no problems in a JTC1 context in 1997. (Sun agreed to normative referencing by the JTC1 standards committee for “Coding of Audio, Picture, Multimedia and Hypermedia Information.” It held on to its IPRs but asked no fees [10].) In sum, standards bodies deal summarily with patent ownership. The patent holder can choose between reasonable licensing terms or no inclusion. More elaborate rules exist to regulate the inclusion of copyrighted material in standards (Table 1). What could be the cause of this difference in IPR treatment? It could be that: • Standardizers see patent holders as competitors in technology development (idea generators, see above), which leads to more straightforward go-no go procedures — while copyright holders work on the expression of an idea. • Copyright owners are more prepared to negotiate and more easily waive their rights than patent owners, which would call for more subtle procedures. • Standards procedures complement legal provisions, which would mean that patent law is more elaborate and needs less addition than copyright law. Additional research is needed to check these hypotheses.

IEEE Communications Magazine • April 2001

JAVA IN ECMA Sun’s reason to withdraw from the ECMA process was, according to its press release, that “… ECMA has formal rules governing patent protections; however, at this time there are no formal protections for copyrights or other intellectual property.” Sun was under the impression that ECMA had agreed that Sun would retain copyright of the specifications during the standards process, and that ECMA would copyright the resulting standard. Although Sun would not claim copyright on the standard, it would hold onto its trademarked Java name and Java Compatibility logo, which had business value. During the first TC41 meeting, it appeared, however, that the oral agreement on copyright, as Sun understood it, would not be upheld. Sun lawyers were taken aback by the ECMA Secretary General’s (SG’s) explanation of IPR rules regarding contributions to standardization. Regarding the copyright status of the Java specs, Sun’s contribution would become an ECMA document once it was assigned a TC document submission number — which it would receive at the start of the standards process. Sun protested, and did not wait to see whether the ECMA SG could find an acceptable compromise. The problem was, first, that Sun and ECMA had a different view on what was previously agreed about copyright of the Java specs. Second, at that point Sun attached two different meanings to copyright. It differentiated between a copyrighted specification and copyright of the contents of the specification (i.e., roughly speaking, the difference between paper and software) [11]. The latter copyright interpretation was new to all concerned. Early December, before the negotiations could start, Sun announced its withdrawal. The steps Sun took in the following months give credence to Sun’s official reason to withdraw: concern about copyright protection. The European Information and Communication Technology Industry Association (EICTA), founded in January 2000, installed a Standards Policy Group (SPG) chaired by Sun. The policy group was to develop a position on the licensing terms of software technology embedded in standards that was to be protected by copyright rather than patents. Sun also planned to raise the issue at a meeting of the European ICT Standards Board, but ultimately decided not to do so. Lastly, Sun called together a Standards IPR Forum meeting during the Open Group Conference (April 2000, London). Its aim was to discuss copyright on submissions, among other things. These initiatives, however, do not appropriately explain Sun’s withdrawal from standardization. Possibly, proceeding with standardization would have had additional adverse consequences for the scope of IPR protection. As Stuurman [12] argues, de facto standards require resilience in respect to imitations. If they are formalized, they become more susceptible to infringement of IPRs because the difference between the expression of an idea (copyright) and the idea itself (patent) becomes unclear. However, the copyright conflict can also be a symptom of a struggle for power behind the scenes, as is argued elsewhere [3].

DEFAULT LEGAL REGIME The discussion below is confined to the IPR laws regarding software in Europe and the United States, and to the influential Agreement on TradeRelated Aspects of Intellectual Property Rights (TRIPS agreement) of the World Trade Organization (WTO). Of interest is the way they address IPR issues and whether compatibility interests are referred to in IPR regulation. European Regulation — [13] Abuse of IPR is subject to EU competition rules. A European Directive of 1991 specifically addresses IPRs on software. It aims to curb the copying of computer programs. Copyrights are to be respected. The sole exception concerns the copying of information about interfaces when needed and used for the purpose of interoperability with an independently created program. “… An objective of this exception is to make it possible to connect all components of a computer system, including those of different manufacturers, so

111

U.S. patent law allows companies

Regimes

Standards regime

Interests

Patent

IPR

Compatibility

to patent anything useful and nonobvious,

Legal regime Copyright

Patent

Copyright

Low Medium (e.g., treated as an exception, (e.g., Normative code of conduct) Referencing)

High (patent law)

High (copyright law)

High (standardization procedures)

Absent

Partial (interoperability clauses)

including business methods and algorithms.

■ Table 1. The degree to which IPR and compatibility interests are anchored in the standards and legal regimes.

Software patents are not explicitly discussed. Nor are exceptions mentioned to patent infringement that could be related to compatibility interests.

that they can work together.” Although the Article 6 in question has been heavily debated, it indicates under which circumstances compatibility is deemed more important than ownership protection [12, p. 459]. Different from the United States, in the European Union only the expression of a computer program is protected by law (copyright protection as a literary work). The ideas and principles which underlie programs are not (no patents). Patent-oriented R&D in the United States and the need to comply with the international TRIPS Agreement (see below) led in 1997 to a Green Paper about the patentability of computer software in Europe. The follow-up document of 1999 noted that there were 13,000 European patents on software, despite the fact that computer programs were not patentable. Apart from the need for a harmonized approach among member-states, the discrepancy with U.S. and Japanese law pressed the Commission and the European Parliament to propose changes. The feeling was that software should meet the conditions of “novelty and industrial application” to be patented. Software patents would encourage companies to invest in R&D and would therefore stimulate innovation. The follow-up document made no mention of the problems that patents could pose for standardization or other issues of compatibility. A draft directive on the patentability of computer programs was drawn up to complement the copyright directive. However, it was voted down in November 2000. In particular, open-source software advocates thought the directive would hinder the development of new software programs. Programmers would fear infringing on someone else’s patent. They referred to the situation in the United States, where patent infringement claims kept software companies quite busy because the U.S. patent and trademark organization had in the past not been very critical in assigning software patents [14]. U.S. Regulation — U.S. patent law allows companies to patent anything useful and nonobvious, including business methods and algorithms. Software patents are not explicitly discussed [15]. Nor are exceptions mentioned to patent infringement that could be related to compatibility interests. U.S. copyright jurisdiction appears to struggle with the compatibility issue, as the following examples will illustrate. They all concern de facto standards. The first example is that of

112

Lotus vs. Paperback. Paperbacksoftware International copied the user interface of Lotus 1-2-3 because the latter was a de facto standard. Consumers would not agree to anything else, according to Paperback, and the company thus felt forced to infringe on the copyright of Lotus. Paperback argued that its actions furthered compatibility and were therefore in the interest of consumers. The judge rejected these arguments. There was no prior jurisdiction which said that standardization, if not achieved through formal channels, was in the interest of the public at large. According to Judge Keaton (28 June 1990), “A moment’s reflection is enough to disclose that the public interest in standardization is a sharply debatable issue” [12, p. 461]. In other words, copyright infringement could not be condoned for reasons of seeking compatibility with a de facto standard. In the second example, the case of Lotus vs. Borland, Lotus accused Borland International of infringing on copyright of the menu structure of Lotus 1-2-3. In this case, the verdict was in favor of Borland: “to allow users to operate its programs in substantially the same way …, Borland had to copy the Lotus menu command hierarchy” [12, p. 462]. The third example, the case of Sun Microsystems vs. Microsoft, is discussed in box 3. Here, the integrity of the Java platform was the central issue. Sun accused Microsoft of intentionally fragmenting the Java platform by means of misusing the Java name and the Java compatibility logo. It sued Microsoft for copyright infringement and, at a later stage, for unfair competition (box 3). The court judged that only the unfair competition part could be sustained. The verdict suggests that compatibility arguments are not well institutionalized in U.S. law. They need to be worded in terms of competitive market interests to be acknowledged. The above cases illustrate that jurisdiction regarding copyright vs. compatibility interests differs per situation. The Digital Millennium Copyright Act of October 1998 more clearly refer to the desirability of compatibility. The Copyright Act includes exceptions for circumventing copyright. One exception is reverse engineering for the purpose of interoperability [16]. TRIPS Agreement — The Agreement on TradeRelated Aspects of Intellectual Property Rights of 1994 is, according to the WTO, currently the most comprehensive multilateral agreement on intellectual property. In respect to copyright,

IEEE Communications Magazine • April 2001

computer programs, whether in source or in object code, shall be protected as literary works (Article 10(1)). The agreement further only mentions that exceptions should be limited, and does not specifically refer to compatibility. With regard to patents, “... Patents shall be available for any inventions, whether products or processes, in all fields of technology, provided they are new, involve an inventive step and are capable of industrial application,” according to Article 27(1). This includes software. (There could be, implicitly, some leeway for unauthorized use of patents for compatibility purposes if such use would fall under “public non-commercial use” [Article 31(b)].) In sum, both European and U.S. copyright law have a clause which says that copyright infringement is only allowed for the sake of interoperability (i.e., interface information for achieving interoperability with an independently created program, and reverse engineering for the purpose of interoperability, respectively). The proposed and implemented patent laws include no such exceptions (Table 1). Thus, overall, intellectual property interests are well protected by the current dominant legal regime. In comparison, the public interest in compatibility is not. This means that the societal significance of technical compatibility will regularly need to be renegotiated. Compatibility will at best be a recurrent ad hoc policy issue, subject to changing short-term political forces.

INNOVATION: INTELLECTUAL PROPERTY VS. COMPATIBILITY Comparing copyright protection and patents, Kultti and Takalo note that only one patent can be awarded among similar innovations, “whereas copyright law permits independent discoveries. For instance, several papers on the same idea may be published …” [17, p. 1]. In this respect, copyright law appears to reflect R&D practice better than the patent system. Kultti and Takalo point out that similar inventions often occur simultaneously in different places. Their point is supported by Thomas Kuhn’s paradigm theory. Kuhn identifies communities of practitioners, who work in the same field, think along the same lines, and focus on the same sort of problems. They share the same paradigm. This heightens the probability that within a limited time span similar inventions will be made in the same field of research. There are few studies that address the tension between IPR and compatibility from a social studies of technology angle. Interesting exceptions are Schoechle [6] and Iversen [18]. Iversen takes an evolutionary approach. He views the IPR regime as one in which variation of technology takes place. He likens the formal standards regime to a selection environment: during the standards process diversity is reduced. His analysis builds on three implicit assumptions: first, that the standards setting environment is generally not an innovative one; second, that the phase of standards setting is of primary interest in relation to technology development; and third, that standardization processes in the

IEEE Communications Magazine • April 2001

SUN VS. MICROSOFT In 1995, Java was on its way to become a hype. As the Findings of fact in the antitrust lawsuit against Microsoft indicate, Java’s promise of platform-independent computing made Microsoft nervous. It undermined the fundaments of Microsoft’s software market, the Windows platform. In that period, Microsoft approached companies such as Netscape and Intel to withdraw from activities that supported Java developments. In March 1996, Sun and Microsoft signed a Technology License and Distribution Agreement (TDLA) for the use of Java. The document started with reciting the need for Java compatibility. Part of the agreement was that Microsoft would incorporate the Java technology in its Internet Explorer (IE) 4.0. In late 1996, Microsoft released IE 3.0. In order maximize its use vis-a-vis Netscape Navigator, Microsoft decided that the next version would be more tightly integrated into the Windows operating system. Moreover, Microsoft started creating Java development tools and a Java runtime environment in a manner that undermined the portability of Java programs and was incompatible with Sun’s Java products. A lawsuit ensued. In October 1997 Sun filed a complaint against Microsoft for copyright infringement. In March 1998 the court granted Sun’s request for a preliminary injunction: Microsoft was not allowed to use the Java Compatible logo unless its products passed Sun’s test suites. In May, Sun filed an additional complaint for unfair competition. In November 1998 the court ordered Microsoft to change its software and development tools. Microsoft appealed against the ruling. It argued that the punishment did not fit the crime committed. It pleaded guilty of breach of contract, for which the TDLA stipulated a much lighter punishment than injunction. In August 1999 the court granted Microsoft’s appeal, upon which Sun protested. In January 2000 a higher court confirmed that copyright infringement was not at stake. At stake was unfair competition by Microsoft. In January 2001 the dispute was finally settled. Among other things, the TDLA was terminated and Microsoft agreed not to use Sun’s Java Compatible logo anymore.

formal standards bodies well illustrate the ways in which compatibility can be achieved. In recent years, Iversen’s first assumption, namely that past accounts of standardization have overemphasized the inventive quality of technical contributions, has gained support [9; 19, p. 38]. Multiparty standards usually codify the state of the art in a certain technical field. However, the crux of standardization is not that it leads to innovative standards. Innovative opportunities, for example, lie in the way specifications are implemented, occur because R&D resources are freed once compatibility is achieved, or lie in the exploitation of externalities. During standards diffusion, variation of technology takes place. The post-standardization phase is in respect to technology development at least as influential as the standards setting process itself is, to answer to Iversen’s second assumption. Moreover, in respect to his third assumption, many strategies other than formal standardization improve technical compatibility. Examples in the field of software are licensing and open source strategies [4]. In particular, in the case of open source software development, where to date no distinction is made between forging compatibility (developing the “standard”) and developing software, technology development shows a different pattern. It would seem that innovations sometimes occur despite the IPR regime.

DISCUSSION The previous raises a number of fundamental policy questions. I will formulate them as bluntly as possible in order to stimulate debate:

113

Standardization is one of the many compatibility strategies that companies can opt for. Software licensing and open source strategies, for example, may also enhance compatibility. Such strategies use various forms of IPR protection.

• A regulatory asymmetry exists between IPR interests and compatibility interests. Current regulation anchors the primacy of IPR ownership and market competition in law, but it hardly recognizes the societal significance of compatibility interests (i.e., technical interoperability). Would it be desirable to legally anchor compatibility interests in a way similar to intellectual property interests? • There is a difference between the judicial treatment of patents and copyright. The patent system, which is stricter than copyright protection, leaves no room for compatibility priorities, whereas U.S. and European copyright regulation does. Copyright law allows different people to write on the same subject. This approach is more consistent with the way R&D takes place — the nearsimultaneity of inventions — than patent law. Should patent law take the near-simultaneity of inventions into account? • Most standards bodies try to avoid the use of patented work for standards. The IPR rules treat their inclusion as an exception. Should these standards bodies resign themselves to a noninnovative, process-oriented role and start thinking more in terms of “purchasing innovative technology” (i.e., incorporate patents more often)? • Standardization is one of the many compatibility strategies for which companies can opt. Software licensing and open source strategies, for example, may also enhance compatibility. Such strategies use various forms of IPR protection. O’Mahoney [20] lists the following types of software control: copyhoarding, licensing, shareware, copylefting, freeware, and public domain. Should IPR regulation address these IPR approaches to software?

REFERENCES [1] R. Bekkers and I. Liotard, “European Standards for Mobile Communications: The Tense Relationship between Standards and Intellectual Property Rights,” Euro. Intellectual Property Rev., vol. 21, no. 3, 1999, pp. 110–26. [2] J. Ubacht, “UMTS: To Boldly Go Where No One Has Gone Before?” presented at Congres Onderzoek in Nieuwe Media, Mar. 25, 1999, Rotterdam, The Netherlands. [3] T. M. Egyedi, “Why Java‘ Was — Not — Standardized Twice,” IEEE Proc. 34th Hawaii Int’l. Conf. Sys. Sci., Jan. 3–6, 2001. [4] T. M. Egyedi, “Compatibility Strategies in Licensing, Open Source Software and Formal Standards: Externalities of Java ‘Standardization,’” presented at 5th EURAS Helsinki Wksp. Standardization and Networks, VATT, Helsinki, Finland, Aug. 13–14, 2000. [5] M.B.H. Weiss and M.B. Spring, “Selected Intellectual Property Issues in Standardization,” K. Jakobs, Ed., IT Standards and Standardization: A Global Perspective, London: Idea Group Publishing, 2000, pp. 63–79. [6] T. Schoechle, “Intellectual Property Rights and Emerging Technologies: Friends or Foes?” submitted to the Minitrack on Standardization in Information Technology, PHICSS-34, Jan. 3–6, 2001. [7] D. A. Hounshell and J. K. Smith, Science and Corporate Strategy, Du Pont R&D, 1902-1980, Cambridge: Cambridge University Press, 1988; Ph. A. Roussel, K. N. Saad, and T. J. Erickson, 3rd Generation R&D Managing the Link to Corporate Strategy, Boston: Harvard Business School Press, 1991.

114

[8] V. Schneider and R. Werle, “Co-Evolution and Development Constraints: The Development of Large Technical Systems in Evolutionary Perspective,” Int’l. Res. Seminar: Large Tech. Sys. and Networks: Interconnection Processes, Governance Issues, Conceptual Development, Autun, France, Sept. 27–30, 1995. [9] T. M. Egyedi, “Institutional Dilemma in ICT Standardization: Coordinating the Diffusion of Technology?,” K. Jakobs, Ed., IT Standards and Standardization: A Global Perspective, London: Idea Group Publishing, 2000, pp. 48–62. [10] ISO/IEC sources: “ISO/IEC Directives — Part 2: Methodology for the Development of International Standards, Annex A,” 1992; “Procedures for the Technical Work of ISO/IEC JTC 1,” 1999; “The Normative Referencing of Specifications other than International Standards in JTC 1 International Standards – Guidelines for JTC 1 SCs,” 1996-03-13, JTC1 N4046; ISO/IEC JTC1/SC29, 03-061997, N2082. [11] ECMA sources: “Code of Conduct in Patent Matters,” “ECMA By-laws, Promulgation of Standards and Technical Reports,” Art 8.4, ECMA Memento 2000; Working documents and formal documents: rules for editing, recording and exchanging, Art. 2.11, ECMA, Feb. 2000; Minutes of ECMA CC 11-12 Nov. 1999. [12] C. Stuurman, “Technische normen en het recht. Beschouwingen over de interactie tussen het recht en technische normalisatie op het terrein van informatietechnologie en telecommunicatie,” Reeks Informatica en Recht, dissertation, deel 17, 1995. [13] EC, Council Directive 91/250/EEC of 14 May 1991 on the legal protection of computer programs, Off. J. L 122, May 17, 1991, pp. 0042–0046; Report from the Commission to the Council, the European Parliament and the Economic and Social Committee on the implementation and Effects of Directive 91/250/EEC on the legal protection of computer programs, Brussels, Belgium, Oct. 4, 2000, COM(2000) 199 final; Promoting innovation through patents: the follow-up to the Green Paper on the Community Patent and the Patent System in Europe, Communication from the Commission to the Council, the European Parliament and the Economic and Social Committee, May 1999. [14] M. L. D’Amico, “Europe Considers Loosening SoftwarePatent Rules,” IDG News, July 8, 1999; G. Lea, “US Patent Mess will Get Worse Before It gets Better,” The Register, Mar. 31, 2000. [15] 35 U.S.C. § 101 Inventions patentable; § 103 Conditions for patentability; non-obvious subject matter, Patent Laws and Regulations, Jan. 18, 2000. [16] L. Jamtgaard, “The U.S. Digital Millennium Copyright Act,” International Legal Protection for Software, 1999, http://www.fenwick.com. [17] K. Kultti and T. Takalo, “A Search Model of Intellectual Property Protection: Patent vs. Copyright,” presented at 4th EURAS Helsinki Wksp., 1999. [18] E. J. Iversen, “Standardization and Intellectual Property Rights: Conflicts between Innovation and Diffusion in New Telecommunications Systems,” K. Jakobs, Ed., IT Standards and Standardization: A Global Perspective, London: Idea Group Publishing, 2000, pp. 80–101. [19] P. Mähönen, “The Standardization Process in IT — Too Slow or too Fast?” K. Jakobs, Ed., IT Standards and Standardization: A Global Perspective, London: Idea Group Publishing, 2000, pp. 35–47. [20] B. O’Mahoney, “Software Issues,” 2000, http://www.benedict.com/news/resume

BIOGRAPHY TINEKE MIRJAM EGYEDI ([email protected]) received the Ph.D. in standardization from the Delft University of Technology in 1996. As a consultant for KPN Research, she compared JTC1 and Internet standardization. Subsequently, the Royal Institute of Technology in Stockholm engaged her to study the role of containers in the transport infrastructure from a standardization perspective. She participated in two European multimedia projects (ELECTRA and SLIM) for the University of Maastricht, and is presently working as a senior researcher in Delft on a third European Union project (consortium standardization). Her other activities include the co-organization of the EURAS 2001 workshop on standardization and infrastructure development.

IEEE Communications Magazine • April 2001