Yes, direct or transitive dependencies have no bearing on the
application of the license or ASF policy.
Remember, the phrasing of the policy is important: "[you may not bundle
any products which are category-X]" (probably a bad time to not quote
directly, but hopefully my point gets across nonetheless).
The "optional dependencies" is the only relevant caveat here (and I'll
avoid re-hashing in depth as I think it was pretty clear last time). If
the Geo-Indexing module that Rya provides is 'optional', the dependency
is OK, but I believe you still must not bundle it (e.g. uber.jar) in a
release, it would be something users can build themselves if they accept
the terms of the lgpl.
- Josh
Aaron D. Mihalik wrote:
As we discussed before, a direct dependency on a LGPL licensed jar is
prohibited, but are transitive dependencies prohibited?
For instance, Rya Geoindexing depends on Geomesa (Apache 2.0 licensed) and
Geomesa depends on Geotools (LGPL licensed). I believe that we get into
trouble in Rya Geoindexing for two reasons:
1. We build an uber jar that contains the Geotools jars.
2. The Rya Geoindexing source code directly uses (or "links") to classes
contained in Geotools.
If we were able to eliminate 1 and 2 (but still have Geomesa and Geotools
as transitive dependencies), could we include Rya Geoindexing in the
release?
Thanks,
Aaron
