www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <p...@apache.org>
Subject Re: StAX (JSR 173) API source license
Date Mon, 24 Apr 2006 20:27:26 GMT
Do I mistake or what you are describing is the license of the reference 
implementation and not the license of the API which is the subject of 
this thread ?

I think an RI may or may not be under APL.... it's less important... but 
an API to be under a difficult license makes every consumer of this API 
(that includes both users of implementations and implementors) under 

I hope I do mistake.


Jim Barnett wrote:
> Michael, Paul & Co.:
> To clarify, the RI and some related JSR 173 code is currently available
> (probably in modified form due to accreted community contributions
> post-upload) via Codehaus.  
> http://stax.codehaus.org/
> Recently BEA put a new Spec Lead in place for JSR 173, and one of the
> first jobs on his platter will be to update the JCP JSR 173 web page to
> make the official (unmodified, fully TCK compliant) RI and related files
> available under the ASF 2.0 license agreement on the JCP site.
> Currently the JCP page for JSR 173 is out of date.
> On the Apache usability front, importation of third party code available
> under an ASF 2.0 license would be highly compatible from a licensing
> requirements perspective (i.e., the ASF 2.0 license allows almost
> transparent re-licensing by another party under almost any terms,
> including ASF 2.0).  What you don't get when ASF imports third party
> code under a compatible license agreement is the reassurance of the
> representations and warranties you get under the contributor license
> agreements.  
> At BEA we assess inbound third party licensing problems (whether open
> source or proprietary) using a 4-part analysis.  Those 4 parts are (1)
> license compatibility, (2) intellectual property pedigree, (3)
> supportability and (4) continued availability.  (3) and (4) are not as
> relevant when looking at open source code candidates because we have
> source and can both self-educate on the product support front and
> maintain our own code tree to ensure long term availability of the code
> for our use.  (1) and (2), however, are critical in assessing open
> source candidates.  (1) relates to ensuring that the applicable open
> source license agreement permits use of the code by the licensee
> (whether it be BEA, IBM or ASF) under the licensee's desired license
> agreement(s).  
> Item (2) relates to making an educated assessment as to whether there is
> anything in the third party code candidate that ought not to be there.
> One example of code that fails the "pedigree" test would be code
> putatively licensed under a highly compatible license agreement such as
> the ASF 2.0 license, yet which on investigation includes portions
> licensed into the licensor-project under incompatible licenses such as
> the GPL, LGPL, etc.  This is a problem because a licensor can grant a
> licensee no greater rights than the licensor had to grant.  In the
> simplest case, this means that a licensor who includes code it obtained
> under an LGPL in a project that it licenses to others under an ASF 2.0
> license, *most likely* (lawyer hedge; if you buy my analysis of the
> incompatibility of ASF 2.0 and LGPL on an earlier thread) is
> distributing the LGPL-encumbered parts in violation of the LGPL and in
> breach of the authors' Copyright in those LGPL-covered portions.
> Item (2) is of some concern to open source organizations such as ASF, as
> they want to be as certain as possible that the outbound licensing under
> ASF 2.0 is valid and that they are respecting the rights of others, but
> it's even more of a concern to proprietary software vendors.  The reason
> is that such proprietary vendors generally take open source software "as
> is" and re-license it providing some level of warranty or indemnity
> against infringement.  Unlike outbound licensing in an "as is" state, by
> offering indemnity and/or warranty on code obtained without warranty,
> the licensor is assuming a contingent financial liability that is hard
> to measure but could be substantial in amount in an extreme case.
> That's a long winded way of saying that when we look at code licensed
> under the ASF 2.0 license, we favor ASF project code versus non ASF
> project code because the ASF contributor license agreement policy and
> process offers one circumstantial proof point that the code will be of
> lower risk of third party IP encumbrances than code developed without
> any form of contributor-level promise or commitment.  
> I will be working with the new Spec Lead to get the JCP page for JSR 173
> updated as soon as possible.  Thanks for reminding me that this issue is
> still unresolved, and sorry for the confusion our delay in cleaning this
> up may have caused.
> Regards,
> Jim Barnett
> Associate General Counsel
> BEA Systems, Inc. 
> -----Original Message-----
> From: Michael Glavassevich [mailto:mrglavas@ca.ibm.com] 
> Sent: Sunday, April 23, 2006 2:00 PM
> To: legal-discuss@apache.org
> Cc: polx@apache.org
> Subject: Re: StAX (JSR 173) API source license
> Paul Libbrecht <polx@apache.org> wrote on 04/23/2006 08:56:16 AM:
>> Two little opinions:
>> - last I checked the StAX API was under one of these extra weird 
>> licenses that big companies a specially able to realize, one such as
> the 
>> early JAXP or Servlet API licenses which may bite you for the need to 
>> update or... at least at the time it has retained me from embarking on
>> ActiveSoap. Now that StAX is getting more presence, it would be real 
>> nice to have the StAX API under APL 2!
> ... and from what I understand BEA has made the StAX API available under
> the APL 2.0. Quoting a post from Radu Preotiuc-Pietro (see here [1] in
> the 
> archives) on the xmlbeans-dev list:
> "The XmlBeans team (esp Lawrence, with his Apache hat on ;-) ) have
> worked 
> with BEA (represented by the BEA legal team) to clarify the licensing 
> status of jsr173 APIs. The jar that we have made available at 
> http://www.apache.org/dist/java-repository/xmlbeans/jars/jsr173_1.0_api_
> bundle.jar 
> is totally legit, as provided by BEA, licensed under the Apache License 
> 2.0 and with no modifications on our part. It is NOT something that we 
> just downloaded, changed a few things and commited.
> It's also been oked by Cliff (with his legal affairs hat on), see this 
> thread for details: 
> http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200510.mbox/%3c113
> 0357486.13564.0.camel@knossos.elmet%3e
> ".
>> - I doubt that the fact that it is distributed under APL 2 means you
> can 
>> check this is an ASF repo... I do not think, unless a donation
> happened 
>> like in the case of JAXP I think, we the ASF claim any ownership and I
>> believe folks expect ASF ownership on ASF versionning servers.
> I wasn't implying that the ASF owns code distributed by some other 
> organization under the APL 2.0. StAX would be included as a third-party 
> work like the SAX and DOM sources which are already part of XML Commons.
> There's a proposed policy on third-party licensing (see here [2]) that 
> states that third-party source licensed under the ASL 2.0 may be
> included 
> within Apache products. It would seem that including the StAX API source
> (licensed under the APL 2.0) in xml-commons would be okay provided that 
> it's in an acceptable form. I'm not assuming that it currently is in an 
> acceptable form since the individual source files are missing the Apache
> license header.
>> Why would you want to commit the sources under ASF ?
> The primary goal of XML Commons External [3] is to provide other Apache 
> projects (Xerces, Xalan, FOP, Batik, etc...) with stable versions of 
> XML-related externally-defined standards-based code. This includes 
> controlled bug fixes and performance improvements.
>> Note, oh note, that I would looooove for StAX to be either under APL
> or 
>> even donated to ASF. But we need to know this from someone like Bea or
> ??
> An official donation would be cool.
>> paul
> [1] 
> http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200603.mbox/%3c994
> 79F4D39C9244F8E17E688193A3DD805D876@repbex02.amer.bea.com%3e
> [2] http://people.apache.org/~cliffs/3party.html#category-a
> [3] http://xml.apache.org/commons/components/external/index.html
>> Michael Glavassevich wrote:
>>> XML Commons External [1] maintains Apache-hosted sets of the SAX, 
>> DOM and  JAXP APIs. We're planning to upgrade these sources to JAXP 
>> 1.4 which now  includes the StAX API.
>>> A copy of the StAX API source/binary is being distributed in the 
>>> xmlbeans/jars directory of the java-repository [2] (see 
>>> jsr173_1.0_api_bundle.jar) and on Apache mirror sites. The README 
>>> contained in the jar states that the source and binary files are 
>>> distributed under the Apache License 2.0 and I've been assured by 
>> one of  the XMLBeans developers [3] that the jar is legitimate and
> that 
> it 
>>> originates from BEA. We would like to commit the StAX sources 
>> contained in  this jar to SVN however none of the source files 
>> contain the Apache 
>>> license header. Can these source files be included in an ASF project
> in 
>>> their current form?
>>> Thanks.
>>> [1] http://xml.apache.org/commons/components/external/index.html
>>> [2] http://www.apache.org/dist/java-repository/xmlbeans/jars/
>>> [3] 
>>> http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200603.
> mbox/%3c99479F4D39C9244F8E17E688193A3DD805D876@repbex02.amer.bea.com%3e

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