www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+apa...@sunstarsys.com>
Subject Re: Proposed policy going forward
Date Sat, 07 Jul 2007 04:33:03 GMT
"Henri Yandell" <bayard@apache.org> writes:

> 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).
> 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.

Are you requiring that the TCK be open source?

> 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.

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?

> 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.

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.

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).

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 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.

-- 
Joe Schaefer

Mime
View raw message