Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Received-SPF: unknown (asf.osuosl.org: error in processing during lookup of
 jimb@bea.com)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: StAX (JSR 173) API source license
Date: Mon, 24 Apr 2006 11:21:48 -0700
Message-ID: <9186D1D624F88F469BE0CC4F2DDB970B774C82@repbex02.amer.bea.com>
Thread-Topic: StAX (JSR 173) API source license
Thread-Index: AcZny4IXRvwzhQIkTZWL5g4NCEVtJQAAGhLg
From: "Jim Barnett" <jimb@bea.com>
To: "Aleksander Slominski" <aslom@cs.indiana.edu>
Cc: "Carlos Sanchez" <carlos@apache.org>,
   "Michael Glavassevich" <mrglavas@ca.ibm.com>, <legal-discuss@apache.org>,
   <polx@apache.org>

Thanks Alek.

Will do.

Jim

-----Original Message-----
From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]=20
Sent: Monday, April 24, 2006 11:18 AM
To: Jim Barnett
Cc: Carlos Sanchez; Michael Glavassevich; legal-discuss@apache.org;
polx@apache.org
Subject: Re: StAX (JSR 173) API source license

Jim Barnett wrote:
> :)
>
> Whadda mess on our part!
>
> Oh boy...
>
> Okay.  Here's what I *think* will be happening.
>
> 1.  The first bundle available via the link to the BEA ftp download
site
> will be going away.  The licenses in that bundle are just plain wrong
> for a host of reasons.   (- BEA
> http://ftpna2.bea.com/pub/downloads/jsr173.jar (API is jarred inside -
> Hasta la vista, baby.)
>
> 2.  The OFFICIAL JSR 173 API will be hosted for download via the
> official JSR 173 JCP site (mirrored from a BEA server I think), and
will
> be CLEARLY provided under an ASF 2.0 license.
> (http://www.jcp.org/aboutJava/communityprocess/first/jsr173/
>
> 3.  The API used in XML Beans versus the official JSR 173 API is a new
> issue for me and I will look into it as part of this exercise.  I am
> pretty sure, however, that the two are the same and once the licensing
> issue is cleared up on the official JCP site, all should be well.
>
> 4.  Codehaus is able to do what any licensee under the ASF 2.0 license
> is allowed to do - fork the tree.  Through time it is possible (though
> probably not optimal) that the Codehaus API version and the official
API
> version might be different.  My hope is that when we get the wrinkles
> ironed out for the official version, the existence of a Codehaus
> distribution won't be as confusing.
>=20=20=20
hi Jim,

the version of API in codehaus has no modifications and it is *exactly*
what was provided by Ron Benson under ASF2.0 license (that time around
December his email was rbenson at bea.com but I think he no longer works
for BEA)

there is no intention to make any changes or create incompatible
versions of API - StAX API including source code is in codehaus SVN:
http://svn.stax.codehaus.org/trunk/dev/

if there are any differences in JARs it may be only because of ways they
were generated (different JDKs) but content should be the same.
> Would the foregoing action plan be helpful or am I misunderstanding
your
> concern?
>=20=20=20
if there were to be any changes to the API please let us know so we make
sure to sync up the version in codehaus.

thanks,

Alek
> -----Original Message-----
> From: carlossg@gmail.com [mailto:carlossg@gmail.com] On Behalf Of
Carlos
> Sanchez
> Sent: Monday, April 24, 2006 10:37 AM
> To: Jim Barnett
> Cc: Michael Glavassevich; legal-discuss@apache.org; polx@apache.org
> Subject: Re: StAX (JSR 173) API source license
>
> What I mean is that there are three jsr173 API jars, all different
> (binary comparison)
>
> - BEA http://ftpna2.bea.com/pub/downloads/jsr173.jar (API is jarred
> inside)
> - Apache xmlbeans
>
http://www.apache.org/dist/java-repository/xmlbeans/jars/jsr173_1.0_api_
> bundle.jar
> (API is jarred inside)
> - Codehaus Stax http://dist.codehaus.org/stax/jars/stax-api-1.0.jar
>
> For my point of view the only official API is the one from BEA, as
> said in the JSR page.
>
> My questions are:
>
> - can BEA jars uploaded to a public place, allowing redistribution?
> based on the license inside=20
> http://ftpna2.bea.com/pub/downloads/jsr173.jar I'd say no
> - are Apache xmlbeans provided api officially the reference
> implementation? then I can upload it to javax.xml the place for
> referenc implementations
> - if not, is Codehaus provided api officially the reference
> implementation?
>
>
> On 4/24/06, Jim Barnett <jimb@bea.com> wrote:
>=20=20=20
>> Carlos:
>>
>> Thanks for the further information.
>>
>> I haven't looked at the Codehaus files in quite some time but you
>> mentioned that the API 1.0 is different from the other jars.  Do you
>> mean that it is in a different format (i.e., not in source)?
>>
>> I can investigate that if so, but I think the ASF 2.0 license applies
>>=20=20=20=20=20
> to
>=20=20=20
>> the file no matter what format the code is provided under.
>>
>> IANAP (I Am Not A Programmer), but from a legal licensing terms
>> perspective I don't think there should be an issue regarding
confusion
>> over permitted use.  From a developer perspective, there could well
be
>> an ease of use, convenience, practicality or similar issue.
>>
>> I am going to go an take a peek at those files though...
>>
>> Regards,
>>
>> Jim
>>
>> -----Original Message-----
>> From: carlossg@gmail.com [mailto:carlossg@gmail.com] On Behalf Of
>>=20=20=20=20=20
> Carlos
>=20=20=20
>> Sanchez
>> Sent: Monday, April 24, 2006 9:51 AM
>> To: Jim Barnett
>> Cc: Michael Glavassevich; legal-discuss@apache.org; polx@apache.org
>> Subject: Re: StAX (JSR 173) API source license
>>
>> With my "repository" hat on,
>>
>> Currently we have to placeholders in the repository for the API and
>>=20=20=20=20=20
> the
>=20=20=20
>> RI
>>
>> http://www.ibiblio.org/maven2/javax/xml/jsr173/1.0/
>> http://www.ibiblio.org/maven2/com/bea/xml/jsr173-ri/1.0/
>>
>> POMs with information are there, but jars are not because or the
>> license doesn't allow redistribution or it was too long to be read
and
>> IANAL ;).
>>
>> In any case, if we have an APL version of the same API jar, it should
>> be uploaded to the iBiblio central repository and make xmlbeans use
>> it, instead of redistributing from xmlbeans group which looks like it
>> were a xmlbeans customized version. And BTW it's not exactly the same
>> as the one you can download from BEA webpage.
>>
>> Regarding the codehaus implementation available at
>> http://www.ibiblio.org/maven2/stax/ the api 1.0 is also different
from
>> any other of the jars, so more confusion added.
>>
>> Regards
>>
>>
>> On 4/24/06, Jim Barnett <jimb@bea.com> wrote:
>>=20=20=20=20=20
>>> Michael, Paul & Co.:
>>>
>>> To clarify, the RI and some related JSR 173 code is currently
>>>=20=20=20=20=20=20=20
>> available
>>=20=20=20=20=20
>>> (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
>>>=20=20=20=20=20=20=20
> the
>=20=20=20
>>> first jobs on his platter will be to update the JCP JSR 173 web page
>>>=20=20=20=20=20=20=20
>> to
>>=20=20=20=20=20
>>> make the official (unmodified, fully TCK compliant) RI and related
>>>=20=20=20=20=20=20=20
>> files
>>=20=20=20=20=20
>>> 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
>>>=20=20=20=20=20=20=20
>> available
>>=20=20=20=20=20
>>> 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
>>>=20=20=20=20=20=20=20
> open
>=20=20=20
>>> source or proprietary) using a 4-part analysis.  Those 4 parts are
>>>=20=20=20=20=20=20=20
> (1)
>=20=20=20
>>> license compatibility, (2) intellectual property pedigree, (3)
>>> supportability and (4) continued availability.  (3) and (4) are not
>>>=20=20=20=20=20=20=20
> as
>=20=20=20
>>> 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
>>>=20=20=20=20=20=20=20
>> code
>>=20=20=20=20=20
>>> 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
>>>=20=20=20=20=20=20=20
> there
>=20=20=20
>> is
>>=20=20=20=20=20
>>> anything in the third party code candidate that ought not to be
>>>=20=20=20=20=20=20=20
> there.
>=20=20=20
>>> One example of code that fails the "pedigree" test would be code
>>> putatively licensed under a highly compatible license agreement such
>>>=20=20=20=20=20=20=20
>> as
>>=20=20=20=20=20
>>> the ASF 2.0 license, yet which on investigation includes portions
>>> licensed into the licensor-project under incompatible licenses such
>>>=20=20=20=20=20=20=20
> as
>=20=20=20
>>> the GPL, LGPL, etc.  This is a problem because a licensor can grant
>>>=20=20=20=20=20=20=20
> a
>=20=20=20
>>> licensee no greater rights than the licensor had to grant.  In the
>>> simplest case, this means that a licensor who includes code it
>>>=20=20=20=20=20=20=20
>> obtained
>>=20=20=20=20=20
>>> under an LGPL in a project that it licenses to others under an ASF
>>>=20=20=20=20=20=20=20
> 2.0
>=20=20=20
>>> 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
>>>=20=20=20=20=20=20=20
> in
>=20=20=20
>>> breach of the authors' Copyright in those LGPL-covered portions.
>>>
>>> Item (2) is of some concern to open source organizations such as
>>>=20=20=20=20=20=20=20
> ASF,
>=20=20=20
>> as
>>=20=20=20=20=20
>>> they want to be as certain as possible that the outbound licensing
>>>=20=20=20=20=20=20=20
>> under
>>=20=20=20=20=20
>>> ASF 2.0 is valid and that they are respecting the rights of others,
>>>=20=20=20=20=20=20=20
>> but
>>=20=20=20=20=20
>>> it's even more of a concern to proprietary software vendors.  The
>>>=20=20=20=20=20=20=20
>> reason
>>=20=20=20=20=20
>>> is that such proprietary vendors generally take open source software
>>>=20=20=20=20=20=20=20
>> "as
>>=20=20=20=20=20
>>> is" and re-license it providing some level of warranty or indemnity
>>> against infringement.  Unlike outbound licensing in an "as is"
>>>=20=20=20=20=20=20=20
> state,
>=20=20=20
>> by
>>=20=20=20=20=20
>>> offering indemnity and/or warranty on code obtained without
>>>=20=20=20=20=20=20=20
> warranty,
>=20=20=20
>>> the licensor is assuming a contingent financial liability that is
>>>=20=20=20=20=20=20=20
> hard
>=20=20=20
>>> 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
>>>=20=20=20=20=20=20=20
> licensed
>=20=20=20
>>> under the ASF 2.0 license, we favor ASF project code versus non ASF
>>> project code because the ASF contributor license agreement policy
>>>=20=20=20=20=20=20=20
> and
>=20=20=20
>>> process offers one circumstantial proof point that the code will be
>>>=20=20=20=20=20=20=20
> of
>=20=20=20
>>> lower risk of third party IP encumbrances than code developed
>>>=20=20=20=20=20=20=20
> without
>=20=20=20
>>> any form of contributor-level promise or commitment.
>>>
>>> I will be working with the new Spec Lead to get the JCP page for JSR
>>>=20=20=20=20=20=20=20
>> 173
>>=20=20=20=20=20
>>> updated as soon as possible.  Thanks for reminding me that this
>>>=20=20=20=20=20=20=20
> issue
>=20=20=20
>> is
>>=20=20=20=20=20
>>> still unresolved, and sorry for the confusion our delay in cleaning
>>>=20=20=20=20=20=20=20
>> this
>>=20=20=20=20=20
>>> 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:
>>>
>>>=20=20=20=20=20=20=20
>>>> 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
>>>>=20=20=20=20=20=20=20=20=20
> as
>=20=20=20
>>> the
>>>
>>>=20=20=20=20=20=20=20
>>>> early JAXP or Servlet API licenses which may bite you for the need
>>>>=20=20=20=20=20=20=20=20=20
>> to
>>=20=20=20=20=20
>>>> update or... at least at the time it has retained me from
>>>>=20=20=20=20=20=20=20=20=20
> embarking
>=20=20=20
>> on
>>=20=20=20=20=20
>>>> ActiveSoap. Now that StAX is getting more presence, it would be
>>>>=20=20=20=20=20=20=20=20=20
> real
>=20=20=20
>>>> nice to have the StAX API under APL 2!
>>>>=20=20=20=20=20=20=20=20=20
>>> ... and from what I understand BEA has made the StAX API available
>>>=20=20=20=20=20=20=20
>> under
>>=20=20=20=20=20
>>> the APL 2.0. Quoting a post from Radu Preotiuc-Pietro (see here [1]
>>>=20=20=20=20=20=20=20
> in
>=20=20=20
>>> 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
>>>=20=20=20=20=20=20=20
> licensing
>=20=20=20
>>> status of jsr173 APIs. The jar that we have made available at
>>>
>>>=20=20=20=20=20=20=20
>
http://www.apache.org/dist/java-repository/xmlbeans/jars/jsr173_1.0_api_
>=20=20=20
>>> bundle.jar
>>> is totally legit, as provided by BEA, licensed under the Apache
>>>=20=20=20=20=20=20=20
>> License
>>=20=20=20=20=20
>>> 2.0 and with no modifications on our part. It is NOT something that
>>>=20=20=20=20=20=20=20
> we
>=20=20=20
>>> just downloaded, changed a few things and commited.
>>> It's also been oked by Cliff (with his legal affairs hat on), see
>>>=20=20=20=20=20=20=20
> this
>=20=20=20
>>> thread for details:
>>>
>>>=20=20=20=20=20=20=20
>
http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200510.mbox/%3c113
>=20=20=20
>>> 0357486.13564.0.camel@knossos.elmet%3e
>>> ".
>>>
>>>=20=20=20=20=20=20=20
>>>> - I doubt that the fact that it is distributed under APL 2 means
>>>>=20=20=20=20=20=20=20=20=20
> you
>=20=20=20
>>> can
>>>
>>>=20=20=20=20=20=20=20
>>>> check this is an ASF repo... I do not think, unless a donation
>>>>=20=20=20=20=20=20=20=20=20
>>> happened
>>>=20=20=20=20=20=20=20
>>>> like in the case of JAXP I think, we the ASF claim any ownership
>>>>=20=20=20=20=20=20=20=20=20
> and
>=20=20=20
>> I
>>=20=20=20=20=20
>>>> believe folks expect ASF ownership on ASF versionning servers.
>>>>=20=20=20=20=20=20=20=20=20
>>> 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
>>>=20=20=20=20=20=20=20
>> third-party
>>=20=20=20=20=20
>>> work like the SAX and DOM sources which are already part of XML
>>>=20=20=20=20=20=20=20
>> Commons.
>>=20=20=20=20=20
>>> There's a proposed policy on third-party licensing (see here [2])
>>>=20=20=20=20=20=20=20
> that
>=20=20=20
>>> 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
>>>=20=20=20=20=20=20=20
>> source
>>=20=20=20=20=20
>>> (licensed under the APL 2.0) in xml-commons would be okay provided
>>>=20=20=20=20=20=20=20
>> that
>>=20=20=20=20=20
>>> it's in an acceptable form. I'm not assuming that it currently is in
>>>=20=20=20=20=20=20=20
>> an
>>=20=20=20=20=20
>>> acceptable form since the individual source files are missing the
>>>=20=20=20=20=20=20=20
>> Apache
>>=20=20=20=20=20
>>> license header.
>>>
>>>=20=20=20=20=20=20=20
>>>> Why would you want to commit the sources under ASF ?
>>>>=20=20=20=20=20=20=20=20=20
>>> The primary goal of XML Commons External [3] is to provide other
>>>=20=20=20=20=20=20=20
>> Apache
>>=20=20=20=20=20
>>> 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.
>>>
>>>=20=20=20=20=20=20=20
>>>> Note, oh note, that I would looooove for StAX to be either under
>>>>=20=20=20=20=20=20=20=20=20
> APL
>=20=20=20
>>> or
>>>=20=20=20=20=20=20=20
>>>> even donated to ASF. But we need to know this from someone like
>>>>=20=20=20=20=20=20=20=20=20
> Bea
>=20=20=20
>> or
>>=20=20=20=20=20
>>> ??
>>>
>>> An official donation would be cool.
>>>
>>>=20=20=20=20=20=20=20
>>>> paul
>>>>=20=20=20=20=20=20=20=20=20
>>> [1]
>>>
>>>=20=20=20=20=20=20=20
>
http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200603.mbox/%3c994
>=20=20=20
>>> 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
>>>
>>>=20=20=20=20=20=20=20
>>>> Michael Glavassevich wrote:
>>>>=20=20=20=20=20=20=20=20=20
>>>>> XML Commons External [1] maintains Apache-hosted sets of the
>>>>>=20=20=20=20=20=20=20=20=20=20=20
> SAX,
>=20=20=20
>>>> DOM and  JAXP APIs. We're planning to upgrade these sources to
>>>>=20=20=20=20=20=20=20=20=20
> JAXP
>=20=20=20
>>>> 1.4 which now  includes the StAX API.
>>>>=20=20=20=20=20=20=20=20=20
>>>>> 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
>>>>>=20=20=20=20=20=20=20=20=20=20=20
> README
>=20=20=20
>>>>> contained in the jar states that the source and binary files are
>>>>> distributed under the Apache License 2.0 and I've been assured
>>>>>=20=20=20=20=20=20=20=20=20=20=20
> by
>=20=20=20
>>>> one of  the XMLBeans developers [3] that the jar is legitimate and
>>>>=20=20=20=20=20=20=20=20=20
>>> that
>>> it
>>>=20=20=20=20=20=20=20
>>>>> originates from BEA. We would like to commit the StAX sources
>>>>>=20=20=20=20=20=20=20=20=20=20=20
>>>> contained in  this jar to SVN however none of the source files
>>>> contain the Apache
>>>>=20=20=20=20=20=20=20=20=20
>>>>> license header. Can these source files be included in an ASF
>>>>>=20=20=20=20=20=20=20=20=20=20=20
>> project
>>=20=20=20=20=20
>>> in
>>>=20=20=20=20=20=20=20
>>>>> 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.
>>>>>=20=20=20=20=20=20=20=20=20=20=20
>
mbox/%3c99479F4D39C9244F8E17E688193A3DD805D876@repbex02.amer.bea.com%3e
>=20=20=20
>>>>> Michael Glavassevich
>>>>> XML Parser Development
>>>>> IBM Toronto Lab
>>>>> E-mail: mrglavas@ca.ibm.com
>>>>> E-mail: mrglavas@apache.org
>>>>>
>>>>>
>>>>>=20=20=20=20=20=20=20=20=20=20=20
> ---------------------------------------------------------------------
>=20=20=20
>>>>> DISCLAIMER: Discussions on this list are informational and
>>>>>=20=20=20=20=20=20=20=20=20=20=20
>>> educational
>>>=20=20=20=20=20=20=20
>>>>> only.  Statements made on this list are not privileged, do not
>>>>> constitute legal advice, and do not necessarily reflect the
>>>>>=20=20=20=20=20=20=20=20=20=20=20
>> opinions
>>=20=20=20=20=20
>>>>> and policies of the ASF.  See <http://www.apache.org/licenses/>
>>>>>=20=20=20=20=20=20=20=20=20=20=20
>> for
>>=20=20=20=20=20
>>>>> official ASF policies and documents.
>>>>>
>>>>>=20=20=20=20=20=20=20=20=20=20=20
> ---------------------------------------------------------------------
>=20=20=20
>>>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>>>=20=20=20=20=20=20=20=20=20=20=20
>>> Michael Glavassevich
>>> XML Parser Development
>>> IBM Toronto Lab
>>> E-mail: mrglavas@ca.ibm.com
>>> E-mail: mrglavas@apache.org
>>>
>>>
>>>=20=20=20=20=20=20=20
> ---------------------------------------------------------------------
>=20=20=20
>>> DISCLAIMER: Discussions on this list are informational and
>>>=20=20=20=20=20=20=20
> educational
>=20=20=20
>>> 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.
>>>
>>>=20=20=20=20=20=20=20
> ---------------------------------------------------------------------
>=20=20=20
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>>
>>>=20=20=20=20=20=20=20
>
_______________________________________________________________________
>=20=20=20
>>> Notice:  This email message, together with any attachments, may
>>>=20=20=20=20=20=20=20
>> contain
>>=20=20=20=20=20
>>> information  of  BEA Systems,  Inc.,  its subsidiaries  and
>>>=20=20=20=20=20=20=20
>> affiliated
>>=20=20=20=20=20
>>> entities,  that may be confidential,  proprietary,  copyrighted
>>>=20=20=20=20=20=20=20
>> and/or
>>=20=20=20=20=20
>>> legally privileged, and is intended solely for the use of the
>>>=20=20=20=20=20=20=20
>> individual
>>=20=20=20=20=20
>>> or entity named in this message. If you are not the intended
>>>=20=20=20=20=20=20=20
>> recipient,
>>=20=20=20=20=20
>>> and have received this message in error, please immediately return
>>>=20=20=20=20=20=20=20
>> this
>>=20=20=20=20=20
>>> by email and then delete it.
>>>
>>>
>>>=20=20=20=20=20=20=20
> ---------------------------------------------------------------------
>=20=20=20
>>> DISCLAIMER: Discussions on this list are informational and
>>>=20=20=20=20=20=20=20
> educational
>=20=20=20
>>> 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.
>>>
>>>=20=20=20=20=20=20=20
> ---------------------------------------------------------------------
>=20=20=20
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>>
>>>=20=20=20=20=20=20=20
>> --
>> I could give you my word as a Spaniard.
>> No good. I've known too many Spaniards.
>>                              -- The Princess Bride
>>
>>=20=20=20=20=20
>
_______________________________________________________________________
>=20=20=20
>> Notice:  This email message, together with any attachments, may
>>=20=20=20=20=20
> contain
>=20=20=20
>> information  of  BEA Systems,  Inc.,  its subsidiaries  and
>>=20=20=20=20=20
> affiliated
>=20=20=20
>> entities,  that may be confidential,  proprietary,  copyrighted
>>=20=20=20=20=20
> and/or
>=20=20=20
>> legally privileged, and is intended solely for the use of the
>>=20=20=20=20=20
> individual
>=20=20=20
>> or entity named in this message. If you are not the intended
>>=20=20=20=20=20
> recipient,
>=20=20=20
>> and have received this message in error, please immediately return
>>=20=20=20=20=20
> this
>=20=20=20
>> by email and then delete it.
>>
>>=20=20=20=20=20
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                              -- The Princess Bride
>
_______________________________________________________________________
> 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
>
>
>=20=20=20


--=20
The best way to predict the future is to invent it - Alan Kay


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

_______________________________________________________________________
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