www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Thompson <jt...@us.ibm.com>
Subject RE: JCP spec licensing (was RE: StAX (JSR 173) API source license)
Date Thu, 27 Apr 2006 20:01:30 GMT
"Jim Barnett" <jimb@bea.com> wrote on 04/27/2006 12:21:07 PM:

> What mystifies me is the following. 
> I understand that in forming the Java Community long ago, Sun made a
> business decision to prioritize compliance with the standards 
> through mandatory compatibility testing.  Not every standards 
> promulgating body relies on mandatory testing to ensure 
> compatibility, but many do.  Whether you agree or disagree with the 
> business logic or practicality of that decision, isn't there a huge 
> hole in the Java licensing scheme that undermines the extra 
> protection on compatibility sought via the mandatory testing 

I don't think so.  What is most important, not only to developers but to 
customers, is clarity and accuracy in representations regarding 
compatibility.  If an implementation represents itself as compatible, it 
better actually be compatible.  Running the TCK and applying the Java logo 
is the right way to do that, and that is one thing that the JCP has right. 
 You can't use the logo and go around claiming compatibility if you aren't 
able to pass the test suites.

The question is to what the "mandatory compatibility testing" should 
apply.  Clearly anything using the logo and claiming compliance.  However, 
if someone takes an Apache licensed RI and goes left while the JCP goes 
right, as long as s/he doesn't use the logo, claim compliance, or 
otherwise mislead customers as to whether the code is compatible, I don't 
see the conflict with the JCP. 

> Look at the API example.  The API itself is considered to be part of
> the specification under the JSPA, and is subject to the 
> compatibility "preservation" requirements.  Implementations of the 
> specification, however, are licensable under downstream license 
> forms (ASF, GPL, whatever) that allow derivation, modification and 
> alteration of the implementation, and do not require compatibility 
> testing of the modified implementation.  In other words, where a 
> party implements an API, and dutifully passes the compatibility 
> tests for that implementation, the testing buck stops there.  Anyone
> licensing that specification from the implementer under a license 
> such as the ASF 2.0 license may break compatibility without 
> breaching the license they accepted, and without causing their 
> licensor (who dutifully passed the tests) to be in breach of its JSPA.
> If ten different licensees took the JSR 173 api implementation jar 
> file under the ASF 2.0 license agreement, and made modifications 
> forking the implementation code into 10 different modified 
> implementations that would not pass the TCK, the JSPA framework and 
> mandatory testing at the Spec level looks to be fairly ineffective 
> at contractually ensuring compatibility.

Only if you assume that all derivative works of all compatible 
implementations must remain compatible.  I don't see why that's necessary, 
or even desirable, especially in an open source context. 

> Assuming the above analysis is contractually valid under the JSPA, 
> couldn't ASF avoid the undesired mandatory testing by electing to 
> start with an implementation developed by another Java licensee and 
> offered under an Apache-compatible license rather than the Java 
> specification itself, and simply modify the heck out of the 
> implementation to suit its project purposes without regard to the 
> compatibility of the resulting modifications?  Isn't this a loophole
> that swallows the benefit of inflexible testing requirements 
> collaring the specification license?

Well, I'm not going to assume Apache's motives, however, I believe that 
Apache actually wants their code to be compatible.  They see the value in 
supporting an agreed, interoperable standard and are willing to 
participate as long as it doesn't prevent them from being the organization 
that they want to be.  I happen to like that.  Standards should be adopted 
because they are better -- technically superior, more interoperable, etc. 
-- not because you are contractually forced to do so.

> I am curious as to what the developers and the other lawyers think about 

Just my 2 cents.

> Regards,
> Jim

Staff Counsel, IBM Corporation  (914)766-1757  (tie)8-826  (fax) -8160
(notes) jthom@ibmus  (internet) jthom@us.ibm.com (home) jeff@beff.net
(web) http://www.beff.net/ 

View raw message