www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: [VOTE] New ASF/JCP Policies
Date Sun, 15 Jul 2007 14:01:40 GMT

--- Matt Hogstrom <matt@hogstrom.org> wrote:

> 
> On Jul 13, 2007, at 4:19 PM, Dain Sundstrom wrote:
> 
> > Given the above, Apache could choose to stop
> running any TCKs and  
> > continue to develop and ship implementations of
> JSRs.
> >
> > A long time ago, when I was involved in TCK
> negotiations with Sun,  
> > I remember that their biggest fear was the idea of
> fracture in  
> > Java, and they believed that the TCKs guaranteed
> that the fracture  
> > would not happen.  If Sun has the same fear,
> Apache could choose to  
> > stop using TCKs and let people know that our
> implementations may  
> > not be compliant anymore.  Users that are upset
> can pressure Sun to  
> > change.
> 
> Not being the lawerly one perhaps I'm not
> understanding how one can  
> ship software that implements a specification (and
> doesn't pass a  
> TCK) based on this license from the Java EE 5.0
> Specification (page  
> iii).
> 
> LIMITED LICENSE GRANTS
> 1. License for Evaluation Purposes. Sun hereby
> grants you a fully- 
> paid, non-exclusive, non-transferable,
> worldwide, limited license (without the right to
> sublicense), under  
> Sun’s applicable intellectual property
> rights to view, download, use and reproduce the
> Specification only  
> for the purpose of internal evaluation.
> This includes (i) developing applications intended
> to run on an  
> implementation of the Specification, provided
> that such applications do not themselves implement
> any portion(s) of  
> the Specification, and (ii) discussing
> the Specification with any third party; and (iii)
> excerpting brief  
> portions of the Specification in oral or written
> communications which discuss the Specification
> provided that such  
> excerpts do not in the aggregate consti-
> tute a significant portion of the Specification.
> 
> Apologies to those with text e-mail...I hilighted
> the sentence above  
> where a license is granted for the specification
> 
> "to view, download, use and reproduce the
> Specification only for the  
> purpose of internal evaluation. This includes (i)
> developing  
> applications intended to run on an implementation of
> the  
> Specification, provided that such applications do
> not themselves  
> implement any portion(s) of the Specification, "
> 
> It sounds to me like one cannot do a whole lot
> (including  
> implementing the spec) expect for internal purposes
> let alone  
> redistributing an implementation.
> 
> 2. License for the Distribution of Compliant
> Implementations. Sun  
> also grants you a perpetual, non-exclu-
> sive, non-transferable, worldwide, fully paid-up,
> royalty free,  
> limited license (without the right to sublicense)
> under any applicable copyrights or, subject to the
> provisions of  
> subsection 4 below, patent rights it may have
> covering the Specification to create and/or
> distribute an Independent  
> Implementation of the Specification
> that: (a) fully implements the Specification
> including all its  
> required interfaces and functionality; (b) does not
> modify, subset, superset or otherwise extend the
> Licensor Name Space,  
> or include any public or protected
> packages, classes, Java interfaces, fields or
> methods within the  
> Licensor Name Space other than those
> required/authorized by the Specification or
> Specifications being  
> implemented; and (c) passes the
> Technology Compatibility Kit (including satisfying
> the requirements  
> of the applicable TCK Users Guide) for
> such Specification ("Compliant Implementation").
> 
> Sounds to me like, based on the above, you can't
> distribute an  
> implementation without passing the TCK.  I've seen
> several folks  
> comment on not certifying but I guess how does one
> implement a non- 
> certified implementation of a specification that
> they never read?
> 
> I must be missing some lawerly element that gets
> around the above.

I have read this too, but in the JSR 176 specification
license, it states:
"You need not include limitations (i)-(iii) from the 
previous paragraph or any other particular "pass 
through" requirements in any license You grant 
concerning the use of your Independent Implementation 
or products derived from it. However, except with 
respect to implementations of the Specification (and 
products derived from them) that satisfy limitations 
(i)-(iii) from the previous paragraph, You may 
neither: (a) grant or otherwise pass through to your 
licensees any licenses under Sun's applicable 
intellectual property rights; nor (b) authorize your 
licensees to make any claims concerning their 
implementation's compliance with the Spec in
question."

So, I guess the question is what is "products
derived"'s meaning. I think then that having one
version of harmony using a TCK with the limitations or
FOU can have another (non-Java) version which is
licensed differently which is derived from the TCK
version. So you have:

Apache Harmony Java Runtime

and

Apache Harmony Runtime

It seems to be the "Apache Harmony Runtime" can be
advertised as being 100% compatible with the Apache
Harmony Java Runtime. I don't see anything which says
this can't happen. Anyways, Apache could come up with
one special license for this case while working
through the JCP to fix future licensing issues in JSR
306. It certainly seems doable. Sure, it isn't the
best solution as that would be the license the way it
needs to be and now, but hey...make the best of what
you have and hopefully 306 will change the future and
Harmony 1.7 or what ever won't need to do such things.
I'm not sure about other specifications than 176. Does
the quoted license above have the same clause as 176?

Wade

Mime
View raw message