www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: [VOTE] New ASF/JCP Policies
Date Tue, 03 Jul 2007 13:07:48 GMT
[+1]  Update http://www.apache.org/jcp/ with the markup indicated in


On 7/3/07, Sam Ruby <rubys@apache.org> wrote:
> [ ] +1 Update http://www.apache.org/jcp/ with the markup indicated in
> http://people.apache.org/~rubys/jcp.html
> [ ] +/- 0
> [ ] -1 Do not update http://www.apache.org/jcp/ based on this proposal
> In light of the upcoming US holiday, this vote will go 120 hours (5 days).
> And forgive the length of this email, but if this is a topic that
> interest you and yet you don't have time to read it all, I would
> encourage you to skip to the bottom and read my request and possibly
> the implications section before it.
>  - -
> It should be clear now to everybody that we need a clear and
> documented policy with regard to our continued participation in the
> JCP.
> Forgive me Geir, but you are a perennial optimist, and we have to love
> you for that, and in your eyes the solution is always just a month a
> way, but at some point we need to wake up and smell the coffee.
> You may view it as 'forcing', but when you gave a 30 day deadline, and
> that deadline has since passed not once, nor twice, but nearly three
> times over, the time to stop EVERYTHING and nail down a policy is NOW.
>  Not next month, not next week, not tomorrow, but NOW.
> I've asked repeatedly for a written policy, and in return I've seen
> various reframings of the questions that we face, and poking of holes
> in various people's proposals, but no written policy.
> The lack of such a policy is hurting our ability to take simple
> actions.  Actions like voting on an the creation of an expert group.
> So accordingly I am calling for a VOTE on a proposal I made an
> unprecedented seven weeks ago.  The proposal is not intended to be the
> final word.  If merely is intended to reflect a better policy than the
> one currently documented.  If it should happen to be ratified, then it
> could be changed at any time in response to another proposal.
> I will acknowledge that I have seen a number of recent comments.  Ones
> that might very well represent an improvement if properly flushed out.
>  But I don't intend to muddy the waters by changing the proposal at
> this late date.  If that means that the proposal gets voted down, so
> be it.  If that's the reason for this proposal being shot down -- i.e.
> it is so fatally flawed that it can't be rectified by a subsequent
> patch -- it is my hope that somebody picks up the baton and carries it
> forward.
> I will also acknowledge that there seems to be a lot of confusion
> about the proposal itself, so below I will lay out the basic context
> as I see it for the proposal (in a 'preface') followed by what I think
> the rather straightforward implications are of the proposal itself.
> Should these implications not match the proposal, I'll leave it up to
> the people who care to vote as whether that can be cleaned up in a
> subsequent 'patch', or whether the current policy should be left as is
> for now, possibly awaiting a better proposal.
>  - - -
> Preface:
> For purposes of this discussion only, the term 'open standard' means
> 'capable of being implemented as open source', nothing more, nothing
> less.  Whether we like the individual or group that produced it is
> irrelevant.  Whether or not that individual or group has done 'bad
> things' in the past is irrelevant.  Whether or not the process by
> which that specification was developed was 'open' is irrelevant.
> Whether or not the 'reference implementation' or the TCK is open
> source or not is irrelevant.
> What *IS* relevant is whether or not that standard has any known IP
> encumbrances which prevent an open source implementation.  If the
> specification has an unknown set of IP encumbrances, and the person
> who controls such IP is publicly spreading FUD, that, too, may be
> relevant.
> And as a matter of history, the ASF has 'bent' its core belief system
> to accommodate the JCP based on the belief that the JCP is worthwhile,
> and we could do more to change the JCP for the better from the inside
> than from the outside.  Until recently, this has been a good bet.
> Let me re-emphasize that last point.  The JCP and the JSPA have been
> dramatically improved based on the hard work of both Geir and Jason
> before him, and based on the countless individuals who have
> contributed to ASF projects which implement or make productive use of
> these specifications.  And in a number of cases, it was exactly Geir's
> optimism and persistence in the face of circumstances where I would
> have long since given up that made the difference.
> Yet, I know of no other process in which the ASF participates which
> requires NDAs which prevent a committer on an ASF project from
> discussing technical details pertinent to that project with another
> ASF committer on that same project; yet this is something that we have
> swallowed 'for the greater good' of our relationship with the JCP.
> Times have changed.
> 84 days ago, Geir notified Sun via an open letter of a significant
> breach of the JSPA contract which affects an ASF project.  He invited
> them to respond within 30 days.  30 days came and went.  Not once, not
> twice, but we are on the eve of it passing a third time.
> The fact that we had to resort to an open letter itself is an
> indication that we had given up hope of fixing the JCP from the
> inside.  The fact that nearly 90 days have elapsed since then just
> makes it that much clearer that while we once were a force shaping the
> JCP from the inside, we are now clearly and firmly on the 'outside'.
> In short, the time for 'warping' our belief in open development in
> order to accommodate a standards process that we can not change from
> inside needs to come to an end.
> So, yes, that means that I am 'forcing' a vote.  Enough is enough.  We
> need to treat the JCP as we would any other group which issues
> (allegedly open) standards.
> - - -
> Implications on the Proposal itself on our participation in the JCP:
> Any ASF committer is welcome to participate in a JSR expert group as
> an individual or as an employee of their respective employer, but may
> not participate as the designated representative of the ASF if the
> conditions upon their doing so require that person to not be able to
> share technical details related to their participation with their peer
> committers at the ASF.
> Any ASF committer is welcome to obtain access to a TCK as an
> individual or as an employee of their respective employer, but the ASF
> will not obtain a TCK on their behalf if the conditions upon doing so
> require that any person with access to the TCK will technical details
> related to that TCK with their peer committers at the ASF.
> From time to time, as a member of the EC, the ASF will be asked to
> review and vote on expert group formation, community drafts, and final
> approval of the JSR itself.  Under no circumstances will the ASF vote
> YES on any vote which prevents the ASF from creating a implementation.
>  If the spec requires a certification process which involves a TCK,
> then the terms of for obtaining that TCK can neither pose restrictions
> on the distribution of the project above what the Apache License
> requires, and must be freely available to anybody who so much as wants
> to submit a patch against an ASF codebase which implements said
> standard.
>  - - -
> Request:
> If you got this far, thanks for listening.  I will only ask one thing:
> given the length of time that this proposal has been out there, if you
> wish to debate the terms of this proposal, do it on a new thread.
> Vote -1 if you feel you must on this proposal with a pointer to that
> thread if you like, but lets keep this thread to the vote itself.
> - Sam Ruby

Davanum Srinivas :: http://davanum.wordpress.com

View raw message