1. Introduction and Summary
Sun has submitted an expansive response to the comments of the prior "No" JTC 1 vote. However, there is no substantive change in Sun’s position: it desires both ISO PAS status and control over the evolution of the Java "standard." Sun will continue to set the rules for evolution and branding of Java and asks ISO to endorse the Sun Java product and distribute Sun-authored specifications. Sun plans to maintain control over all substantive changes and enhancements to the Java technology. At the same time, Sun seeks to gain ISO as an endorser, if not an advertiser, of Sun’s products via the use of an "open" specification name that explicitly references Sun’s proprietary implementation.
Sun’s application contradicts basic principals of open, international standards and the rules of fair play previously required by ISO and other consensus efforts.
Restating, Microsoft recommends that the U.S. National Body vote "no" on the revised application because Sun, in large part, has ignored the National Body comments and not substantively altered its stance on:
And this single, for-profit, company has not demonstrated that it can be a neutral steward of an international standard as evidenced by:
2. Background
In March, 1997, Sun Microsystems Inc. applied to the ISO/IEC JTC 1 to be designated a submitter of publicly available specifications (PAS) of certain Java technologies under the guidelines of Document ISO/IEC JTC 1 N3660. Sun is the owner of a set of technologies it describes as "the Java Platform" and seeks to submit the specifications for that platform as proposed International Standards.
The application was initially opposed by a number of organizations, including Microsoft, on the grounds that Sun is seeking to have its products accepted as International Standards while simultaneously retaining complete control over them. Sun should not be given the benefit of ISO standardization of its technologies while controlling them as proprietary products that compete with vendors like Microsoft and others. A majority of ISO member National Bodies held similar views and rejected Sun’s application.
3. Sun Has Refused to Give Control of the Proposed Java Standard to ISO
3.1 A Majority of National Bodies Requested JTC 1 Control
One of the common themes in the responses of the National Bodies was the need for Sun to give JTC 1 control over the future evolution of any Java-based ISO standard. Appendix A summarizes relevant statements made by 19 of the 25 voting National Bodies in this regard.
3.2 Sun’s Response to the Evolution Issue is Indirect But Clear: Sun Retains Full Control
Sun’s Response avoids a direct answer to the most important question in this proceeding: Assuming Sun’s submission is accepted, who controls evolution of the Java specification? Sun’s failure to give an explicit answer to this question is disconcerting considering its overriding importance.
Note that Sun does answer the question indirectly. It takes analysis to decode, but once that effort is made, there is no doubt about the answer: Sun and its "open" process, not ISO JTC 1, will control the evolution of Java.
To derive Sun’s answer consider these questions in turn: Is Sun’s offer of co-managed "maintenance" of the Java specifications an offer to give ISO JTC 1 control over the evolution of the specification? If not, what does Sun see as JTC 1’s role in future evolution of the specification? Finally, are there statements by Sun outside its Response that clarify its intentions? This is not an issue that can be left for later resolution.
3.2.1 Sun’s "Maintenance" Offer is Narrow and Its Procedure is Novel and Unnecessary
Throughout Sun’s Response, "maintenance" is used narrowly and mechanically. In ISO terminology "maintenance" is construed more broadly to include full evolutionary control. But in Sun’s Response "maintenance" is clearly distinguished from evolution in the interesting sense of substantive changes, additions, or deletions to the "platform." For example, "maintenance" is twice described as "handling defect reports, writing draft technical corrigenda, writing draft amendments, and carrying out the 5-year periodic review of the International Standard." [Sun Response, Section 2.1.] These are narrow activities that refine in mechanical fashion the substance of an existing specification. There is no mention of new APIs or other significant enhancements to the "Java Platform."
Moreover, the narrow "maintenance" offer is coupled with a requirement for the creation of an new kind of JTC 1 "Working Group." This "Working Group" appears to consist both of traditional JTC 1 members and processes but also contains novel elements mixed together in an ill-defined way. In the words of Jim Mitchell, Vice President of Sun for Technology and Architecture, at a press conference the same day that the Response was filed,
Second, regarding maintenance: Sun agrees that JTC-1 processes must control any international standard that results from our PAS submission. We also believe that maintenance activities related to the International Standard must include the international Java community. Since current JTC 1 procedures do not allow the level of participation in a typical Working Group that our open specification process does, we propose a solution that should satisfy all interested parties: Sun will carry out maintenance of the International Standard on behalf of the Java community using our established open process and we will also participate in JTC-1 internal maintenance processes.
Sun seeks to justify this innovation by asserting that to do otherwise would exclude "active participation of all interested parties (including industry experts, Java source-code licensees, software developers, and the general public)." [Sun Response, Section 2.1.]
There is no justification for this assertion. JTC 1 procedures are far more open than Sun’s "open" process. Industry experts, software developers, and the general public are able to work freely within the context of their National Bodies to provide the necessary input into JTC 1 Working Groups. There is no basis in fact for Sun’s hybrid process. Sun desires greater control than it would otherwise have, even in the narrow area of mechanical maintenance.
In sum, Sun begins its maintenance comments with the broad, reassuring statement that:
Sun agrees with the National Bodies that JTC 1 must control any International Standard that results from a PAS submission by Sun and that maintenance of the standard must be carried out with the approval and consensus of the National Bodies following established JTC 1 procedures.
Close examination of the remainder of Sun’s Response makes the expected interpretation of this sentence untenable. Instead, we conclude that Sun is (a) stating the truism that no ISO standards can be adopted or changed without an approving vote by the National Bodies and (b) incorrectly asserting that its proposed hybrid model for maintenance "follow[s] established JTC 1 procedures."
3.2.2 Sun’s Vision for the Role of ISO JTC 1 in Java Evolution Is Unacceptably Narrow
Since substantive changes to the Java specification are omitted from Sun’s definition of maintenance, we must look elsewhere for Sun’s view of what role JTC 1 might play in this pivotal area.
The answer is found in Section 2.6 of the Response, entitled "Sun’s Open and Inclusive Development Process." This section begins with an expansive review of Sun’s "open" process. In the sixth paragraph, however, we find a major shift in meaning. Sun describes how ISO JTC 1 and the National Bodies will fit into this process in the future: "Members of standards developing bodies, JTC 1 subcommittees, working group, or National Bodies will be included in this process at the same level as our licensees."
That sentence is the only statement Sun makes on the role of JTC 1 in the future evolution of the Java platform. In it, Sun relegates JTC 1 to the ill-defined status of its 150+ commercial licensees. JTC 1 and its member National Bodies will be a few more voices among the many supplicants for Sun’s attention (and perhaps receiving as little in response).
Paragraph six of Section 2.6 continues, "Any changes, corrections, or additions to the International Standard will flow through the normal JTC 1 procedures for consideration and voting by the National Bodies." However, in light of the context and Sun’s discussion of maintenance, this statement cannot mean more than the truism that JTC 1 and the National Bodies must vote on and approve any future changes to the ISO specifications. It says nothing about the process by which new specifications will emerge to be voted on up-or-down by JTC 1. According to Sun, that process is its current "open" process, as the remainder of Section 2.6 makes clear.
3.2.3 Sun’s Executives Stated Its Intentions On the Day The Response Was Filed
The basic position of Sun regarding the role of ISO JTC 1 in the future evolution of Java can be discovered by a careful reading of its Response. In addition, Sun itself provided JTC 1 and its National Bodies with additional confirmation of its intentions during a press briefing held the day that Sun’s Response was filed. Lisa Poulson, Senior Manager of Public Relations at JavaSoft, responded to a series of questions from the press on the topic "who controls Java?"
Poulson: I think part of the reason this is becoming a big issue is because people are thinking maintenance means a lot more than it does. Maintenance just means fixing bugs and fixing ambiguities. It does not mean adding new things to the Java platform at all. So it is simply the specifications you've already submitted, we found a bug or we found some warning that needs to be changed. So, it's housekeeping. [emphases added]
Q: All right. When you go from Java 1.2 to 1.3 or whatever it winds up being, how does that happen within the standards process?
Poulson: It has nothing to do with maintenance at all. Jim, can you explain that briefly?
Mitchell: Lisa is exactly right. Maintenance is fixing these bugs and everything, and there is a process in JTC 1 to go through that and put even those things up for voting and comment. But if Java changes in some substantial way what we would expect to do is a new submission of the Java platform specs…
3.3 Conclusion: Sun Alone Controls Java
Sun has denied the request of the National Bodies that it turn over control of the Java platform specification to ISO JTC 1 in order to makes its PAS application palatable. Sun has made clear that, in the words of Alan Baratz, President of the JavaSoft division of Sun, "The only company that has the right to define interfaces to the Java platform is Sun Microsystems." See http://www.javasoft.com/pr/1997/oct/transcript.html. It is unprecedented for a single company to be accepted as a PAS submitter, yet Sun would also ask for unprecedented control over an international standard. Consequently, National Bodies of the JTC 1 should reject Sun’s application.
4. Sun’s "Open" Process is Demonstrably Inadequate For An International Standard
In order to accept Sun’s application, JTC 1 members must accept the claim that Sun deserves PAS submitter status because it has developed or, more to the point, will develop specifications for the Java platform using an open, consensus-based design process. There are at least two reasons for rejecting this claim: (1) Sun has failed to answer many crucial questions about its process, leading to the conclusion that it has failed to justify it as open and consensus-based, and (2) the experience of Microsoft and other vendors is directly contrary to Sun’s claims; at a minimum, those experiences raise too many questions to allow Sun’s application to be approved in its present form.
4.1 Sun Has Omitted Key Information About Its Process
Sun describes at length the openness of its processes, but neglects to provide basic information, such as:
1. Precise description of the decision group. Sun has used a number of different names for the team of people who work on a Java design, going from "working group" to "ad hoc design group" to "ad hoc editing group" in iterations of its "open" process document (http://java.sun.com/aboutJava/ standardization/annexes.html#AnnexE). But the reality is this: either the members of this group (called hereafter the "decision group") have final authority over the content of the new Java specification, or else someone even less visible (perhaps Sun’s management team) has the final authority.
In the face of this uncertainty, we will assume the expected answer of Standards Bodies: the decision group has final authority. This leads to a number of other questions.
2. Precise description of the way the decision group is chosen. Sun has said that this group is made up of industry "experts"; Sun has given no information about who determines expertise and who picks the experts and why some experts and not others are selected.
3. Precise description of the decision-making process. Sun has stated that anyone can send email to the decision group and that someone reads the mail. It has not stated what the decision group does to deal with inputs. Does the group have regular meetings? Are minutes kept? Are the meetings recorded on audio or videotape? Does the decision group deal with all inputs or do individuals filter out some before reaching the group? Is there any written record of decisions made on inputs? Where is that record? If not, how can anyone outside the group be confident that decisions reached reflect either a broad consensus or a fair and reasoned response?
4. Precise description of the final decision process. When all inputs have been received, do the "experts" vote? Is there a lead architect who makes final decisions? or breaks ties? Are the groups small and cohesive enough that there are no formal decision-making rules?
These are just a few of the obvious questions. Yet Sun gives no answers.
Moving to specific designs, Sun uses the examples of JDBC and JavaBeans to illustrate the high quality of its open process. Yet those examples raise more questions than they answer.
1. Who initiated these standardization efforts? How did they do it?
2. Who are the members of the "ad hoc editing group" along with their company affiliations?
3. Describe the process by which these decision group members were selected to guide the standardization process.
4. Describe the process used by the decision group. For example, was work done by email? Approximately how often was mail exchanged and among whom? Is the email record public? If not, why not? Was standardization work done in meetings? About how often did the meetings occur? Are records of the meetings (minutes, recordings, trip reports, meeting summaries, etc.) public? If not, why not?
Raising these obvious questions show just how little Sun has actually told JTC 1 about its "open" process. The inevitable conclusion from its own evidence, shorn of fancy phrases and self-praise, is that Sun’s "open" process amounts to the following:
1. Sun employees are given permission by Sun management to unilaterally pick other Sun employees or employees of allied companies to join in the decision group. Microsoft, despite it large commitment to Java, its right to be informed of new Java features no later than any other licensee, and its considerable resources and expertise in many relevant areas, is usually excluded from any Java design process.
2. The decision group publishes an initial draft of the design. Up to this point there are no means for public input. The design is often ready for its first publication by the time it is publicly announced, well after the time when it is feasible to influence the basic design.
3. The stated "international, industry-wide" input involves people sending email to a Sun mailing list that is monitored by one or more members of the decision group. No responses to email are guaranteed and in practice none are forthcoming. The inputs made via email may or may not influence the design, and if they do or do not the submitter is unlikely to be told why. In any case, the submitter has no right to know what happened to its inputs. And Sun has no obligation to act on any input.
4. The decision group takes the ideas it likes and incorporates those into the design. The remainder are discarded and not discussed publicly.
5. Essentially, the decision group has no visible formal process at all. Decisions are made in secret with final authority resting in the management chains of Sun and the other vendors that it unilaterally involves in its design processes.
This kind of process is useful for getting good ideas from outsiders to improve the Java product as well as for building industry acceptance of a proprietary technology like the Java platform. Microsoft uses a similar process for its products, although we take pride in our investment, ability and commitment to engage, inform and support effectively all developers on our platforms, competitor or not.
However it has little to do with an open process in the sense in which that phrase is used by ISO JTC 1 and others in the open systems world. The gulf between Sun’s process and an open process – characterized by pre-existing rules of procedure regarding selection and operation of the decision group, openness to all materially interested parties, and open, public, and on-the-record democratic decision-making according to well-known procedures – is wide and clear.
The National Bodies correctly questioned Sun’s processes in their responses. Sun’s Response, though expansive, can’t disguise the reality. Sun’s processes are not sufficiently open for an organization seeking PAS submitter status.
4. 2 Experience Demonstrates That Sun is Not Open, Fair, or Unbiased
Microsoft has been a Java licensee for approximately 18 months. During that time, Sun has defined a wide range of new Java APIs and enhancements. Many licensees discovered these APIs through press events scheduled by Sun and its partners. Often Microsoft is informed that a feature is being designed after a draft has been completed. In no (zero) cases have Microsoft employees been asked to participate up-front, nor, in general, is input from Microsoft sought proactively by Sun. The overwhelming majority of our feedback has been ignored, which is perplexing as the recommendations usually detailed low-impact to Java and low-cost to developer solutions for Java platform compatibility with the preponderance of computing systems. Upon request, Microsoft will provide details on the closed nature of the definition process for JDBC, JavaBeans, PersonalJava, EmbeddedJava, SmartCardJava, Enterprise JavaBeans, JFC, JNDI, Java Accessibility API, JavaMedia, JavaSpeech, or JavaMail. Microsoft is one of the largest and most important Java licensees, with considerable staff and treasure dedicated to its advancement, and one of the most expert software organizations in the world on many of these issues. The systematic failure of Sun to engage Microsoft in an early-specification dialog on any of these wide-ranging enhancements refutes Sun’s claims of using an "open" process to design Java. Microsoft is an interesting edge case. As its self-proclaimed largest competitor, Sun's behavior towards Microsoft is an ideal test of its ability to serve as a neutral steward of Java for the entire industry.
Note that Sun is obligated as part of its licensing agreement to "…promptly notify Licensee of the nature of any Upgrades or other planned modifications to the Technology [Java platform] no later than the date that it provides such notice to any other commercial licensee of the Source Code to the Technology." [Technology License and Distribution Agreement, Section 3.1 http://www.microsoft.com/corpinfo/contract.htm] This now-public contract is relevant because it shows that even under the obligations created by its contract, Sun has not engaged this licensee in any significant way in its "open process." And while Microsoft has no interest in discussing the substantive issues of Sun’s lawsuit against it, the simple existence of the suit suggests that Sun is not a neutral "steward" of Java but a sophisticated and competitive company seeking to maximize its revenues and return on investment. Microsoft is not criticizing Sun for being what it is: a for-profit company. Self-interest is the norm in the context of for-profit business and competitive markets. However, this is emphatically not the norm for standards bodies and submitters of publicly available specifications. Therefore Sun’s application should be rejected.
4.3 Sun is Under No Obligation to Continue It’s "Open" Process
Whatever one thinks of Sun’s undocumented "open" process, it is beyond dispute that it continues at the whim of Sun’s management. It can also cease at the whim of today’s or tomorrow’s management.
Sun has made no binding commitments to anyone to continue with its current process or any other process. ISO JTC 1 cannot rely on Sun’s future behavior because Sun is not bound to continue with its current behavior. Otherwise, JTC 1 is taking an unacceptable risk that changes in market forces or changes in Sun management (or both) will change Sun’s "open" process in an unacceptable fashion – or abolish it altogether.
4.4 Conclusion: JTC 1 Should Not Rely on Sun’s Process
Many JTC 1 National Bodies rejected Sun’s original application in part based on the lack of open process used in the design of the technologies that Sun seeks to submit as PAS. In response, Sun has left unanswered the key questions about its "open" process. The opportunity for Sun to explain its process has now ended, and the JTC 1 and its National Bodies should reach again the conclusion that the openness of the Sun process is not what is expected of an organization seeking the privileged status of PAS submitter.
5. Sun’s Trademark and Conformance Positions Are Unacceptable
5.1 Sun’s Proposal Results in ISO Endorsement of The Proprietary Sun Implementation
Sun originally asserted that it would retain full trademark rights in "Java" and that the ISO specification could not use the "Java" term (notwithstanding the fact that Sun’s claimed trademark rights in the name of a programming language are tenuous at best). In its Response, Sun takes essentially the same position: the ISO standard still may not use the term "Java" in any straightforward or unencumbered fashion. Rather, Sun suggests that ISO JTC 1 refer to Sun’s product in the name of standard by using the phrase "ISO-xxx, The ISO Specification for the Java™ Platform."
Use of the name "ISO-xxx, The ISO Specification for the Java™ Platform" for an ISO specification is unacceptable. Sun is asking ISO to provide advertising and endorsement of its proprietary Java implementation as part of the name of the related ISO specification. The essence of ISO standardization of a given technology is to allow vendors to compete on implementations of the standard. Presumably there is a "level playing field" among vendors of open systems standards – they expect to be treated equally and judged only on the quality, features, and price of their implementations. In this case, however, rather than competing on equal terms with other vendors for Java implementations, Sun is seeking to have its product name embedded in the name of the International Standard. This would give Sun the benefit of the ISO label while penalizing its competitors in the commercial marketplace.
Sun’s proposal violates a basic principle of open standards (that standards should not give an explicit advantage to one vendor over another). The trademark issue alone is sufficient grounds to reject Sun’s application for PAS submitter status.
5.2 Sun’s Trademark Control Redefines The Role of ISO
Sun has repeatedly claimed that it must retain ownership and control of Java as a trademark in order to keep the Java "value proposition" intact by enforcing a unified "write once run anywhere" platform with neither supersetting or subsetting. Sun describes itself as a "steward" of Java, as if it did not own Java but was acting on someone else’s behalf.
Sun’s position rests on the assumption that ISO cannot maintain and evolve a commercially successful Java technology and that Sun therefore must enforce compliance. One national body has clearly recognized this paradox. As it states:
The claim that trademarks represent "strict compatibility and interoperability criteria inherent in the Java platform specifications" is unacceptable. This implies that a private company would exert stringent control over the implementation of an ISO/IEC standard as well as its conformance evaluation. This would result in an unequal competition.
Comments of China, http://www.javasoft.com/aboutJava/standardization/j1n4833.html#attach5.
If Sun had faith in ISO, it would not need or want to use trademark law to control the Java programming language. We believe this is clear evidence that Sun is misusing the PAS process to further its proprietary strategy, and therefore the application should be rejected.
5.3 Sun’s Trademark Control is used Selectively for Its Own Commercial Benefit
Since Sun is not a neutral disinterested party it should not be in control of the Java Standard through use of trademark law. For instance Sun disregards its own rules of "write once run anywhere" and "neither subsetting or supersetting" in its own use of Java in its product names . For example, Sun’s PersonalJava and EmbeddedJavaproducts both subset and superset the Java platform. The PersonalJava 1.0 final specification states: "The PersonalJava 1.0 API is a subset of the JDK 1.1 API, supplemented by a small number of new APIs designed to meet the needs of networked embedded applications." See http://www.javasoft.com/products/personaljava/spec-1-0-0/personalJavaSpec.html. The specification goes on to document a list of missing JDK features, many optional features that application may not count on being present, a number of new, incompatible features, use of which will render an application unable to run on a JDK 1.1 platform. Subsetting and supersetting are only a problem if you are not Sun.
Meanwhile, Sun has brought a lawsuit against a licensee for allegedly making changes to the JDK 1.1 APIs several orders of magnitude smaller than those made by Sun in its alternative Java platforms, and less significant than those made by companies that are either friendly to Sun, or a member of the undocumented decision group. This leads to another question: "Is Java an Open Standard or a double standard?"
Which leads us to believe that Sun is not a neutral "steward" of Java but a successful business venture appropriately intent on maximizing revenues and returns to its shareholders. Therefore Sun’s claim that it needs to retain Java trademark control for noble purposes must be rejected.
5.4 Non-Licensed Implementers May Not Use "Java" in A Reasonable Fashion
Assuming non-licensed products based on the proposed ISO standard can use "Conformant with ISO-xxx, The International Specification for the Java™ Platform," this tie-in to Java is insufficient for commercial products based on the ISO specification. The tagline is too long and cumbersome to be commercially useful in normal product literature, packaging, and advertising. It also makes an endorsement of Sun’s Java product family, which is likely to be in direct competition with the implementer’s product line. It is contradictory and unfair for a competitor to be required to sell Sun’s products whenever it refers to compliance with the proposed ISO standard. It certainly provides little incentive to use and reference an ISO standard cast in this form.
A fair solution consistent with past standards practice is (a) for the proposed ISO standard name to incorporate the term "Java" with no trademark symbol or other implied reference to Sun’s Java products; and (b) for implementers of the ISO Java standard to be able simply to refer to their products as conformant to "Java" or "the ISO Java specification."
6. The Scope of Sun’s Proposed Submission is Ambiguous and Risky
6.1 The Contents of the JDK Changes Rapidly
Sun defines the scope of its submission by supplying three URLs corresponding to the language, VM, and class library roots of the documentation tree for the Java Development Kit distribution. Sun also speaks in the past tense about the content of its submission, clearly implying that it was fixed in time as of the date of Sun’s Response.
The apparent stability implied by Sun’s Response does not match the reality of Sun’s development process. Java is constantly being changed, enhanced, upgraded, and expanded, often due to serious omissions in early designs. For example, in 1997 Java licensees received multiple new source code drops corresponding to versions 1.1 and 1.2, as well as a number of standalone technologies without a JDK delivery date. Each release corresponds to anywhere from small to moderately large changes in the Java platform.
Moreover, there is no indication that the degree of change in the Java platform will be decreasing in the future. To the contrary, the large number of new API initiatives announced and underway by Sun and its commercial allies is staggering in scope and complexity. Their ambitions appear to be no less than replicating the work done by the PC and UNIX industries over the last fifteen years. At any moment these enhancements can be added to the JDK and its minor or major version number updated.
This constant flux has two important implications for ISO JTC 1:
1. Sun has still not clearly specified the content (scope) of its proposed PAS submission. The entire contents of all the web pages pointed to by Sun must be frozen at a particular moment in time so that JTC 1 can fairly judge what Sun is actually proposing to submit.
2. That obvious requirement creates a paradox: As soon as Sun makes that snapshot, the JTC 1 is now guaranteed to have an out-of-date version of Java submitted for International standardization. There is no suggestion by Sun that its development processes will stop or even slow down after making the PAS snapshot. Therefore, on the very day the ISO standard is achieved, it is guaranteed not to match the current content of Sun’s "Java platform". And the gap will only continue to widen each month as the standard waits patiently for future updating by Sun – updating that Sun is not even contractually obligated to perform. Past standards practice would be to focus on those items of demonstrated maturity and most agreement, perhaps starting with the language and bytecodes. This appears to be at odds with Sun’s commercial objectives.
6.2 The JDK is Not Backwards-Compatible From Release To Release
The "moving target" problem that JTC 1 faces might be workable if it had assurances that the standard was a forward-compatible subset of Sun’s proprietary Java platform. But there is no reason to think that will be true. Sun’s track-record on backward-compatibility is far less than sterling as evidenced in the difficulties seen by developers and licensees upgrading between versions of the JDK, though those familiar with upgrading Sun’s commercial operating systems will likely find this is a considerable improvement. For a technology nominally based on a value proposition of compatibility, this is not only astounding, it is a disaster for the development community. Between the first and second releases of Java, major incompatibilities were introduced, such as the graphics and event models.
6.3 ISO Standards Based on Sun's Java Would Become Obsolete Rapidly
Thus, any ISO standard based on Sun’s rapidly-changing Java platform would not only be out-of-date the day it is adopted; it would likely soon be obsolete as well. Based on Sun’s record to date, we can predict that code written to the ISO standard will not execute properly in the latest version of Sun’s commercial, proprietary implementation, which an ISO standard would endorse. This is an untenable position for JTC 1 or any standards organization to be put in. This alone is sufficient ground for rejecting Sun’s application for PAS submitter status.
7. Sun Would Control Java Compliance With Secret Tests
7.1 Sun Would Effectively Determine Compliance With an International Standard
By using its trademarks to control compliance with its proprietary implementation of Java, Sun would effectively control compliance with the proposed International standard for Java while competing in the marketplace with other vendors seeking to conform to the standard. To allow a competitor to have this much control undermines the credibility of the standard.
7.2 The Compatibility Tests Are Secret
Moreover, Sun's compatibility tests are secret and available only under non-disclosure to companies who license technology from Sun. Thus, as a practical matter, to conform to the proposed international standard companies would be forced to license conformance testing technology from Sun. The secrecy underlying these tests has given rise to an unfair proceeding where unknown judges make life-and-death product decisions using unknown procedures and unknown laws (metrics). For example, in the case of Sun's lawsuit against a licensee, it has asserted a product does not pass the tests (that presumably others are passing), yet those tests are not available to the public for independent, third-party verification.
8. Conclusion
Java is important. Microsoft believes that for Java’s own welfare it must be placed firmly in either the commercial, market-driven standards domain (similar to Microsoft Windows) or into an official standards regime with its guarantees of fairness and due process. To attempt to mix the two is seductive but a disservice to both. Microsoft supports both these approaches when used in their own spheres, but rejects the proposed hybrid.
International Standards of ISO enjoy a preferred status in the global marketplace. The World Trade Organization encourages governments to base regulations and procurements on International Standards in the interests of avoiding non-tariff barriers to trade. But this special status flows directly from confidence in the fairness of their development process and procedures. In striving to keep this International Standards’ development process relevant to the needs of the Information Technology sector, we must not sacrifice its essential integrity or place organizations in areas of high moral hazard. Giving a single company control of the evolution of an International Standard will fatally compromise the integrity of the process that is the justification for the special status of an International Standard in the first place.
In sum, National Bodies members of JTC 1 have a variety of reasons for continuing to reject Sun’s application for PAS submitter status. Sun has refused to give substantive control over the Java standard to JTC 1 as a majority of members requested. Sun’s process is not sufficiently open to entitle it to PAS submitter status. Its trademark proposal is unacceptable because it asks the ISO to become the effective endorser and advertiser of its proprietary implementation of the proposed standard. And, finally, the scope of Sun’s Java submission is systematically ambiguous and certain to result in an out-of-date if not obsolete and incompatible "International Standard" for Java.
Therefore, Microsoft recommends that the U.S. National Body vote again "no, with comments."
| Country | Comments on Maintenance/Evolution/Control |
| Australia | "Any editorial changes to the specification should be performed consistent with JTC 1 requirements." |
| Brazil | "In dealing with the present submission, Brazil would like to ensure that additional clarification be given by Sun with respect to the evolution of the proposed standard. Brazil would support that responsibilities for maintenance should rest with JTC 1." |
| Canada | "We believe that the SMI responses contained in JTC 1 N 4615 do not clearly establish that this has, or will be done with regard to Java Technologies. Specifically, we are concerned with the absence of needed assurances such as, for example, in the following areas: Section 3.1.2 Ongoing Maintenance; Section 3.1.3 Changes; Section 3.1.4 Future Plans;…" |
| China | Flatly rejects any possibility that Sun can be designated a PAS submitter. "However China suggests that Java standards activities be placed within a standard organization like JTC 1/SC 22/JSG (Java Study Group), and hope that with many competent voluntary individuals and organizations participating, a standard could be successfully produced in a timely manner." |
| Denmark | "It is of great importance that JTC 1 takes over the product and, especially, the maintenance of JAVA. In SUN's application they want to be responsible for the maintenance themselves. Therefore, this has to be changed so that the maintenance is passed on to JTC 1. In JTC 1 the responsibility for maintenance should be supervised by one Sub Committee." |
| Finland | Supports U.S. position. |
| France | "AFNOR considers essential that maintenance and evolution of the Java standards are totally under the control of JTC1. It implies that: When the first set of Java specifications are submitted for standardization, the necessary clarifications, interpretations and minor changes that result from the submission and voting process are performed within JTC1 in an open and consensus-based fashion. For those Java specifications that have reached the ISO/IEC standard status, both the maintenance process (resulting from Defect Reports) and the evolution of standards (resulting from proposed enhancements) take place within JTC1 in an open and consensus-based fashion." [paragraph breaks omitted] |
| Germany | "b) Maintenance and enhancements: It is recognized that Sun is committed to provide the necessary resources for ongoing maintenance. However, the development process as described in clause 3.2.1 of N 4615 does not cater for sufficient openness. In particular, the role of JTC 1 and its member bodies in contributing to future evolutions of Java needs clarification." [paragraph break omitted] |
| Ireland | "Any application for recognition as a PAS submitter by a body other than an open consensus specification-development organization should be accompanied by a clear assurance that the applicant agrees that maintenance (which includes corrections and enhancements) of any ISO/IEC standard(s) resulting from its PAS inputs shall be conducted by ISO/IEC JTC 1." |
| Italy | "Future maintenance and evolution of Java specifications should be done in an open, consensus based process within JTC1. Revisions should not result from subsequent submissions of a Sun specification using the PAS process, as the current text seems to imply." |
| Japan | "If SMI wishes to propose the standardization of the enhanced functions of Java technologies in the future which are not dealt with this time, SMI should follow the normal JTC 1 NP procedure in consultation with appropriate member bodies or subgroups of JTC 1, or should submit another application for recognition as a PAS submitter." |
| Republic of Netherlands | Flatly reject’s Sun application, suggesting alternative, traditional means of standardization. |
| New Zealand | Request resolution of unresolved issues regarding, among other things, "arrangements for ongoing maintenance of the resulting PAS specifications." |
| Norway | Rejects Sun’s application and states "[W]e suggest that Sun follow a more traditional (but fast) standards path. The Java Study Group in JTC1/SC22 has previously suggested such a path to Sun." |
| Romania | "Sun company wants to keep the intellectual property on Java. This will forbid future development of Java technology and its evolution as required by user's market. If ISO accepts these specifications as standard, Sun can deny any further improvements and changes of Java, even if proposed by ISO!" |
| Slovenia | "Maintenance: Sun's Application does not demonstrate a willingness to allow all affected parties to participate in the on-going development of the Standard Sun's Java technology on an equal footing. The fact that a number of vendors have chosen to collaborate with Sun on the evolution of its Java technology is not enough to guarantee for an open standard process to further develop that technology. We believe that responsibilities for maintenance and enhancements of the standard should rest with JTC 1 and not with the PAS submitter in cases where the PAS Submitter is not a consensus-based standard body like X-Open or EWOS." |
| Switzerland | "Main interests of standardization are: … 3) to provide a real public control of the standards in order to maximize the room for openness/open systems and for added value for competing implementations." |
| United Kingdom | "The response by Sun does not appear to fully commit to the accepted revision cycle process. For these reasons, future maintenance and major revision of the Java specifications should preferably be undertaken under an open, consensus-based process subject to JTC 1 procedures, probably within a JTC1 SC. … There is an indication, both in the original application and its amendment, that Sun would wish to remain the final arbiter of change." |
| USA | "The U.S. National Body believes that responsibilities for maintenance and enhancements should rest with JTC 1 and not with the PAS submitter in cases where the PAS Submitter is not a consensus-based standards body. Therefore, the U.S. requires that once a PAS is adopted as a standard, any subsequent revisions of that specification will be conducted under JTC 1 procedures, as opposed to a revision being submitted as a subsequent PAS." |
Posted October 17th, 1997.