www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Barnett" <j...@bea.com>
Subject RE: JCP spec licensing (was RE: StAX (JSR 173) API source license)
Date Thu, 27 Apr 2006 20:57:02 GMT
Thanks Jeff.

To be clear, I wasn't advocating for or against Sun's interpretation of the JSPA on the issue
of Spec License requirements.  Rather I was questioning whether the interpretation Sun offers
on that point (when taken as being correct for sake of argument only) is logically effective
at preserving compatibility given that there is no requirement for downstream licensees to
maintain compatibility when they modify otherwise compatible implementations.

While there are plenty of reasons why downstream licensees would choose maintain compatibility
of implementations, my point was that nothing in the JSPA requires that downstream licensees
be compelled contractually to maintain compatibility of implementations, even when they make
changes to and further distribute the modified implementations.        

It seems like there's an incongruity between the position that implementers should be contractually
required to pass the TCK in order to distribute their implementations, and the position that
it is acceptable for any party licensing those implementations to freely modify so as to make
them incompatible and further distribute the modified implementations.  If you allow the latter,
why be so insistent on the former?  It smacks of dogmatism rather than reason.

Against this backdrop, conditioning use of the Java compatibility logo on passage of the TCK
makes much more sense than gating distribution of independent implementations on passage of
the TCK.  



-----Original Message-----
From: Jeffrey Thompson [mailto:jthom@us.ibm.com] 
Sent: Thursday, April 27, 2006 1:02 PM
To: Jim Barnett
Cc: Legal Discuss
Subject: RE: JCP spec licensing (was RE: StAX (JSR 173) API source license)

"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 requirements?

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

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

> 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 this.

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/ 

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.5.0/325 - Release Date: 4/26/2006

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.5.0/325 - Release Date: 4/26/2006
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message