www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: require ex ante IP disclosure was: [VOTE] New ASF/JCP Policies
Date Sun, 15 Jul 2007 18:45:25 GMT

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.

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


Mime
View raw message