2011/12/21 - Jakarta has been retired.

For more information, please explore the Attic.



This is the TCK license (and explanatory side letter from Rob Gingell at Sun) which Apache Software Foundation negotiated with Sun as a consequence of the concerns voiced in the fourth point below. ASF's other concerns in its position on the JSPA have been largely addressed in revision 2.5 of the JSPA. JCP (and JSPA) 2.5 is due to launch in late 2002.

In addition, Sun has provided TCK coverage for the following ASF projects:

  • Axis, for JAX-RPC (JSR-101), JAXM and SAAJ (JSR-67)
  • Project TBD, for JAXR (JSR-93)
  • Crimson, Xerces and Xalan, for JAXP (JSR-63)
  • Jakarta Taglibs, for taglibs (JSR-52)
  • Tomcat, for JSP and servlets (JSR-53)

Sun has also established a TCK license grant program for academic institutions and other qualified nonprofit entities, on which ASF is represented.

jspa-position.xml 2002/03/26 08:30:58

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.

About Jakarta

About Apache

Retired Subprojects