You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Matt Benson <gu...@yahoo.com> on 2008/01/04 18:40:06 UTC
JAXP license
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?). 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?
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? Is it possible to distribute a
library as "non-certified", "non-compliant", or
similar? 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. 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
Re: JAXP license
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Matt,
Matt Benson <gu...@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