Apache's JSPA position

$Id: jspa-position.html,v 1.10 2002/03/02 03:03:21 rubys Exp $

The following is a statement of the Apache position with regard to the JSPA revision (NOTE: The JSPA revision is only available for people with special access. There is another page on the JCP site that has information about JSR99 which was created to manage the revision process.) and the items currently under discussion. Please post your comments about this to the general@jakarta mailing list.

First, some background. Over the past two years members of the JCP Executive Committee, including Apache, have been working on revising the legal agreement members sign with Sun when joining the JCP, known as the "JSPA" (Java Specification Participation Agreement). This document defines many of the rules of the JCP and is responsible for allowing -- and in some cases requiring -- many of the restrictions which have hindered open source implementations of JSR specification.

Apache has participated in the JSPA revision process with the following goals:

1. The JSPA must require that a JSR spec license cannot prohibit a compatible independent 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 an unrestricted and free-from-cost license.

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). As Sun has done this with success for JSR-052 and JSR-053 (Servlets, JSPs, and Taglibs), so should other Expert Group's be allowed to follow the same strategy.

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 explicitly marked confidential are of course protected.

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

This first week of February the latest version of the JSPA document is being released for Community Review where JCP members will be allowed to view and comment on the draft. If you or your organization is a JCP member, you should review the draft and form your own opinion on how these goals have been satisfied.

Apache in its reading of the document had believed there had been some progress on these issues. However, Apache recently learned that in Sun's legal opinion none of these (save the first) has changed in status since the currently in-force JSPA.

Because Sun runs the JCP's Program Management Office (PMO), Sun's opinion on what's allowed is very important. No matter what the JSPA document itself says, the PMO enforces the rules by determining which JSRs go up for a vote, and thus the PMO's interpretation of the document has been the ruling opinion within the JCP.

Consequently, Apache would not only like to see the above issues resolved in the new JSPA, but furthermore will look for some assurance from Sun that Sun's official legal opinion agrees that the above requirements have been satisfied.