You are viewing a plain text version of this content. The canonical link for it is here.
Posted to site-cvs@jakarta.apache.org by jo...@apache.org on 2002/02/05 02:02:52 UTC
cvs commit: jakarta-site2/xdocs/site jspa-position.xml
jon 02/02/04 17:02:52
Added: xdocs/site jspa-position.xml
Log:
initial commit of apache's jspa position as written by jhunter and
posted to the jcp@apache.org mailing list.
note: the generated .html file has not been checked into CVS yet and
thus will not appear on the live website. this should NOT
be done until jason and the jcp mailing list gives the go ahead.
(note to sam: this is yet another reason why checking the website into
cvs is a better idea than live generation...this is a cool feature of the
process...).
-jon
Revision Changes Path
1.1 jakarta-site2/xdocs/site/jspa-position.xml
Index: jspa-position.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<author email="jhunter@servlets.com">Jason Hunter</author>
<author email="jon@latchkey.com">Jon S. Stevens</author>
<title>Apache's JSPA Position</title>
</properties>
<body>
<section name="Apache's JSPA Position">
<p>
The following is a statement of the Apache position with regard to the
JSPA revision and the items currently under discussion.
</p>
<p>
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". 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.
</p>
<p>
Apache has participated in the JSPA revision process with the
following goals:
</p>
<p>
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.
</p>
<p>
2. The JSPA must grant an Expert Group the right, at the EG'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 EGs
be allowed to follow the same strategy.
</p>
<p>
3. The JSPA must grant an Expert Group the right, at the EG'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.
</p>
<p>
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".
</p>
<p>
This first week of February 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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</section>
</body>
</document>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>