www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: [Draft] New ASF/JCP Policies
Date Wed, 27 Jun 2007 19:13:55 GMT
Ok...I am staring to get it.  Thanks for some of the clarifications here.


robert burrell donkin wrote:
> On 6/27/07, *Jeff Genender* <jgenender@apache.org
> <mailto:jgenender@apache.org>> wrote:
>     My concern here is where we are going with this.  I apologize in advance
>     if I missed something regarding the JCK vs TCK with respect to Harmony.
>     If I did, please point it out.
> sadly, most of the extensive previous discussions within apache have had
> to be private :-/
>     I asked in a previous email about the open letter to Sun about if anyone
>     has made direct contact with those folks instead of expecting a public
>     response to the open letter.  Calling a company out publicly may be a
>     bit much to expect a public response.  I just hope that we have followed
>     through with the personal side before being heavy handed.  Again, I may
>     have not been privy to past discussions so it possible I am not seeing
>     this with full view.
> AIUI apache has been talking with sun privately about the JCP for around
> a decade. AIUI contacts continue.
> the difficulty of private contacts is that it means keeping people in
> the dark. IMO the time has come to talk about these things openly. IMHO
> the open letter was part of that process. we gave sun the opportunity to
> response publicly. they have chosen not to take it.
> IMHO it's good that we can now discuss these issues in public
>     I think the issue of JCK vs TCK and our stance is a difficult one.  I
>     would hope we do not cut off our nose to spite our face.  As I
>     understand it, the JCK is a different testing animal than the TCKs.
>     They test different things AFAICT.
>     The TCKs allow our products to compete in the market place with
>     commercial and other open source offerings (non-Apache).  I think our
>     ability to pass these TCKs allows us to have people in the community
>     want to adopt our products, and ultimately helps us build even more
>     community and followers.  It allows folks to take us really seriously.
>     But stopping or hindering our ability to obtain and use newer TCKs will
>     likely have the effect of people not wanting to adopt some of our
>     products because they are not "certified" or do not pass certification
>     tests.
> apache is a non-profit organisation. we are all bound by our charter
> both legally, ethically and morally.
>     I believe this is a large risk to take because Sun will not bend to a
>     JCK license or has not responded publicly to the open letter.  I think
>     risking several projects' ability to continue adoption due to
>     certification with respect to an issue with Harmony is something we
>     should really examine carefully and weigh the risk vs reward on what we
>     are about to do.
> IMO it's better to risk lower adoption rates than to close the efforts
> entirely
> the fatal flaw with the JCP is the power given to the specification
> lead. the vast majority of specification leads have not abused their
> position. however, apache's non-profit status requires that in the
> future, we have more substantial guarantees that the specification lead
> will behave ethically. apache needs to frame a new policy so that
> specification leads understand what the requirements for official
> participation from apache so that they can clearly agree or disagree to
> these terms before the process starts.
>     I would ask that we see if we have exhausted all efforts to
>     communication with Sun on this issue 
>     and do a risk/reward analysis on
>     steps moving forward.
> fine: propose some steps and post your analysis ;-)
>     Thoughts?  Can I help with this somewhere? 
> of course - analyse, synthesis and post your findings ;-)
> our approach to the JCP going forward will be formulated in public on
> this list
> - robert

View raw message