Re: RYA-179 Review License / Copyright notices on Rya Artifacts

2016-09-14 Thread Puja Valiyil 
Could we revive the indexer profile again?  Make everything in indexing
only included in that profile?  That could push off refactoring the
geoindexing until our next release.

On Wed, Sep 14, 2016 at 10:29 AM, Aaron D. Mihalik 
wrote:

> Yeah, that sounds possible. I don't like the idea of having to maintain
> another build/ci/release process, though.
>
> More importantly, we'd also have to modify our GeoIndexer interface [1] to
> something Apache Friendly.  It looks like Ersi puts out an Apache 2.0
> library [2].
>
> [1]
> https://github.com/apache/incubator-rya/blob/master/
> extras/indexing/src/main/java/mvm/rya/indexing/GeoIndexer.java
> [2] https://github.com/Esri/geometry-api-java
>
> On Tue, Sep 13, 2016 at 10:36 PM Jim Hughes  wrote:
>
> > Hi Aaron,
> >
> > Thanks, wasn't finding that list quickly...
> >
> > It sounds like the GeoMesa/GeoTools usage might fall under this Q/A:
> > http://www.apache.org/legal/resolved.html#optional.
> >
> > Thoughts?
> >
> > Jim
> >
> > On 9/13/2016 9:25 PM, Aaron D. Mihalik wrote:
> > > Jim,
> > >
> > > We've been working off of these lists:
> > >
> > > http://www.apache.org/legal/resolved.html#category-a
> > >
> > > On Tue, Sep 13, 2016 at 6:07 PM Jim Hughes  wrote:
> > >
> > >> Hi David,
> > >>
> > >> A number of the geo-dependencies are likely from the geo-indexing
> (which
> > >> uses GeoMesa (Apache 2.0) which uses GeoTools and JTS).
> > >>
> > >> Are there options to make the geoindexing a profile, provide the
> source,
> > >> and not provide artifacts for that code at Apache?
> > >>
> > >> Also, is there a list of approved licenses for Apache projects
> > >> dependencies?
> > >>
> > >> Cheers,
> > >>
> > >> Jim
> > >>
> > >> On 09/13/2016 05:46 PM, David Lotts wrote:
> > >>> This issue is a release blocker:
> > >>> 
> > >>>
> > >>> RYA-179  Review
> > License /
> > >>> Copyright notices on Rya Artifacts
> > >>>
> > >>> I was able to create a 3rd party dependency license report for Rya
> > >>> from the license
> > >>> maven plugin.
> > >>> 
> > >>>
> > >>> Good: I can send the full list if you like.  Mostly ASL and clearly
> > >>> permitted.
> > >>>
> > >>> Okay: A number of CDDL and CPL licenses -- permitted if no source
> code
> > is
> > >>> included.
> > >>>
> > >>> Needs Improvement: The following are not clearly permitted licenses:
> > >>>
> > >>>(cern.colt MIT license see
> > >>> https://dst.lbl.gov/ACSSoftware/colt/license.html) colt
> > >> (colt:colt:1.2.0 -
> > >>> no url defined)
> > >>>-- this is a mistake, should be  java.util.Arrays, not
> > >>> cern.colt.Arrays  -- creating an issue to eliminate dependency.
> > >>>(GNU LESSER GENERAL PUBLIC LICENSE) JCalendar
> > >>> (com.toedter:jcalendar:1.1.4 - http://www.toedter.com/en/jcalendar/)
> > >>>(Lesser General Public License (LGPL)) JTS Topology Suite
> > >>> (com.vividsolutions:jts:1.13 -
> > >>> http://sourceforge.net/projects/jts-topo-suite)
> > >>>(Lesser General Public License (LGPL)) Image I/O-Extensions -
> > >> GeoCore
> > >>> (it.geosolutions.imageio-ext:imageio-ext-geocore:1.1.13 - no url
> > defined)
> > >>>(Lesser General Public License (LGPL)) Image I/O-Extensions -
> > >> Custom
> > >>> Streams (it.geosolutions.imageio-ext:imageio-ext-streams:1.1.13 - no
> > url
> > >>> defined)
> > >>>(Lesser General Public License (LGPL)) Improved TIFF Plugin
> > >>> (it.geosolutions.imageio-ext:imageio-ext-tiff:1.1.13 - no url
> defined)
> > >>>(Lesser General Public License (LGPL)) Image I/O-Extensions -
> > >>> utilities classes and methods
> > >>> (it.geosolutions.imageio-ext:imageio-ext-utilities:1.1.13 - no url
> > >> defined)
> > >>>(Unknown license) jai_codec (javax.media:jai_codec:1.1.3 - no
> > url
> > >>> defined)
> > >>>(Unknown license) jai_core (javax.media:jai_core:1.1.3 - no
> url
> > >>> defined)
> > >>>(Unknown license) jai_imageio (javax.media:jai_imageio:1.1 -
> no
> > url
> > >>> defined)
> > >>>(Unknown license) jgridshift (jgridshift:jgridshift:1.0 - no
> url
> > >>> defined)
> > >>>(GNU Lesser General Public License) Remote Tea Runtime
> > >>> (org.acplt:oncrpc:1.0.7 - http://remotetea.sourceforge.net/)
> > >>>(Unknown license) Antlr 3.4 Runtime
> > (org.antlr:antlr-runtime:3.4 -
> > >>> http://www.antlr.org)
> > >>>(Unknown license) Jettison (org.codehaus.jettison:
> jettison:1.1
> > - no
> > >>> url defined)
> > >>>(Lesser General Public License (LGPL)) API interfaces
> > >>> (org.geotools:gt-api:14.3 - no url defined)
> > >>>(Lesser General Public License (LGPL)) Grid Coverage module
> > >>> (org.geotools:gt-coverage:14.3 - no url defined)
> > >>>(Lesser General Public License (LGPL)) OGC CQL to Filter
> parser
> > >>>

Re: RYA-179 Review License / Copyright notices on Rya Artifacts

2016-09-14 Thread David Lotts 
I am seeing something happening might make this a non-issue in the medium
term.  Maybe someone can confirm this.  It looks like the LocationTech
community is adopting JTS and (here is my speculation) trying to shed
GeoTools and any dependence on LGPL.

"... induction of JTS
 into the
LocationTech community. The project tasks to address including a license
change from LGPL to BSD/EPL, ..."
found here:
http://boundlessgeo.com/2016/02/locationtech-incubation-sprint-update/

This is great, but Geotools is LGPL only, correct?   Third-party code
redistributed by Eclipse (EPL) explicitly excludes LGPL
.
But then I see this:

http://boundlessgeo.com/press-release/boundless-ccri-launch-opengeo-suite-geomesa/

Perhaps this will all work out and we can just grab a later version of
GeoMesa with 100% Apache redistributability.  :-)

david.

On Wed, Sep 14, 2016 at 12:09 PM, David Lotts  wrote:

> Great find Aaron!
> The ESRI library is quite comparable!
>
> Rya via Geomesa are using *JTS Topology Suite (*JTS): (the javadocs at
> vividsolutions seems to be 404 )
> http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/
> Geometry.html
>
> Far from a drop-in replacement, but a path forward:
> http://esri.github.io/geometry-api-java/javadoc/
>
> Interesting, ESRI has Shape file support, but no GML, the opposite of JTS!
> david.
>

On Wed, Sep 14, 2016 at 10:39 AM, Puja Valiyil  wrote:

> Could we revive the indexer profile again?  Make everything in indexing
> only included in that profile?  That could push off refactoring the
> geoindexing until our next release.
>
> On Wed, Sep 14, 2016 at 10:29 AM, Aaron D. Mihalik <
> aaron.miha...@gmail.com>
> wrote:
>
> > Yeah, that sounds possible. I don't like the idea of having to maintain
> > another build/ci/release process, though.
> >
> > More importantly, we'd also have to modify our GeoIndexer interface [1]
> to
> > something Apache Friendly.  It looks like Ersi puts out an Apache 2.0
> > library [2].
> >
> > [1]
> > https://github.com/apache/incubator-rya/blob/master/
> > extras/indexing/src/main/java/mvm/rya/indexing/GeoIndexer.java
> > [2] https://github.com/Esri/geometry-api-java
> >
> > On Tue, Sep 13, 2016 at 10:36 PM Jim Hughes  wrote:
> >
> > > Hi Aaron,
> > >
> > > Thanks, wasn't finding that list quickly...
> > >
> > > It sounds like the GeoMesa/GeoTools usage might fall under this Q/A:
> > > http://www.apache.org/legal/resolved.html#optional.
> > >
> > > Thoughts?
> > >
> > > Jim
> > >
> > > On 9/13/2016 9:25 PM, Aaron D. Mihalik wrote:
> > > > Jim,
> > > >
> > > > We've been working off of these lists:
> > > >
> > > > http://www.apache.org/legal/resolved.html#category-a
> > > >
> > > > On Tue, Sep 13, 2016 at 6:07 PM Jim Hughes  wrote:
> > > >
> > > >> Hi David,
> > > >>
> > > >> A number of the geo-dependencies are likely from the geo-indexing
> > (which
> > > >> uses GeoMesa (Apache 2.0) which uses GeoTools and JTS).
> > > >>
> > > >> Are there options to make the geoindexing a profile, provide the
> > source,
> > > >> and not provide artifacts for that code at Apache?
> > > >>
> > > >> Also, is there a list of approved licenses for Apache projects
> > > >> dependencies?
> > > >>
> > > >> Cheers,
> > > >>
> > > >> Jim
> > > >>
> > > >> On 09/13/2016 05:46 PM, David Lotts wrote:
> > > >>> This issue is a release blocker:
> > > >>> 
> > > >>>
> > > >>> RYA-179  Review
> > > License /
> > > >>> Copyright notices on Rya Artifacts
> > > >>>
> > > >>> I was able to create a 3rd party dependency license report for Rya
> > > >>> from the license
> > > >>> maven plugin.
> > > >>> 
> > > >>>
> > > >>> Good: I can send the full list if you like.  Mostly ASL and clearly
> > > >>> permitted.
> > > >>>
> > > >>> Okay: A number of CDDL and CPL licenses -- permitted if no source
> > code
> > > is
> > > >>> included.
> > > >>>
> > > >>> Needs Improvement: The following are not clearly permitted
> licenses:
> > > >>>
> > > >>>(cern.colt MIT license see
> > > >>> https://dst.lbl.gov/ACSSoftware/colt/license.html) colt
> > > >> (colt:colt:1.2.0 -
> > > >>> no url defined)
> > > >>>-- this is a mistake, should be  java.util.Arrays, not
> > > >>> cern.colt.Arrays  -- creating an issue to eliminate dependency.
> > > >>>(GNU LESSER GENERAL PUBLIC LICENSE) JCalendar
> > > >>> (com.toedter:jcalendar:1.1.4 - http://www.toedter.com/en/
> jcalendar/)
> > > >>>(Lesser General Public License (LGPL)) JTS Topology Suite
> > > >>> (com.vividsolutions:jts:1.13 -
> > > >>> http://sourceforge.net/projects/jts-topo-suite)
> > > >>>(Lesser General Public License (LGPL)) Image I/O-Extensions
> -
> > > >> GeoCore
> > > >>>

Re: RYA-179 Review License / Copyright notices on Rya Artifacts

2016-09-14 Thread Jim Hughes 

Hi David,

I'm involved with lots of things at LocationTech and the 
GeoTools/GeoServer community.  JTS is close to get sorted out with a 
dual license.  That said, GeoTools is still LGPL and will likely remain 
so for awhile.


As far as I know, ESRI's Geometry library and JTS aren't immediately 
compatible.  (I.e., I don't think one is a drop-in replacement for the 
other.)  Either way, GeoMesa uses GeoTools which leverages JTS.  I just 
mention that to explain that trying to change the geometry libraries 
would not sort out the GeoTools dependency.


I think the profile approach might be best for the medium term.

Cheers,

Jim

On 09/14/2016 12:31 PM, David Lotts wrote:

I am seeing something happening might make this a non-issue in the medium
term.  Maybe someone can confirm this.  It looks like the LocationTech
community is adopting JTS and (here is my speculation) trying to shed
GeoTools and any dependence on LGPL.

"... induction of JTS
 into the
LocationTech community. The project tasks to address including a license
change from LGPL to BSD/EPL, ..."
found here:
http://boundlessgeo.com/2016/02/locationtech-incubation-sprint-update/

This is great, but Geotools is LGPL only, correct?   Third-party code
redistributed by Eclipse (EPL) explicitly excludes LGPL
.
But then I see this:

http://boundlessgeo.com/press-release/boundless-ccri-launch-opengeo-suite-geomesa/

Perhaps this will all work out and we can just grab a later version of
GeoMesa with 100% Apache redistributability.  :-)

david.

On Wed, Sep 14, 2016 at 12:09 PM, David Lotts  wrote:


Great find Aaron!
The ESRI library is quite comparable!

Rya via Geomesa are using *JTS Topology Suite (*JTS): (the javadocs at
vividsolutions seems to be 404 )
 http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/
Geometry.html

Far from a drop-in replacement, but a path forward:
 http://esri.github.io/geometry-api-java/javadoc/

Interesting, ESRI has Shape file support, but no GML, the opposite of JTS!
david.


On Wed, Sep 14, 2016 at 10:39 AM, Puja Valiyil  wrote:


Could we revive the indexer profile again?  Make everything in indexing
only included in that profile?  That could push off refactoring the
geoindexing until our next release.

On Wed, Sep 14, 2016 at 10:29 AM, Aaron D. Mihalik <
aaron.miha...@gmail.com>
wrote:


Yeah, that sounds possible. I don't like the idea of having to maintain
another build/ci/release process, though.

More importantly, we'd also have to modify our GeoIndexer interface [1]

to

something Apache Friendly.  It looks like Ersi puts out an Apache 2.0
library [2].

[1]
https://github.com/apache/incubator-rya/blob/master/
extras/indexing/src/main/java/mvm/rya/indexing/GeoIndexer.java
[2] https://github.com/Esri/geometry-api-java

On Tue, Sep 13, 2016 at 10:36 PM Jim Hughes  wrote:


Hi Aaron,

Thanks, wasn't finding that list quickly...

It sounds like the GeoMesa/GeoTools usage might fall under this Q/A:
http://www.apache.org/legal/resolved.html#optional.

Thoughts?

Jim

On 9/13/2016 9:25 PM, Aaron D. Mihalik wrote:

Jim,

We've been working off of these lists:

http://www.apache.org/legal/resolved.html#category-a

On Tue, Sep 13, 2016 at 6:07 PM Jim Hughes  wrote:


Hi David,

A number of the geo-dependencies are likely from the geo-indexing

(which

uses GeoMesa (Apache 2.0) which uses GeoTools and JTS).

Are there options to make the geoindexing a profile, provide the

source,

and not provide artifacts for that code at Apache?

Also, is there a list of approved licenses for Apache projects
dependencies?

Cheers,

Jim

On 09/13/2016 05:46 PM, David Lotts wrote:

This issue is a release blocker:


RYA-179  Review

License /

Copyright notices on Rya Artifacts

I was able to create a 3rd party dependency license report for Rya
from the license
maven plugin.


Good: I can send the full list if you like.  Mostly ASL and clearly
permitted.

Okay: A number of CDDL and CPL licenses -- permitted if no source

code

is

included.

Needs Improvement: The following are not clearly permitted

licenses:

(cern.colt MIT license see
https://dst.lbl.gov/ACSSoftware/colt/license.html) colt

(colt:colt:1.2.0 -

no url defined)
-- this is a mistake, should be  java.util.Arrays, not
cern.colt.Arrays  -- creating an issue to eliminate dependency.
(GNU LESSER GENERAL PUBLIC LICENSE) JCalendar
(com.toedter:jcalendar:1.1.4 - http://www.toedter.com/en/

jcalendar/)

(Lesser General Public License (LGPL)) JTS Topology Suite
(com.vividsolutions:jts:1.13 -
http://sourceforge.net/projects/jts-topo-suite)
(Lesser General Public License (LGPL)) Image I/O-Extensions

-

Re: RYA-179 Review License / Copyright notices on Rya Artifacts

2016-09-14 Thread Aaron D. Mihalik 
> Could we revive the indexer profile again?

(tl;dr: Yes.  Mentors: Please correct us if we're wrong)

This might be a solution.  I found a couple similar cases with Apache
projects and discussions related to those cases.

Apache Flink integrated with Amazon Kinesis [1] and [2].  Note that Kinesis
is an optional profile, and it's well documented in the POM why it's
optional.

(Note that NiFi got around this by using Amazon's SDK for Java [3], which
is purely Apache 2.0)

Spark uses optional profiles to build artifacts based on LGPL
dependencies.  Spark has to built by the user to use netlib [4][5], Ganglia
[6], or Kinesis [6].

I think a profile will work, but I'd like to see it well documented (both
in the POM and manual) so that we never accidentally create a release with
these artifacts.

I was going to open a separate ticket to implement this, but I think it's
good to track all of this effort under RYA-177.

--Aaron

[1]
https://github.com/apache/flink/blob/release-1.1.2/flink-streaming-connectors/pom.xml#L69
[2]
https://github.com/apache/flink/blob/release-1.1.2/flink-streaming-connectors/flink-connector-kinesis/pom.xml#L73

[3] https://github.com/apache/nifi/blob/master/pom.xml#L1316

[4] https://github.com/apache/spark/blob/v2.0.0/mllib/pom.xml#L120
[5]
https://github.com/apache/spark/blob/v2.0.0/docs/ml-guide.md#dependencies

[6] https://github.com/apache/spark/blob/v2.0.0/pom.xml#L2414

[7] https://issues.apache.org/jira/browse/LEGAL-198
[8] https://www.gnu.org/licenses/lgpl-java.html



On Wed, Sep 14, 2016 at 12:09 PM David Lotts  wrote:

> Great find Aaron!
> The ESRI library is quite comparable!
>
> Rya via Geomesa are using *JTS Topology Suite (*JTS): (the javadocs at
> vividsolutions seems to be 404 )
>
>
> http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html
>
> Far from a drop-in replacement, but a path forward:
> http://esri.github.io/geometry-api-java/javadoc/
>
> Interesting, ESRI has Shape file support, but no GML, the opposite of JTS!
> david.
>
>
> On Wed, Sep 14, 2016 at 10:29 AM, Aaron D. Mihalik <
> aaron.miha...@gmail.com>
> wrote:
>
> > Yeah, that sounds possible. I don't like the idea of having to maintain
> > another build/ci/release process, though.
> >
> > More importantly, we'd also have to modify our GeoIndexer interface [1]
> to
> > something Apache Friendly.  It looks like Ersi puts out an Apache 2.0
> > library [2].
> >
> > [1]
> > https://github.com/apache/incubator-rya/blob/master/
> > extras/indexing/src/main/java/mvm/rya/indexing/GeoIndexer.java
> > [2] https://github.com/Esri/geometry-api-java
> >
> > On Tue, Sep 13, 2016 at 10:36 PM Jim Hughes  wrote:
> >
> > > Hi Aaron,
> > >
> > > Thanks, wasn't finding that list quickly...
> > >
> > > It sounds like the GeoMesa/GeoTools usage might fall under this Q/A:
> > > http://www.apache.org/legal/resolved.html#optional.
> > >
> > > Thoughts?
> > >
> > > Jim
> > >
> > > On 9/13/2016 9:25 PM, Aaron D. Mihalik wrote:
> > > > Jim,
> > > >
> > > > We've been working off of these lists:
> > > >
> > > > http://www.apache.org/legal/resolved.html#category-a
> > > >
> > > > On Tue, Sep 13, 2016 at 6:07 PM Jim Hughes  wrote:
> > > >
> > > >> Hi David,
> > > >>
> > > >> A number of the geo-dependencies are likely from the geo-indexing
> > (which
> > > >> uses GeoMesa (Apache 2.0) which uses GeoTools and JTS).
> > > >>
> > > >> Are there options to make the geoindexing a profile, provide the
> > source,
> > > >> and not provide artifacts for that code at Apache?
> > > >>
> > > >> Also, is there a list of approved licenses for Apache projects
> > > >> dependencies?
> > > >>
> > > >> Cheers,
> > > >>
> > > >> Jim
> > > >>
> > > >> On 09/13/2016 05:46 PM, David Lotts wrote:
> > > >>> This issue is a release blocker:
> > > >>> 
> > > >>>
> > > >>> RYA-179  Review
> > > License /
> > > >>> Copyright notices on Rya Artifacts
> > > >>>
> > > >>> I was able to create a 3rd party dependency license report for Rya
> > > >>> from the license
> > > >>> maven plugin.
> > > >>> 
> > > >>>
> > > >>> Good: I can send the full list if you like.  Mostly ASL and clearly
> > > >>> permitted.
> > > >>>
> > > >>> Okay: A number of CDDL and CPL licenses -- permitted if no source
> > code
> > > is
> > > >>> included.
> > > >>>
> > > >>> Needs Improvement: The following are not clearly permitted
> licenses:
> > > >>>
> > > >>>(cern.colt MIT license see
> > > >>> https://dst.lbl.gov/ACSSoftware/colt/license.html) colt
> > > >> (colt:colt:1.2.0 -
> > > >>> no url defined)
> > > >>>-- this is a mistake, should be  java.util.Arrays, not
> > > >>> cern.colt.Arrays  -- creating an issue to eliminate dependency.
> > > >>>(GNU LESSER GENERAL PUBLIC LICENSE) JCalendar
> > > >>> (com.toedter:jcalendar:1.1.4 -
>

Re: RYA-179 Review License / Copyright notices on Rya Artifacts

2016-09-14 Thread David Lotts 
Oops, this thread was supposed to be subject RYA-177
RYA-179 is corrections to Rya source file license headers.

Jim, do you know when GeoMesa plans to be completely free of GeoTools ?
Clearly Geotools is an obstacle for Apache projects to use LocationTech
projects, or at least GeoMesa.
Or is there another path forward for GeoMesa?

On Wed, Sep 14, 2016 at 1:48 PM, Aaron D. Mihalik 
wrote:

> > Could we revive the indexer profile again?
>
> (tl;dr: Yes.  Mentors: Please correct us if we're wrong)
>
> This might be a solution.  I found a couple similar cases with Apache
> projects and discussions related to those cases.
>
> Apache Flink integrated with Amazon Kinesis [1] and [2].  Note that Kinesis
> is an optional profile, and it's well documented in the POM why it's
> optional.
>
> (Note that NiFi got around this by using Amazon's SDK for Java [3], which
> is purely Apache 2.0)
>
> Spark uses optional profiles to build artifacts based on LGPL
> dependencies.  Spark has to built by the user to use netlib [4][5], Ganglia
> [6], or Kinesis [6].
>
> I think a profile will work, but I'd like to see it well documented (both
> in the POM and manual) so that we never accidentally create a release with
> these artifacts.
>
> I was going to open a separate ticket to implement this, but I think it's
> good to track all of this effort under RYA-177.
>
> --Aaron
>
> [1]
> https://github.com/apache/flink/blob/release-1.1.2/
> flink-streaming-connectors/pom.xml#L69
> [2]
> https://github.com/apache/flink/blob/release-1.1.2/
> flink-streaming-connectors/flink-connector-kinesis/pom.xml#L73
>
> [3] https://github.com/apache/nifi/blob/master/pom.xml#L1316
>
> [4] https://github.com/apache/spark/blob/v2.0.0/mllib/pom.xml#L120
> [5]
> https://github.com/apache/spark/blob/v2.0.0/docs/ml-guide.md#dependencies
>
> [6] https://github.com/apache/spark/blob/v2.0.0/pom.xml#L2414
>
> [7] https://issues.apache.org/jira/browse/LEGAL-198
> [8] https://www.gnu.org/licenses/lgpl-java.html
>
>
>
> On Wed, Sep 14, 2016 at 12:09 PM David Lotts  wrote:
>
> > Great find Aaron!
> > The ESRI library is quite comparable!
> >
> > Rya via Geomesa are using *JTS Topology Suite (*JTS): (the javadocs at
> > vividsolutions seems to be 404 )
> >
> >
> > http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/
> Geometry.html
> >
> > Far from a drop-in replacement, but a path forward:
> > http://esri.github.io/geometry-api-java/javadoc/
> >
> > Interesting, ESRI has Shape file support, but no GML, the opposite of
> JTS!
> > david.
> >
> >
> > On Wed, Sep 14, 2016 at 10:29 AM, Aaron D. Mihalik <
> > aaron.miha...@gmail.com>
> > wrote:
> >
> > > Yeah, that sounds possible. I don't like the idea of having to maintain
> > > another build/ci/release process, though.
> > >
> > > More importantly, we'd also have to modify our GeoIndexer interface [1]
> > to
> > > something Apache Friendly.  It looks like Ersi puts out an Apache 2.0
> > > library [2].
> > >
> > > [1]
> > > https://github.com/apache/incubator-rya/blob/master/
> > > extras/indexing/src/main/java/mvm/rya/indexing/GeoIndexer.java
> > > [2] https://github.com/Esri/geometry-api-java
> > >
> > > On Tue, Sep 13, 2016 at 10:36 PM Jim Hughes  wrote:
> > >
> > > > Hi Aaron,
> > > >
> > > > Thanks, wasn't finding that list quickly...
> > > >
> > > > It sounds like the GeoMesa/GeoTools usage might fall under this Q/A:
> > > > http://www.apache.org/legal/resolved.html#optional.
> > > >
> > > > Thoughts?
> > > >
> > > > Jim
> > > >
> > > > On 9/13/2016 9:25 PM, Aaron D. Mihalik wrote:
> > > > > Jim,
> > > > >
> > > > > We've been working off of these lists:
> > > > >
> > > > > http://www.apache.org/legal/resolved.html#category-a
> > > > >
> > > > > On Tue, Sep 13, 2016 at 6:07 PM Jim Hughes  wrote:
> > > > >
> > > > >> Hi David,
> > > > >>
> > > > >> A number of the geo-dependencies are likely from the geo-indexing
> > > (which
> > > > >> uses GeoMesa (Apache 2.0) which uses GeoTools and JTS).
> > > > >>
> > > > >> Are there options to make the geoindexing a profile, provide the
> > > source,
> > > > >> and not provide artifacts for that code at Apache?
> > > > >>
> > > > >> Also, is there a list of approved licenses for Apache projects
> > > > >> dependencies?
> > > > >>
> > > > >> Cheers,
> > > > >>
> > > > >> Jim
> > > > >>
> > > > >> On 09/13/2016 05:46 PM, David Lotts wrote:
> > > > >>> This issue is a release blocker:
> > > > >>> 
> > > > >>>
> > > > >>> RYA-179  Review
> > > > License /
> > > > >>> Copyright notices on Rya Artifacts
> > > > >>>
> > > > >>> I was able to create a 3rd party dependency license report for
> Rya
> > > > >>> from the license
> > > > >>> maven plugin.
> > > > >>> 
> > > > >>>
> > > > >>> Good: I can send the full list if you like.  Mostly ASL and
>

Re: RYA-179 Review License / Copyright notices on Rya Artifacts

2016-09-14 Thread Jim Hughes 

Hi Dave,

Good question.  Currently, there are no plans for GeoMesa to be free of 
GeoTools.  At the minute, GeoTools and GeoServer are two of the best 
projects for handling geospatial processing and serving up the results 
via OGC access patterns.  It is inconvenient that their licenses aren't 
more business friendly.  I'd point out that several of these projects 
were in existence before ASF license version 1.1.;)


In terms of integrations of GeoMesa and Apache projects, in many cases 
(such as Storm or Kafka), I think it might make more sense for GeoMesa 
to depend on the Apache project or for there to be a third-party project 
which depends on both (for example with NiFi). Overall, I'd love to see 
better licensing so that dependencies can go either direction.  I spend 
more time than I care to dealing with legal details like this...


For other LocationTech projects, I'd point out that only a few use 
GeoTools.  For instance, Spatial4J is used by Apache Lucene. Overall, 
the Eclipse Foundation (and LocationTech by extension) hosts projects 
which have business-friendly licenses.


Anyhow, I hope that helps clarify things a bit.

Cheers,

Jim

On 09/14/2016 02:29 PM, David Lotts wrote:

Oops, this thread was supposed to be subject RYA-177
RYA-179 is corrections to Rya source file license headers.

Jim, do you know when GeoMesa plans to be completely free of GeoTools ?
Clearly Geotools is an obstacle for Apache projects to use LocationTech
projects, or at least GeoMesa.
Or is there another path forward for GeoMesa?

On Wed, Sep 14, 2016 at 1:48 PM, Aaron D. Mihalik 
wrote:


Could we revive the indexer profile again?

(tl;dr: Yes.  Mentors: Please correct us if we're wrong)

This might be a solution.  I found a couple similar cases with Apache
projects and discussions related to those cases.

Apache Flink integrated with Amazon Kinesis [1] and [2].  Note that Kinesis
is an optional profile, and it's well documented in the POM why it's
optional.

(Note that NiFi got around this by using Amazon's SDK for Java [3], which
is purely Apache 2.0)

Spark uses optional profiles to build artifacts based on LGPL
dependencies.  Spark has to built by the user to use netlib [4][5], Ganglia
[6], or Kinesis [6].

I think a profile will work, but I'd like to see it well documented (both
in the POM and manual) so that we never accidentally create a release with
these artifacts.

I was going to open a separate ticket to implement this, but I think it's
good to track all of this effort under RYA-177.

--Aaron

[1]
https://github.com/apache/flink/blob/release-1.1.2/
flink-streaming-connectors/pom.xml#L69
[2]
https://github.com/apache/flink/blob/release-1.1.2/
flink-streaming-connectors/flink-connector-kinesis/pom.xml#L73

[3] https://github.com/apache/nifi/blob/master/pom.xml#L1316

[4] https://github.com/apache/spark/blob/v2.0.0/mllib/pom.xml#L120
[5]
https://github.com/apache/spark/blob/v2.0.0/docs/ml-guide.md#dependencies

[6] https://github.com/apache/spark/blob/v2.0.0/pom.xml#L2414

[7] https://issues.apache.org/jira/browse/LEGAL-198
[8] https://www.gnu.org/licenses/lgpl-java.html



On Wed, Sep 14, 2016 at 12:09 PM David Lotts  wrote:


Great find Aaron!
The ESRI library is quite comparable!

Rya via Geomesa are using *JTS Topology Suite (*JTS): (the javadocs at
vividsolutions seems to be 404 )


http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/

Geometry.html

Far from a drop-in replacement, but a path forward:
 http://esri.github.io/geometry-api-java/javadoc/

Interesting, ESRI has Shape file support, but no GML, the opposite of

JTS!

david.


On Wed, Sep 14, 2016 at 10:29 AM, Aaron D. Mihalik <
aaron.miha...@gmail.com>
wrote:


Yeah, that sounds possible. I don't like the idea of having to maintain
another build/ci/release process, though.

More importantly, we'd also have to modify our GeoIndexer interface [1]

to

something Apache Friendly.  It looks like Ersi puts out an Apache 2.0
library [2].

[1]
https://github.com/apache/incubator-rya/blob/master/
extras/indexing/src/main/java/mvm/rya/indexing/GeoIndexer.java
[2] https://github.com/Esri/geometry-api-java

On Tue, Sep 13, 2016 at 10:36 PM Jim Hughes  wrote:


Hi Aaron,

Thanks, wasn't finding that list quickly...

It sounds like the GeoMesa/GeoTools usage might fall under this Q/A:
http://www.apache.org/legal/resolved.html#optional.

Thoughts?

Jim

On 9/13/2016 9:25 PM, Aaron D. Mihalik wrote:

Jim,

We've been working off of these lists:

http://www.apache.org/legal/resolved.html#category-a

On Tue, Sep 13, 2016 at 6:07 PM Jim Hughes  wrote:


Hi David,

A number of the geo-dependencies are likely from the geo-indexing

(which

uses GeoMesa (Apache 2.0) which uses GeoTools and JTS).

Are there options to make the geoindexing a profile, provide the

source,

and not provide artifacts for that code at Apache?

Also, is there a list of approved licenses for

Re: RYA-179 Review License / Copyright notices on Rya Artifacts

2016-09-14 Thread Josh Elser 
I would have said that this is only kosher when you have an alternative 
to the incompatibly licensed software. Is the indexer actually optional 
(I don't have enough context)? Are there ways for me to to indexing of 
the same type of data that don't require use of these incompatible 
dependencies?


Billie might be able to provide some more context too.

Aaron D. Mihalik wrote:

Could we revive the indexer profile again?


(tl;dr: Yes.  Mentors: Please correct us if we're wrong)

This might be a solution.  I found a couple similar cases with Apache
projects and discussions related to those cases.

Apache Flink integrated with Amazon Kinesis [1] and [2].  Note that Kinesis
is an optional profile, and it's well documented in the POM why it's
optional.

(Note that NiFi got around this by using Amazon's SDK for Java [3], which
is purely Apache 2.0)

Spark uses optional profiles to build artifacts based on LGPL
dependencies.  Spark has to built by the user to use netlib [4][5], Ganglia
[6], or Kinesis [6].

I think a profile will work, but I'd like to see it well documented (both
in the POM and manual) so that we never accidentally create a release with
these artifacts.

I was going to open a separate ticket to implement this, but I think it's
good to track all of this effort under RYA-177.

--Aaron

[1]
https://github.com/apache/flink/blob/release-1.1.2/flink-streaming-connectors/pom.xml#L69
[2]
https://github.com/apache/flink/blob/release-1.1.2/flink-streaming-connectors/flink-connector-kinesis/pom.xml#L73

[3] https://github.com/apache/nifi/blob/master/pom.xml#L1316

[4] https://github.com/apache/spark/blob/v2.0.0/mllib/pom.xml#L120
[5]
https://github.com/apache/spark/blob/v2.0.0/docs/ml-guide.md#dependencies

[6] https://github.com/apache/spark/blob/v2.0.0/pom.xml#L2414

[7] https://issues.apache.org/jira/browse/LEGAL-198
[8] https://www.gnu.org/licenses/lgpl-java.html



On Wed, Sep 14, 2016 at 12:09 PM David Lotts  wrote:


Great find Aaron!
The ESRI library is quite comparable!

Rya via Geomesa are using *JTS Topology Suite (*JTS): (the javadocs at
vividsolutions seems to be 404 )


http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html

Far from a drop-in replacement, but a path forward:
 http://esri.github.io/geometry-api-java/javadoc/

Interesting, ESRI has Shape file support, but no GML, the opposite of JTS!
david.


On Wed, Sep 14, 2016 at 10:29 AM, Aaron D. Mihalik<
aaron.miha...@gmail.com>
wrote:


Yeah, that sounds possible. I don't like the idea of having to maintain
another build/ci/release process, though.

More importantly, we'd also have to modify our GeoIndexer interface [1]

to

something Apache Friendly.  It looks like Ersi puts out an Apache 2.0
library [2].

[1]
https://github.com/apache/incubator-rya/blob/master/
extras/indexing/src/main/java/mvm/rya/indexing/GeoIndexer.java
[2] https://github.com/Esri/geometry-api-java

On Tue, Sep 13, 2016 at 10:36 PM Jim Hughes  wrote:


Hi Aaron,

Thanks, wasn't finding that list quickly...

It sounds like the GeoMesa/GeoTools usage might fall under this Q/A:
http://www.apache.org/legal/resolved.html#optional.

Thoughts?

Jim

On 9/13/2016 9:25 PM, Aaron D. Mihalik wrote:

Jim,

We've been working off of these lists:

http://www.apache.org/legal/resolved.html#category-a

On Tue, Sep 13, 2016 at 6:07 PM Jim Hughes  wrote:


Hi David,

A number of the geo-dependencies are likely from the geo-indexing

(which

uses GeoMesa (Apache 2.0) which uses GeoTools and JTS).

Are there options to make the geoindexing a profile, provide the

source,

and not provide artifacts for that code at Apache?

Also, is there a list of approved licenses for Apache projects
dependencies?

Cheers,

Jim

On 09/13/2016 05:46 PM, David Lotts wrote:

This issue is a release blocker:


RYA-179  Review

License /

Copyright notices on Rya Artifacts

I was able to create a 3rd party dependency license report for Rya
from the license
maven plugin.


Good: I can send the full list if you like.  Mostly ASL and clearly
permitted.

Okay: A number of CDDL and CPL licenses -- permitted if no source

code

is

included.

Needs Improvement: The following are not clearly permitted

licenses:

(cern.colt MIT license see
https://dst.lbl.gov/ACSSoftware/colt/license.html) colt

(colt:colt:1.2.0 -

no url defined)
-- this is a mistake, should be  java.util.Arrays, not
cern.colt.Arrays  -- creating an issue to eliminate dependency.
(GNU LESSER GENERAL PUBLIC LICENSE) JCalendar
(com.toedter:jcalendar:1.1.4 -

http://www.toedter.com/en/jcalendar/)

(Lesser General Public License (LGPL)) JTS Topology Suite
(com.vividsolutions:jts:1.13 -
http://sourceforge.net/projects/jts-topo-suite)
(Lesser General Public License (LGPL)) Image

Re: [VOTE] Release Rya (Incubating) version 3.2.10

2016-09-14 Thread Adina Crainiceanu 
-1 because some test are failing and other issues

I was able to build from source. Some test on Mongo took so long that I had
to abort the build, so I ended up building with skipTests flag.
Hashes are OK. I did not have time to check more.

Several easy things to fix:

1) Release artifacts should be staged at
https://dist.apache.org/repos/dist/dev/incubator/rya/...  (Josh said so
already)
2) The artifacts names should contain "incubating" - something like
rya-3.2.10-incubating-source-release...
3) DISCLAIMER  - we should have a DISCLAIMER file  with the following
content:
Apache Rya is an effort undergoing incubation at The Apache Software
Foundation (ASF), sponsored by the Apache Incubator PMC. Incubation is
required of all newly accepted projects until a further review indicates
that the infrastructure, communications, and decision making process have
stabilized in a manner consistent with other successful ASF projects. While
incubation status is not necessarily a reflection of the completeness or
stability of the code, it does indicate that the project has yet to be
fully endorsed by the ASF.
4) KEYS file with the release manager's keys and maybe other committers'
too can typically be found at
https://dist.apache.org/repos/dist/dev/incubator/rya/KEYS
5) LICENSE issues - already discussed

Thank you all for working on this.
Adina


On Thu, Sep 8, 2016 at 10:01 PM, Aaron D. Mihalik 
wrote:

> I am pleased to be calling this vote for the source release of Apache Rya
> (Incubating), version 3.2.10.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/
> orgapacherya-1001/org/apache/rya/rya-project/3.2.10/
>
> The Git tag is v3.2.10
> The Git commit ID is 16196b4c658062545964602835cb5fbd2870e578
> https://git-wip-us.apache.org/repos/asf?p=incubator-rya.git;a=commit;h=
> 16196b4c658062545964602835cb5fbd2870e578
>
> Checksums of rya-project-3.2.10-source-release.zip:
> SHA1: dee4a5e4f8e74c4de614d02c7b17a5e0db132649
> MD5: df4a47ae1232725bc95450f5e49de95c
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/mihalik.asc
>
> Issues that were closed/resolved for this release are here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12334209=Html=12319020
>
> The vote will be open for 72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, and test.  Then
> please vote:
>
> [ ] +1 Release this package as rya-project-3.2.10
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because...
>



-- 
Dr. Adina Crainiceanu
Associate Professor, Computer Science Department
United States Naval Academy
410-293-6822
ad...@usna.edu
http://www.usna.edu/Users/cs/adina/

RE: RYA-179 Review License / Copyright notices on Rya Artifacts

2016-09-14 Thread Meier, Caleb 
While the indexer project extensions are optional in that they are turned off 
by default to minimize data plume, I would argue that they are not optional in 
the sense that Josh has described.  There is no other way to index/query for 
freetext, geospatial, and temporal data without these extensions.  So if a user 
wants these capabilities, they need the indexer project and all of the 
incompatibly licensed dependencies that come along with it.

From: Puja Valiyil [puja...@gmail.com]
Sent: Wednesday, September 14, 2016 9:49 PM
To: dev@rya.incubator.apache.org
Cc: Billie Rinaldi
Subject: Re: RYA-179 Review License / Copyright notices on Rya Artifacts

The indexer project has a set of configurable optional extension to Rya.  
Things like support for geosparql, support for free text indexing, and support 
for precomputed joins (which is where the fluo integration comes in).  These 
are extensions that by default are turned off.  They can really increase the 
data plume associated with some data, which is the main reason why.

In the original port into Apache, this project was only included if you 
specified that profile.  This was because we have traditionally considered 
those features experimental and they bring in a lot of possibly unwanted 
dependencies.  Aaron refactored it to not be optional when he was updating the 
pond to reference the Apache parent Pom.
So no alternative, but functionality that a typical user may debatably not want.

Sent from my iPhone

> On Sep 14, 2016, at 8:05 PM, Josh Elser  wrote:
>
> I would have said that this is only kosher when you have an alternative to 
> the incompatibly licensed software. Is the indexer actually optional (I don't 
> have enough context)? Are there ways for me to to indexing of the same type 
> of data that don't require use of these incompatible dependencies?
>
> Billie might be able to provide some more context too.
>
> Aaron D. Mihalik wrote:
>>> Could we revive the indexer profile again?
>>
>> (tl;dr: Yes.  Mentors: Please correct us if we're wrong)
>>
>> This might be a solution.  I found a couple similar cases with Apache
>> projects and discussions related to those cases.
>>
>> Apache Flink integrated with Amazon Kinesis [1] and [2].  Note that Kinesis
>> is an optional profile, and it's well documented in the POM why it's
>> optional.
>>
>> (Note that NiFi got around this by using Amazon's SDK for Java [3], which
>> is purely Apache 2.0)
>>
>> Spark uses optional profiles to build artifacts based on LGPL
>> dependencies.  Spark has to built by the user to use netlib [4][5], Ganglia
>> [6], or Kinesis [6].
>>
>> I think a profile will work, but I'd like to see it well documented (both
>> in the POM and manual) so that we never accidentally create a release with
>> these artifacts.
>>
>> I was going to open a separate ticket to implement this, but I think it's
>> good to track all of this effort under RYA-177.
>>
>> --Aaron
>>
>> [1]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_flink_blob_release-2D1.1.2_flink-2Dstreaming-2Dconnectors_pom.xml-23L69=CwIFAg=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY=wnYDdDdgR8EEFav9sKC7ftd6ZjSJcOXU8FISG6jJMHc=
>> [2]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_flink_blob_release-2D1.1.2_flink-2Dstreaming-2Dconnectors_flink-2Dconnector-2Dkinesis_pom.xml-23L73=CwIFAg=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY=ZFTL5gQzyzLvRcWrafGrCobMJ8d1DWSmZlIVz9M7EuQ=
>>
>> [3] 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_nifi_blob_master_pom.xml-23L1316=CwIFAg=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY=6pMGnZxiQccMUFNO18dbUc8luQrhNKa-XVCc1y_YlGg=
>>
>> [4] 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_spark_blob_v2.0.0_mllib_pom.xml-23L120=CwIFAg=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY=apxAyRJMc-jDvRpVzA6wFnuOjlNtFUKev9nXgiv79DM=
>> [5]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_spark_blob_v2.0.0_docs_ml-2Dguide.md-23dependencies=CwIFAg=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY=yFa0G6qUiJpaZxKA--8iuH8m3hxgmutd-0ZD0B32268=
>>
>> [6] 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_spark_blob_v2.0.0_pom.xml-23L2414=CwIFAg=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8=USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY=3xSSyDcql0fPyGpmzCoVV4W8Zgv2yHzm_HhKNhQahko=
>>
>> [7] 
>>

Re: RYA-179 Review License / Copyright notices on Rya Artifacts

2016-09-14 Thread Puja Valiyil 
The indexer project has a set of configurable optional extension to Rya.  
Things like support for geosparql, support for free text indexing, and support 
for precomputed joins (which is where the fluo integration comes in).  These 
are extensions that by default are turned off.  They can really increase the 
data plume associated with some data, which is the main reason why.

In the original port into Apache, this project was only included if you 
specified that profile.  This was because we have traditionally considered 
those features experimental and they bring in a lot of possibly unwanted 
dependencies.  Aaron refactored it to not be optional when he was updating the 
pond to reference the Apache parent Pom.  
So no alternative, but functionality that a typical user may debatably not want.

Sent from my iPhone

> On Sep 14, 2016, at 8:05 PM, Josh Elser  wrote:
> 
> I would have said that this is only kosher when you have an alternative to 
> the incompatibly licensed software. Is the indexer actually optional (I don't 
> have enough context)? Are there ways for me to to indexing of the same type 
> of data that don't require use of these incompatible dependencies?
> 
> Billie might be able to provide some more context too.
> 
> Aaron D. Mihalik wrote:
>>> Could we revive the indexer profile again?
>> 
>> (tl;dr: Yes.  Mentors: Please correct us if we're wrong)
>> 
>> This might be a solution.  I found a couple similar cases with Apache
>> projects and discussions related to those cases.
>> 
>> Apache Flink integrated with Amazon Kinesis [1] and [2].  Note that Kinesis
>> is an optional profile, and it's well documented in the POM why it's
>> optional.
>> 
>> (Note that NiFi got around this by using Amazon's SDK for Java [3], which
>> is purely Apache 2.0)
>> 
>> Spark uses optional profiles to build artifacts based on LGPL
>> dependencies.  Spark has to built by the user to use netlib [4][5], Ganglia
>> [6], or Kinesis [6].
>> 
>> I think a profile will work, but I'd like to see it well documented (both
>> in the POM and manual) so that we never accidentally create a release with
>> these artifacts.
>> 
>> I was going to open a separate ticket to implement this, but I think it's
>> good to track all of this effort under RYA-177.
>> 
>> --Aaron
>> 
>> [1]
>> https://github.com/apache/flink/blob/release-1.1.2/flink-streaming-connectors/pom.xml#L69
>> [2]
>> https://github.com/apache/flink/blob/release-1.1.2/flink-streaming-connectors/flink-connector-kinesis/pom.xml#L73
>> 
>> [3] https://github.com/apache/nifi/blob/master/pom.xml#L1316
>> 
>> [4] https://github.com/apache/spark/blob/v2.0.0/mllib/pom.xml#L120
>> [5]
>> https://github.com/apache/spark/blob/v2.0.0/docs/ml-guide.md#dependencies
>> 
>> [6] https://github.com/apache/spark/blob/v2.0.0/pom.xml#L2414
>> 
>> [7] https://issues.apache.org/jira/browse/LEGAL-198
>> [8] https://www.gnu.org/licenses/lgpl-java.html
>> 
>> 
>> 
>>> On Wed, Sep 14, 2016 at 12:09 PM David Lotts  wrote:
>>> 
>>> Great find Aaron!
>>> The ESRI library is quite comparable!
>>> 
>>> Rya via Geomesa are using *JTS Topology Suite (*JTS): (the javadocs at
>>> vividsolutions seems to be 404 )
>>> 
>>> 
>>> http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/Geometry.html
>>> 
>>> Far from a drop-in replacement, but a path forward:
>>> http://esri.github.io/geometry-api-java/javadoc/
>>> 
>>> Interesting, ESRI has Shape file support, but no GML, the opposite of JTS!
>>> david.
>>> 
>>> 
>>> On Wed, Sep 14, 2016 at 10:29 AM, Aaron D. Mihalik<
>>> aaron.miha...@gmail.com>
>>> wrote:
>>> 
 Yeah, that sounds possible. I don't like the idea of having to maintain
 another build/ci/release process, though.
 
 More importantly, we'd also have to modify our GeoIndexer interface [1]
>>> to
 something Apache Friendly.  It looks like Ersi puts out an Apache 2.0
 library [2].
 
 [1]
 https://github.com/apache/incubator-rya/blob/master/
 extras/indexing/src/main/java/mvm/rya/indexing/GeoIndexer.java
 [2] https://github.com/Esri/geometry-api-java
 
> On Tue, Sep 13, 2016 at 10:36 PM Jim Hughes  wrote:
> 
> Hi Aaron,
> 
> Thanks, wasn't finding that list quickly...
> 
> It sounds like the GeoMesa/GeoTools usage might fall under this Q/A:
> http://www.apache.org/legal/resolved.html#optional.
> 
> Thoughts?
> 
> Jim
> 
>> On 9/13/2016 9:25 PM, Aaron D. Mihalik wrote:
>> Jim,
>> 
>> We've been working off of these lists:
>> 
>> http://www.apache.org/legal/resolved.html#category-a
>> 
>>> On Tue, Sep 13, 2016 at 6:07 PM Jim Hughes  wrote:
>>> 
>>> Hi David,
>>> 
>>> A number of the geo-dependencies are likely from the geo-indexing
 (which
>>> uses GeoMesa (Apache 2.0) which uses GeoTools and JTS).
>>> 
>>> Are there options to make the geoindexing a