xerces-j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Glavassevich <mrgla...@ca.ibm.com>
Subject Re: JAXP license
Date Wed, 09 Jan 2008 20:58:25 GMT
Hi Matt,

Matt Benson <gudnabrsam@yahoo.com> wrote on 01/04/2008 12:40:06 PM:

> Hi Xerces guys-
>   I have attempted to do some homework by searching
> the archives, asking around, etc. and what I seem to
> find is that the licensing approach used by Xerces-J
> is to depend on the APIs published by XML Commons
> (which it appears was voted in 2006 to move to
> Xerces?).

That's right. XML Commons is now a subproject of the Xerces TLP. Releases
of Xerces-J bundle the XML APIs and resolver components from XML Commons.

> These APIs are of course ASL licensed.  I
> am trying to run down precisely what requirements must
> be met to implement parts of these APIs in an Apache
> project, specifically the JXPath subproject of the
> Apache (formerly Jakarta) Commons.  Is there any
> difference between the source and/or binary
> representation of the JAXP APIs as published by XML
> Commons vs. the underlying ideas expressed
> therein?--as best I understand it there is no
> hindrance to implementing these APIs despite the fact
> that they were originally developed at Sun.  Is this
> simply by virtue of Sun's having donated the sources
> of the APIs to Apache XML, or does any further
> documentation exist that expressly states that the
> APIs can be freely implemented?

There are terms and conditions in the spec which allow for independent
implementations. I think the main difference between a donation from Sun
and authoring the API classes within the ASF is that we get Sun's javadoc
vs. having to write original javadoc ourselves.

> Next, I have found statements to the effect that it a
> component must pass the JAXP TCK in order to claim to
> be "an implementation."  Is this indeed the case?  I
> have it on authority that there is no such thing as
> partial TCK certification; does this group concur that
> a "partial implementation" (e.g. of XPath only) will
> never pass the TCK?

I'd agree with that. Passing a TCK implies a full implementation (or at
least enough of an implementation to pass all the tests).

> Is it possible to distribute a
> library as "non-certified", "non-compliant", or
> similar?

If you're looking for a legal opinion legal-discuss@apache.org [1] is
probably a better place to ask. I'm not a lawyer. Don't want to mislead you
with my perception of how things are or how they ought to be. I don't have
a clear understanding myself.

> I'd also appreciate information on getting
> access to the ASF's JAXP TCK so that, even if Commons
> JXPath can never be certified and thus officially
> compliant, the portions it does implement can be
> verified to be as good as possible.

I believe you need to ask for that on the jcp-open mailing list. There are
instructions on this page [2] which describe how one goes about requesting
it and any other TCK.

> Another
> possibility might be for a "full" JAXP implementation
> to fall back to e.g. Xerces for other than XPath
> functionality.  I think this ought to be considered
> compliant.
> Thanks,
> Matt

> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search.  http://tools.search.yahoo.
> com/newsearch/category.php?category=shopping
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org

[1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/
[2] http://www.apache.org/jcp/

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

To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

View raw message