www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: JSR-198 up for final vote
Date Mon, 27 Feb 2006 10:48:08 GMT
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



Mime
View raw message