JCP Chair Responds to ASF

Java Community Process^SM (JCP) Program Chair responds to Apache Software Foundation

The Apache Software Foundation published a position statement (available at http://jakarta.apache.org/site/jspa-position.html) summarizing its concerns on the work in process to revise the Java^TM Specification Participation Agreement (JSPA), the agreements under which the Java Community Process (JCP) operates.

In summary, Sun's response is that some of Apache's requirements are satisfied in the current draft, but others are not. Sun is proposing changes to the JSPA draft so that all of Apache's requirements are satisfied, and with this note we convey the assurance that Sun's interpretation of them satisfies Apache's requirements. In what follows, we show how this is or will be made so, both in letter and in spirit.

Apache's Enumerated Requirements

"1. The JSPA must require that a JSR spec license cannot prohibit
     a compatible open source (Apache-style license minimum) implementation
     of a JSR.  If a JSR has what are known as "shared code requirements" --
     which  happens when some portion of the specification can't easily
     be tested and thus all implementors are required to use the same
     shared code -- the shared code must be available under and unrestricted
     and free-from-cost license."

The draft of the JSPA submitted for community review meets these requirements.

"2. The JSPA must grant an Expert Group the right, at the Expert Group's
     discretion, to release its own Reference Implementation (RI) and/or
     Test Compatibility Kit (TCK) under an open source license (Apache-style
     license minimum.) ..."

The draft of the JSPA submitted for community review would permit the TCK to be so licensed, but not the RI.

We have written and circulated a change to the draft JSPA that would permit the RI to be so licensed. The changes support the notion that those providing the work product should be able to produce technologies for compatible implementations of specifications under licenses of their choosing, including open source licenses such as the Apache license.

The change also supports the expectations and requirements of the Java application community by distinguishing between the Specification Lead designated RI and TCK binaries as opposed to the technologies used to implement them. In our discussions with members of Apache we understand that this is viewed as a satisfactory arrangement.

"3. The JSPA must grant an Expert Group the right, at the Expert Group's
     discretion, to have their discussion and drafts made public when they
     desire, even if the time happens to be before formal public review.
     Discussions explicited marked confidential are of course protected."

Both the JSPA currently in force and the draft JSPA submitted for community review permit public disclosure of information at the Specification Lead's discretion. Although the requirement above discusses "expert group" we understand from conversations with members of Apache that the current wording indeed meets the requirement.

"4. Because a TCK license is required (not optional) when performing an independent implementation and TCK licences often cost tens of thousands of dollars, the JSPA must require all TCK licenses to be easy to obtain by a non-profit (open source or academic) group. Note that 'hoping the spec lead grands a special-case free waiver' does not count as 'easy to obtain'."

The draft of the JSPA submitted for community review does not speak to this requirement (neither prohibiting nor permitting), leaving it up to specification leads to decide how they will price or make available TCKs. This has been true in part because TCKs can represent significant investments on the part of the specification lead, in particular, an ongoing investment with respect to providing support for their use. The state of the art of test suites in general tends to be labor intensive not only for creation but also for ongoing use and interpretation.

However, we take Apache's point that those trying to complete compatible implementations of specifications must have access to them in order to do so, and that some of those efforts may be long on energy and short on financial resources. To have a robust community of such efforts is indeed part of why the JCP exists in the first place. The issue is less about what should be true (having access) than it is how to reasonably support doing so. A strategy that would accomplish this is to separate the access to the implementation of the TCK from the support of it (potentially very costly to the specification lead).

Thus, to meet Apache's requirement, we have drafted a change to the JSPA that would require specification leads to provide no-cost access to the TCK implementations (without obligations for support) to qualified individuals, or not-for-profit or educational organizations engaged in efforst to create compatible implementations of JSRs.

In the interests of full disclosure, however, we feel obligated to note that taking the JSPA step described above, while technically meeting Apache's requirement, will not always succeed in meeting it in substance. It is important to realize that the state of the art in conformance testing is such that for major specifications, the successful execution of the test suites can be a daunting experience. This is not a condition peculiar to Java TCKs but is reflected in (for instance) UNIX and various language compiler conformance testing as well. This is the reason that test suites in many domains are often provided inclusive of support structures, which is a major contributor to their cost.

While simpler specifications might not present a problem, complex specifications or entire platforms will certainly be more difficult and it would be disingenous to simply throw them "over the wall" and expect that anyone is going to find the result satisfactory. Some support will be found essential for some groups for some specifications.

To fulfill the spirit of the request, Sun will therefore offer an annual support scholarship program to suitably qualified efforts to cover access to support services for TCKs offered by Sun. We will fund the program at or above a rate of at least 30 efforts per year (current value of approximately $1M) for at least the next 3 years.

The determination of what efforts would be eligible for a scholarship would be left to a review board consisting of three members, one from Sun and two from the open source and/or educational communities. This group would operate on a majority rule principle in making decisions about the allocation of support scholarships.

Sun would use the same group as the means by which JSPA qualified individuals would be accredited for no-cost access to TCKs for JSRs for which Sun is the specification lead. With this letter, we would like to invite Apache to provide one of the members of this board.

We believe this meets both the letter, and more importantly the spirit, of what Apache has required.

Further Steps

The JSPA draft under consideration, and with the proposed changes, will continue as JSR 99 under the JCP. Taking Apache's comments (and their echoes from other parties) as feedback from Community Review into the draft which will then go to Public Review and then the final vote by both Executive Committees of the JCP.

The revised JSPA will govern the execution of JSRs which are created after it has gone into effect, which is probably several months away. When that occurs, all new JSRs (led by Sun or others) will be governed by an agreement that satisfies Apache's requirements.

Again in the interests of meeting the spirit of the requirements, Sun will modify the specification licenses of all the JSRs currently in progress to reflect Apache's requirements as met in the new draft JSPA. And we reaffirm a previous statement that we would work over time to change the licenses of previously completed JSRs to comply with the new JSPA draft. We specifically commit to doing such changes at a minimum for:

JSR 31 (JAXB), JSRs 52, 53, 152, 154 (JSPs/Servlets), JSR 63 (JAXP), JSR 67 (JAXM), JSR 93 (JAXR), JSR 101 (JAXRPC), JSR 127 (Java Server Faces), JSR 172 (J2ME Web Services)

As noted in the introductory summary, we believe these changes constitute a full meeting of Apache's requirements both in letter and in spirit.

Robert A. Gingell
Sun Fellow & Vice President
Chair of the Java Community Process
Sun Microsystems, Inc.