You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2006/08/14 01:53:28 UTC
RE: Specifications as (part of) ASF projects
Geir Magnusson Jr wrote:
> Noel J. Bergman wrote:
>> Wait ... why can't a specification be a releasable, just like a
>> codebase? The only issue, as I see it, would be enforcement of
>> compliance. And Roy even put forward a proposed license amendment
>> for such things.
> Which license amendment? The license amendment that I'm thinking of was
> specific to JCP TCKs and how derivative works of a TCK can't be used for
> compatibility - it had nothing to do w/ enforcement of compliance with a
> spec.
The JSR licemse, not the TCK license. Not that it can't be modified, but what else would you call the clauses forbidding the use of the trademark names, references to the specification, and restricted name space unless the code passed the TCK?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Specifications as (part of) ASF projects
Posted by "Noel J. Bergman" <no...@devtech.com>.
Geir Magnusson Jr wrote:
> Noel J. Bergman wrote:
>> Geir Magnusson Jr wrote:
>>> Noel J. Bergman wrote:
>>>> Wait ... why can't a specification be a releasable, just like a
>>>> codebase? The only issue, as I see it, would be enforcement of
>>>> compliance. And Roy even put forward a proposed license amendment
>>>> for such things.
>>> Which license amendment? The license amendment that I'm thinking of was
>>> specific to JCP TCKs and how derivative works of a TCK can't be used for
>>> compatibility - it had nothing to do w/ enforcement of compliance with a
>>> spec.
> <grrr mail client changed?>
Not for the past 6 years. Would love the chance, and still waiting for someone to get clueful about migrating Outlook in its entirety, and not just a piece here and there. I've got >4.5GB of mail to migrate, plus 1000s of contact and calendar entries.
> > The JSR licemse, not the TCK license.
> I don't remember a JSR license.
I was referring to http://www.apache.org/licenses/proposed/JSR-LICENSE-2.0.txt, which could be adapted for the purpose.
> > what else would you call the clauses forbidding the use of the
> > trademark names, references to the specification, and restricted
> > name space unless the code passed the TCK?
> Dunno, but different than enforced compliance.
Denying implementers the ability to use the specification's restricted name space, which effects the use of the API; make any reference to the specification; or use the trademark(s) is probably about right when dealing with Open Source.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Specifications as (part of) ASF projects
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Noel J. Bergman wrote:
> Geir Magnusson Jr wrote:
>> Noel J. Bergman wrote:
>>> Wait ... why can't a specification be a releasable, just like a
>>> codebase? The only issue, as I see it, would be enforcement of
>>> compliance. And Roy even put forward a proposed license amendment
>>> for such things.
>> Which license amendment? The license amendment that I'm thinking of was
>> specific to JCP TCKs and how derivative works of a TCK can't be used for
>> compatibility - it had nothing to do w/ enforcement of compliance with a
>> spec.
>
<grrr mail client changed?>
> The JSR licemse, not the TCK license.
I don't remember a JSR license. I remember an addendum for an RI, and
an addendum for a TCK.
> Not that it can't be modified,
> but what else would you call the clauses forbidding the use of the
> trademark names, references to the specification, and restricted
> name space unless the code passed the TCK?
Dunno, but different than enforced compliance.
geir
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org