You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by Henri Yandell <ba...@apache.org> on 2007/07/05 22:30:00 UTC
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).
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
Re: Proposed policy going forward
Posted by Gary VanMatre <gv...@apache.org>.
----- Original Message -----
From: "Henri Yandell" <ba...@apache.org>
To: <jc...@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
>
Re: Proposed policy going forward
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Andrew C. Oliver" <ac...@buni.org> writes:
> Joe Schaefer wrote:
>
>> 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).
Scrap the RI part, I don't think it's necessary. AIUI Geir is
already implementing this policy to some extent. Nevertheless
I think it would be good to codify it, and ask spec leads to
address it from the very start.
> 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?
All we currently require is fair access to the TCKs, not that they
be licensed as open source. If we go the route of voting against
TCKs which are not open source, then there will probably be a period
of time where we are a bit hypocritical in that position - in that
we may need to accept a TCK for use that we may have voted against
on those grounds.
>> 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
I don't mean it like that. I just mean that whatever recommendations
we currently have in place for participation in JSR's (e.g. most of the
work done in public, using consensus to make decisions) should now
become requirements. If people want to participate in JSR's which
do not meet those requirements, they should do so without the ASF
affiliation.
[...]
>> 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?
I think so. Dare I say it- I believe that eliminating NDA's will
actually require some *cooperation* from Sun and other vendors.
Setting a schedule and signalling that we intend to eliminate them
might help facilitate that as a start. However, taking a principled
stand against them at this point seems riddled with problems, both
in muddying the FOU issue, and in sorting out the operational
details of how to surgically shut down the NDA program Geir has been
running for us with some success.
--
Joe Schaefer
Re: Proposed policy going forward
Posted by "Andrew C. Oliver" <ac...@buni.org>.
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.
Re: Proposed policy going forward
Posted by Mark Thomas <ma...@apache.org>.
Joe Schaefer wrote:
> 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).
+1
> 2) We will vote against any JSR produced by a spec lead who in
> our view is in breech of the JSPA.
+1
> 3) We will not participate in the development of any JSR which
> does not conduct itself in an Apache-like fashion.
-1 because 'Apache-like fashion' is too vauge.
If you mean "We will not particiapte in the development of any JSR that:
- does not hold technical discussions in public
- does not maintain a public issue tracking system
then +1.
Note that I would still expect every JSR to have a private list and/or
issue tracking system to exist for the same reason Apache projects
have the private@ list and private JIRA issues.
> 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.
+1
Re: Proposed policy going forward
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Henri Yandell" <ba...@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