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

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

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

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

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

Here the method I used to find the licenses for dependencies, and below is reprint of the results with better wrapping: I used the license-maven-plugin[1] It does not require changes to the pom.xml. I just ran this command in the root. mvn license:aggregate-add-third-party It generated a

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

Hi David, Ayup. As I mentioned in another part of the thread, we had to exclude and work around category-X transitive dependencies. Eclipse and Apache both agree on many of the no-go licenses and only-if you must ones. Since you mentioned JAI, I'd note that there is a project called Raster

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

r.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 wh

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

f 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

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

; 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 &g

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

@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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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:

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

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