www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@buni.org>
Subject Re: Proposed policy going forward
Date Sat, 07 Jul 2007 05:30:21 GMT
Joe Schaefer wrote:
> Are you requiring that the TCK be open source?
>
>   
The TCK is an essential part of the specification as an app is not 
considered meeting the specification unless it passes the TCK, 
(paraphrasing roy I think).  So the TCK is the real specification, the 
specification is barely worth the bits its printed on.
> How would this impact Tomcat and Geronimo?  Are they shit-out-of-luck
> just because Sun made some bad arrangements with whomever wrote the
> TCKs?  Will we allow third parties to arrange for a TCK for those
> committers to use?
>
>   
Geronimo has already passed the TCK.  So it wouldn't affect
Geronimo unless J<strike>2</strike>EE<strike>1.</slash>6 has a bad
TCK, 
which we can do something about. 
> The "middle moved" because of a contract breech, not because of
> an NDA on committers using the TCK.  We don't even have the 
> JCK yet, so that can't be the problem.
>
>   
But the NDAs helped make the contact breech easy and many folks have 
never been comfortable with them in the first place.  This is a long 
time coming.
> For the short term, I'd advocate a policy more along the
> lines of the following:
>
> 1) We will vote against any JSR which does not have a public set
>    of terms attached to the TCK and RI. (Those terms may involve
>    NDAs and closed source licenses on the software).
>   
Why would Apache vote for a closed standard?  The TCK determines if you 
comply with the standard (not the spec) and is an essential part of the 
specification.  If these are "open standards" why should it be 
acceptable for the authoritative part to be top secret?
> 2) We will vote against any JSR produced by a spec lead who in
>    our view is in breech of the JSPA.
>
> 3) We will not participate in the development of any JSR which
>    does not conduct itself in an Apache-like fashion.
>
>   
I don't even agree with that.  The apache voting rule aren't for 
everything and no one even can define what "apache-like" means (and 
please for the love of god let's not start that thread for the 1000th 
time again).
> I think the foundation would be best served by adopting a simple
> set of changes like the above immediately, and revisiting the NDA
> issue at a later date.
>   
A later date?  JavaEEs got maybe 1 good rev left that anyone will be 
left caring about.  For all its superiority, JavaEE 1.5 is a dud on the 
market from what I can tell (Dain can maybe offer his experience on 
whether Geronimo got even 1/2 the bump they got from J2EE 1.4 
certification or even Spring stuff).  Sad because I think EJB3 is really 
a decent ride for corporate developers to create transactional software, 
but true.  "The JDK" is now mostly-sorta open source and with some help 
(http://icedtea.classpath.org/), you can even get it there.  So what, do 
we wait like rev to Java's market death to address the actual disease 
rather than the symptoms?  Sunlight disinfects it all.  The NDA issue is 
a must-address to put the OPEN back in Apache Open Source and OPEN 
standards.  So yeah the FOU contract breech started the latest battle, 
but its time to go for end game.  If not today, then when?

-Andy

-- 
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email, 
Calendaring (including freebusy), 
Rich Webmail, Web-calendaring, ease 
of installation/administration.


Mime
View raw message