You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by Sam Ruby <ru...@apache.org> on 2007/07/15 16:49:20 UTC
require ex ante IP disclosure was: [VOTE] New ASF/JCP Policies
On 7/15/07, Geir Magnusson Jr. <ge...@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.
Furthermore, we should seek out other EC members in the hopes that
they will make similar pledges. If we gather enough support to make a
difference in, say, the next 30 days we will continue on as a JCP
member, otherwise we will simply and quietly exit that organization as
we will have determined that it is incapable of self-governance. And
if we do succeed and stay on, we should view this policy as the first
step towards a much needed, and much broader, reform.
- Sam Ruby
P.S. One does not need to be a member of the JCP in order to create
an independent implementation of specifications that permit such
activities, nor does one need to be a member of the JCP in order to
enter into an NDA, so both of these are orthogonal concerns.
Re: require ex ante IP disclosure was: [VOTE] New ASF/JCP Policies
Posted by Wade Chandler <hw...@yahoo.com>.
--- "Geir Magnusson Jr." <ge...@pobox.com> wrote:
>
> On Jul 15, 2007, at 1:16 PM, Wade Chandler wrote:
>
> > --- "Geir Magnusson Jr." <ge...@pobox.com> wrote:
> >>
> >> On Jul 15, 2007, at 10:49 AM, Sam Ruby wrote:
> >>
> >>> On 7/15/07, Geir Magnusson Jr. <ge...@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
Re: require ex ante IP disclosure was: [VOTE] New ASF/JCP Policies
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 15, 2007, at 1:16 PM, Wade Chandler wrote:
> --- "Geir Magnusson Jr." <ge...@pobox.com> wrote:
>>
>> On Jul 15, 2007, at 10:49 AM, Sam Ruby wrote:
>>
>>> On 7/15/07, Geir Magnusson Jr. <ge...@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.
geir
> "2.2.1 CONFIRMATION OF LICENSING TERMS FOR RI AND TCK
>
> The Spec Lead's company or organization is responsible
> for the Reference Implementation (RI) and Technology
> Compatibility Kit (TCK) and its licensing under terms
> compatible with the licensing guidelines established
> for use within the JCP. The Spec Lead will provide the
> EC with confirmation of the terms under which the RI
> and TCK will be licensed at each review period. EC
> members will provide feedback on the terms as an
> indication of how the community might react as a whole
> to the terms.
> 2.3 EARLY DRAFT REVIEW
>
> definition - Community Review: A 30 to 90 day
> period when Members review and comment on the draft
> Specification.
>
> definition – Early Draft Review: A 30 to 90 day
> period, coexistent with Community Review, when the
> public review and comment on the draft Specification.
>
> Refinement of the draft Specification begins when the
> PMO posts it to the JCP Web Site and announces the
> start of Early Draft Review to all of the Members and
> the public. Anyone with access to the Internet can
> download and comment on the draft. The goal of Early
> Draft Review is to get the draft Specification into a
> form suitable for Public Review as quickly as possible
> by uncovering and correcting major problems with the
> draft. Early Draft Review is an early access review,
> designed to ideally take place when the specification
> still has some unresolved issues. The public's
> participation in Early Draft Review is an important
> part of the JCP. In the past, comments from the public
> have raised fundamental architectural and
> technological issues that have considerably improved
> some Specifications.
>
> All comments from Members and the public should be
> sent to the e-mail feedback address listed in the
> draft. The Spec Lead is responsible for ensuring that
> all comments are read and considered. Members have a
> right to receive a response to their comments. For
> simplicity, similar comments may be combined and
> responded to as one. "
>
> Wade
Re: require ex ante IP disclosure was: [VOTE] New ASF/JCP Policies
Posted by Wade Chandler <hw...@yahoo.com>.
--- "Geir Magnusson Jr." <ge...@pobox.com> wrote:
>
> On Jul 15, 2007, at 10:49 AM, Sam Ruby wrote:
>
> > On 7/15/07, Geir Magnusson Jr. <ge...@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.
"2.2.1 CONFIRMATION OF LICENSING TERMS FOR RI AND TCK
The Spec Lead's company or organization is responsible
for the Reference Implementation (RI) and Technology
Compatibility Kit (TCK) and its licensing under terms
compatible with the licensing guidelines established
for use within the JCP. The Spec Lead will provide the
EC with confirmation of the terms under which the RI
and TCK will be licensed at each review period. EC
members will provide feedback on the terms as an
indication of how the community might react as a whole
to the terms.
2.3 EARLY DRAFT REVIEW
definition - Community Review: A 30 to 90 day
period when Members review and comment on the draft
Specification.
definition Early Draft Review: A 30 to 90 day
period, coexistent with Community Review, when the
public review and comment on the draft Specification.
Refinement of the draft Specification begins when the
PMO posts it to the JCP Web Site and announces the
start of Early Draft Review to all of the Members and
the public. Anyone with access to the Internet can
download and comment on the draft. The goal of Early
Draft Review is to get the draft Specification into a
form suitable for Public Review as quickly as possible
by uncovering and correcting major problems with the
draft. Early Draft Review is an early access review,
designed to ideally take place when the specification
still has some unresolved issues. The public's
participation in Early Draft Review is an important
part of the JCP. In the past, comments from the public
have raised fundamental architectural and
technological issues that have considerably improved
some Specifications.
All comments from Members and the public should be
sent to the e-mail feedback address listed in the
draft. The Spec Lead is responsible for ensuring that
all comments are read and considered. Members have a
right to receive a response to their comments. For
simplicity, similar comments may be combined and
responded to as one. "
Wade
Re: require ex ante IP disclosure was: [VOTE] New ASF/JCP Policies
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 15, 2007, at 10:49 AM, Sam Ruby wrote:
> On 7/15/07, Geir Magnusson Jr. <ge...@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.
>
> Furthermore, we should seek out other EC members in the hopes that
> they will make similar pledges. If we gather enough support to make a
> difference in, say, the next 30 days we will continue on as a JCP
> member, otherwise we will simply and quietly exit that organization as
> we will have determined that it is incapable of self-governance. And
> if we do succeed and stay on, we should view this policy as the first
> step towards a much needed, and much broader, reform.
>
> - Sam Ruby
>
> P.S. One does not need to be a member of the JCP in order to create
> an independent implementation of specifications that permit such
> activities, nor does one need to be a member of the JCP in order to
> enter into an NDA, so both of these are orthogonal concerns.
Yes they are and I haven't the slightest idea
a) why you bring them up and
b) why you used a "P.S." since you could have just gone back up in
your mail editor and inserted the text before your signature :)
Unless you are typing on a typewriter and scanning, in which case
this comment is moot.
geir