You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Michael Glavassevich <mr...@ca.ibm.com> on 2006/05/01 07:03:34 UTC

RE: StAX (JSR 173) API source license

Hello Jim,

"Jim Barnett" <ji...@bea.com> wrote on 04/24/2006 12:30:09 PM:

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

The Xerces developers are starting to work on an implementation of JSR 173 
and will eventually be wanting to verify its compliance with the TCK. Will 
this update also include posting of the TCK or new instructions on how one 
obtains it? The current JCP page says to send an e-mail to the old spec 
lead. I'm guessing that isn't right anymore.

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

<snip/>

> 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 understand. I'm hoping as an alternative we could do what the Geronimo 
folks have done [1] for other JSRs by developing an ASF authored version 
of the StAX API spec classes/interfaces.

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

Thanks.

[1] 
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200502.mbox/%3c42137ADD.2050606@apache.org%3e

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

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