www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip at Apache <fha...@apache.org>
Subject Re: [VOTE] New ASF/JCP Policies
Date Tue, 03 Jul 2007 15:19:26 GMT
-1
This discussion has been very long, so I might have missed the reasoning 
behind not issuing new NDAs for TCK tests.
This seems backwards, projects add committers all the time, and if all 
the committers with previous NDA have left the project,
then suddenly a project has no way of using the TCKs.

I have no problem adjusting my vote if I can see the reasoning behind 
such a statement

Filip

Sam Ruby 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
>
>


Mime
View raw message