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 16:21:07 GMT
I know Jonathan very well and respect him greatly.  I don't think Sun's licensing scheme is
invalid or bad, but rather not necessarily compatible with the direction collaborative software
development has taken via the open source movement.  I see it as a philosophical difference
between the ethos of the OSS movement and the ethos of the Java community.  The JCP prioritizes
standardization and compatibility above all.  The OSS movement prioritizes developer freedom
and openness above all.  That's not to say that the JCP isn't more open or free than a true
proprietary licensing model.  Likewise that's not to say that the OSS movement doesn't value
standardization and compatibility where relevant.     

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?

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.

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?

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

Regards,

Jim

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: Thursday, April 27, 2006 6:26 AM
To: Dittert, Eric
Cc: Jim Barnett; Legal Discuss
Subject: Re: JCP spec licensing (was RE: StAX (JSR 173) API source license)

On Apr 26, 2006, at 3:40 PM, Dittert, Eric wrote:

> The licensing of a JCP specification does have conditions placed on it
> by the JSPA (http://www.jcp.org/aboutJava/communityprocess/JSPA2.pdf).
> IANAL, but it appears to me that AL2 does not meet those  
> conditions.  It
> is probably not fair to blame Jonathan for insisting that those
> conditions be adhered to.

On the contrary, it was Jonathan that wrote those restrictions.
Jonathan was also present during the Sun & Apache negotiations
over the conditions under which Apache would be willing to participate
in the JCP, and he knows quite well that they block the API
from being released as open source.  The whole dance is due to
Jonathan's scheme of using click-through licensing of specifications
to create an agreement that goes beyond copyright law to enforce
compatibility constraints, as opposed to simply using trademark law
to protect the namespace, and thus he is entirely to blame for Sun's
continued obstruction of open source JSRs.

> That said, I would be interested to know if one of the following  
> were to
> occur:
> - A JCP spec lead proposes to use a specification license which (at
> least arguably) does meet the conditions of the JSPA, but still
> encounters obstacles.
> - A particular desirable use of a particular JCP spec is blocked  
> because
> of the JSPA conditions.  I know there are a number of philosophical
> objections to various pieces of the JSPA; what I am looking for  
> here is
> concrete, practical examples.

I already tried that.

    http://www.apache.org/licenses/proposed/JSR-LICENSE-2.0.txt

Sun rejected it.  They refused to consider anything other than a
click-through license agreement within the scope of a template
provided by Sun legal.  OTOH, they do allow the RI and TCK to
be distributed under the Apache License 2.0 with no other
restrictions (e.g., JSR 170 RI and TCK is in Apache Jackrabbit).

The minimum specification license is what JSR 170 uses right now
(included below).  The only restrictions in it are those
required by the JSPA, but those restrictions are sufficient to
prevent it from being open source.  Note that the RI is only the
implementation -- the API is a separate jar file that the spec
lead is forbidden from supplying to anyone without the click-through
license.  Thus, the RI is dependent on a separate binary interface
file that is assumed to be part of the "java system".

It is possible to use a tool to generate an API jar file from the
RI such that the new file is only covered by the RI's license,
but that would have to be done by some entity other than the spec
lead, and it could be prevented by Sun on trademark grounds.

> Finally, just a note that the JCP Executive Committees *are* elected
> (well, mostly) and I know most of the representatives feel that they
> represent the community as well as their particular organizations.  So
> if licensing or other issues working with the JCP arise, I am  
> certainly
> willing to hear about them and do what I can, as I am sure Geir is,  
> and,
> as I said, most of the other EC reps (who are all listed at
> http://www.jcp.org/en/participation/committee).

Sun legal currently has complete authority to prevent publication
on jcp.org of any specification that doesn't meet Sun legal's
requirements (which are determined by Sun at their own discretion).
As such, the EC is entirely irrelevant to the actual policy and
procedures imposed on spec leads.  I suggest that the EC might want
to address that issue in a revision of the JSPA, since the actual
publication process occurs behind the scenes and allows Sun to
control the content of a JSR *before* it is presented to the EC
for a final ballot.

....Roy

========= JSR 170 spec license =========

Day Management AG ("Licensor") is willing to license this  
specification to
you ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS  
CONTAINED IN
THIS LICENSE AGREEMENT ("Agreement"). Please read the terms and  
conditions
of this Agreement carefully.

Content Repository for JavaTM Technology API Specification
("Specification")
Version: 1.0
Status: FCS
Release: 11 May 2005

Copyright 2005 Day Management AG
Barf├╝sserplatz 6, 4001 Basel, Switzerland.
All rights reserved.

NOTICE; LIMITED LICENSE GRANTS

1. License for Purposes of Evaluation and Developing Applications.
Licensor hereby grants you a fully-paid, non-exclusive, non- 
transferable,
worldwide, limited license (without the right to sublicense), under
Licensor's applicable intellectual property rights to view, download,  
use
and reproduce the Specification only for the purpose of internal
evaluation. This includes 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.

2. License for the Distribution of Compliant Implementations. Licensor
also grants you a perpetual, non-exclusive, 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"). In addition, the foregoing
license is expressly conditioned on your not acting outside its  
scope. No
license is granted hereunder for any other purpose (including, for
example, modifying the Specification, other than to the extent of your
fair use rights, or distributing the Specification to third parties).

3. Pass-through Conditions. You need not include limitations (a)-(c)  
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 Independent Implementations (and products derived from them) that
satisfy limitations (a)-(c) from the previous paragraph, You may  
neither:
(a) grant or otherwise pass through to your licensees any licenses under
Licensor's applicable intellectual property rights; nor (b) authorize  
your
licensees to make any claims concerning their implementation's  
compliance
with the Specification.

4. Reciprocity Concerning Patent Licenses. With respect to any patent
claims covered by the license granted under subparagraph 2 above that
would be infringed by all technically feasible implementations of the
Specification, such license is conditioned upon your offering on fair,
reasonable and non-discriminatory terms, to any party seeking it from  
You,
a perpetual, non-exclusive, non-transferable, worldwide license under  
Your
patent rights that are or would be infringed by all technically feasible
implementations of the Specification to develop, distribute and use a
Compliant Implementation.

5. Definitions. For the purposes of this Agreement: "Independent
Implementation" shall mean an implementation of the Specification that
neither derives from any of Licensor's source code or binary code
materials nor, except with an appropriate and separate license from
Licensor, includes any of Licensor's source code or binary code  
materials;
"Licensor Name Space" shall mean the public class or interface
declarations whose names begin with "java", "javax", "javax.jcr" or  
their
equivalents in any subsequent naming convention adopted by Licensor
through the Java Community Process, or any recognized successors or
replacements thereof; and "Technology Compatibility Kit" or "TCK" shall
mean the test suite and accompanying TCK User's Guide provided by  
Licensor
which corresponds to the particular version of the Specification being
tested.

6. Termination. This Agreement will terminate immediately without notice
from Licensor if you fail to comply with any material provision of or  
act
outside the scope of the licenses granted above.

7. Trademarks. No right, title, or interest in or to any trademarks,
service marks, or trade names of Licensor is granted hereunder. Java  
is a
registered trademark of Sun Microsystems, Inc. in the United States and
other countries.

8. Disclaimer of Warranties. The Specification is provided "AS IS".
LICENSOR MAKES NO REPRESENTATIONS OR WARRANTIES, EITHER EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT (INCLUDING AS A
CONSEQUENCE OF ANY PRACTICE OR IMPLEMENTATION OF THE SPECIFICATION), OR
THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE.  
This
document does not represent any commitment to release or implement any
portion of the Specification in any product.

The Specification could include technical inaccuracies or typographical
errors. Changes are periodically added to the information therein; these
changes will be incorporated into new versions of the Specification, if
any. Licensor may make improvements and/or changes to the product(s)
and/or the program(s) described in the Specification at any time. Any  
use
of such changes in the Specification will be governed by the then- 
current
license for the applicable version of the Specification.

9. Limitation of Liability. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO
EVENT WILL LICENSOR BE LIABLE FOR ANY DAMAGES, INCLUDING WITHOUT
LIMITATION, LOST REVENUE, PROFITS OR DATA, OR FOR SPECIAL, INDIRECT,
CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND
REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO ANY
FURNISHING, PRACTICING, MODIFYING OR ANY USE OF THE SPECIFICATION, EVEN
IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

10. Report. If you provide Licensor with any comments or suggestions in
connection with your use of the Specification ("Feedback"), you hereby:
(i) agree that such Feedback is provided on a non-proprietary and
non-confidential basis, and (ii) grant Licensor a perpetual,
non-exclusive, worldwide, fully paid-up, irrevocable license, with the
right to sublicense through multiple levels of sublicensees, to
incorporate, disclose, and use without limitation the Feedback for any
purpose related to the Specification and future versions,  
implementations,
and test suites thereof.


-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.6/324 - Release Date: 4/25/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


Mime
View raw message