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 JavaTM Specification Participation
Agreement (JSPA), the agreements under which the Java Community Process (JCP)
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
"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
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.
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.