www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary VanMatre" <gvanma...@apache.org>
Subject Re: Proposed policy going forward
Date Sat, 07 Jul 2007 02:38:24 GMT

----- Original Message ----- 
From: "Henri Yandell" <bayard@apache.org>
To: <jcp-open@apache.org>
Sent: Thursday, July 05, 2007 2:30 PM
Subject: Proposed policy going forward


> Sam has asked for a plan of action. Lots of emails on his, so here's
> what I think:
>
> 1) We won't run non-open TCKs.
> 2) We will vote -1 on each JSR we're involved in that is not open
> (either for the TCK, or some other reason).


Will legal counseling be available to review each vote on behalf of an 
Apache EG rep?
My degree is in computer science.  This question might sound sarcastic but I 
have serious concern.
A recent inquiry on a simple IP clearance came up in the shale community 
that took nearly a month to get confirmation for legal.



> 3) We'll still get involved heavily with JSR EGs.
> 4) We'll still implement JSRs.
>
> ---
>
> The first one means that, yes, we will not sign NDAs as they are not
> open. This is hard for existing projects who are tied to such things
> and my line here would be:
>
> * Any project who have officially passed a TCK can continue to run
> that SAME TCK again for future releases. Projects who have not passed
> one and have licensed one are out of luck unless they convince us/me
> that it's right about to happen.
>
> The second one would be unilateral. If you are a part of the JCP as an
> ASF member, then that is how you vote. If you're there as an
> individual, then whatever you want is fine.
>
> Of course we will also accept any patches that increase TCK compliance
> - the TCK compliance shouldn't make a difference to us as it'll also
> be a patch that fixes a bug as per the spec.
>
> As a disclaimer; I've never run a TCK though I did sign the NDA
> recently as I'm pondering trying to get and run the JSTL 1.1 TCK. From
> what I hear, they're abysmally written pieces of software that take an
> age to run. Personally it seems like a lot of work that just bogs down
> our ability to release early and release often.
>
> So that's my view/proposed plan. We had an accepted middle ground, the
> middle moved, we should move to the new middle.
>
> Hen
> 



Mime
View raw message