Compatibility strategies in licensing, open source software and
formal standards: Externalities of Java 'standardisation'
Tineke M. Egyedi
Delft University of Technology
Faculty of Systems Engineering, Policy Analysis and Management
Information and Communication Technology
Contribution to 5th Helsinki Workshop on Standardization and Networks,
13-14 August 2000
FIRST DRAFT1
Abstract
Standardisation is a means of co-ordinating technology diffusion in a way that preserves
compatibility. It is in essence an ex ante market mechanism, which levels the playing
ground of product and service developers. Its primary value for software developers,
users and its importance for public ICT policy developers lies in the positive externalities
that derive from compatibility.
But need these externalities be achieved by formal standardisation? I this paper I explore
and compare the compatibility effects of de facto standards, quasi-open source software
developments and - indirect means of - formal standardisation. I centre the comparison on
the Java technology, which is currently one of the key technologies in the field of ICT.
Sun's compatibility strategies regarding Java illustrate a whole range of options:
proprietary de facto (licensing and open source software), gated-multiparty, consortium,
and international formal standardisation. Sun tries to combine wide involvement of
developers with cross-platform compatibility. Overall, its efforts have resulted in market
co-ordination - although not without costs. Could formal standardisation bodies also have
achieved this outcome?
1
The empirical material to be used is more or less complete (the references, in particular the websites, are
not). The conceptual framework still needs further polishing - and extra (re-)reading. Comments are
welcome. My email address is: T.M.Egyedi@tbm.tudelft.nl
Interviewees: Willem Wakker, Jan van den Beld, participants to the ECMA TC 41 meetings.
I thank my colleague Jan-Pascal van Best for commenting on the technical part of this draft.
This research project is sponsored by DITSE (Delft University of Technology), and Verdonck Holding.
Contents:
1. Introduction ..................................................................................................................... 3
2. Conceptual framework .................................................................................................... 4
3. Java™ Technology ......................................................................................................... 6
4. Compatibility strategies .................................................................................................. 7
4.1 Orchestrated software development and 'Open Source' Java.................................... 7
4.1.1 Licensing ............................................................................................................ 8
4.1.2 Sun Community Process .................................................................................. 12
4.2 Initiated routes to formal standardisation ............................................................... 14
4.2.1 JTC1 PAS procedure........................................................................................ 15
4.2.2 ECMA and the fast track procedure................................................................. 17
4.3 Compatibility strategies compared ......................................................................... 20
5. Instances of Failing Co-ordination................................................................................ 22
5.1 Lawsuit Sun vs. Microsoft ...................................................................................... 23
5.2 Real-Time Java: J consortium ................................................................................. 24
6. Conclusions ................................................................................................................... 25
References ......................................................................................................................... 26
1. Introduction
The term 'compatibility standards' is confusing for all standards (are meant to) lead to
compatible implementations. Indeed, de facto standards more forcibly impose
compatibility than the formal committee standards, to which the term refers. Moreover,
treating the term 'standardisation' and 'compatibility' as separate notions helps us to
recognise that ultimately our interest is not in the activity of standardisation per se, but in
compatibility.
There are several strategies to achieve compatibility. Multiparty standardisation (formal
and 'consortium') is one them. But compatibility can also develop as a result of market
dominance. The processes by which de facto 'standards' develop are seldom scrutinised
from a standardisation perspective. They are taken as a natural consequence of market
dominance. Therefore the events, which led to their dominance, are retrospectively
recounted. De facto standards are the result of successful market strategies, but what do
these market strategies mean in terms of compatibility? And would it not be of higher
interest to determine whether a company's compatibility strategies led to market
dominance?
A widely shared contention is that compatibility benefits industry and users. This applies
in particular to the ICT sector where configurational technologies (Williams, 1999) are
produced. Compatibility is crucial to the developers of middleware2 such as Java. Java is
one of the key technologies for developing cross-platform, network-centric software. The
core technology is owned by Sun Microsystems. It has evolved with much input from the
'Java community'. Sun manages this process. It uses different strategies to 'co-ordinate'
the market.
This paper examines Sun's compatibility strategies regarding Java development and
explores the externalities involved. A framework is developed that centres on the
compatibility strategies as ex ante market mechanisms (section 2).
In section 3, I briefly explain what the Java technology entails. Sun's methods to maintain
compatibility have raised much debate within the Java and the standards communities. Its
main strategies have been licensing and the Community Source Model (section 4.1.1),
formalising the Java Community Process (section 4.1.2), and initiatives in respect to
formal (JTC1 PAS procedure; section 4.2.1) and consortium standardisation (ECMA;
section 4.2.2). Their externalities are compared in section 4.3.
Section 5 addresses two instances where market co-ordination failed: Microsoft's
development of incompatible Java products, which led to a lawsuit (section 5.1) and the
embedded Java activities of the J consortium (section 5.2). I explore their implications for
Sun's strategies and Java development in the concluding section (section 6). The general
issues, which this case raises, are discussed.
2
"Generally, in advanced networks, middleware consists of services and other resources located between
both the applications and the underlying (…) infrastructure, although no consensus currently exists
(…)."(ISOC RFC 2768 Network Policy and Services: A Report of a Workshop on Middleware)
2. Conceptual framework
Standardisation3 is an endogenous factor to market development. It is part of the
competitive product development process between producers (Weiss & Sirbu, 1990,
p.112). Companies use standards as change agents. They are used as strategic tools to
consolidate a market position or gain advantage over competitors (Cargill, 1989; Bonino
& Spring, 1991). Companies do not contribute true technological novelty to multiparty
standards committees. Committee standards codify shared ideas on the state-of-the-art in
a certain technological field. They level the playing ground for subsequent
implementation and product diffusion. In this respect, committee standardisation is an ex
ante mechanism for co-ordinated market development; it is an effort to co-ordinate the
diffusion of implementation in a way that preserves technical compatibility4. The
innovations introduced during the diffusion process (innofusion; Fleck, 1988) form
potential threats to compatibility. They may fragment the market.
On supply side, the most evident benefits of standardisation are cost benefits from
economies of scale, reduced costs of production and reduced storage costs (Bonino &
Spring, 1991). On the demand side, standards lower the transaction costs of user
evaluation "(...) by improving recognition of technical characteristics and avoidance of
buyer dissatisfaction" (Reddy, 1990, p.50). Where networks are concerned,
interoperability leads to positive externalities on the demand side (i.e. network
externalities5) and on the supply side. Companies are more likely to develop products and
services for the network. Indeed, the notion of externalities need not be restricted to
networks (Schmidt & Werle, 1998). All standards for configurational technologies such
as ICT have comparable externalities. The term is used here to refer to effects that result
when an increasing number of people 'connect' to a certain technology, product or
specification.
Standardisation
Compatibility
Externalities
Figure 1: The relationship between standardisation and externalities. The figure
highlights the intermediate variable of 'compatibility'.
3
The term 'standardisation' refers here to those activities that are exclusively set up for that purpose, and
are meant to lead to standards (specifications). It takes place in formal standards bodies and standards
consortia (i.e. industry and multi-party standards fora).
4
The ISO defines compatibility as the "suitability of products, processes or services for use together under
specific conditions to fulfil relevant requirements without causing unacceptable interactions." (ISO/IEC
Guide 2: 1991 (2.2))
5
The term denotes the increased benefits, which derive from being connected to a network when the
number of connected participants grows. (see e.g. Katz & Shapiro, 1985; David, 1985; Blankart & Knieps,
1992)
In the introduction, I argued that a clear distinction should be made between the term
'standardisation' and 'compatibility'. Standardisation ideally leads to compatible
implementations, which in turn lead to externalities. (See figure 1: standardisation
activities are instigated to achieve compatibility, which in turn may lead to externalities.)
But there are also other ways to achieve compatibility. For example, proprietary
interfaces also foster compatibility. With an eye to long-term advantages, firms may give
away a technology or enter into coalitions with rivals to enlarge their user base and widen
support for their proprietary standard. Where a firm monopolises the production of a key
component, it may define an interface, which effectively ties complementary products of
other firms to the proprietary component technology (David & Greenstein, 1990). In
combination with market dominance we retrospectively speak of 'de facto
standardisation'. But by so naming it, we confuse the issues. We should instead speak of
'de facto compatibility', which is foremost a consequence of a commercially successful
product development trajectory, rather than the outcome of a proprietary standardisation
trajectory. Standards development and ICT product development may both lead to
compatibility. Figure 2 summarises the line of argument.
Figure 2: Examples of different compatibility strategies with regard to software
development.
If we restrict ourselves to the strategies of large software companies, they are significant
contributors to formal standardisation and consortium standardisation. They partake in
order to develop new markets, and protect established markets (i.e. prevent compatibility
to block competitors from their market). They may withhold information on interface
specifications, or change proprietary product interfaces at regular times to put off
competitive product development, etc. These things are 'common practice'.
A less common market strategy, one that is gaining public interest, is distributing
software source code for free (e.g. Netscape and Linux). Open source software generally
comes with an undemanding general public license. For example, the operating system
Linux currently allows one to download Linux, and use, change and distribute
adaptations without charge. These adaptations to the source code should, in turn, be made
available in source code (see www.Linux.org). Due to the open source movement, it is
less odd to demand that commercial companies open up their source code. A number of
companies have been asked to do so (e.g. Microsoft and IBM). Sun partly applies this
strategy with regard to Java (see section 4).
Both open source and proprietary software development can both lead to a sizeable
market share and 'de facto standards'. Their externalities differ, however. Open source
software strongly encourages technology innofusion. The degree of compatibility
achieved among the resulting heterogeneous software products will strongly depend on
the community of developers, and their adherence to the principles of use laid down in
the license. There needs to be a pull towards compatibility. Proprietary system
development works differently. Proprietary software imposes compatibility on other
players. Complementary system developers and competitive developers of clean-room
are forced to comply with the interface specifications. Compatibility is controlled and
innofusion is limited. Both mechanisms are evident in Sun's strategies for Java
development.
3. Java™ Technology
Java originated from a Sun research project that took place in the early 1990s. The idea
was to connect different computer-based devices (e.g. house-hold appliances, TV, etc.) in
a network. Sun developed a computer language to work in these devices. The language
was simple and concise (small VM: kilobytes) and network-oriented (no software in
devices). Its design addressed heterogeneous architectures, software portability (virtual
machine), and safety. The project was abandoned because there appeared to be no
market. But in 1995 Sun realised that the project 's outcomes could be useful for
programming for the Internet. They called the language Java. The platform-independence
of Java allows small Java programs to be downloaded and executed by web browsers.
These moving, colourful "applets" triggered Java's breakthrough on the Internet.
Java is presently also used for embedded systems, that is, for purposes that Sun had
originally envisioned. For example, the set top box that is being developed for Digital
Video Broadcasting contains Java technology. This area of application is called
embedded Java, or Real-Time embedded Java. I will address embedded Java briefly in
section 5.2. The emphasis in this paper is, however, on developments in the Java
programming environment, that is, on Sun's Java ™ technology.
According to Sun officials, Java is not part of Sun's core business. Java is a means to sell
servers. Its main field of operation is networked computing. The current, dominant
practice is much local intelligence and little intelligence on the server. Sun's preferred
practice is for intelligent servers6. One of Sun's maxims is 'The network is the computer'.
6
Although they add, that Java ported to PCs also generates much data - and thus requires more 'Java'
servers.
It is a network-centric vision. 'Dumb' terminals would suffice. Software is centrally
stored on network servers - instead of on peripheral devices (e.g. desk-top computers). A
second important maxim is 'Write Once Run Anywhere' (WORA). Java programs are to
be portable and scaleable. A Java software developer should not need to rewrite his or her
software program for different platforms. In order to achieve cross-platform
compatibility, Sun has created a standardised application programming environment.
Each system and browser provider must fully implement the specifications and
Application Programming Interfaces (APIs)7 of the standardised Java environment if
WORA is to be achieved.
Since 1995 Java has undergone several changes. In particular the first update in 1996 was
drastic - and not downward compatible, requiring rewriting of Java programs. Later
updates of the platform were incremental. The Java Programming Language appears to
have remained stable over the last few years. The number of APIs has strongly
increased.8 Several system providers, such as IBM and HP, have developed compatible
Java Virtual Machines (i.e. software that runs on proprietary operating systems and is
capable of interpreting compiled Java byte code). The Java ™ version that was
considered for standardisation was the Java 2™ Standard Edition (J2SE) Version 1.2.2. It
consists of the Java Language Specification, the Java Virtual Machine Specification, and
the Java API Core Class Library Specification. This version is largely viewed as a full
programming environment.
4. Compatibility strategies
The basic ideas that underlie Java and Sun's manner of involving others in developing
and implementing the Java platform have led to a large user base. In 1999, according to a
Sun spokesperson, there were more than 1,7 million developers9. This figure consists of
Java developers that work for companies, some of which have more people working on
Java than Sun itself (e.g. IBM), and a majority of independent Java developers.
Cross-platform compatibility is essential to Java development. It is more than a product
asset. It is the essence of WORA. Sun uses and has initiated several strategies to ensure
compatibility in Java software development. They are discussed below under the
headings of 'orchestrated software development' and formal standardisation.
4.1 Orchestrated software development and 'Open Source' Java
Sun started by giving interested parties access to it source code. It invited developers to
comment on, experiment with and improve the original source code.
7
APIs comprise the standard packages, classes, methods and fields made available to software developers
to write programs. (Sun, October 14, 1997)
8
Some say the time to market is set too short because the current set of APIs contains many bugs. (source:
contributor to the NIST discussion list on Java)
9
Baratz, Sun, JavaOne conference 1999
"One of the important things that we did when we first launched Java was to take
the whole source of the system and put it out on our Web site. (…) There was the
crowd of people who just play- they just had fun with it. (…) Then there were the
people who were doing marginally useful things, like porting it, which was very
interesting to watch, that is, watching people port it to lots of different platforms.
But in the end, probably the most important reason for putting the source out was
to allow people to scrutinise it. (…)" (Source: Transcript of James Gosling's
presentation at the JavaOne conference, May 29, 1996)
Throughout the years, the source code has remained available. (At presently, early 2000,
source code of the Java™ 2 platform, Standards Edition has been made available.) But
from the start Sun has retained control over the process. The source code is 'open' in the
sense of being accessible and free of charge, but e.g. the decision of what changes to the
original code are to be carried through in the specification updates lies in Sun's hands,
and commercial use is bound to license restrictions.
Sharing the source code means that the developer community works with the same basic
material. It has a light-weight co-ordinating effect, comparable to the availability of a
voluntary formal standard. Analogously, the instructional books which Sun and other
authors have written on the Java programming language and the Java platform, and the
training programs that lead to 'certified' Java developers feed a co-ordinated development
of the Java trajectory. These activities support the development of a Java practitioner
community, but they do not guarantee compatible Java implementations or prevent
fragmentation of the market.
A more straightforward approach is the distribution of the Java Software Development
Kit (SDK, formerly JDK), which contains 'a full suite of development tools (…) to write,
compile, debug, and run applications and applets' (e.g. implement new APIs) and the Java
runtime environment (i.e. the execution environment needed to run applets and
applications). Use of the SDK narrows down the number of possible programs to those
that run on 'standard' Java platforms. (This may not be the case if developers use Java
Toolkit from other companies; see section 5.1).
4.1.1 Licensing
Sun's most effective means to foster and maintain compatibility is its licensing policy.
Part and parcel of this policy are the test suites that are use to certify compatible Java
products, and use of the 'Java compatible' logo (the steaming cup of coffee) to brand
compatible products. These instruments of control are closely tied to Sun's ownership of
and IPR to trademarks (Java™, Java-Compatible logo), patents (software algorithms) and
copyright (primarily copyright on specifications; documentation seems to be less of an
issue). (See Egyedi, forthcoming)
The company licenses for commercial use of Java pose the most constraints in the use of
Java™ Technology. The Research Use license of the Sun Community Source Licensing
model is the least restrictive. Both are discussed below.
'Technology License and Distribution Agreement' (TDLA)
Usually, licenses for commercial use are kept strictly confidential. In the case of
Microsoft's license to Sun's Java, the confidentiality clause was broken in 1998. From
1997 onwards the two parties were involved in a lawsuit (Sun vs. Microsoft, more is said
in section 5.1). The lawsuit centred on the licensing agreement. To inform the Java
community, Sun published the 'Technology License and Distribution Agreement'
(TDLA) on the web. Licensee reactions to the publicised agreement indicate that Sun
licenses differ according to company10. The TDLA with Microsoft is used here to
illustrate the kind of restrictions concerned.
The agreement came into effect in March 1996. It starts with two recitals on
compatibility that state Sun's interest in maintaining compatibility among Java language
based products and in protecting and promoting its Java compatibility logo. The
subsequent licensing conditions that are most relevant to Java compatibility are
summarised in Table 1. The table shows that the agreement comprises several licenses.
'Technology License and Distribution Agreement' between Sun and Microsoft
License
Contents
Main restrictions
Source Code
and
Development
License to
Technology
SUN grants (…) a license (…) to (…) create Derivative Works of
the Technology in Source Code form for the purposes of
developing, compiling to binary form and supporting Products;
Sun Technology and patents
are only to be used for
development of the Java
platform.
(…) a patent license to develop Independent Works of the
Technology for the purposes of developing, compiling to binary
form and supporting Products;
(..) a license to sublicense and distribute the Source Code of the
Technology and Derivative and Independent Works thereof, to
third party licensees … which may include Licensee's original
equipment manufacturers.
Distribution
License to
Technology
(…) a license to distribute the Technology and Derivative Works
thereof in binary form for internal use, for use by third parties, and
to end-users;
Sun Technology is only to be
used for development of the
Java platform.
(…) a license to distribute development tools such as the
Reference Implementation VM [binary code] and Reference
Implementation Java Classes [source/binary code] among third
parties and end-users.
Sub-licensees should agree to
license the binary RI only in
order to develop products that
significantly add to the RI
functionality.
(…) a patent license to distribute copies of the Independent Works
of the Technology for Licensee's internal use, and - in binary formto distributors and end users as part of the Products.
Documentation
10
(…) a license to create Derivative Works of the Documentation;
and distribute them in connection with distribution of the
Product(s).
Private communication, ECMA meeting, January 1999. Implied was, that more restrictive licenses are
used to check the market activities of immediate competitors. I could also imagine that earlier licensees get
more favourable conditions because they are needed to expand the user base.
License to
JavaScript
… when Sun obtains the IPR to license JavaScript, Sun will state
the compatibility requirements for a license ("which shall be
consistent with the compatibility requirements for other SUN
licensees of JavaScript"). If the conditions are acceptable,
Microsoft may distribute JavaScript products.
Microsoft's products using
JavaScript should be
'consistent' with Netscape's
JavaScript specs11
License to
Microsoft's Java
Reference
Implementation
Microsoft grants to Sun (…) a license to create Derivative Works of
Microsoft's Java Reference Implementation in Source Code form;
and to sublicense and distribute the Source Code of the Java
Reference Implementation and Derivative Works of the Java
Reference Implementation to third party licensees"
…. sublicense "on terms and
conditions no less restrictive
than the terms upon which SUN
licenses the Source Code for its
Technology to such third party
licensees."
… a license to use Microsoft's "Java Reference Implementation
and Derivative Works thereof in binary form for sun's internal use"
and distribute it for third party use
… and a patent license to use and reproduce "sun's Independent
Works of the Java Reference Implementation for Licensee's
internal use" and for third party use.
License to Sun
Test Suites
Sun grants Microsoft … a license to distribute Java Test Suites for
internal use (at no cost); significant upgrades of the Java
Technology are to be accompanied by upgrades of Microsoft's
Java Reference Implementation; it needs to pass the test suites
(compatible implementation).
….a license to use the Java Compatibility Logo that indicates
compatibility with the Java Test Suites (see Trademark License)
… a license to use (the upgrade of) the Java Language Test
Suites at no cost to achieve compiler compatibility.
Compatibility is required with
Sun's most recent version.
Microsoft products may pass the
tests if - although only part of
the Java Classes is
implemented in the product they make the supplementary
classes available to the public.
…on delivery, a license to the JavaScript test suites for internal
use
Trademark
license for the
JavaCompatible
Logo
Sun grants a license to use the Compatibility logo for versions of
Microsoft's products that pass Sun's Java test suites. Sun has the
right to inspect Microsoft's branded products (i.e. products
distributed in association with the logo).
Restrictions on how and where
to display the logo.
Microsoft may not harm the
reputation and goodwill
associated with the logo.
Both parties to the agreement show an interest in expanding their base of users. The
agreement allows Microsoft to make its own Java products, distribute and sublicense
them to third parties - on certain conditions; in exchange Microsoft lets Sun use,
distribute and sublicense Microsoft's Java implementation - also subject to certain
conditions.
Sun expects Microsoft's products to conform to the latest developments of the Java
platform. To test their compatibility, Sun offers Microsoft its test suites. Sun does not
charge any costs for licensing its test suites, which indicates their significance in
maintaining compatibility. If the products pass these tests, Microsoft may use the JavaCompatible logo for marketing purposes. The goodwill that has become associated with
Sun's logo is a result of Sun's compatibility strategies. Since, the logo is a force in itself.
Different from compatibility instruments such as licensing and encouraging the use of the
Java Software Development Kit - which are foremost means to push developers towards
11
(5.7) Microsoft agrees to 'make best effort' to include the Java Application Environment in the new
version of Internet Explorer (3.0).
compatible implementations (compatibility propulsion) -, the logo's value creates a pull
towards developing compatible commercial products (compatibility suction).
Lastly, compatibility is also an issue with regard to the license to JavaScript, a scripting
language for browsers. Microsoft should seek compatibility with Netscape's JavaScript
specs when implementing JavaScript in Internet Explorer. As noted earlier, Netscape's
co-operation with Sun on this matter brought Java applets, and in its wake the potential of
Java Technology, to the attention of a wider public. Compatibility on the level of the
browser platform would bring the ideal of a network-oriented computing environment a
step further.12
Sun Community Source Licensing
Pressed by its licensees to develop a more liberal licensing regime, Sun presents the 'Sun
Community Source License' Principles (SCSL) in December 1998 (Gabriel & Joy). Sun
proposes the 'Community Source' licensing model, which seeks to combine the
advantages of the Open Source licensing model and the Proprietary licensing model. The
advantages of the former model, which is the lesser known of the two, are understood to
be: open source code, more developers working with the code (higher quality, rapid
innovation), participants determine their own priorities, self-organising mechanisms that
balance proprietary and community concerns, and reaping the fruits of each others
work.13 Likewise, in the new model community members are given broad access to the
Java source code and are encouraged to critically partake in developing it. Community
member must sign a license. Every developer can join the community free of charge by
becoming a Research Use licensee (i.e. simple click-through license). The research
license grants "broad experimentation and evaluation rights", and, as was already the
case, grants the use the Java Runtime Environment binary for incorporation into products
free of charge.14
The changes for commercial use of Java are greater. Those who want to deploy their Java
products, retain their intellectual property rights. But the license requires them to be open
with regard to the specs of programming interfaces and related test suites. This trajectory
is covered by the Internal Deployment license (distribution of developed products within
the company, and testing them before launching) and the Commercial Use license (which
is for selling products). The Community Source model




12
Allows commercial entities to use and modify the source code for commercial software
product development without charge.
Allows innovation on the source code without requiring that innovation be returned to Sun.
Allows commercial entities to modify and share compatible source code with other
commercial entities without charge and without mediation from Sun.
Allows licensees to package for resale Sun's Java platform class libraries with virtual
machines from other licensees.15
Microsoft did not fully comply with Sun's request. Netscape and Microsoft later co-operated on a
standardised version of JavaScript within ECMA, which resulted in ECMAscript.
13
For more information on the Open Source model see [EZ report].
14
The SDK source code, for example, has been made available under the SCSL program.
15
www.sun.com
The Community Source license model defines and binds community members. The
community shares expertise and moves the Java platform forward. But Sun continues to
charge fees for companies that want to sell products based on modified source code; and
"products distributed under the Commercial Use license must be branded with the
appropriate Sun logo which requires execution of a separate trademark license with Sun".
Furthermore, error corrections must be given back to the community, regardless of the
kind of license concerned. Sun still owns the 'infrastructure part of the original code and
upgrades' and provides test suites to ensure compatibility.
4.1.2 Sun Community Process
Licensing is one arena of compatibility control and co-ordinated development of the Java
Platform. The Sun Community Process is another. In the same period as the Sun
Community Source Licensing Principles are published, Sun issues The Java Community
Process (sm) Program Manual: The formal procedures for using Java Specification
development process (version 1.0, December 1998). In this manual, Sun unfolds
"(…) a formal process for developing Java™ specifications (…) using an
inclusive, consensus building process that not only delivers the specification, but
also the reference implementation and its associated suite of compatibility tests."
In this version the specifications are those for the Java Application Programming
Interfaces (APIs). It is an elaborate reaction to the criticism that Sun excludes nonlicensees, that Sun monopolises ultimate decisions regarding the Java specification, and
that the Java community and in particular the companies depend on what Sun decides
behind closed doors. The proposed process discusses the procedures that are to be
followed from the stage of requesting a new specification, through to the drafting of the
specification by an expert group and the increasingly wider review process, to its final
release and maintenance. In order to participate in drafting the new specification, i.e. all
phases except participating in the public reviews, one must be a Participant, and sign the
Java Specification Participation Agreement (JSPA). The JSPA confirms Sun's control.
For example, Sun owns the copyright of the developed specifications; Sun or the
Specification Lead own/license the Reference Implementation and Compatibility Test
Suites (an annual maintenance fee is asked); and Sun retains control over the trademark.
Key decisions are made by the Process Management Office (PMO). The PMO consists of
Sun employees. They oversee the process (e.g. selection the person who leads the expert
group that develops a particular specification, is responsible for the development of the
concurrent reference implementation and compatibility test suite, and is responsible for a
transparent maintenance process of the spec, the RI and the CTS) . In independent
auditing firm is to review the community process at key milestones.
The Java Community Process and the JSPA have been criticised. In order to become a
participant a sum of 2000-5000$ should be paid to Sun. Only company employees are
counted as experts. Sun has a veto in deciding which specification request is eligible. Etc.
Harold calls it a gated community process.16 IBM, which has more Java developers than
even Sun has, objects to paying for the trademark. Rick Ross, the founder of the
JavaLobby remarks that "Sun’s open process is broken (…) because only licensees can
participate […and] Sun’s control is too arbitrary.” Ross speaks of a benevolent dictator
and demands a seat at the standards process table for 99% of the – independent - Java
developers.17 A vocal group of criticisers is the working group that wants to develop a
standard on real-time Java extensions18, the Real-Time Java Working Group (RTJWG),
but did not get Sun's support to do so (see section 5.2 in this paper). It comments that19:




Sun's role is too dominant in the JCP
Interests of non-licensees: although non-licensees are able to participate by signing the
Participation Agreement, Sun reserves the right to change Community Process; non-licensees
want to use the specs to create clean-room implementations, they want the Java Compatibility
Kit, and they want the trademark; the JSPA does not provide or address these issues
IPR: Sun retains copyright on the specs - although it is reviewing joint ownership on
copyright - and it retains ownership of the test suites; Sun controls IPR licensing issues of
contributing participants, but they should be controlled by a commercially neutral entity;
derivative work should be outside Sun's control
Conformance testing: Conformance testing should be open, with published tests, and
available to non-licensees
Sun's second (review draft) version of the Java Community Process, which dates from
April 2000, differs in many ways from the first version. It would appear to answer much
of the critique on the first version.20 It starts with a paragraph about the installed base and
guarding against fragmentation. The Executive Committee now largely carries out the
former key role of the Sun-based Process Management Office. This committee represents
"major stakeholders and is responsible for approving the passage of specifications
through key points of the JCP (…)". Its members must have signed the Executive
Committee Participation Agreement (ECPA). The committee consists of 16 members and
a chair. Two of them are Sun employees: one, the committee chair, does not vote except
to cast a tie-breaking vote; the other has a permanent voting seat on the EC. Java
Community Process Members who are not Sun-employed hold the other seats. These
other members are partly nominated within Sun's sphere of influence (10 ratified seats),
partly they are nominated by community members - they can nominate themselves (5
elected seats). In both cases, all Java Community Process Members can participate in the
ballot. All seats have a 3-year term. (see appendix A)
16
'The Java Gated Community Process', Elliotte Rusty Harold, 1999,
http://metalab.unc.edu/javafaq/editorials/jcp.html
17
'Java Lobby president calls for reform', Michael Vizard, InfoWorld Electric, Nov 19, 1998.
(http://www.infoworld.com/cgi-bin/displayStory.pl?981119.ehjavalobby.htm)
18
Namely, in the US National Committee for Information Technology Standardisation (NCITS), ANSI
accredited
19
RT-Java mailing list, Subject: Sun's Community Process, 29 December 1998, the original message is
from Wendy Fong (HP).
20
The scope of this document is also wider. A specification may cover the Java language, the VM,
Platform Edition Specifications, Profiles and APIs. Apart from the reference implementation and the
compatibility test suites, a more elaborate technology compatibility kit is to accompany the developed
specification that includes the latter.
With regard to the major steps in the process, the EC decides whether to proceed. Its
decisions can be tracked in the initial phase, i.e. when a new Specification is proposed.
All the public comments, and the decision, actions , and votes taken by the EC are
published on the JCP web site. Following approval, the Expert Group draws up a
Community Draft.21 The draft is reviewed by the Java Community Process Members, and
balloted. If approved, the draft Specification is posted on the JCP web site for public
review. The expert group makes the necessary revisions, after which the final ballot takes
place. The Specification Lead, i.e. "the person responsible for leading the effort to
develop or make major revisions to the specification, has in the mean time completed the
Reference Implementation and the Technology Compatibility Kit. These are also subject
to the Final Approval Ballot. NB: The Specification Lead is expected to be the main
developer and thus the owner of the specification, the Reference Implementation and the
Technology Compatibility Kit. His or her company is expected to become the
Maintenance Lead after the specification is final. The procedures for maintenance are
specified (including, e.g. the rules for an appeals process) Approved specification is
posted on the JCP web site.
Shankar believes the change is due to " the influence of Pat Sueltz, leader of Sun's
software efforts and the former leader of IBM's use of Java. Sueltz has seen what Java
looks like from outside Sun and assembled a panel to address community control of
Java."22 The review phase of JCP version 2 ends on May 30 2000. The few reactions
there are, are cautious. Possibly the nomination process for the 10 ratified seats, where
Sun retains the initiative, is the cause.
Sun has put much effort into devising licensing regimes and institutional structures that
support the development of Java while maintaining cross-platform compatibility. At stake
is co-ordinated technology development, controlled by licensing and agreements and
based on proprietary ownership of Java in key areas (testing, trademark). The institutional
provisions laid down in the second version of the JCP may signal a change. But much
depends on whether and how the JCPA will be adapted. Its provisions are in some respect
similar to the provisions of standards bodies and standards consortia23: phased approach,
voting procedures, expert groups, apart from the wordings (e.g. specifications, approval
ballot).
4.2 Initiated routes to formal standardisation
Sun announced very early on that its aim was to have Java, which already seemed to
become a de facto standard in 1996, formally standardised by JTC 1. The reasons given,
are that JTC1 approval makes Java "customers, partners and developers feel more
21
Apart from the earlier Java Specification Participation Agreement (JSPA), There is an Individual Expert
Participation Agreement (IEPA) for those who want to serve on an Expert Group.
22
'Sun offers olive branch to Java partners', Stephen Shankland, CNET News.com, March 1, 2000.
23
In one of the critical reviews of the JCP/JSPA version 1.0, the comparison is drawn between Sun's JCP
and the standardisation context of NCITS (- and commented on by Sun). (source: RT-Java mailing list,
Subject: Corrected Comparison of NCITS vs. Java Community Process, 7 January 1999, the original
message is a comment from Doug Johnson (Sun) on Barry Hedquist's comparison.)
confident about investing in it"24. The status of International Standard also makes it easier
for governments to use Java technology, and for other industry standards bodies to refer
to it as a cross-platform technology.25 There may be other reasons, too. For example, to
keep its earlier promise and create further goodwill; or, perhaps Sun sees standardisation
as a mere extension of what it is already doing as part of product development strategy;
or, because Java is said not to be part of its core-business, it may appear to be a good idea
to siphon off its troublesome custodianship to a standards body; or, standardisation may
make it more difficult for competitors to hijack the technology; or, the 'formal'
standardisation trajectory may be seen as a way to certify the means (JCP) and objectives
(compatibility)of Java development.
Sun's initiatives regarding international standardisation started with a failed attempt to get
the Java specifications accepted by the US national body, which could have then offered
it as a work item to the JTC1.
4.2.1 JTC1 PAS procedure
In March 1997, Sun starts it application to become an authorised Publicly Available
Specification (PAS) submitter to JTC1. The PAS procedure is a means for JTC1 to
transpose a publicly available specification that has high market relevance (i.e. de facto
standards) in an effective manner into an international standard. Instead of passing
through the usual stages of committee standardisation, the specification starts out as a
Draft International Standard (DIS), which, if approved by JTC1 members, acquires the
status of an International Standard (IS). In the third edition of 199526, few hard conditions
are made with regard to the candidate PAS submitter. Its approach to specification
development must, however, be compatible with JTC1 rules. In practice, the organisation
should, for example, be 'open' and strive for 'consensus' with regard to the development
of specifications, and conform to JTC1's rules on Intellectual Property Rights. The
criteria leave room for negotiation. Sun is the first individual company to apply as a PAS
submitter. Other PAS submitters at the time are industry consortia (e.g. ATM Forum and
OMG).
In July 1997, Sun's application is rejected. The comments of JTC1 national members
roughly focus on the Sun desire to keep the trademark for itself and have the ISO
standard called something else; what body will be responsible for updating and
maintaining the Java standard; and whether Sun will be open in accepting changes to the
standard.27 Sun responds to the JTC1 comments in September 199728. With regard to
24
Juan Carlos Perez, 'Sun changes strategy for Java's ISO approval', IDG News Service/ Latin America
Bureau, May 6, 1999.
25
Stephen Shankland, 'Sun seeks control of Java process', CNET News.com, May 6, 1999.
26
ISO/IEC Directives; Procedures for the technical work of JTC1 on Information Technology, third edition
1995, Supplement 1: The Transposition of Publicly Available Specifications to International Standards.
27
'Java standard voted down--for now', Tim Clark, CNET News.com, July 30, 1997. According to an
interviewee, an anti- Java™ lobby supported by Microsoft complicated matters. Microsoft wanted its own
Java functionality's enabled.
28
SUN RESPONSE TO ISO/IEC JTC1 N4811 AND N4833, see Sun's web site.



Maintenance: JTC1 working group, which Sun proposes and for which Sun will provide the
project editor, is open to all stakeholders and is to be responsive to the international Java
community;
Intellectual Property:
 Patents: Sun automatically grants users of the Java specs a patent license without
demanding fees or royalties for the use of Sun patents. Sun is willing to extend terms of
current patent policy to cover implementers of the Java international standard.
 Copyright: "Sun has used its copyright to ensure that the Java ™ platform specifications
are openly available and to prevent unauthorised changes. (…) Sun grants ISO/IEC JTC1
(…) all necessary rights to print and sell copies of the International standard without
payment of copyright fees or royalties. Sun will not use its copyright to prevent or restrict
changes to the International Standard that would result from normal JTC1 processes for
maintenance or evolution." According to Sun, JTC1 rules "do not exclude joint-copyright
ownership", which is what Sun wants.
 Trademark: Sun continues to own trademark logos and names. Java ™ is the name of a
product (brand), not of the specification. Sun allows general use for 'ISO-xxxxx, The ISO
specification of the Java™ platform". Implementers can claim ISO-conformance without
passing external tests by Sun. Furthermore, WIPO says: trademarks can only apply to
products and services. ISO has no capacity to hold or defend a trademark.
Open Standards process: Sun tries to reassure the national bodies on this matter by arguing
that its profit depends on co-operation and openness: it cannot move on its own.
In November 1997, the JTC 1 accepts Sun as an authorised PAS submitter. Most of the
votes in favour include comments (JTC1 N5090, November 1997). They refer to
concerns about whom is to be responsible for maintenance and the evolution of Java, and
the influence of JTC1 national members therein. Concern is expressed about the openness
of Sun's development process in competitive situations; product conformance, it is felt,
should be evaluated by independent testing agencies; and use of the Java trademark (Java
™) raises concerns. Most national bodies understand Sun's response to earlier comments
on copyright to indicate that the copyright of the produced Java specs will be JTC1's. But,
in all, they expect that their comments on responsibility for the evolution of Java, their
IPR concerns, etc. will be addressed in the Explanatory that will accompany Sun's
submission of the Java specs. Many national bodies explicitly state that voting yes at this
stage does not automatically include the approval of the specs.
Following the approval of Sun as a PAS submitter, Sun's reaction in the press is that the
outcome of the voting is to be understood as international approval of Sun’s open
standards process. In retrospect, recognition for Sun's Java Community Process may have
been Sun's primary goal. For it has not responded to the last round of comments, nor has
it taken any steps to actually submit the Explanatory Report or the Java specifications to
JTC1. It may have judged that it was unlikely that JTC1 would agree to ratify Sun's work
and leave the organisation of a wider, participatory Java development process to Sun29.
At that point in time, it does not want to surrender control of the evolution of Java.30 Sun
later withdraws from the PAS process, it says, because it does not agree with the change
29
Sun blames MS as Java ISO plans die.'
(http://www.zdnet.com/zdnn/stories/news/0,4586,1014537,00.html)
30
Stephen Shankland, 'Sun revising plan for Java recognition', CNET News.com, April 29, 1999.
of rules for the PAS procedure, which was voted on in November 1998.31 According to
the new procedures, Sun would have to turn control over to JTC1 regarding the
maintenance of the standard and the evolution of Java. Standards maintenance would not
be restricted to minor adjustments such as bug-fixing, as it had hoped.
An interviewee mentions that too much had happened between Sun and JTC1 - in
particular the US representatives that participated in the JTC1 process. Personal friction
and unbacked strong stances (‘we would never ...’) made future, constructive cooperation impossible. Sun does not want to seem anti-standards and turns to ECMA.
4.2.2 ECMA and the fast track procedure
In April 1999, Sun approaches the ECMA to discuss Java standardisation32. The ECMA,
an international Europe-based industry association for standardising information and
communication systems, has produced standards since 1961. There are several reasons
why Sun may have approached ECMA. First of all, ECMA's access to the Fast-Track
procedure may have been one of the reasons to turn to ECMA. It has close ties with the
formal European and international standards bodies. It is an A-liaison member of JTC1
(i.e. a liaison for organisations, which contribute actively in many standards committees).
This status gives it access to ISO/IEC's Fast-Track procedure, a procedure on which the
PAS procedure has been based. The Fast-Track procedure allows a standard, regardless of
its origin, to be put to the vote as a Draft International Standard without going through prior
stages. In the past ECMA standards were submitted to a yes/no vote in JTC1 without
modifying them. By keeping open the option to international standardisation, continuity in
Sun's standardisation strategy is suggested.
Other reasons could be that Sun was already an ECMA member and had good previous
contacts with the forum; that ECMA has a good reputation in timely delivery of its
standards and good distribution channels; many large companies are members, so ECMA
processes promise to be relevant in respect to 'pre-market co-ordination'; and lastly, the
distribution of power within the ECMA could have been favourable to Sun (e.g. Sun's
opponent in the lawsuit, Microsoft, was a too influential player in US national body and
in JTC1).
During the negotiations, Sun expects ECMA to agree with "passive maintenance" of the
Java standard, meaning that Sun would in essence remain the gatekeeper 33 of Java
development through the Java Community Process, and forward Java updates through
ECMA to ISO. However, the two parties ultimately appear to agree to a programme of
work for the installed ECMA TC 41 (see box) that leaves room for a mode of
standardisation that goes further than ‘bug fixing’.
31
(JTC1 N5746, The transposition of Publicly Available Specifications into International Standards - A
management Guide, 1999-01-29) Microsoft, HP and others according to Sun, brought about the changes
from the 'Wintel world'. The 'Wintel world' and Sun lobbied strongly for/against a change in PAS rules. ()
32
Stephen Shankland, 'Sun renews Java standards effort', CNET News.com, May 5, 1999.
33
(Shankland, May 6)
ECMA TC41 on Platform-Independent Computing Environments
Scope: To standardise the syntax and semantics of both general-purpose and domain specific
platform-independent computing environments.
Programme of Work
1. Develop a standard for a cross-platform computing environment based upon the Java 2™
Standard Edition (J2SE) Version 1.2.2, specification that consists of the Java Language
Specification, the Java Virtual Machine Specification, and the Java API Core Class Library
Specification.
2. Contribute the standard to ISO/IEC JTC 1.
3. Upon completion of item 1, to assume responsibility for the maintenance of the ECMA
standards prepared by this TC with a commitment to preserving binary and source
compatibility across platforms, and compatibility with the initial ECMA standard.
4. Upon completion of item 1, development of standards based upon other platform-independent
Java technology specifications ensuring compatibility with the initial ECMA standard and
preservation of binary and source compatibility across platforms.
5. Maintain liaison with appropriate other standards developing bodies, consortia, and forums.
6. Maintain liaison with appropriate other ECMA TCs and TGs
The first TC41 meeting took place in October 1999. During the meeting, Sun emphasises
that ECMA TC41 aim should focus on ‘edition rather than addition’ of Sun’s Java specs.
The committee discusses the use, which Sun would permit of the Java specs. ECMA rules
on this matter are that "an ECMA Standard has never been copyrighted. (…)
Contributions can bear copyright: this is fully acceptable if the owner of the contribution
permits the use of the contribution for standardisation.(…) The [Java] specification is
copyrighted by Sun, with permission to use it for standardisation purposes. It will be the
principal document for the work of TC41, and will be made available as an ECMA
working document (…).”34
To questions regarding the maintenance of the ECMA standard and maintenance
compatibility between the ECMA and ISO/IEC standard, the ECMA SG answers that
ECMA has several mechanisms available35, as does the ISO/IEC. Usually ISO/IEC does
not treat contributions from other fora (ECMA) as a new project. ECMA TC41 has an
34
ECMA/TC41/99/16, Minutes of the 1st meeting of ECMA TC41.
The ECMA approach to the standards maintenance issue in ECMA depends on the circumstances.(WW)
maintenance scenario 1: ISO working group
With regard to the PCTE (portable tool environment), a recent example, the fast-track procedure was
invoked. JTC1 comments on the ECMA draft were processed by an ISO working group in co-operation
with the ECMA TC. The same mode of co-operation was followed in revising the PCTE standard.
maintenance scenario 2: ad hoc group
ECMA script was a smaller standard, and was also fast-tracked to JTC1. One ad hoc meeting was organised
within ISO - i.e. it was not really a Work Item in ISO - together with the project editor of ECMA. After this
one-time ad hoc meeting it was published as an IS.
35
official liaison with the JTC1 SC 2236 Java Study Group, whose input will asked before
formally invoking the fast-track procedure.37
JTC1 SC22 thinks this Study Group should be the one to address the PAS-/fast-track
procedure of Java. The chair of this group maintains contacts with ECMA TC 41. He is
supported by the study group, which allows the study group to indirectly influence the
ECMA process. Relevant to Java standardisation is that in this period (October 1999) a
successor is sought for the current chair of JTC1 SC22. The resigning chair is participant
in ECMA TC41 for the OMG. There are two candidates: one from SUN and one from
Microsoft. Both did not get the required 75% of the votes.38 The acting chair is a Sun
representative.
During the meeting, Sun was to distribute the Java 1.2 specification on CD-ROM.
However, one of the Sun representatives announces at the end of the meeting that "Sun
lawyers require somewhat more time to further consider IPR issues."39
Late 1999 it becomes clear that Sun will not contribute the Java specifications to the
ECMA TC41. A second TC41 meeting is held to explore whether it would be feasible to
draft a Java 2 standard partly with material from other companies and partly by normative
referencing to Sun’s Java specs. It drafts the following recommendation for consideration
by the ECMA management:
“TC41 recommends that it proceed with the current program of work using published Sun
documents as a normative reference instead of incorporating them in the ECMA
document. ECMA should approach Sun to request its agreement to the referencing of its
documents in an ECMA and possible ISO/IEC standard.”40
But one of the Sun representatives expressed doubts whether Sun would agree with
normative referencing. He mentions IPR problems – without going into any details - and
indicates that Sun might, for example, request a licensing agreement with ECMA TC41
for working on the specification.
ECMA TC41 is formally disbanded in March 2000. Several reasons are given for Sun's
withdrawal. First of all, the most specific pointer in Sun's press release is that "(…)
ECMA has formal rules governing patent protections; however, at this time there are no
formal protections for copyrights or other intellectual property." (December 7, 1999) Sun
differentiates between a copyrighted specification and a copyright of the contents of the
specification, that is, between a specification and a piece of software (i.e. software
product). It was Sun's intention "to provide ECMA with a derivative copyright but that
36
JTC1 SC 22 is the standards committee for Programming Languages, their Environments, and System
Software Interfaces
37
Private notes, TE.
38
Interview with former chair of SGFS, 7 October 1999.
39 ECMA/TC41/99/16, Minutes of the 1st meeting of ECMA TC41
held in Menlo Park (USA) on 25th - 26th October 1999.
40
ECMA/TC41/2000/1, Minutes of the 2nd meeting of ECMA TC41
this has to be treated as an IPR, under a copyright license agreement"41, but it could not
find a compromise that would be acceptable to both Sun and ECMA.
However, George Paolini, vice president of Java community development at Sun, gives a
different reason. He says in a letter to ECMA that Sun decided to keep control of Java
within its Java Community Process. "The Java Community Process has expanded its level
of activity to a point where we now believe the interests of the entire Java community
will be best met by continuing to evolve the Java specifications with the open JCP
process," Paolini wrote.42
But some participants believe that Sun cannot hand over its copyright to ECMA because
that would jeopardise its position in the lawsuit against Microsoft, which is at time still
not finished.43 (See also section 5.1)
4.3 Compatibility strategies compared
The above sections illustrate various compatibility strategies. They contribute in different
degrees towards fostering compatibility. Some strategies are focused, others are more
diffuse; some are forceful, while others are more lightly coercive; some strategies are
based on proprietary control, while others are based on broad involvement of
participants; some focus on the early stage of product development, others on handling
mature products. Table 2 summarises those discussed in the text.
Degree of pressure Light/coercive
Stage in Java
development
Early
 Open source code
 Instructional books Certified
training programs
Mature
 Distribution of the Java
Software Development Kit
 ANSI/JTC1 standardisation
 JTC1 PAS procedure
 ECMA/JTC1 Fast-Track
procedure
Heavy/forceful
 Java Community Process
 Java Specification Participation
Agreement
 Reference Implementations
 Test suites
 Java-Compatible logo
 Licensing (IPR)
 Sun Community Source
Licensing model
 Technology License and
Distribution Agreement
Table 2: Categorisation of the compatibility strategies used by Sun arranged according to
the assessed degree of pressure exerted towards compatibility and the level of
technological maturity concerned.
41
ECMA/GA/99/127, Minutes of the meeting of the Co-ordinating Committee held in Geneva on 11th 12th November 1999.
42
'Sun offers olive branch to Java partners', Stephen Shankland, CNET News.com, March 1, 2000
43
Informal communication with ECMA TC 41 participants.
All these strategies, and in particular the ones which are forceful, may contribute to the
positive externalities that come with cross-platform compatibility. The main externalities
are 44



for developers: to write only one program, reduction of costs for development,
support and distribution, time-savings
for organisations with different system platforms and browsers: reduction of expenses
for software development, procurement, maintenance and support
for third part media providers of browser programs (programs that run on browsers)
and of service providers: to write only one program, reduction of costs for
development, support and distribution, time-savings
But some of the forceful strategies also have negative externalities. There is a risk of
alienating independent software developers in the way the first version of JCP was set up.
It contains a company-based approach. There are also risks to restrictive licensing
agreements and a strict definition of an in-group and an out-group (JSPA), especially
when Sun heavily depends on third parties for co-developing and implementing Java.
Sun's initiatives on developing Java specifications involve two Java standardisation
initiatives, the JTC1/PAS procedure and the ECMA/Fast-track procedure, and its own
Java Community Process. As indicated in Table 2, Sun did not approach the two
standards bodies with the idea that it would hand over the evolution of Java to these
bodies. The initiated standards activities appear to have been attempts to certify ongoing
product development, and accredit previously developed, largely mature specifications - a
role to which neither forum agreed. The two standards fora are in another sense
comparable. During the preliminary standards activities in ECMA, Sun insisted on
'edition, not addition'. Indeed, this might best have served the market. But it also
illustrates that 'rubberstamping' - which is a crude generalisation of the work which
'edition' would nevertheless entail - is a practice which takes place in standards consortia
and JTC1.
From Sun's point of view, voluntary international standards receive wide acceptance. But
it has little faith in their ability to foster and maintain compatibility. Sun does not want to
relinquish control over the decisions making process. Figure 3 situates the three
specification development environments of JCP, JTC 1 and ECMA against the
dimensions of multi-party decision making and multi-party input. Sun starts with the JCP
(much multiparty input, largely proprietary decision making); it then initiates a PAS
submitter application for JTC1 (wide input, high on the multi-party decision making
dimension- also in respect to draft international standards); after a brief period in which it
develops JCP version 1 (less open in all dimensions), Sun subsequently turns to ECMA
(which has a higher threshold to participate than JCT1 but is a multiparty forum with
respect to input and decision making); and Sun is back, for the moment, to the revised
JCP process, which reserves more room for multi-party decision making than the original
44
Sun, October 14, 1997, p.24.
Multi-party
JCP did. The figure illustrates that the control dimension (i.e. the degree of multi-party
decision allowed) primarily explains Sun's subsequent steps.
JCP
JTC1/ PAS
1997
Input
JCP 2
JCP 1
1998
ECMA (FT)
1999
1995
Single
Multi-party
Decisions
Sun Compatibility Strategies for Java:


Product Development
Standards Development
Figure 3: Sun's subsequent choice of forum characterised on the dimensions of multiparty input and decision making. The fora emphasise product or standards development,
respectively.
The figure also tries to distinguish between product and standards development fora.
Usually the difference is clear. In such situations, according to Ferné (1990, p.13), what
committee standards lose in market control they gain - in comparison to de facto
standards - in network externalities. In the case of Sun's Java, compatibility is essential to
Java development; the distinction in figure 3 is therefore a relative one. As a
consequence, the additional externalities that he refers to are also less evident.
5. Instances of Failing Co-ordination
There are two clear instances where Sun, despite its strategies of licensing, formalising
the JCP, etc., could not forestall other players to initiate actions that could lead to
fragmentation of the Java market. The first example concerns the way Microsoft used
Java, and for which Sun sued Microsoft. The second example concerns real-time Java,
the development of which is now taking place within and outside of Sun's realms.
5.1 Lawsuit Sun vs. Microsoft
In October 1997, Sun files a complaint against Microsoft for breaching its contract for
licensing Java™ Technology (i.e. the 'Technology License and Distribution Agreement';
see section 4.1.1). The agreement obliges Microsoft to make implementations that are
compatible with Sun's Java platform. However, Microsoft has developed a platform
dependent Software Development Kit for Java . It contains a different set of
functionalities than the Sun toolkit. Program developers are led to think that their
programs will run on all Java Virtual Machines, while this may not be the case. Since the
syntax which Microsoft uses suggests that Sun is the author of the 'alien APIs', Sun is
likely to be accused of not delivering a 'Write Once, Run Anywhere' platform. For
example, Internet Explorer (IE) version 4.0 does not pass the Java compatibility tests 45.
Sun wants to forestall fragmentation of the market - as happened to Unix ® - and prevent
Microsoft from improper use of Sun's Java™ Compatible Logo, which Microsoft uses on
its consumer packaging and in promotional materials. Sun accuses Microsoft of
deliberately attempting to break cross-platform compatibility of Java software46.
The judge believes that Sun has a case, and grants Sun a preliminary injunction based on
Microsoft's infringement on Sun's copyrights. Microsoft may not use Sun's 'Java
Compatible' logo unless its products pass the test-suites, and the spring of 1998 Microsoft
is also prohibited from using Sun's Java Compatible™ logo to promote and distribute
Internet Explorer 4.0. The lawsuit takes an unexpected turn Microsoft's appealed to a
higher court on procedural grounds. The core of Microsoft argument is that it has not
infringement on Sun's copyright; the matter should be dealt with as a breach of contract.
This means in effect that the hard measure, the preliminary injunction, should be
revoked.47 Sun could not convince the court otherwise48. Microsoft's appeal was granted
in the summer of 1999.
In response, Sun appealed and filed a new lawsuit in which it accused Microsoft of unfair
competition. January 2000 the court decided that, indeed a breach of contract was at
stake, and not copyright infringement. But the second case was decided in Sun's favour.
Most of Sun's arguments that Microsoft was competing unfairly were deemed correct.
Therefor the Preliminary Injunction was reinstated - and acerbated. The first injunction
rules that incompatible products may not carry the logo; the second injunction prescribes
that the product must be changed. In effect,

45
Microsoft may carry out no Java business - unless products such as SDKJ 2.0/3.0 and
VJ++ 6.0 support Sun's JNI ( pass the compatibility tests)
Concerned are the Application Programming Interfaces (APIs). For example, Microsoft's IE does not
support Java Native Method Invocation (JNI).
46
Jack McCarthy, 'Microsoft stymied in Sun Java case', IDG News Service\ San Francisco Bureau,
February 25, 2000 (www.idg.net).
47
The 'Technology License and Distribution Agreement' contains much lighter measures in case of breach
of contract, namely which allow Microsoft to largely buy-off its conduct and stall any effects on the sales
of products.
48
That is, it could not convince the court that respecting copyright, it being part of the compatibility
requirements, is an additional condition to the license.


Microsoft' s product must by default disable Microsoft's keyword extensions in the
compiler, and it must include a dialog box that warns the user of Microsoft's
extensions that their use may lead to incompatibility with Sun's specs.
Microsoft may not falsely suggest compliance with Sun's Java specs.
In the box, I quote a number of relevant parts from the latter court order that illustrate
what was at stake.
Quotes from the US court order regarding Sun vs. Microsoft on 'unfair competition'
(United States District Court For The Northern District Of California, January 24, 2000)






"(…) threatened fragmentation of the Java programming environment (…)" (p.5)
"Microsoft's unparalleled market power and distribution channels (…) pose a significant risk
that an incompatible and unauthorised version of the Java Technology will become the de
facto standard." p.5
"(…) Microsoft introduced strategic incompatibilities in its implementations of the Java
Technology (…)[and] excluded Sun's JNI native method interface (…)" p.7
"software developers are naturally motivated to create software applications for the operating
system platform having the largest installed base (…)" p.8
"Microsoft has falsely advertised that its implementation of the Java Technology is the
'official reference implementation' (…)" (p.9) and made other false and misleading statements
suggesting compliance to Sun's specs (e.g. Microsoft's white paper "Integrating Java and
COM". (p.9-10)) Microsoft's representations are likely to confuse or mislead developers into
thinking that (1) Sun approves of Microsoft's extended Java programming technology, (2) the
such extended Java programming technology complies with Sun's specifications, and,
therefore, (3) is a compatible addition to the standard Java programming and runtime
environment."
The preliminary injunction entailed that Microsoft should replace the Java incompatible 4. 0
version of Internet Explorer with a compatible one. However Microsoft's provisions for
installing Java compatible IE 5.0 is counterintuitive.
The lawsuit is likely to have had a strong influence on Sun's compatibility strategies in
the period between October 1997 and January 2000. Its copyright and trademark
licensing provisions could not prevent Microsoft from using Java in damaging ways.
Microsoft's dominance in the market, its lack of 'fair play' and the means it has at its
disposal to influence JTC1 standardisation, makes going public with Java specifications a
hazardous enterprise - both for Sun's business and for the Java ideology.
5.2 Real-Time Java: J consortium
The real-time Java platform serves the market of small devices, an area for which the
Java Virtual machine is too elaborate. An IBM representative mentions examples such as
"the Barney doll which uses infrared to talk to the TV, cruise missiles and telephone
switches" (Gage, 1999). It is a highly expanding market.
June 1998 the US National Institute of Standards and Technology (NIST) started a series
of workshops to specify their requirements for real-time Java extensions. Sun
participated, together with many of its competitors. The result was a document with corerequirements. Many of those who had attended thought Sun's JCP environment was too
restrictive for developing a real-time Java standard (e.g. Microsoft, HP, NewMonics).
Negotiations with the 'Sun-camp' failed. They founded the Real-Time Java Working
Group (RTJWG). In an effort to proceed their activities as a technical committee within a
more neutral environment, the US National Committee for Information Technology
Standardisation (NCITS/ ANSI) was approached. After initial approval, the attempt
stranded during the second round of voting in February 1999. ANSI feared that the
initiative would fragment the market . (Jensen, 1999; Bowen, 1999) The working group
then formed the J consortium, an industry consortium for developing embedded Java
49
applications. In March 1999, Sun publicly announced the establishment of a
multivendor Real-Time Expert Group (RTEG) led by IBM.
In September 1999, the Java consortium releases it specs for embedded Java. A 45 day
public review is held. Because the specs are based on clean-room Java software (and does
not use Sun technology), the consortium has no copyright obligations. It can make the
spec royalty free and publicly available. (Gonsalves, 1999) Wendy Fong (HP member,
president of the J Consortium) expects that because the two groups depart from the same
set of requirements, their specs will not differ too much (Gonsalves, 1999)
February 2000 the J Consortium applies to JTC1 to become a recognised PAS submitter.
The JTC1 ballot closes on the 6th of June 2000.
6. Conclusions
The lawsuit raises the question whether arguments of compatibility ought not to be more
fully recognised by the legal regime as a general interest issue. Instead, in the Sun vs.
Microsoft lawsuit it was dealt with as an issue of market competition, an area in which
the judicial system appears to have the most elaborate legal instruments. The current way
in which the US deals with these matters, forces individual companies who want to
partake in standardisation, to devise elaborate IPR systems, since the default legal regime
prioritises other - commercial - values. Europe appears to be following suit with a
Directive on software patenting.
Sun's strategy on Java product development (JCP, in particular version 1.0) and the two
abandoned initiatives towards standardisation (JTC1 PAS procedure and the ECMA/
JTC1 fast-track procedure) are as confusing as Sun's conflicting aims, i.e.: combining the
involvement of many in developing the Java platform with preserving cross-platform
compatibility in a controlled, proprietary way. In devising increasingly elaborate legal
control mechanisms, its has focused on large companies. Its dealings with independent
Java developers have suffered. So has its relationship with the standards fora. With
hindsight, it is difficult to understand that these fora and Sun did not clarify the difficult
issues (IPR and maintenance) before embarking on standardisation. Whether Sun
misused these fora to demonstrate its willingness to standardise Java, or to get its JCP
49
Partly the membership of the two real-time groups overlap.
approach accredited as being 'open'; or whether it panicked because of the Microsoft
lawsuit, or competing real-time Java initiatives; or whether the standards fora themselves
were too avid in including Java and had an interest in keeping their conditions unclear
- the answer may be manifold. What is certain, is that Sun has created a market and an
aim, which is highly valued. In the minds of many developers, Java has become public
property, a feeling that underlies the demand for standardisation. Of interest is whether
Sun's new Java Community Process together with the Participant Agreement will succeed
in meeting the quest for 'open standards', and bind independent and company Java
developers to the cross-platform ideals.
Proprietary product development that centres on compatibility and (partial) open source
code deserves attention from the public interest angle. Proprietary measures have many
disadvantages, but they are forceful in co-ordinating the market. In particular in respect
standards maintenance and certification, it may be hazardous to dismantle proprietary
solutions during PAS and fast-track procedures. By applying an elaborate control system,
Sun has largely succeeded in preventing market fragmentation. One difficult area of Java
remains: real-time Java. If the J consortium becomes a PAS submitter, it will have the
further lead in defining the specifications. It is to be hoped for Sun that real-time
activities of the RTEG will be considered from a technical angle in JTC1 - i.e. that the
national JTC1 members have some goodwill left.
References
Blankart, Ch.B. & G. Knieps (1992). The Critical Mass Problem in a Dynamic World:
Theory and Applications to Telecommunication. In: F. Klaver & P. Slaa (Eds.),
Telecommunication, New Signposts to Old Roads. Amsterdam: IOS Press, pp.55-63
Bonino, M.J. & M.B. Spring (1991). Standards as change agents in the information
technology market. Computer Standards & Interfaces, 12, pp.97-107.
Bowen, Ted Smalley (May 8 1999), 'J consortium forms to push for independent
embedded Java', Info World Electric. [www.infoworld.com]
Brian Krebs, Newsbytes 1/25/2000.
Cargill, C.F. (1989). Information Technology Standardisation. Theory, Process and
Organisations. Digital Press, Digital Equipment Corporation.
David, P.A. (1985). Clio and the Economics of QWERTY. Economic History, 75 (2),
pp.332-337.
David, P.A. & S. Greenstein (1990). The economics of compatibility standards: an
introduction to recent research. Economics of Innovation and New Technologies,
Vol. 1, pp.3-41.
Egyedi, T.M. (1999a). ‘’Tension between Standardisation and Flexibility’ Revisited: A
Critique’, in: K. Jakobs & R. Williams (Eds.), Standardisation and Innovation in
Information Technology SIIT '99, Conference proceedings, 1st IEEE Conference
on Standardisation and Innovation in Information Technology (SIIT '99), Aachen,
Germany, September 15-17, 1999, Piscataway, NJ: IEEE, pp. 65-74.
Egyedi, T.M. (2000). ‘Institutional Dilemma in ICT Standardisation: Co-ordinating the
Diffusion of Technology?’, in: K. Jakobs (Ed.), IT Standards and
Standardisation: A Global Perspective, London: Idea Group Publishing, pp. 4862 (ISBN 1-878289-70-5).
Egyedi, T.M. (forthcoming). Judicio-standardisation regime: IPR paralysis in Java
standardisation. To be presented at the HICCS conference, Hawaii.
Ferné, G. (1990a). The Economic Stakes in Computer Standardisation. The OECD
Observer, 64 June/July, pp.9-14.
Fleck, J. (1988). Innofusion or diffusation: the nature of technological development in
robotics. Edinburgh PICT Working Paper No. 4. Edinburgh: Edinburgh
University.
Gage, Deborah (January 12, 1999). 'Real-Time Java dispute comes to a head this week',
[www.Znet.com/pcweek]
Gonsalves Antone (September 22, 1999). 'J consortium to release embedded Java spec
for review', [www.Znet.com/pcweek]
Jensen, E. Douglas (January 24, 1999). Real-Time Java Status Report, Revised Draft,
http://www.real-time.org/no_frames/noteworthy/rt-java_summary.htm
Katz, M.L. & C. Shapiro (1985). Network externalities, competition and compatibility.
American Economic Review 75, pp.424-440.
Mahonen, P. (2000). 'The Standards Process in IT - Too Slow or Too Fast', in: K. Jakobs
(Ed.), IT Standards and Standardisation: A Global Perspective, London: Idea
Group Publishing, pp35-47.
Reddy, N.M. (1990). Product of Self-Regulation. A paradox of technology policy.
Technological Forecasting and Social Change, 38, pp.43-63.
Schmidt, S.K. & R. Werle (1998). Co-ordinating Technology. Studies in the International
Standardisation of Telecommunications. Cambridge, Mass.: MIT Press.
Sun (October 14, 1997). Amended Complaint. (Sun vs. Microsoft lawsuit)
Sun (February 27, 1998). Memorandum of Points and Authorities in Support of Sun
Microsystems, Inc.'s Motion for Preliminary Injunction, No. C 97-20884 RMW
(PVT) ENE, United States District Court, Northern District Of California, San
Jose Division. (Sun vs. Microsoft lawsuit)
United States District Court For The Northern District Of California (January 24, 2000),
No. C 97-20884 Rmw (Pvt), Order Re Sun's Motion To Reinstate November 17,
1998 Preliminary Injunction Under 17 U.S.C. § 502 (Sun vs. Microsoft Lawsuit;
copyright infringement)
United States District Court For The Northern District Of California (January 24, 2000),
No. C 97-20884 Rmw (Pvt) Order Re Sun's Motion To Reinstate November 17,
1998 Preliminary Injunction Under Cal.Bus. & Prof. Code §§ 17200 Et Seq. (Sun
vs. Microsoft Lawsuit; about unfair competition)
Weiss, M.B.H. & M. Sirbu (1990). Technological choice in voluntary standards committees:
an empirical analysis. Economics of Innovation and New Technology, 1, pp.111-133.
Williams, 1999). 'ICT Standards Setting from an Innovation Studies Perspective', in: K.
Jakobs & R. Williams (Eds.), Standardisation and Innovation in Information
Technology SIIT '99, Conference proceedings, 1st IEEE Conference on
Standardisation and Innovation in Information Technology (SIIT '99), Aachen,
Germany, September 15-17, 1999, Piscataway, NJ: IEEE, pp. 251-261.