www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: require ex ante IP disclosure was: [VOTE] New ASF/JCP Policies
Date Sun, 15 Jul 2007 20:49:59 GMT
--- "Geir Magnusson Jr." <geir@pobox.com> wrote:
> 
> On Jul 15, 2007, at 1:16 PM, Wade Chandler wrote:
> 
> > --- "Geir Magnusson Jr." <geir@pobox.com> wrote:
> >>
> >> On Jul 15, 2007, at 10:49 AM, Sam Ruby wrote:
> >>
> >>> On 7/15/07, Geir Magnusson Jr. <geir@pobox.com>
> >> wrote:
> >>>>
> >>>> On Jul 15, 2007, at 2:17 AM, Justin Erenkrantz
> >> wrote:
> >>>>
> >>>>> Unless we have another license grant for the
> >> specification (and in
> >>>>> some particular cases we have agreements that
> >> supersede the JSR
> >>>>> specification licenses), the only way for us
> to
> >> legally
> >>>> implement the
> >>>>> spec - since we are a signatory to the JSPA -
> >> is to adhere to those
> >>>>> terms: a) fully implement, b) do not modify,
> >> etc; and c) pass
> >>>> the TCK.
> >>>>
> >>>> This is why what Sun is doing w/ the JCK
> license
> >> is so nasty, and why
> >>>> the JCP needs to be fixed.
> >>>>
> >>>> The TCK license breaks any chance of "ex ante"
> IP
> >> policy at the JCP
> >>>> because there's no disclosure requirement.  The
> >> implementor works in
> >>>> good faith under the terms of the spec license,
> >> only to discover that
> >>>> later, the spec lead can control how they
> >> distribute their software.
> >>>>
> >>>> The irony is that Sun is a very vocal and
> active
> >> proponent of ex ante
> >>>> IP disclosure
> >>>>
> >>>>
> >>
> >
>
http://mailman.ctyme.com/pipermail/openstds/2007-April/000109.html
> >>>>
> >> http://www.amc.gov/comments/sunmicrosystems.pdf
> >>>>    etc..
> >>>
> >>> So why don't we do this: publish on
> >> http://www.apache.org/jcp/ that we
> >>> intend to vote NO on every JSR Review Ballot,
> >> Community Draft Ballot,
> >>> and Final Approval Ballot that does not provide
> a
> >> full and complete
> >>> disclosure of any and all relevant TCK terms, or
> >> on any such Ballot on
> >>> which we determine that the disclosed TCK terms
> >> would prevent the an
> >>> independent implementation under the Apache
> >> License, version 2.0.
> >>
> >> I have no problem with this, other than two minor
> >> changes.
> >>
> >> First, because putting together business terms
> isn't
> >> what engineeers
> >> who do JSRs do, I'd want to give the ecosystem
> >> warning that we're
> >> going to do this.  IOW "Don't show up after Oct 1
> >> w/o TCK terms" (or
> >> whatever date).
> >>
> >> Second, not only should we see a TCK license, but
> >> the spec lead
> >> should also publicly commit to have those terms
> >> always available to
> >> any licensor, short of being required by law or
> such
> >> to change them.
> >>
> >
> > Then Spec Leads would actually be expected to
> follow
> > the JCP procedures :-D I don't see how one can
> have
> > license terms and not have the license as the
> license
> > i the terms.
> >
> 
> But they are not required to guarantee those terms
> are publicly  
> available.
> 

Right, maybe that is something which can be worked on
in JSR 306. Then instead of the EG and the SL making a
determination for the community the community could
let the EG and SL know how they feel about the terms.
Either way though, I think they should show the EG the
terms, and I think the terms are the license, so the
process rules I mentioned mean part of the JSR review
should be the terms and the license for the RI and the
TCK and not just some sentence telling the EG the
rules will be good or something they previously agreed
to. That will hopefully get more EG members voting no
on JSRs until the terms are good and equal for all
according to the JSPA.

Wade

Mime
View raw message