You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/02/21 00:09:18 UTC
JSR-198 up for final vote
http://www.jcp.org/en/jsr/detail?id=198
Currently, I'm going to vote "yes" unless I hear otherwise. Deadline is
COB tomorrow. I'll get these to the list earlier in the future.
Personally, I think this is a dumb spec. Eclipse and IDEA aren't
involved (by their own choice). It's not clear to me what problem this
spec solves. However, it's optional, and up to the spec particpants to
try and generate market interest. That said, I can find no compelling
ASF reason to vote against.
geir
Re: JSR-198 up for final vote
Posted by Brett Porter <br...@apache.org>.
It seemed like a good idea at the time :)
I agree.
- Brett
Geir Magnusson Jr wrote:
> http://www.jcp.org/en/jsr/detail?id=198
>
> Currently, I'm going to vote "yes" unless I hear otherwise. Deadline is
> COB tomorrow. I'll get these to the list earlier in the future.
>
> Personally, I think this is a dumb spec. Eclipse and IDEA aren't
> involved (by their own choice). It's not clear to me what problem this
> spec solves. However, it's optional, and up to the spec particpants to
> try and generate market interest. That said, I can find no compelling
> ASF reason to vote against.
>
> geir
>
Re: JSR-198 up for final vote
Posted by Steve Loughran <st...@apache.org>.
Dain Sundstrom wrote:
> On Feb 23, 2006, at 5:30 PM, Geir Magnusson Jr wrote:
>
>> Dain Sundstrom wrote:
>>> On Feb 22, 2006, at 1:23 PM, Geir Magnusson Jr wrote:
>>>>> And I suppose they are granting rights to compliant
>>>>> implementations; it is only non-compliant rights that have to worry
>>>>> about possibly infringing some software patent that oracle holds.
>>>>> The trouble is: how do you define compliance?
>>>>
>>>> Passing the TCK.
>>>>
>>>> This got me thinking - I do wonder what Oracle has here - I guess a
>>>> patent. I wonder how much that aspect matters since no one is going
>>>> to implement this anyway except Sun and Oracle.
>>> The patent clause is what worries me. With the patent restriction is
>>> it possible to license an clean-room implementation under an OSI
>>> license? I feel we should not support a JSR that doesn't a grant
>>> field of use license to any derivative works of a complaint
>>> implementation regardless of the derivative work being compliant or not.
>>
>> The JSPA says that's every JSR.
>
> If that is true, then Oracle's statement does not follow the JSPA.
> Specifically this:
>
> under the JSPA, no copyright or patent licenses are granted for any
> non-compliant
> implementation made by downstream licensees, whether independent or
> based on the reference implementation.
>
> I don't care about the copyright as we can just write our own
> implementation of the specification, but if there are patents required
> to implement the specification, downstream licensees of our code can not
> make non-compliant implementations. To me that goes completely against
> the definitions of OpenSource. Therefore, I don't think we should
> support any JSR that includes such language.
>
> -dain
This is a really serious issue, as it shows up in any standards body
that I've ever got involved in. Patents can tear an org apart. Look at
the fuss that arose when the W3C started thinking of a RAND license,
which caused so much fuss (rightfully), that they killed that, which is
one of the reasons why some specs now go to OASIS, and others to ECMA.
(Eu computer manufacters association; says it all)
Out in grid-land, all GGF meetings are preceeded by a declaration of IPR
policy (you announce something, you are giving some rights to it), and
they take a list of all attendees. Nobody wants a repetition of the
great rambus/ddr debacle, in which something got standardised that
rambus had a submarine patent on.
Sunw hold some Java-related patents, specifically to do with code
validation. Ignore code path validation (not the signing, but the bit
where the validity of untrusted code is checked), and you don't have to
care. If you do want to run untrusted code with less than full rights,
then it starts to matter. So the Java VM spec itself must have some kind
of patent burden.
-steve
Re: JSR-198 up for final vote
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 23, 2006, at 5:30 PM, Geir Magnusson Jr wrote:
> Dain Sundstrom wrote:
>> On Feb 22, 2006, at 1:23 PM, Geir Magnusson Jr wrote:
>>>> And I suppose they are granting rights to compliant
>>>> implementations; it is only non-compliant rights that have to
>>>> worry about possibly infringing some software patent that oracle
>>>> holds. The trouble is: how do you define compliance?
>>>
>>> Passing the TCK.
>>>
>>> This got me thinking - I do wonder what Oracle has here - I guess
>>> a patent. I wonder how much that aspect matters since no one is
>>> going to implement this anyway except Sun and Oracle.
>> The patent clause is what worries me. With the patent restriction
>> is it possible to license an clean-room implementation under an
>> OSI license? I feel we should not support a JSR that doesn't a
>> grant field of use license to any derivative works of a complaint
>> implementation regardless of the derivative work being compliant
>> or not.
>
> The JSPA says that's every JSR.
If that is true, then Oracle's statement does not follow the JSPA.
Specifically this:
under the JSPA, no copyright or patent licenses are granted for any
non-compliant
implementation made by downstream licensees, whether independent or
based on the reference implementation.
I don't care about the copyright as we can just write our own
implementation of the specification, but if there are patents
required to implement the specification, downstream licensees of our
code can not make non-compliant implementations. To me that goes
completely against the definitions of OpenSource. Therefore, I don't
think we should support any JSR that includes such language.
-dain
Re: JSR-198 up for final vote
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 22, 2006, at 1:23 PM, Geir Magnusson Jr wrote:
>> And I suppose they are granting rights to compliant
>> implementations; it is only non-compliant rights that have to
>> worry about possibly infringing some software patent that oracle
>> holds. The trouble is: how do you define compliance?
>
> Passing the TCK.
>
> This got me thinking - I do wonder what Oracle has here - I guess a
> patent. I wonder how much that aspect matters since no one is
> going to implement this anyway except Sun and Oracle.
The patent clause is what worries me. With the patent restriction is
it possible to license an clean-room implementation under an OSI
license? I feel we should not support a JSR that doesn't a grant
field of use license to any derivative works of a complaint
implementation regardless of the derivative work being compliant or not.
I know this is all water under the bridge since it the vote was
already cast, but I think we should make a policy moving forward that
we will vote against any JSR, regardless of merit, if it carries such
a clause.
-dain
Re: JSR-198 up for final vote
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Steve Loughran wrote:
> Geir Magnusson Jr wrote:
>>
>>
>> Dain Sundstrom wrote:
>>> I think we should take a firm stand and vote against against any JSR
>>> that includes the downstream licensing restrictions, since it
>>> violates the Apache compromise
>>
>> Oracle is emphasizing the "Apache compromise", actually. We (Apache)
>> can do open source implementations, and have no requirement to enforce
>> or pass down any additional license restrictions.
>>
>> (as Roy notes in a later email these restrictions
>>> do not allow us to license under an OSI compliant license).
>>
>> I don't believe so - he was commenting on the RI not being under an
>> OSI compliant license, and I didn't think that Oracle had any
>> intention of releasing the RI as free or open source software.
>>
>> I'm afraid
>>> that these notices are the proverbial camel's nose under the tent.
>>
>> As I read it, they are emphasizing the existence of the terms in the
>> JSPA that have been there for 5 years.
>>
>> geir
>
> I have no objection to the RI being built by a legacy closed source
> process, it is probably of too low a quality to want to use by virtue of
> that selfsame process :)
I dunno. I really think that the RIs should be open source, but
companies sometimes use product as the RI - the point is really to
demonstrate that the spec is implementable and testable, rather then
being an open resource for reference, which is a shame, IMO.
>
> And I suppose they are granting rights to compliant implementations; it
> is only non-compliant rights that have to worry about possibly
> infringing some software patent that oracle holds. The trouble is: how
> do you define compliance?
Passing the TCK.
This got me thinking - I do wonder what Oracle has here - I guess a
patent. I wonder how much that aspect matters since no one is going to
implement this anyway except Sun and Oracle.
gier
>
> -steve
>
>
>
Re: JSR-198 up for final vote
Posted by Steve Loughran <st...@apache.org>.
Geir Magnusson Jr wrote:
>
>
> Dain Sundstrom wrote:
>> I think we should take a firm stand and vote against against any JSR
>> that includes the downstream licensing restrictions, since it violates
>> the Apache compromise
>
> Oracle is emphasizing the "Apache compromise", actually. We (Apache)
> can do open source implementations, and have no requirement to enforce
> or pass down any additional license restrictions.
>
> (as Roy notes in a later email these restrictions
>> do not allow us to license under an OSI compliant license).
>
> I don't believe so - he was commenting on the RI not being under an OSI
> compliant license, and I didn't think that Oracle had any intention of
> releasing the RI as free or open source software.
>
> I'm afraid
>> that these notices are the proverbial camel's nose under the tent.
>
> As I read it, they are emphasizing the existence of the terms in the
> JSPA that have been there for 5 years.
>
> geir
I have no objection to the RI being built by a legacy closed source
process, it is probably of too low a quality to want to use by virtue of
that selfsame process :)
And I suppose they are granting rights to compliant implementations; it
is only non-compliant rights that have to worry about possibly
infringing some software patent that oracle holds. The trouble is: how
do you define compliance?
-steve
Re: JSR-198 up for final vote
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Alan D. Cabrera wrote:
> On 2/21/2006 8:13 PM, Geir Magnusson Jr wrote:
>
>>
>>
>> Dain Sundstrom wrote:
>>
>>> I think we should take a firm stand and vote against against any JSR
>>> that includes the downstream licensing restrictions, since it
>>> violates the Apache compromise
>>
>>
>> Oracle is emphasizing the "Apache compromise", actually. We (Apache)
>> can do open source implementations, and have no requirement to enforce
>> or pass down any additional license restrictions.
>
>
> What is our mandate in terms of our participation in these JSRs? Do we
> look out for the greater community of which Apache is a part or do we
> only care about the ASF? More specifically, IIUC, the compromise seems
> to only apply to ASF.
No, there's nothing ASF specific in the language. I didn't mean to
imply that above.
We work for open source solutions, not apache ones.
geir
Re: JSR-198 up for final vote
Posted by "Alan D. Cabrera" <ad...@apache.org>.
On 2/21/2006 8:13 PM, Geir Magnusson Jr wrote:
>
>
> Dain Sundstrom wrote:
>
>> I think we should take a firm stand and vote against against any JSR
>> that includes the downstream licensing restrictions, since it
>> violates the Apache compromise
>
>
> Oracle is emphasizing the "Apache compromise", actually. We (Apache)
> can do open source implementations, and have no requirement to enforce
> or pass down any additional license restrictions.
What is our mandate in terms of our participation in these JSRs? Do we
look out for the greater community of which Apache is a part or do we
only care about the ASF? More specifically, IIUC, the compromise seems
to only apply to ASF.
Regards,
Alan
Re: JSR-198 up for final vote
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Dain Sundstrom wrote:
> I think we should take a firm stand and vote against against any JSR
> that includes the downstream licensing restrictions, since it violates
> the Apache compromise
Oracle is emphasizing the "Apache compromise", actually. We (Apache)
can do open source implementations, and have no requirement to enforce
or pass down any additional license restrictions.
(as Roy notes in a later email these restrictions
> do not allow us to license under an OSI compliant license).
I don't believe so - he was commenting on the RI not being under an OSI
compliant license, and I didn't think that Oracle had any intention of
releasing the RI as free or open source software.
I'm afraid
> that these notices are the proverbial camel's nose under the tent.
As I read it, they are emphasizing the existence of the terms in the
JSPA that have been there for 5 years.
geir
>
> -dain
>
> On Feb 20, 2006, at 6:34 PM, Roy T. Fielding wrote:
>
>> On Feb 20, 2006, at 3:09 PM, Geir Magnusson Jr wrote:
>>
>>> http://www.jcp.org/en/jsr/detail?id=198
>>>
>>> Currently, I'm going to vote "yes" unless I hear otherwise. Deadline
>>> is COB tomorrow. I'll get these to the list earlier in the future.
>>>
>>> Personally, I think this is a dumb spec. Eclipse and IDEA aren't
>>> involved (by their own choice). It's not clear to me what problem
>>> this spec solves. However, it's optional, and up to the spec
>>> particpants to try and generate market interest. That said, I can
>>> find no compelling ASF reason to vote against.
>>
>> Well, there is this note in the business terms
>>
>> 6. Although Oracle will place no restrictions on modifications that
>> may be made by or license terms given to "downstream" licensees,
>> it is Oracle's intention to clarify in the licenses, that under the
>> JSPA,
>> no copyright or patent licenses are granted for any non-compliant
>> implementation made by downstream licensees, whether independent or
>> based on the reference implementation.
>>
>> which is a somewhat different attitude than what we took at Day, which
>> is that the RI is licensed under the Apache License and the only
>> restriction is (as mandated by Sun) on redistribution of the
>> specification
>> and its API jar.
>>
>> *shrug*
>>
>> ....Roy
>
>
>
Re: JSR-198 up for final vote
Posted by Brett Porter <br...@apache.org>.
Now that I've seen that, I agree.
However, don't we get an opportunity to voice that concern at the start
under the rules of the JCP 2.6? It's not that important of a JSR to kick
up a fuss about if that was the case and we've "missed the chance". I
don't expect the JCP honours "-0" though :)
In the end, they are probably crippling themselves if they need market
adoption to give it traction.
- Brett
Steve Loughran wrote:
> Dain Sundstrom wrote:
>> I think we should take a firm stand and vote against against any JSR
>> that includes the downstream licensing restrictions, since it
>> violates the Apache compromise (as Roy notes in a later email these
>> restrictions do not allow us to license under an OSI compliant
>> license). I'm afraid that these notices are the proverbial camel's
>> nose under the tent.
>>
>> -dain
>
> Unless anyone has a pressing need for the vote go through, I am in
> agreement here.
>
> This whole thing about "non-compliant" implementation clause is
> bollocks. We already sort of have it with some of the other JCP stuff
> where we can only release stuff with the appropriate title after passing
> the TCK, but there is nothing to stop any cutting their own release as
> long as they don't say "Java EE" or something similar. This
> "non-compliant doesnt get the patent rights" clause prevents any third
> party from making a release.
>
> -Steve
>
Re: JSR-198 up for final vote
Posted by Steve Loughran <st...@apache.org>.
Dain Sundstrom wrote:
> I think we should take a firm stand and vote against against any JSR
> that includes the downstream licensing restrictions, since it violates
> the Apache compromise (as Roy notes in a later email these restrictions
> do not allow us to license under an OSI compliant license). I'm
> afraid that these notices are the proverbial camel's nose under the tent.
>
> -dain
Unless anyone has a pressing need for the vote go through, I am in
agreement here.
This whole thing about "non-compliant" implementation clause is
bollocks. We already sort of have it with some of the other JCP stuff
where we can only release stuff with the appropriate title after passing
the TCK, but there is nothing to stop any cutting their own release as
long as they don't say "Java EE" or something similar. This
"non-compliant doesnt get the patent rights" clause prevents any third
party from making a release.
-Steve
Re: JSR-198 up for final vote
Posted by Dain Sundstrom <da...@iq80.com>.
I think we should take a firm stand and vote against against any JSR
that includes the downstream licensing restrictions, since it
violates the Apache compromise (as Roy notes in a later email these
restrictions do not allow us to license under an OSI compliant
license). I'm afraid that these notices are the proverbial camel's
nose under the tent.
-dain
On Feb 20, 2006, at 6:34 PM, Roy T. Fielding wrote:
> On Feb 20, 2006, at 3:09 PM, Geir Magnusson Jr wrote:
>
>> http://www.jcp.org/en/jsr/detail?id=198
>>
>> Currently, I'm going to vote "yes" unless I hear otherwise.
>> Deadline is COB tomorrow. I'll get these to the list earlier in
>> the future.
>>
>> Personally, I think this is a dumb spec. Eclipse and IDEA aren't
>> involved (by their own choice). It's not clear to me what problem
>> this spec solves. However, it's optional, and up to the spec
>> particpants to try and generate market interest. That said, I
>> can find no compelling ASF reason to vote against.
>
> Well, there is this note in the business terms
>
> 6. Although Oracle will place no restrictions on modifications that
> may be made by or license terms given to "downstream" licensees,
> it is Oracle's intention to clarify in the licenses, that under
> the JSPA,
> no copyright or patent licenses are granted for any non-compliant
> implementation made by downstream licensees, whether independent or
> based on the reference implementation.
>
> which is a somewhat different attitude than what we took at Day, which
> is that the RI is licensed under the Apache License and the only
> restriction is (as mandated by Sun) on redistribution of the
> specification
> and its API jar.
>
> *shrug*
>
> ....Roy
Re: JSR-198 up for final vote
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Yes - but I don't believe they had any intention of making is open source...
Roy T. Fielding wrote:
> On Feb 20, 2006, at 3:44 PM, Geir Magnusson Jr wrote:
>
>> It comes as no surprise to me that Day and Oracle have different views
>> towards this... :)
>
> Yes. Oracle's version means that the RI won't meet the OSI's
> definition of open source.
>
> ....Roy
>
>
Re: JSR-198 up for final vote
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Feb 20, 2006, at 3:44 PM, Geir Magnusson Jr wrote:
> It comes as no surprise to me that Day and Oracle have different
> views towards this... :)
Yes. Oracle's version means that the RI won't meet the OSI's
definition of open source.
....Roy
Re: JSR-198 up for final vote
Posted by Geir Magnusson Jr <ge...@pobox.com>.
It comes as no surprise to me that Day and Oracle have different views
towards this... :)
Roy T. Fielding wrote:
> On Feb 20, 2006, at 3:09 PM, Geir Magnusson Jr wrote:
>
>> http://www.jcp.org/en/jsr/detail?id=198
>>
>> Currently, I'm going to vote "yes" unless I hear otherwise. Deadline
>> is COB tomorrow. I'll get these to the list earlier in the future.
>>
>> Personally, I think this is a dumb spec. Eclipse and IDEA aren't
>> involved (by their own choice). It's not clear to me what problem
>> this spec solves. However, it's optional, and up to the spec
>> particpants to try and generate market interest. That said, I can
>> find no compelling ASF reason to vote against.
>
> Well, there is this note in the business terms
>
> 6. Although Oracle will place no restrictions on modifications that
> may be made by or license terms given to "downstream" licensees,
> it is Oracle's intention to clarify in the licenses, that under the JSPA,
> no copyright or patent licenses are granted for any non-compliant
> implementation made by downstream licensees, whether independent or
> based on the reference implementation.
>
> which is a somewhat different attitude than what we took at Day, which
> is that the RI is licensed under the Apache License and the only
> restriction is (as mandated by Sun) on redistribution of the specification
> and its API jar.
>
> *shrug*
>
> ....Roy
>
>
Re: JSR-198 up for final vote
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Feb 20, 2006, at 3:09 PM, Geir Magnusson Jr wrote:
> http://www.jcp.org/en/jsr/detail?id=198
>
> Currently, I'm going to vote "yes" unless I hear otherwise.
> Deadline is COB tomorrow. I'll get these to the list earlier in
> the future.
>
> Personally, I think this is a dumb spec. Eclipse and IDEA aren't
> involved (by their own choice). It's not clear to me what problem
> this spec solves. However, it's optional, and up to the spec
> particpants to try and generate market interest. That said, I can
> find no compelling ASF reason to vote against.
Well, there is this note in the business terms
6. Although Oracle will place no restrictions on modifications that
may be made by or license terms given to "downstream" licensees,
it is Oracle's intention to clarify in the licenses, that under the
JSPA,
no copyright or patent licenses are granted for any non-compliant
implementation made by downstream licensees, whether independent or
based on the reference implementation.
which is a somewhat different attitude than what we took at Day, which
is that the RI is licensed under the Apache License and the only
restriction is (as mandated by Sun) on redistribution of the
specification
and its API jar.
*shrug*
....Roy
Re: JSR-198 up for final vote
Posted by Henri Yandell <ba...@apache.org>.
On Mon, 20 Feb 2006, Geir Magnusson Jr wrote:
> http://www.jcp.org/en/jsr/detail?id=198
>
> Currently, I'm going to vote "yes" unless I hear otherwise. Deadline is COB
> tomorrow. I'll get these to the list earlier in the future.
>
> Personally, I think this is a dumb spec. Eclipse and IDEA aren't involved
> (by their own choice). It's not clear to me what problem this spec solves.
> However, it's optional, and up to the spec particpants to try and generate
> market interest. That said, I can find no compelling ASF reason to vote
> against.
JetBrains are listed as 'supporting this JSR', and IBM are on the expert
group (so would WSAD be involved?). Seems odd with the Eclipse/IDEA bit
above.
Hen