You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by Matt Hogstrom <ma...@hogstrom.org> on 2007/07/06 17:34:47 UTC
[DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Sam had challenged us to put our thinking into a form that people
could shoot at. I've thought about this for a bit and have an
alternate set of changes for participation at the JCP. I have marked
up a copy fo the JCP page and submit this for your consideration.
Although I may have left some holes I believe that this change in
policy strikes a balance of communicating our position going forward
without jeopardizing commitments already made in the past.
http://people.apache.org/~hogstrom/jcp/
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 7, 2007, at 6:18 AM, Jim Jagielski wrote:
>
> On Jul 6, 2007, at 10:24 PM, Bill Barker wrote:
>
>>
>> Yes, as someone posted (Gier? it is hard to dig through a list
>> this active
>> :) Sun may permit discussion of test failures on public lists.
>> With this
>> modification, the NDAs are relatively harmless to the Apache Way.
>> Apache
>> has no real interest in being allowed to publish somebody else's IP,
>> including enough information on how to reverse-engineer it. But
>> as long as
>> we can post "The Cross-Context forwarding test failed because the
>> Session in
>> the target wasn't bound to the Session in the originator. What
>> are we going
>> to do about it?" on dev@tomcat, it seems to me enough to keep the
>> process
>> open.
>>
>
> Agreed. When the conditions and provisions of TCK access/usage
> "requires" us to enforce an NDA to prevent people from doing
> the "normal" work associated with development within an
> open source, collaborative, public environment, then the ASF
> should have a problem with that.
>
What does "normal" mean in this context?
Sorry about the flurry of small emails from me, but there are so many
of these kind of strange assertions, I'd like to get a better
understanding where people are coming from...
geir
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jul 6, 2007, at 10:24 PM, Bill Barker wrote:
>
> Yes, as someone posted (Gier? it is hard to dig through a list this
> active
> :) Sun may permit discussion of test failures on public lists.
> With this
> modification, the NDAs are relatively harmless to the Apache Way.
> Apache
> has no real interest in being allowed to publish somebody else's IP,
> including enough information on how to reverse-engineer it. But as
> long as
> we can post "The Cross-Context forwarding test failed because the
> Session in
> the target wasn't bound to the Session in the originator. What are
> we going
> to do about it?" on dev@tomcat, it seems to me enough to keep the
> process
> open.
>
Agreed. When the conditions and provisions of TCK access/usage
"requires" us to enforce an NDA to prevent people from doing
the "normal" work associated with development within an
open source, collaborative, public environment, then the ASF
should have a problem with that.
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Chris Gray <ch...@kiffer.be>.
On Saturday 07 July 2007 04:24, Bill Barker wrote:
> I mostly agree with David here. Also, I'd like to point out that requiring
> an OS TCK would be a legal minefield for the spec-lead. It has to be
> frozen in time, otherwise if a "bug fix" suddenly causes an implementer to
> fail the TCK, where before they passed, lawsuit-city ;-).
Sorry but this is bogus. To be certified, a particular binary artefact has to
pass a particular release version of the test suite. That certification
remains valid even if a later release of the test suite contains tests which
the already-certified artefact would fail. Note: I say "test suite" because
I'm talking about certification as an abstract process, not the policy of a
particular company.
I would argue that open source test suites are even more valuable than open
source implementations. Would be great to have some public debate about what
should be tested and how, no?
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Steve Loughran <st...@apache.org>.
Bill Barker wrote:
> I mostly agree with David here. Also, I'd like to point out that requiring
> an OS TCK would be a legal minefield for the spec-lead. It has to be frozen
> in time, otherwise if a "bug fix" suddenly causes an implementer to fail the
> TCK, where before they passed, lawsuit-city ;-).
>
1. you can tag your repo with the 1.0, 1.1 versions of the spec. it isnt
that hard.
2. I dont personally consider test suites ever to be complete, therefore
stable. Proving completeness of a test suite is probably on par with
proving correctness of an application. You can always add new test cases.
If you make it easy for all participants in a spec to contribute tests,
they are motivated to contrib their tests, tests that not only break
their app, they break their competitor's implementations, so that
everyone breaks together.
for the deployment stuff I modified junit3 to run off XML configuration
files...if you pick a directory
http://deployment.cvs.sourceforge.net/deployment/deployment/test/org/ggf/cddlm/files/cdl/valid/set_05_structure/
you can see three test docs and one test manifest. Add a new file to the
manifest, then both the Java and .NET implementations pick it up.
There is a risk that stuff suddenly breaks, but you can easily say "I
pass the GGF-16" version of the test suite. Furthermore, when your goal
is interop with other implementations, you dont ever have stable third
parties to test against. You just have to set up a really good interop
test runner (me: laptop at home checking out the code, running three
test suites against three endpoints in separate JVMs in parallel) and be
prepared to deal with unstable and intermittently available test endpoints.
-steve
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Bill Barker <wb...@wilshire.com>.
I mostly agree with David here. Also, I'd like to point out that requiring
an OS TCK would be a legal minefield for the spec-lead. It has to be frozen
in time, otherwise if a "bug fix" suddenly causes an implementer to fail the
TCK, where before they passed, lawsuit-city ;-).
The rest of my comments inline.
"David Jencks" <da...@yahoo.com> wrote
in message news:2291BCE1-3E6A-4BA1-A862-6FD030025A58@yahoo.com...
>A couple of quibbles:
>
> 1. At one point we have crossed out:
>
> You must sign an Non-Disclosure Agreement with the Apache Software
> Foundation. as the ASF is a signatory with Sun on behalf of its
> representatives
>
Yes, as someone posted (Gier? it is hard to dig through a list this active
:) Sun may permit discussion of test failures on public lists. With this
modification, the NDAs are relatively harmless to the Apache Way. Apache
has no real interest in being allowed to publish somebody else's IP,
including enough information on how to reverse-engineer it. But as long as
we can post "The Cross-Context forwarding test failed because the Session in
the target wasn't bound to the Session in the originator. What are we going
to do about it?" on dev@tomcat, it seems to me enough to keep the process
open.
> however near the end we have not crossed out:
>
> * Every individual that has access to the TCK materials must have
> executed a Non-Disclosure Agreement with the ASF. The ASF receives these
> materials under the terms of an NDA, and we must take due care in how we
> handle these materials.
>
Even though it is in the original, it should probably be reworded. If the
individual has access to the TCK as an individual, or through his/her
employer they could probably sue the ASF if this was ever inforced.
Probably something like s/TCK materials/copy of the TCK materials licensed
to the ASF/ (of course, IMNAL).
> 2. openjpa has graduated
>
> 3. geronimo has implemented javaee 5 as well as j2ee 1.4
>
> 4. I don't understand this:
>
> Also, the license used to obtain the TCK cannot include terms that would
> restrict open communication and use of the TCK to validate an
> implmentation.
>
With the "open communication" part I agree with, but the last part is
useless once the ASF has licensed the TCK. The JCPA specifically states
that the only point of licensing the TCK is to validate the implementation.
> it looks to me as if that means we want to be free to publish the tck to
> all comers with no NDAs for anyone. I haven't looked back at this entire
> discussion, but is that really what is meant?
>
> david jencks
>
> On Jul 6, 2007, at 8:34 AM, Matt Hogstrom wrote:
>
>> Sam had challenged us to put our thinking into a form that people could
>> shoot at. I've thought about this for a bit and have an alternate set
>> of changes for participation at the JCP. I have marked up a copy fo the
>> JCP page and submit this for your consideration. Although I may have
>> left some holes I believe that this change in policy strikes a balance
>> of communicating our position going forward without jeopardizing
>> commitments already made in the past.
>>
>> http://people.apache.org/~hogstrom/jcp/
>
>
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by David Jencks <da...@yahoo.com>.
A couple of quibbles:
1. At one point we have crossed out:
You must sign an Non-Disclosure Agreement with the Apache Software
Foundation. as the ASF is a signatory with Sun on behalf of its
representatives
however near the end we have not crossed out:
* Every individual that has access to the TCK materials must
have executed a Non-Disclosure Agreement with the ASF. The ASF
receives these materials under the terms of an NDA, and we must take
due care in how we handle these materials.
2. openjpa has graduated
3. geronimo has implemented javaee 5 as well as j2ee 1.4
4. I don't understand this:
Also, the license used to obtain the TCK cannot include terms that
would restrict open communication and use of the TCK to validate an
implmentation.
it looks to me as if that means we want to be free to publish the tck
to all comers with no NDAs for anyone. I haven't looked back at this
entire discussion, but is that really what is meant?
david jencks
On Jul 6, 2007, at 8:34 AM, Matt Hogstrom wrote:
> Sam had challenged us to put our thinking into a form that people
> could shoot at. I've thought about this for a bit and have an
> alternate set of changes for participation at the JCP. I have
> marked up a copy fo the JCP page and submit this for your
> consideration. Although I may have left some holes I believe that
> this change in policy strikes a balance of communicating our
> position going forward without jeopardizing commitments already
> made in the past.
>
> http://people.apache.org/~hogstrom/jcp/
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I've incorporated most of the changes commented on earlier today.
For those that are disconnected, the diff from the original page this
morning and now is at the end of this note.
You can see the most recent changes here: http://people.apache.org/
~hogstrom/jcp/
The first draft is at: http://people.apache.org/~hogstrom/jcp/
index_draft1.html
I wanted to clarify a few things based on my review of the comments
on this thread and to hopefully flush out some possible errors in
what I posted since it is a terse representation of my thoughts.
First, I think that in a perfect world we wouldn't need NDAs or
restrictive licenses that inhibit open development. Certainly we
don't live in a perfect world and many people have different
interests and goals that guide them to different licenses. I for one
do not hold any ill will to folks that want to operate with LGPL,
GPL, MPL, TPL or any other license that may have some restrictions.
Its your code, license it as you wish and consumers will need to
decide if the license works for them and their needs.
Towards that end, having been involved in Apache Geronimo I've seen
first hand how the current situation with the TCK licenses has
divided the community into two groups and hindered open
communication. Not every committer is able to execute the NDA to get
access to the TCK as in some cases they or their employer may not
allow or be able to allow them. Its not an insurmountable challenge,
and we've lived with it, but it does slow down development and cause
all kinds of private mailing lists to be created, separate and
controlled JIRAs, etc. At the end of the day it is doable but gets
very tedious.
That said, validating a project's release against a TCK provides a
significant benefit to our users as they know that the Apache
implementation of a JSR that has passed the TCK will allow them the
freedom to switch from an Apache software component to another
"certified" component and their application should continue to work
correctly. This is really significant. In fact, many users simply
will not use something if it is not certified because there exists
the potential for bugs and other incompatibilities that burns up
their time. So, validating a release is a positive thing and the TCK
helps make that happen. The Apache communities (including developers
and users) have benefited from the TCKs and our use of them.
Unfortunately, the issue with Sun and the JCK terms for Harmony seems
to have surfaced a lot of frustration and unleashed a lot of
different emotions. Sun's failure to respond to our Open Letter as
well as a lack of a concrete action plan at the ASF has brought all
of this frustration to a head and we need to formulate our plan on
how to deal with the JCP and the license issues which are at the
heart of all this frustration.
The intent of my proposed changes takes into account that the ASF has
made commitments in the past that are somewhat disharmonious with
Open development and community principles. Should we have accepted
the TCKs and used NDAs? I'm not sure, I think its been really
positive for both the ASF, the JCP and the communities but not
without some consequences. We cannot simply "make things right" by
dropping NDAs and restricting our position at the JCP. My proposal
is to acknowledge a change is needed that outlines a go forward
strategy and does not breech the trust of communities (both users and
developers) for decisions made in the past.
Very briefly I believe we should:
* Let the existing projects operate as they had based on past
agreements with Sun and the communities.
* Articulate our position on acceptable license terms going forward
and the rationale for our reasons.
* Choose to support and engage in new JSRs where we have people that
are interested in the technical merits of a project and the license
and terms for the specification, TCK, RI and other materials are
consistent with the Apache development model. Respecting that some
licenses may not allow us to redistribute a TCK (which I see as
totally acceptable) but does not restrict the use of a project
validated by the TCK.
* I expect that other members of the JCP Executive committee will
support us where they can.
* The existing projects at Apache that are currently using NDAs will
eventually become uninteresting as technology marches on and new JSRs
come out to replace old ones. The NDA problem will go away naturally
so there is no need to force that to happen in a disruptive manner.
I think this is a reasonable approach to the problem that
demonstrates a reasonable and civil approach to the problem. Has a
plan for how to engage in the future with the JCP and allows users
and developers to make a decision on where they want to invest their
time and resources.
Just my $0.02
Matt Hogstrom
Diff of original to draft 2:
--- index.html 2007-07-06 23:41:25.000000000 -0400
+++ index2.html 2007-07-07 00:16:56.000000000 -0400
@@ -147,17 +147,17 @@
Our goal is to put the "Community" in Java Community Process.
</p>
<p><font color="red" weight="700"><ul>
-Apache's goal in participating in Expert Groups at the JCP as well
as on the Executive Committee is to help promote Open Standards, Open
Communication and Open Community. In the past, the ASF has signed a
Non-Disclosure Agreement (NDA) with Sun to recieve access to the TCKs
for various JSRs that were implemented by communities at Apache. The
ASF has reviewed the impact this decision on communities at Apache as
well as its impact on the industry. Based on this review the ASF is
changing its position on TCK access.
+Apache's goal in participating in Expert Groups at the JCP as well
as on the Executive Committee is to help promote Open Standards, Open
Communication and Open Community. In the past, the ASF has signed a
Non-Disclosure Agreement (NDA) with Sun to receive access to the TCKs
for various JSRs that were implemented by communities at Apache. The
ASF has reviewed the impact this decision on communities at Apache as
well as its impact on the industry. Based on this review the ASF is
changing its position on TCK access.
<p>
-A change of this magnitude comes after a lot of consideration about
many factors. Some of these include alignement of Apache goals and
philosophy with Openess and Community. Also factoring into the
decision is our commitment to users and communities that have made
decisions to consume projects built on specifications from the JCP as
well as of individual contributors to participate in the building of
this technology.
+A change of this magnitude comes after <strike>a lot of</strike>
consideration about many factors. Some of these include alignment of
Apache goals and philosophy with Openness and Community. Also
factoring into the decision is our commitment to users and
communities that have <strike>made decisions</strike> <b>chosen</b>
to consume projects <strike>built</strike> <b>based</b> on
specifications from the JCP as well as of individual contributors to
participate in the building of this technology.
<p>
To be faithful to our users and our principles the ASF has made the
following policy changes:
-<p><li>
-The ASF will no longer seek to receive access to new TCKs or
specifications that have restrictive liceneses.
+<p>
+<li>The ASF will no longer seek to receive access to new TCKs or
specifications that have restrictive licenses.
<li>Access to existing TCKs and specifications will continue to be
allowed so as to not disrupt existing communities or users.
-<li>The ASF will continue to be involved in the Executive Committee
as well as participate in JSRs. Participation in JSRs will be
determined based on the license terms of the specification,
Reference Implementation as well as the TCK used to validate an
implementation.
-<li>Users that currently have signed an NDA with Apache will be
allowed to continue their work.
-<li>Users that are interested in signing an NDA to work on
validating an implementation may do so. However, Apache may, in the
future, no longer accept new NDAs.
+<li>The ASF will continue to be involved in the Executive Committee
as well as participate in JSRs. Participation in JSRs will be
determined based on <b>interest in the JSR as well as</b> the license
terms of the specification, Reference Implementation as well as the
TCK used to validate an implementation.
+<li><strike>Users</strike>Committers that currently have signed an
NDA with Apache will be allowed to continue <strike>their work</
strike> <b>working on the projects and implementations that are in
progress</b>.
+<li><strike>Users</strike>Committers that are interested in
<strike>signing an NDA to</strike> work<b>ing</b> on validating an
implementation may do so <b>by executing an NDA</b>. However, Apache
may, in the future, no longer accept new NDAs <b>for existing
projects</b>.
<p>
</ul></font>
<p>
@@ -372,8 +372,9 @@
</p>
<p><font color="red" weight="700">
-In addition to JSR specifications, the TCK used to validate the JSR
must also be available under a license that does not incur downstream
implications to users of the implementation or the code used to
implement it. Also, the license used to obtain the TCK cannot
include terms that would restrict open communication and use of the
TCK to validate an implmentation.<p>
-Finally, JSRs that violate an open environment in terms of licenses
that add downstream restrictions, whether it be the source that
implements the specification or the consequences of testing that
imposes use restrictions, or other restrictions incompatible with the
AL 2.0 the ASF would regrettably vote against such JSRs.
+In addition to JSR specifications, the TCK used to validate the JSR
must also be available under a license that does not incur downstream
implications to users of the implementation or the code used to
implement it. Also, the license <strike>used to obtain the</strike>
<b>under which the</b> TCK i<b>is made available</b>i cannot include
terms that would restrict open communication and use of the TCK to
validate an implementation. <b>This means that users of the TCK, RI
and/or other materials would not need to sign an NDA to have access
to the materials or be prohibited from discussing its contents.
Restrictions on re-distribution of the test framework itself would be
acceptable as any interested party should be able to obtain the
materials from their source.</b>
+<p>
+Finally, <b>the ASF would regrettably vote against proposed </b>
JSRs that violate an open environment in terms of licenses that add
downstream restrictions, whether it be the source that implements the
specification or the consequences of testing that imposes use
restrictions, or other restrictions incompatible with the AL 2.0
<strike>the ASF would regrettably vote against such JSRs</strike>.
</font>
<p>
The following projects are implementing one or more JCP specifications:
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Sam Ruby <ru...@apache.org>.
On 7/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> I have marked
> up a copy fo the JCP page and submit this for your consideration.
THANK YOU
- Sam Ruby
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Added this:
Finally, JSRs that violate an open environment in terms of licenses
that add downstream restrictions, whether it be the source that
implements the specification or the consequences of testing that
imposes use restrictions, or other restrictions incompatible with the
AL 2.0 the ASF would regrettably vote against such JSRs.
On Jul 6, 2007, at 11:53 AM, Davanum Srinivas wrote:
> Can you please make that explicit in the proposal?
>
> thanks,
> dims
>
> On 7/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>
>> On Jul 6, 2007, at 11:44 AM, Davanum Srinivas wrote:
>>
>> > Matt,
>> >
>> > What should Apache do in this case? Oppose the JSR? Vote No? or
>> just
>> > not participate in the JSR?
>> >
>> > "In addition to JSR specifications, the TCK used to validate the
>> JSR
>> > must also be available under a license that does not incur
>> downstream
>> > implications to users of the implementation or the code used to
>> > implement it. Also, the license used to obtain the TCK cannot
>> include
>> > terms that would restrict open communication and use of the TCK to
>> > validate an implmentation."
>>
>> I would expect we vote no with stated objections pointing back to
>> this policy.
>>
>>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Davanum Srinivas <da...@gmail.com>.
Can you please make that explicit in the proposal?
thanks,
dims
On 7/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
> On Jul 6, 2007, at 11:44 AM, Davanum Srinivas wrote:
>
> > Matt,
> >
> > What should Apache do in this case? Oppose the JSR? Vote No? or just
> > not participate in the JSR?
> >
> > "In addition to JSR specifications, the TCK used to validate the JSR
> > must also be available under a license that does not incur downstream
> > implications to users of the implementation or the code used to
> > implement it. Also, the license used to obtain the TCK cannot include
> > terms that would restrict open communication and use of the TCK to
> > validate an implmentation."
>
> I would expect we vote no with stated objections pointing back to
> this policy.
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jul 6, 2007, at 11:44 AM, Davanum Srinivas wrote:
> Matt,
>
> What should Apache do in this case? Oppose the JSR? Vote No? or just
> not participate in the JSR?
>
> "In addition to JSR specifications, the TCK used to validate the JSR
> must also be available under a license that does not incur downstream
> implications to users of the implementation or the code used to
> implement it. Also, the license used to obtain the TCK cannot include
> terms that would restrict open communication and use of the TCK to
> validate an implmentation."
I would expect we vote no with stated objections pointing back to
this policy.
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Davanum Srinivas <da...@gmail.com>.
Matt,
What should Apache do in this case? Oppose the JSR? Vote No? or just
not participate in the JSR?
"In addition to JSR specifications, the TCK used to validate the JSR
must also be available under a license that does not incur downstream
implications to users of the implementation or the code used to
implement it. Also, the license used to obtain the TCK cannot include
terms that would restrict open communication and use of the TCK to
validate an implmentation."
thanks,
dims
On 7/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> Sam had challenged us to put our thinking into a form that people
> could shoot at. I've thought about this for a bit and have an
> alternate set of changes for participation at the JCP. I have marked
> up a copy fo the JCP page and submit this for your consideration.
> Although I may have left some holes I believe that this change in
> policy strikes a balance of communicating our position going forward
> without jeopardizing commitments already made in the past.
>
> http://people.apache.org/~hogstrom/jcp/
>
--
Davanum Srinivas :: http://davanum.wordpress.com
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Jeff Genender <jg...@apache.org>.
Roland Weber wrote:
> Jeff Genender wrote:
>> What a great way to make this happen....by voting no. Instead of just
>> making a stance by saying we will no longer participate because we don't
>> feel the JCP is doing the right thing, they just don't invite us to play
>> in the game anymore, because we sit in the middle of the court while a
>> game is going on (voting no). Why not walk off the court and say "we
>> don't like the rules, so we don't want to play the game. Invite us when
>> your rules get better." There is a huge difference in delivery, who is
>> in control, and makes a much different statement.
>
> I agree with your analysis. I just don't see how your
> metaphor matches. Abstaining from votes is not "leaving
> the court". Abstaining is sitting in the middle while
> the play goes on. Pulling out altogether would be
> leaving the court. Voting "No" is standing in the
> middle of the court and shouting: listen, this cannot
> continue like it used to be.
>
I have changed my tune somewhat ;-) I am fine with the -1 for
forumulation of JSR...I am not once its ratified and we are on it (and
dealing/voting with technical issues). My experience with the JCP has
really only been on EGs, so I have a different set of glasses on how I
viewed what the -1 is for. ;-)
Jeff
> cheers,
> Roland
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Roland Weber <ro...@apache.org>.
Jeff Genender wrote:
> What a great way to make this happen....by voting no. Instead of just
> making a stance by saying we will no longer participate because we don't
> feel the JCP is doing the right thing, they just don't invite us to play
> in the game anymore, because we sit in the middle of the court while a
> game is going on (voting no). Why not walk off the court and say "we
> don't like the rules, so we don't want to play the game. Invite us when
> your rules get better." There is a huge difference in delivery, who is
> in control, and makes a much different statement.
I agree with your analysis. I just don't see how your
metaphor matches. Abstaining from votes is not "leaving
the court". Abstaining is sitting in the middle while
the play goes on. Pulling out altogether would be
leaving the court. Voting "No" is standing in the
middle of the court and shouting: listen, this cannot
continue like it used to be.
cheers,
Roland
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Jeff Genender <jg...@apache.org>.
Roland Weber wrote:
> Jeff Genender wrote:
>> I really don't like the "vote against" component. IMHO, that is
>> disruptive and will give us an interesting reputation. I would
>> recommend we simply pull out of JSRs that don't play by the rules.
>
> I don't know how the JSR participants are selected. If the
> ASF is asked/invited/accepted as a member of the JSR, and
> our rules of engagement are known in advance, the JSR has
> to deal with "No" votes based on these rules.
Yup...what a great way to make it so we aren't invited again, right?
So now they are in control because we won't get invited any more, right?
> They can't
> just get the ASF on board, issue a press release that the
> effort is backed by the ASF, and then mob us out when the
> press doesn't care anymore. If they don't like our rules,
> they shouldn't let us on board.
What a great way to make this happen....by voting no. Instead of just
making a stance by saying we will no longer participate because we don't
feel the JCP is doing the right thing, they just don't invite us to play
in the game anymore, because we sit in the middle of the court while a
game is going on (voting no). Why not walk off the court and say "we
don't like the rules, so we don't want to play the game. Invite us when
your rules get better." There is a huge difference in delivery, who is
in control, and makes a much different statement.
> Note the "in advance" part above. I don't make a statement
> for the JSRs in which we are currently involved while our
> rules of engagement are revised.
>
> cheers,
> Roland
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Roland Weber <ro...@apache.org>.
Jeff Genender wrote:
> I really don't like the "vote against" component. IMHO, that is
> disruptive and will give us an interesting reputation. I would
> recommend we simply pull out of JSRs that don't play by the rules.
I don't know how the JSR participants are selected. If the
ASF is asked/invited/accepted as a member of the JSR, and
our rules of engagement are known in advance, the JSR has
to deal with "No" votes based on these rules. They can't
just get the ASF on board, issue a press release that the
effort is backed by the ASF, and then mob us out when the
press doesn't care anymore. If they don't like our rules,
they shouldn't let us on board.
Note the "in advance" part above. I don't make a statement
for the JSRs in which we are currently involved while our
rules of engagement are revised.
cheers,
Roland
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Ralph Goers <Ra...@dslextreme.com>.
Jeff Genender wrote:
> Because we are invited to the committee based on our technical acumen.
> If we change our votes that are supposed to be based on the technical
> components to -1s for political reasons (or reasons that are not based
> on technical merits), then we will be viewed as activists, and likely
> won't be invited in the future. The invites should be based on our
> technical capabilities. Whether we choose to accept being on these JSRs
> based on our policies is our choice, but lets not become a roadblock.
> Lets take the high road.
>
I don't comprehend your reasoning. How could anything be more technical
than this? We are voting on technical merits if we do not have the
ability to write the code and test it. In my opinion, voting No whenever
it is warranted for these reasons is required if the ASF has any hope of
effecting change. The status quo is simply not working.
Ralph
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Jeff Genender <jg...@apache.org>.
Joe Schaefer wrote:
> Jeff Genender <jg...@apache.org> writes:
>
>> Justin Erenkrantz wrote:
>>> On 7/6/07, Jeff Genender <jg...@apache.org> wrote:
>>>> Because we are invited to the committee based on our technical acumen.
>>>> If we change our votes that are supposed to be based on the technical
>>>> components to -1s for political reasons (or reasons that are not based
>>>> on technical merits), then we will be viewed as activists, and likely
>>>> won't be invited in the future. The invites should be based on our
>>>> technical capabilities. Whether we choose to accept being on these JSRs
>>>> based on our policies is our choice, but lets not become a roadblock.
>>>> Lets take the high road.
>>> Invites? We were elected. And, we recently won 'JCP Member of the
>>> Year' again. If the JCP voting populace is dis-satisfied with our
>>> behavior, they have an opportunity to voice that displeasure by voting
>>> us off the EC when our term expires soon. Until then, I think we
>>> should act according to our principles - as we have in the past -
>>> within the JCP.
>> Ok..Im refering to the JSRs...those are invites.
>
> Participation in EG's doesn't involve votes, and for some reason
> you are objecting to Matt's rationale for voting no in the EC
> on a JSR. I don't see the connection. Here's what Matt wrote:
>
> "Finally, JSRs that violate an open environment in terms of licenses
> that add downstream restrictions, whether it be the source that
> implements the specification or the consequences of testing that
> imposes use restrictions, or other restrictions incompatible with
> the AL 2.0 the ASF would regrettably vote against such JSRs."
>
Right...he said JSRs. AFAIK, JSRs do have their own votes of sorts.
> I'm not exactly sure what he's aiming for, but I believe most of
> it is covered by just observing that we believe such restrictions
> violate the JSPA. I continue to wonder what we should do about
> Section 5E of the JSPA, and maybe Matt's language is an attempt
> to speak to that. If so, I applaud his efforts.
>
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Jeff Genender <jg...@apache.org> writes:
> Justin Erenkrantz wrote:
>> On 7/6/07, Jeff Genender <jg...@apache.org> wrote:
>>> Because we are invited to the committee based on our technical acumen.
>>> If we change our votes that are supposed to be based on the technical
>>> components to -1s for political reasons (or reasons that are not based
>>> on technical merits), then we will be viewed as activists, and likely
>>> won't be invited in the future. The invites should be based on our
>>> technical capabilities. Whether we choose to accept being on these JSRs
>>> based on our policies is our choice, but lets not become a roadblock.
>>> Lets take the high road.
>>
>> Invites? We were elected. And, we recently won 'JCP Member of the
>> Year' again. If the JCP voting populace is dis-satisfied with our
>> behavior, they have an opportunity to voice that displeasure by voting
>> us off the EC when our term expires soon. Until then, I think we
>> should act according to our principles - as we have in the past -
>> within the JCP.
>
> Ok..Im refering to the JSRs...those are invites.
Participation in EG's doesn't involve votes, and for some reason
you are objecting to Matt's rationale for voting no in the EC
on a JSR. I don't see the connection. Here's what Matt wrote:
"Finally, JSRs that violate an open environment in terms of licenses
that add downstream restrictions, whether it be the source that
implements the specification or the consequences of testing that
imposes use restrictions, or other restrictions incompatible with
the AL 2.0 the ASF would regrettably vote against such JSRs."
I'm not exactly sure what he's aiming for, but I believe most of
it is covered by just observing that we believe such restrictions
violate the JSPA. I continue to wonder what we should do about
Section 5E of the JSPA, and maybe Matt's language is an attempt
to speak to that. If so, I applaud his efforts.
--
Joe Schaefer
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Jeff Genender <jg...@apache.org>.
Justin Erenkrantz wrote:
> On 7/6/07, Jeff Genender <jg...@apache.org> wrote:
>> Because we are invited to the committee based on our technical acumen.
>> If we change our votes that are supposed to be based on the technical
>> components to -1s for political reasons (or reasons that are not based
>> on technical merits), then we will be viewed as activists, and likely
>> won't be invited in the future. The invites should be based on our
>> technical capabilities. Whether we choose to accept being on these JSRs
>> based on our policies is our choice, but lets not become a roadblock.
>> Lets take the high road.
>
> Invites? We were elected. And, we recently won 'JCP Member of the
> Year' again. If the JCP voting populace is dis-satisfied with our
> behavior, they have an opportunity to voice that displeasure by voting
> us off the EC when our term expires soon. Until then, I think we
> should act according to our principles - as we have in the past -
> within the JCP.
Ok..Im refering to the JSRs...those are invites.
>
> If we took the view you are advocating, then the JCP as you know it,
> wouldn't exist. I do realize that you and others weren't around for
> the last round of JCP negotiations in 2002 (briefly summarized at
> http://jakarta.apache.org/site/jspa-position.html). -- justin
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/6/07, Jeff Genender <jg...@apache.org> wrote:
> Because we are invited to the committee based on our technical acumen.
> If we change our votes that are supposed to be based on the technical
> components to -1s for political reasons (or reasons that are not based
> on technical merits), then we will be viewed as activists, and likely
> won't be invited in the future. The invites should be based on our
> technical capabilities. Whether we choose to accept being on these JSRs
> based on our policies is our choice, but lets not become a roadblock.
> Lets take the high road.
Invites? We were elected. And, we recently won 'JCP Member of the
Year' again. If the JCP voting populace is dis-satisfied with our
behavior, they have an opportunity to voice that displeasure by voting
us off the EC when our term expires soon. Until then, I think we
should act according to our principles - as we have in the past -
within the JCP.
If we took the view you are advocating, then the JCP as you know it,
wouldn't exist. I do realize that you and others weren't around for
the last round of JCP negotiations in 2002 (briefly summarized at
http://jakarta.apache.org/site/jspa-position.html). -- justin
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Ralph Goers <Ra...@dslextreme.com>.
Davanum Srinivas wrote:
> Then i'd like for ASF to withdraw from the JCP and Sun can invite any
> of the committers specifically for their technical abilities. ASF need
> not be involved at all.
>
> thanks,
> dims
>
I couldn't agree less. As has been pointed out, many of the JSRs have
been released on acceptable terms. IMO, the ASF has an obligation to
continue to influence open source development. The only effective way to
do that is to be involved.
Pulling out of the JCP is effectively sticking our head in the sand and
hopnig it all gets better on its own.
Ralph
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Davanum Srinivas <da...@gmail.com>.
Then i'd like for ASF to withdraw from the JCP and Sun can invite any
of the committers specifically for their technical abilities. ASF need
not be involved at all.
thanks,
dims
On 7/6/07, Jeff Genender <jg...@apache.org> wrote:
>
>
> Justin Erenkrantz wrote:
> > On 7/6/07, Jeff Genender <jg...@apache.org> wrote:
> >> I really don't like the "vote against" component. IMHO, that is
> >> disruptive and will give us an interesting reputation. I would
> >> recommend we simply pull out of JSRs that don't play by the rules.
> >>
> >> I just wouldn't participate, not be a road block.
> >
> > We have a vote within the Executive Committee. Hence, why should we
> > abdicate our responsibility to vote in line with our own policies?
> >
>
> Because we are invited to the committee based on our technical acumen.
> If we change our votes that are supposed to be based on the technical
> components to -1s for political reasons (or reasons that are not based
> on technical merits), then we will be viewed as activists, and likely
> won't be invited in the future. The invites should be based on our
> technical capabilities. Whether we choose to accept being on these JSRs
> based on our policies is our choice, but lets not become a roadblock.
> Lets take the high road.
>
> Jeff
>
> > AFAIK, JCP votes are majority - not requiring unanimous consent;
> > though I have heard that Sun wields veto authority on certain votes.
> > -- justin
>
--
Davanum Srinivas :: http://davanum.wordpress.com
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by Jeff Genender <jg...@apache.org>.
Andrew C. Oliver wrote:
> Let's not get bogged down in the procedural details or we'll never reach
> a consensus. And we WILL be colored as nutso fanatics just like OSI is
> being colored like nutso fanatics because they've been taking a stand
> against companies calling software clearly licensed in contradiction
> with the OSD "open source".
Bingo ;-) That was really where I was coming from. Lets do what we
need to do, but lets do it right...and I think we are ;-)
> Retroactivity
> 6. If Apache takes a stance on these things do we apply it to ALL work
> or NEW work only?
This is where my concerns begin to form. Since we are already a part of
JSRs that are in effect, I think we need to either wave them, or back
out gracefully.
I really want to know what the projects who are affected think and like
to hear from them.
Jeff
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by "Andrew C. Oliver" <ac...@buni.org>.
Let's not get bogged down in the procedural details or we'll never reach
a consensus. And we WILL be colored as nutso fanatics just like OSI is
being colored like nutso fanatics because they've been taking a stand
against companies calling software clearly licensed in contradiction
with the OSD "open source". This is just how the game is played, sad
but true.
At core, what is on the table is:
NDAs
1. Apache taking a stance against NDAs in the formation of the "open
standard" specification?
2. Apache taking a stance against NDAs in negotiating the terms of the
TCK -- or really up front licensing terms for TCKs that are compatible
with open source?
3. Apache taking a stance against NDAs in regards to actually performing
the test?
TCKs
4. As a side issue since the TCK is the final arbitrator of the
specification should it also be open? (I think that was Roy, hopefully
my paraphrase doesn't botch it)
5. Apache taking a stance against TCKs that have open source
incompatible license restrictions?
Retroactivity
6. If Apache takes a stance on these things do we apply it to ALL work
or NEW work only?
I view the "when" the negative or abstaining vote is taken to be a
procedural detail that we can work out after we come to a consensus on
the core. Am I missing anything?
-Andy
Jeff Genender wrote:
>
> Ok...again...I think we have our wires crossed. I am *not* opposed to
> abstaining the formulation of the JSR based on licensing issues. I
> think that goes hand in hand with your director analogy and voting on
> something based on business as usual. I *am* opposed to voting -1 when
> the JSR has bee established and the votes internally are technical in
> nature. Perhaps I read Matt's write up wrong:
>
> "Finally, JSRs that violate an open environment in terms of licenses
> that add downstream restrictions, whether it be the source that
> implements the specification or the consequences of testing that imposes
> use restrictions, or other restrictions incompatible with the AL 2.0 the
> ASF would regrettably vote against such JSRs."
>
> Maybe I read this as all too over reaching regarding the JSR. Vote
> against the formulation of the JSR, but once we are on it and it becomes
> technical, then I think we are in a different situation, and we are best
> to just pull out. *That* is my point.
>
> Jeff
>
>
>
>> Ralph
>>
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jul 6, 2007, at 4:25 PM, Jeff Genender wrote:
>
> "Finally, JSRs that violate an open environment in terms of licenses
> that add downstream restrictions, whether it be the source that
> implements the specification or the consequences of testing that
> imposes
> use restrictions, or other restrictions incompatible with the AL
> 2.0 the
> ASF would regrettably vote against such JSRs."
>
> Maybe I read this as all too over reaching regarding the JSR. Vote
> against the formulation of the JSR, but once we are on it and it
> becomes
> technical, then I think we are in a different situation, and we are
> best
> to just pull out. *That* is my point.
>
Perhaps some wording to clarify this is about new JSRs. The comment
was never intended to be retroactive. That would be just plain silly :)
Although, I'm confused about the voting process at the JCP. How can
Sun revise the legal issues without invalidating everyone's vote?
Seems that the legal issues are a fundamental part of the formulation
of a JSR. Looking at this: http://jcp.org/en/jsr/results?id=4216
more red would have been a clear direction as all the grey looks a
bit timid. Perhaps its more political niceness. If Sun had not
withdrawn the JSR would it have passed with two yeses and all all the
abstains?
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by Ralph Goers <Ra...@dslextreme.com>.
Jeff Genender wrote:
> Ok...again...I think we have our wires crossed. I am *not* opposed to
> abstaining the formulation of the JSR based on licensing issues. I
> think that goes hand in hand with your director analogy and voting on
> something based on business as usual. I *am* opposed to voting -1 when
> the JSR has bee established and the votes internally are technical in
> nature. Perhaps I read Matt's write up wrong:
>
> "Finally, JSRs that violate an open environment in terms of licenses
> that add downstream restrictions, whether it be the source that
> implements the specification or the consequences of testing that imposes
> use restrictions, or other restrictions incompatible with the AL 2.0 the
> ASF would regrettably vote against such JSRs."
>
> Maybe I read this as all too over reaching regarding the JSR. Vote
> against the formulation of the JSR, but once we are on it and it becomes
> technical, then I think we are in a different situation, and we are best
> to just pull out. *That* is my point.
>
>
That is all well and good, but the point I keep hearing here is that
participants don't know what the licensing terms will be when the JSR is
initiated. As I understand it, the Spec lead gets to set the rules and
apparently often doesn't publish the licensing for the TCK until late in
the game or perhaps even after the JSR is approved. If my understanding
is correct, then I don't see how the ASF could ever possibly vote Yes on
such a JSR, even when the vote is supposed to be just on technical merits.
In other words, once the licensing issues are agreed upon I would agree
with your position - all votes should then be just on technical grounds.
Ralph
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by Jeff Genender <jg...@apache.org>.
Ralph Goers wrote:
> When does a vote on a JSR take place on licensing terms? I suggest you
> re-review http://jcp.org/en/jsr/results?id=4216 and look at the
> comments. Here you have most of the participants abstaining due to
> licensing issues, not on the technical merits of interfaces or
> annotations. From what I can see, all that is being suggested is that
> the ASF continue to do this whenever it is necessary with one change
> being a No vote instead of an abstention.
>
Ok...again...I think we have our wires crossed. I am *not* opposed to
abstaining the formulation of the JSR based on licensing issues. I
think that goes hand in hand with your director analogy and voting on
something based on business as usual. I *am* opposed to voting -1 when
the JSR has bee established and the votes internally are technical in
nature. Perhaps I read Matt's write up wrong:
"Finally, JSRs that violate an open environment in terms of licenses
that add downstream restrictions, whether it be the source that
implements the specification or the consequences of testing that imposes
use restrictions, or other restrictions incompatible with the AL 2.0 the
ASF would regrettably vote against such JSRs."
Maybe I read this as all too over reaching regarding the JSR. Vote
against the formulation of the JSR, but once we are on it and it becomes
technical, then I think we are in a different situation, and we are best
to just pull out. *That* is my point.
Jeff
> Ralph
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by Ralph Goers <Ra...@dslextreme.com>.
Jeff Genender wrote:
>
> Wait...I think we have our lines crossed somewhere...if the other
> directors are voting on whether we do business as usual or not, then
> absolutely yes, vote the -1.
>
> If the other directors are voting on some interfaces and annotations,
> and we vote -1 based on doing business as usual, that doesn't seem real
> appropriate to me...
>
>
When does a vote on a JSR take place on licensing terms? I suggest you
re-review http://jcp.org/en/jsr/results?id=4216 and look at the
comments. Here you have most of the participants abstaining due to
licensing issues, not on the technical merits of interfaces or
annotations. From what I can see, all that is being suggested is that
the ASF continue to do this whenever it is necessary with one change
being a No vote instead of an abstention.
Ralph
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by Jeff Genender <jg...@apache.org>.
Ralph Goers wrote:
> Jeff Genender wrote:
>>
>> Sorry, I fail to see how your analogy to congress (and bending over)
>> plays out here.
>>
>> It really comes down to how you want to be viewed outside of Apache. Do
>> we want to be viewed as the activists who block doctors from going to
>> abortion clinics because we are against abortion? Or do we want to say,
>> "hey, we don't like the way you do business, therefore we will be happy
>> to play when you guys get it together, but until then we would rather
>> not be a part of this." How do you want Apache to be viewed by their
>> peers?
>>
>>
> That is exactly the point. We aren't standing outside the entrance
> blocking doctors from coming in. We are one of the members of the
> clinic's board of directors. So what if all the other directors vote to
> continue to do business as usual. If we don't agree then as someone with
> a right to vote we should vote according to our principles, not
> according to the majority so we won't make waves.
Wait...I think we have our lines crossed somewhere...if the other
directors are voting on whether we do business as usual or not, then
absolutely yes, vote the -1.
If the other directors are voting on some interfaces and annotations,
and we vote -1 based on doing business as usual, that doesn't seem real
appropriate to me...
>
> Ralph
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by Ralph Goers <Ra...@dslextreme.com>.
Jeff Genender wrote:
>
> Sorry, I fail to see how your analogy to congress (and bending over)
> plays out here.
>
> It really comes down to how you want to be viewed outside of Apache. Do
> we want to be viewed as the activists who block doctors from going to
> abortion clinics because we are against abortion? Or do we want to say,
> "hey, we don't like the way you do business, therefore we will be happy
> to play when you guys get it together, but until then we would rather
> not be a part of this." How do you want Apache to be viewed by their
> peers?
>
>
That is exactly the point. We aren't standing outside the entrance
blocking doctors from coming in. We are one of the members of the
clinic's board of directors. So what if all the other directors vote to
continue to do business as usual. If we don't agree then as someone with
a right to vote we should vote according to our principles, not
according to the majority so we won't make waves.
Ralph
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by "Andrew C. Oliver" <ac...@buni.org>.
Jeff Genender wrote:
>
>
> Ummm...no...I clearly am not very good at getting my point across. I
> said "leave" if they don't work with policies that are acceptable to us.
> Don't collaborate, don't lend the good name, and don't
> legitimatize...just leave the JCP.
>
>
I don't disagree with that, but we have to find a consensus in here
somewhere so I think both for the recent proposals are good starting
points (minus shoring up some of the "may not sign NDA" type language in
the recent one nor do I think it is all that regrettable to vote against
bad things)
-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: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by Jeff Genender <jg...@apache.org>.
Andrew C. Oliver wrote:
> Jeff Genender wrote:
>>
>> We can agree to disagree on this point. We can be viewed as a true open
>> source organization, and still stand our ground. If you truly don't
>> want to be a Quisling, then don't collaborate with the enemy...it's
>> simple. But don't put us so Apache is viewed as an acitivist...this
>> will hurt us in the future from being part of organizations or getting
>> "elected" because of fear that we will throw a tantrum if we don't like
>> how things are run. Don't want to be a Quisling? Exit the JCP.
>>
>>
> I never joined it for this reason. So you're arguing that Apache should
> collaborate and lend its good name to and legitimize an organization
> that creates "open standards" that aren't implementable in open source
> and aren't even "open"?
Ummm...no...I clearly am not very good at getting my point across. I
said "leave" if they don't work with policies that are acceptable to us.
Don't collaborate, don't lend the good name, and don't
legitimatize...just leave the JCP.
> That it should not stand in the way of them
> being associated with its good name because it would look bad if it was
> an "activist" for open source? I agree that if Apache cannot change the
> JCP soon that it should exit the JCP.
> -Andy
>>> -Andy
>>>
>>>
>
>
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by "Andrew C. Oliver" <ac...@buni.org>.
Jeff Genender wrote:
>
> We can agree to disagree on this point. We can be viewed as a true open
> source organization, and still stand our ground. If you truly don't
> want to be a Quisling, then don't collaborate with the enemy...it's
> simple. But don't put us so Apache is viewed as an acitivist...this
> will hurt us in the future from being part of organizations or getting
> "elected" because of fear that we will throw a tantrum if we don't like
> how things are run. Don't want to be a Quisling? Exit the JCP.
>
>
I never joined it for this reason. So you're arguing that Apache should
collaborate and lend its good name to and legitimize an organization
that creates "open standards" that aren't implementable in open source
and aren't even "open"? That it should not stand in the way of them
being associated with its good name because it would look bad if it was
an "activist" for open source? I agree that if Apache cannot change the
JCP soon that it should exit the JCP.
-Andy
>> -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: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by Jeff Genender <jg...@apache.org>.
Andrew C. Oliver wrote:
> Jeff Genender wrote:
>> Andrew C. Oliver wrote:
>>
>> Sorry, I fail to see how your analogy to congress (and bending over)
>> plays out here.
>>
>> It really comes down to how you want to be viewed outside of Apache. Do
>> we want to be viewed as the activists who block doctors from going to
>> abortion clinics because we are against abortion? Or do we want to say,
>> "hey, we don't like the way you do business, therefore we will be happy
>> to play when you guys get it together, but until then we would rather
>> not be a part of this." How do you want Apache to be viewed by their
>> peers?
> A great reason to participate as an individual and not as a member of
> Apache. I want Apache to be viewed as true to open source organization
> not as a Quisling. How Jeff Genender is viewed ought to be on his own
> individual participation.
We can agree to disagree on this point. We can be viewed as a true open
source organization, and still stand our ground. If you truly don't
want to be a Quisling, then don't collaborate with the enemy...it's
simple. But don't put us so Apache is viewed as an acitivist...this
will hurt us in the future from being part of organizations or getting
"elected" because of fear that we will throw a tantrum if we don't like
how things are run. Don't want to be a Quisling? Exit the JCP.
>
> -Andy
>
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by "Andrew C. Oliver" <ac...@buni.org>.
Jeff Genender wrote:
> Andrew C. Oliver wrote:
>
>
> Sorry, I fail to see how your analogy to congress (and bending over)
> plays out here.
>
> It really comes down to how you want to be viewed outside of Apache. Do
> we want to be viewed as the activists who block doctors from going to
> abortion clinics because we are against abortion? Or do we want to say,
> "hey, we don't like the way you do business, therefore we will be happy
> to play when you guys get it together, but until then we would rather
> not be a part of this." How do you want Apache to be viewed by their
> peers?
A great reason to participate as an individual and not as a member of
Apache. I want Apache to be viewed as true to open source organization
not as a Quisling. How Jeff Genender is viewed ought to be on his own
individual participation.
-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: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by Jeff Genender <jg...@apache.org>.
Andrew C. Oliver wrote:
> Sun knew Apache was an open source organization. Why should the expect
> it to vote for things that aren't conducive to open source when it uses
> Apache to legitimize the JCP? That logic baffles me...Taking the high
> road is bending over? Who are we? Congress?
>
Sorry, I fail to see how your analogy to congress (and bending over)
plays out here.
It really comes down to how you want to be viewed outside of Apache. Do
we want to be viewed as the activists who block doctors from going to
abortion clinics because we are against abortion? Or do we want to say,
"hey, we don't like the way you do business, therefore we will be happy
to play when you guys get it together, but until then we would rather
not be a part of this." How do you want Apache to be viewed by their
peers?
> Jeff Genender wrote:
>> Justin Erenkrantz wrote:
>>
>>> On 7/6/07, Jeff Genender <jg...@apache.org> wrote:
>>>
>>>> I really don't like the "vote against" component. IMHO, that is
>>>> disruptive and will give us an interesting reputation. I would
>>>> recommend we simply pull out of JSRs that don't play by the rules.
>>>>
>>>> I just wouldn't participate, not be a road block.
>>>>
>>> We have a vote within the Executive Committee. Hence, why should we
>>> abdicate our responsibility to vote in line with our own policies?
>>>
>>>
>>
>> Because we are invited to the committee based on our technical acumen.
>> If we change our votes that are supposed to be based on the technical
>> components to -1s for political reasons (or reasons that are not based
>> on technical merits), then we will be viewed as activists, and likely
>> won't be invited in the future. The invites should be based on our
>> technical capabilities. Whether we choose to accept being on these JSRs
>> based on our policies is our choice, but lets not become a roadblock.
>> Lets take the high road.
>>
>> Jeff
>>
>>
>>> AFAIK, JCP votes are majority - not requiring unanimous consent;
>>> though I have heard that Sun wields veto authority on certain votes.
>>> -- justin
>>>
>
>
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
Posted by "Andrew C. Oliver" <ac...@buni.org>.
Sun knew Apache was an open source organization. Why should the expect
it to vote for things that aren't conducive to open source when it uses
Apache to legitimize the JCP? That logic baffles me...Taking the high
road is bending over? Who are we? Congress?
Jeff Genender wrote:
> Justin Erenkrantz wrote:
>
>> On 7/6/07, Jeff Genender <jg...@apache.org> wrote:
>>
>>> I really don't like the "vote against" component. IMHO, that is
>>> disruptive and will give us an interesting reputation. I would
>>> recommend we simply pull out of JSRs that don't play by the rules.
>>>
>>> I just wouldn't participate, not be a road block.
>>>
>> We have a vote within the Executive Committee. Hence, why should we
>> abdicate our responsibility to vote in line with our own policies?
>>
>>
>
> Because we are invited to the committee based on our technical acumen.
> If we change our votes that are supposed to be based on the technical
> components to -1s for political reasons (or reasons that are not based
> on technical merits), then we will be viewed as activists, and likely
> won't be invited in the future. The invites should be based on our
> technical capabilities. Whether we choose to accept being on these JSRs
> based on our policies is our choice, but lets not become a roadblock.
> Lets take the high road.
>
> Jeff
>
>
>> AFAIK, JCP votes are majority - not requiring unanimous consent;
>> though I have heard that Sun wields veto authority on certain votes.
>> -- justin
>>
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Jeff Genender <jg...@apache.org>.
Justin Erenkrantz wrote:
> On 7/6/07, Jeff Genender <jg...@apache.org> wrote:
>> I really don't like the "vote against" component. IMHO, that is
>> disruptive and will give us an interesting reputation. I would
>> recommend we simply pull out of JSRs that don't play by the rules.
>>
>> I just wouldn't participate, not be a road block.
>
> We have a vote within the Executive Committee. Hence, why should we
> abdicate our responsibility to vote in line with our own policies?
>
Because we are invited to the committee based on our technical acumen.
If we change our votes that are supposed to be based on the technical
components to -1s for political reasons (or reasons that are not based
on technical merits), then we will be viewed as activists, and likely
won't be invited in the future. The invites should be based on our
technical capabilities. Whether we choose to accept being on these JSRs
based on our policies is our choice, but lets not become a roadblock.
Lets take the high road.
Jeff
> AFAIK, JCP votes are majority - not requiring unanimous consent;
> though I have heard that Sun wields veto authority on certain votes.
> -- justin
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/6/07, Jeff Genender <jg...@apache.org> wrote:
> I really don't like the "vote against" component. IMHO, that is
> disruptive and will give us an interesting reputation. I would
> recommend we simply pull out of JSRs that don't play by the rules.
>
> I just wouldn't participate, not be a road block.
We have a vote within the Executive Committee. Hence, why should we
abdicate our responsibility to vote in line with our own policies?
AFAIK, JCP votes are majority - not requiring unanimous consent;
though I have heard that Sun wields veto authority on certain votes.
-- justin
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Jeff Genender <jg...@apache.org>.
I really don't like the "vote against" component. IMHO, that is
disruptive and will give us an interesting reputation. I would
recommend we simply pull out of JSRs that don't play by the rules.
I just wouldn't participate, not be a road block.
My .02.
Jeff
Matt Hogstrom wrote:
> Sam had challenged us to put our thinking into a form that people could
> shoot at. I've thought about this for a bit and have an alternate set
> of changes for participation at the JCP. I have marked up a copy fo the
> JCP page and submit this for your consideration. Although I may have
> left some holes I believe that this change in policy strikes a balance
> of communicating our position going forward without jeopardizing
> commitments already made in the past.
>
> http://people.apache.org/~hogstrom/jcp/
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Roland Weber <ro...@apache.org>.
Hi Matt,
> Also, the license used to obtain the TCK cannot
> include terms that would restrict open communication
> and use of the TCK to validate an implmentation.
I'm perfectly fine with the open communication part.
But the second one sounds ambiguous to me. Which is
your requirement?
a) everyone must have access to the TCK w/o NDA
b) all committers must have access to the TCK w/o NDA
c) a "core" or "test" group of committers must
have access to the TCK
(only PMCs? only those who sign an NDA?)
"cannot restrict" could mean any of these, because
even a term "only Apache committers" is a restriction.
I feel that's too broad. You should specify the
community within which the communication about and
use of the TCK, respectivcely, should be unrestricted.
cheers,
Roland
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jul 6, 2007, at 1:33 PM, Filip at Apache wrote:
> hmm, does this mean I have to put seat belts in 58 Dodge Coronet,
> cause new cars require it :)
> just thought I throw a stick in the wheel,
Think of it more as rehabing a house then... :)
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Filip at Apache <fh...@apache.org>.
Jim Jagielski wrote:
>
> On Jul 6, 2007, at 12:52 PM, Bertrand Delacretaz wrote:
>
>> On 7/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>> ...http://people.apache.org/~hogstrom/jcp/...
>>
>> I like your proposal, it has no impact on existing agreements yet
>> allows us to move forward.
>>
>
> So already existing project aren't affected at all yet
> newer (potential) projects are?
>
> And the parity is where?
>
> "Bobby, spit out that gum right now."
> "But teacher, Billy is chewing gum; how come he
> can but I can't?"
> "Well, Billy was here last year when we allowed
> gum chewing, but even though we disallowed it
> this year, we're still letting previous
> chewers enjoy their gum fix."
hmm, does this mean I have to put seat belts in 58 Dodge Coronet, cause
new cars require it :)
just thought I throw a stick in the wheel,
personally I'm against the existing vs "no new" NDAs. If we accept a
JSR, then a committer on the project should get access, not just the
ones who used to have access.
>
> Shouldn't one goal be to affect change *in the current
> JCP/JSRs?* To not only stop allowing us to go along
> with a system we think is broken, but to also fix
> what *is* broken?
yes, that's what's needed here
Filip
>
>
>
>
>
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 6, 2007, at 1:07 PM, Jim Jagielski wrote:
>
> On Jul 6, 2007, at 12:52 PM, Bertrand Delacretaz wrote:
>
>> On 7/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>> ...http://people.apache.org/~hogstrom/jcp/...
>>
>> I like your proposal, it has no impact on existing agreements yet
>> allows us to move forward.
>>
>
> So already existing project aren't affected at all yet
> newer (potential) projects are?
>
> And the parity is where?
>
> "Bobby, spit out that gum right now."
> "But teacher, Billy is chewing gum; how come he
> can but I can't?"
> "Well, Billy was here last year when we allowed
> gum chewing, but even though we disallowed it
> this year, we're still letting previous
> chewers enjoy their gum fix."
"Even though we claim gum chewing is dangerous and poses serious
risks, we're going to allow it anyway if you were already chewing"
>
> Shouldn't one goal be to affect change *in the current
> JCP/JSRs?* To not only stop allowing us to go along
> with a system we think is broken, but to also fix
> what *is* broken?
>
>
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by Roland Weber <ro...@apache.org>.
Jim Jagielski wrote:
> Shouldn't one goal be to affect change *in the current
> JCP/JSRs?*
Sure, that should be a _goal_.
> To not only stop allowing us to go along
> with a system we think is broken, but to also fix
> what *is* broken?
Are we going to fix what is broken, namely the JSRs?
Or are we going to break more, namely the communities
currently working based on NDAs or other unpleasant
restrictions? Are they supposed to just drop the
keyboards and wait until this is figured out, or
maybe forever?
I'm not here for very long, but even so I have read
several times that Apache is about communities. If
Apache has built some communities subject to NDAs,
then those should not be just killed off. Grant a
grace period, allow them to continue with maintenance
and bug fix releases, but disallow new major or even
minor releases, or find some other means to keep the
community alive or to phase/fade it out honourably.
That's probably a case-by-case decision rather than a
general policy. The general policy should be reserved
for new communities that are forming, or existing ones
that re-form for a new major effort.
If it is possible to release the same code without
running NDA-TCKs, the hard way is surely an option.
But when I read through the mail archive since May,
I found this statement[1] which kind of shocked me:
> Due to the terms of the JSPA, we can't release
> without it first passing the relevant TCK
So if there are communities that can not release
without using the NDA-TCKs that they already got,
I suggest to not kill them off without warning.
just my 0.02€,
Roland
[1]
http://mail-archives.apache.org/mod_mbox/www-jcp-open/200706.mbox/%3c5c902b9e0706271216m7c63f1c1lcc4144ebf708d1fc@mail.gmail.com%3e
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jul 6, 2007, at 12:52 PM, Bertrand Delacretaz wrote:
> On 7/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>> ...http://people.apache.org/~hogstrom/jcp/...
>
> I like your proposal, it has no impact on existing agreements yet
> allows us to move forward.
>
So already existing project aren't affected at all yet
newer (potential) projects are?
And the parity is where?
"Bobby, spit out that gum right now."
"But teacher, Billy is chewing gum; how come he
can but I can't?"
"Well, Billy was here last year when we allowed
gum chewing, but even though we disallowed it
this year, we're still letting previous
chewers enjoy their gum fix."
Shouldn't one goal be to affect change *in the current
JCP/JSRs?* To not only stop allowing us to go along
with a system we think is broken, but to also fix
what *is* broken?
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 7/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> ...http://people.apache.org/~hogstrom/jcp/...
I like your proposal, it has no impact on existing agreements yet
allows us to move forward.
The last red paragraph sounds a bit funny to me, here's a suggestion
which does not change its meaning:
Finally, the ASF would regrettably vote against JSRs that violate an
open environment in terms of licenses that add downstream
restrictions, whether it be the source that implements the
specification or the consequences of testing that imposes use
restrictions, or other restrictions incompatible with the AL 2.0.
-Bertrand
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round
2
Posted by "Andrew C. Oliver" <ac...@buni.org>.
"
* Users that are interested in signing an NDA to work on validating an
implementation may do so. However, Apache may, in the future, no longer
accept new NDAs.
"
change to:
"
Users that are interested in signing an NDA to work on validating an
implementation may do so. However, Apache may, in the future, will no
longer accept new NDAs except for projects adding a committer to an
ongoing effort.
"
Add:
"
* The ASF will not participate in its role as a member of the
scholarship committee with regards to TCKs that have so-called 'field of
use' restrictions in their licensing, undefined licensing or other
licensing restrictions that prohibit compliance with the 'Open Source
Definition' in implementations or downstream implementations."
"
* the ASF in its role as an Executive Committee member will abstain or
vote no in votes where the licensing of the JSR and TCK is not specified
up front and free of 'Field of Use' restrictions or other restrictive
covenants that prevent implementations or downstream implementations
from complying with the 'Open Source Definition'.
"
* link to http://opensource.org/docs/osd
Matt Hogstrom wrote:
> Sam had challenged us to put our thinking into a form that people
> could shoot at. I've thought about this for a bit and have an
> alternate set of changes for participation at the JCP. I have marked
> up a copy fo the JCP page and submit this for your consideration.
> Although I may have left some holes I believe that this change in
> policy strikes a balance of communicating our position going forward
> without jeopardizing commitments already made in the past.
>
> http://people.apache.org/~hogstrom/jcp/
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jul 6, 2007, at 5:37 PM, Geir Magnusson Jr. wrote:
> I wish you included the text so disconnected people could see it,
> and it would be come part of the archive...
>
> geir
I had copied the original page source for the jcp at http://
www.apache.org/jcp and applied the following changes:
--- original_jcp.html Fri Jul 6 20:36:33 2007
+++ index.html Fri Jul 6 09:07:23 2007
@@ -26,7 +26,7 @@
<tr><!-- SITE BANNER AND PROJECT IMAGE -->
<td align="left" valign="top">
-<a href="http://www.apache.org/"><img src="../images/
asf_logo_wide.gif" alt="The Apache Software Foundation" align="left"
border="0"/></a>
+<a href="http://www.apache.org/"><img src="http://apache.org/images/
asf_logo_wide.gif" alt="The Apache Software Foundation" align="left"
border="0"/></a>
</td>
</tr>
</table>
@@ -106,6 +106,9 @@
<!-- CONTENT -->
<td align="left" valign="top" class="content">
+ <font size="+5" color="red">This is a Draft for consideration and
NOT formal policy</font>
+<p>
+
<h2><img src="/images/redarrow.gif" alt=" "/>
Notice regarding open letter to Sun Microsystems
</h2>
@@ -143,8 +146,22 @@
<p>
Our goal is to put the "Community" in Java Community Process.
</p>
+<p><font color="red" weight="700"><ul>
+Apache's goal in participating in Expert Groups at the JCP as well
as on the Executive Committee is to help promote Open Standards, Open
Communication and Open Community. In the past, the ASF has signed a
Non-Disclosure Agreement (NDA) with Sun to recieve access to the TCKs
for various JSRs that were implemented by communities at Apache. The
ASF has reviewed the impact this decision on communities at Apache as
well as its impact on the industry. Based on this review the ASF is
changing its position on TCK access.
+<p>
+A change of this magnitude comes after a lot of consideration about
many factors. Some of these include alignement of Apache goals and
philosophy with Openess and Community. Also factoring into the
decision is our commitment to users and communities that have made
decisions to consume projects built on specifications from the JCP as
well as of individual contributors to participate in the building of
this technology.
<p>
-The JCP activities of the ASF are centered around three areas :
+To be faithful to our users and our principles the ASF has made the
following policy changes:
+<p><li>
+The ASF will no longer seek to receive access to new TCKs or
specifications that have restrictive liceneses.
+<li>Access to existing TCKs and specifications will continue to be
allowed so as to not disrupt existing communities or users.
+<li>The ASF will continue to be involved in the Executive Committee
as well as participate in JSRs. Participation in JSRs will be
determined based on the license terms of the specification,
Reference Implementation as well as the TCK used to validate an
implementation.
+<li>Users that currently have signed an NDA with Apache will be
allowed to continue their work.
+<li>Users that are interested in signing an NDA to work on
validating an implementation may do so. However, Apache may, in the
future, no longer accept new NDAs.
+<p>
+</ul></font>
+<p>
+The JCP activities of the ASF are centered around three areas :
</p>
<ul>
<li>
@@ -199,8 +216,8 @@
<ul>
<li>
-Operate in an open, transparent manner in the same way that our
-Apache community lists work
+Operate in an open, transparent manner in the same way that <font
color="red" weight="700">is consistent with Apache Community
principles</font> <strike>our
+Apache community lists work</strike>
</li>
<li>
Use consensus and/or voting for decision making
@@ -243,8 +260,8 @@
community might build or extend such a specification
</li>
<li>
-You must sign an <a href="ApacheNDA.pdf">Non-Disclosure Agreement</
a> with the Apache Software Foundation. as the ASF is a
-signatory with Sun on behalf of its representatives
+<strike>You must sign an <a href="ApacheNDA.pdf">Non-Disclosure
Agreement</a> with the Apache Software Foundation. as the ASF is a
+signatory with Sun on behalf of its representatives</strike>
</li>
</ul>
@@ -352,7 +369,12 @@
that the JSR was conducted under "JCP version" 2.5 or above. There
are some exceptions, such as
<a href="http://www.jcp.org/en/jsr/detail?id=176">J2SE 5</a> which
was conducted under JCP v 2.1 yet licensed under
the modern open-source-friendly specification license.
+
</p>
+<p><font color="red" weight="700">
+In addition to JSR specifications, the TCK used to validate the JSR
must also be available under a license that does not incur downstream
implications to users of the implementation or the code used to
implement it. Also, the license used to obtain the TCK cannot
include terms that would restrict open communication and use of the
TCK to validate an implmentation.<p>
+Finally, JSRs that violate an open environment in terms of licenses
that add downstream restrictions, whether it be the source that
implements the specification or the consequences of testing that
imposes use restrictions, or other restrictions incompatible with the
AL 2.0 the ASF would regrettably vote against such JSRs.
+</font>
<p>
The following projects are implementing one or more JCP specifications:
</p>
Re: [DISCUSS} Alternate Proposed Changes to JCP Participation - Round 2
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I wish you included the text so disconnected people could see it, and
it would be come part of the archive...
geir
On Jul 6, 2007, at 11:34 AM, Matt Hogstrom wrote:
> Sam had challenged us to put our thinking into a form that people
> could shoot at. I've thought about this for a bit and have an
> alternate set of changes for participation at the JCP. I have
> marked up a copy fo the JCP page and submit this for your
> consideration. Although I may have left some holes I believe that
> this change in policy strikes a balance of communicating our
> position going forward without jeopardizing commitments already
> made in the past.
>
> http://people.apache.org/~hogstrom/jcp/