www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Erenkrantz" <jus...@erenkrantz.com>
Subject Re: [Draft] New ASF/JCP Policies
Date Sun, 01 Jul 2007 17:17:24 GMT
On 7/1/07, Sam Ruby <rubys@apache.org> wrote:
> > 1) No NDAs can be required for participation in ASF activities.  I'm
> > not sure how we'll ever be able to meaningfully require private@ and
> > members@ list to be under an NDA, but I expect that inconvenient
> > observation will be mooted via adding "technical" as a qualifier for
> > "ASF activities".  This solves the NDA for TCK issue.
> +1


> > 2) The ASF won't participate in activities that aren't "run like an
> > Apache project".  This solves the EG issue.
> +1


> > 3) The ASF won't implement specifications that weren't created in a
> > manner similar to "an Apache project".  I'm not sure if we want this,
> > but to me it clearly falls out of your proposal, so I think that you
> > want this too.


> I don't believe it clearly falls out of my proposal, but I would
> support a proposal that removes my addition of "nor will we request
> access to TCKs for any given JSR produced by any working group," from
> the "Representation" section; and adds a new section that concerns
> itself with the conditions under which the ASF will formally request
> access to a TCK.  This new section would essentially repeat the final
> bullet in the "Representation" section.
> This should completely decouple the two issues, no?

I'm not quite sure if it truly decouples it, but I'll play along.

> > If you want operational specifics to get have a meaningful action for
> > the TCK/NDA issue, I'd suggest :
> >
> > 1) We announce that we no longer accept NDAs and will allow existing
> > under-NDA TCK usage for 1 release.
> +1

Does that mean 1 release of the JSR specification?  Or does that mean
one ASF release?

Either way a little bit of wiggle room is okay by me.  So +1 to either

> > 2) We make a public request to Sun that they formally drop any NDA
> > requirements around our TCK usage.  If they agree, we open things
> > up.  If they don't, we just shut it down.
> -1 (of the non-veto variety)
> s/Sun/all affected expert groups/
> s/shut it down/cease ASF representation in the expert groups that don't comply/

+1 to those modifications to Geir's suggestion.

Do note that it'd also bar projects from implementing the specs that
are created in such a manner - since we signed the JSPA, we can't
release unless we first pass the TCK.  But, if our policies prohibit
us from accepting the TCK, we can't do a release.

> Even with these changes, I'm not a fan of making this particular
> change retroactive, but if the majority feels that this should be
> done, I won't stand in the way.

I think if we mean it, we should make it retroactive.  But, I'll
follow the majority as well - though placing a cap of 1 release (be it
the spec or our release) is a reasonable compromise that doesn't allow
us to bring everything to a halt...  -- justin

View raw message