LGPL Compatability (again) for Direct vs. Transitive Dependencies

["Aaron D. Mihalik" <aa...@gmail.com>]

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

Re: LGPL Compatability (again) for Direct vs. Transitive Dependencies

["Aaron D. Mihalik" <aa...@gmail.com>]

Okay, thanks for clearing that up for me.

On Thu, Dec 1, 2016 at 4:00 PM Josh Elser <el...@apache.org> wrote:

> 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
> >
>

Re: LGPL Compatability (again) for Direct vs. Transitive Dependencies

[Josh Elser <el...@apache.org>]

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
>