www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Building ASL code requiring LGPL 3rd party
Date Thu, 31 Mar 2011 13:55:36 GMT

CXF has many examples of the use of explicit java reflection to
exploit optional dependencies. At least one of them has, as I will
explain,  a slightly cloudy license status. Just grepping for
'loadClass' finds dozens of calls. I don't think that any are
'category-X' components. In fact, I just grepped, and I'm certain that
none of them are. In other words, we use the same technology to give
our users more flexibility and reduce the footprint, even when there's
no licensing issue.

CXF's compass is always http://www.apache.org/legal/3party.html.

The 'cloudy' case is 'msv', the multi-schema validator. We wanted to
support XML Schema validation over Stax. This was possible by using
Woodstox (AL) + MSV (BSD). However, MSV in turn has a dependency on a
library of schema-related (relaxngDatatype) code that has, well,
somewhat uncertain parentage. We don't even use this in CXF, since,
sadly, web services can't do relax-ng.

So, the maven poms for CXF simply list MSV as a dependency, and due to
the wonders of transitive dependency management, relaxngDatatype
trails along. However, we do NOT include this jar in our release
packages, and none of our source code actually depends on msv in the
classpath to compile. If you want schema validation, you must download
MSV and dependencies and drop them into the classpath. CXF isn't
compiled against their API; it's all done reflectively.

We could be more stringent by listing msv as a maven 'runtime'
dependency -- that would keep it out of the compilation classpath and
make it harder to accidently create a source dependency, but we could
still have automated tests. Or someone could bust our chops to come up
with some non-maven download scheme.

So, someone who downloads CXF source and types 'mvn' ends up with
relaxngDatatype.jar on their machine. I could imagine taking some flak
for that. Something tells me that, out in the wilder corners of 7-step
transitive dependencies, we're not the only ASF package where
something like this happens. It's awfully hard to keep track of.

For a project like Lucene/Solr, with an ant build, the testing problem
requires the use of the 'optional download' guidelines of the web page
cited above. The build.xml would need to have an entirely optional
target which either (a) expected the user to have downloaded the
radioactive Jar in advance, or (b) downloaded it for them, and then
ran the tests.


To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message