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

Reply via email to