[RESULT] [VOTE] Release Rya (Incubating) version 3.2.10 RC1 Failed
Hello, The vote to release Rya (Incubating) version 3.2.10 RC1 has failed. The results are as follows: -1 (binding): Josh Elser, Adina Crainiceanu -1 (non binding): David Lotts, Caleb Meier Below is the list of JIRA tasks blocking successful release. These tasks should address the concerns raised during the voting process. All of these tasks are tracked on: RYA-184 Perform 3.2.10-RC2 Release https://issues.apache.org/jira/browse/RYA-184 (Blocker) RYA-189 Mongo Tests are failing RYA-177 Review License on Rya Dependencies RYA-186 Create dist.a.o/repos/dist/dev/incubator/rya and add KEYS RYA-187 Add "Incubating" to artifact names RYA-188 Add DISCLAIMER file RYA-169 MongoRya DAO/Examples are currently broken (Non Blocker, but potential inclusion) RYA-183 Run the example apps when automated tests are run RYA-178 Review RAT Exclusions RYA-179 Review License / Copyright notices on Rya Source Files RYA-180 Review Licensing of Shaded/War'd Rya Artifacts RYA-182 Review SCM Tag in Parent POM --Aaron
Re: RYA-179 Review License / Copyright notices on Rya Artifacts
Yeah, this is where I'm not 100% sure how to interpret this. I'm not sure if "optional" is interpreted as "there are other ways to do X" or if it's "X is not a core-feature of Rya". @Sean, do you know how this is supposed to be interpreted? Puja Valiyil wrote: I guess my point is that the average user doesn't want these capabilities. We removed the profile to make build process easier, but the main reason we had it to begin with was because they are optional extensions that can complicate licensing and add a lot of unwanted dependencies. The other option we have would be to swap geomesa with geowave [1]. Geowave has an apache 2 license [2] and so all the dependencies that brings in should be ok. We've talked about adding GeoWave support a lot, so I think that there is value outside of for licensing issues. I don't think it would be trivial to bring in GeoWave for Geomesa, so that might put cutting a release on hold for a while. [1] https://github.com/ngageoint/geowave [2] https://github.com/ngageoint/geowave/blob/master/LICENSE On Thu, Sep 15, 2016 at 12:46 AM, Meier, Caleb wrote: 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&d=CwIFAg&c=Nwf-pp4xtYRe0sCRVM8_ LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8&m= USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY&s= wnYDdDdgR8EEFav9sKC7ftd6ZjSJcOXU8FISG6jJMHc&e= [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&d=CwIFAg&c=Nwf- pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHC geo_4WXTD0qo8&m=USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY&s= ZFTL5gQzyzLvRcWrafGrCobMJ8d1DWSmZlIVz9M7EuQ&e= [3] https://urldefense.proofpoint.com/v2/url?u=https-3A__github. com_apache_nifi_blob_master_pom.xml-23L1316&d=CwIFAg&c= Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r= vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8&m= USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY&s= 6pMGnZxiQ
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 file for each module in the 'target/' folder[2]. The root target folder contains the aggregated list. I researched most of the ones tagged as '(Unknown license)'. We could possibly add something to the pom.xml to do an automatic file generation in our build to update the files. It's described in the plugin docs[1] . [1] http://www.mojohaus.org/license-maven-plugin/usage.html [2] ./target/generated-sources/license/THIRD-PARTY.txt This issue is a release blocker: RYA-177 Review License on Rya Dependencies 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: (LGPL) (OGC copyright) Open GIS Interfaces (org.geotools:gt-opengis:14.1 - no url defined) (LGPL) API interfaces (org.geotools:gt-api:14.3 - no url defined) (LGPL) DataStore Support (org.geotools:gt-data:14.1 - no url defined) (LGPL) Feature Based Graphs and Networks (org.geotools:gt-graph:14.3 - no url defined) (LGPL) Feature transforming feature source wrapper (org.geotools:gt-transform:14.1 - no url defined) (LGPL) GML2 XML Support (org.geotools.xsd:gt-xsd-gml2:14.3 - no url defined) (LGPL) GML3 XML Support (org.geotools.xsd:gt-xsd-gml3:14.3 - no url defined) (LGPL) Grid Coverage module (org.geotools:gt-coverage:14.3 - no url defined) (LGPL) Image I/O-Extensions - Custom Streams (org.geosolutions.imageio-ext:imageio-ext-streams:1.1.13 - no url defined) (LGPL) Image I/O-Extensions - GeoCore (org.geosolutions.imageio-ext:imageio-ext-geocore:1.1.13 - no url defined) (LGPL) Image I/O-Extensions - utilities classes and methods (org.geosolutions.imageio-ext:imageio-ext-utilities:1.1.13 - no url defined) (LGPL) Improved TIFF Plugin (org.geosolutions.imageio-ext:imageio-ext-tiff:1.1.13 - no url defined) (LGPL) JCalendar (com.toedter:jcalendar:1.1.4 - http://www.toedter.com/en/jcalendar/) (LGPL) JTS Topology Suite (com.vividsolutions:jts:1.13 - http://sourceforge.net/projects/jts-topo-suite) (LGPL) Main module (org.geotools:gt-main:14.1 - no url defined) (LGPL) Metadata (org.geotools:gt-metadata:14.1 - no url defined) (LGPL) OGC CQL to Filter parser (org.geotools:gt-cql:14.1 - no url defined) (LGPL) Process (org.geotools:gt-process:14.1 - no url defined) (LGPL) Process Feature (org.geotools:gt-process-feature:14.1 - no url defined) (LGPL) Referencing services (org.geotools:gt-referencing:14.3 - no url defined) (LGPL) Remote Tea Runtime (org.acplt:oncrpc:1.0.7 - http://remotetea.sourceforge.net/) (LGPL) Render (org.geotools:gt-render:14.1 - no url defined) (LGPL) Shapefile module (org.geotools:gt-shapefile:14.1 - no url defined) (LGPL) Vector grids (org.geotools:gt-grid:14.1 - no url defined) (LGPL) XML Parsing (org.geotools.xsd:gt-xsd-core:14.3 - no url defined) (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) (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) (MIT license for package cern.colt.* only) colt (colt:colt:1.2.0 - no url defined) -- this is a mistake, should be using: -- java.util.Arrays, not cern.colt.Arrays -- creating an issue to eliminate dependency. david. On Thu, Sep 15, 2016 at 9:34 AM, Jim Hughes wrote: > 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 > Processing Engine which is getting started to provide a better-licensed > alternative. There are a number of ways in which things are improving > (both license-wise and in terms of technology). > > Cheers, > > Jim > > > On 09/14/2016 03:35 PM, David Lotts wrote: > >> Jim, thanks for the clarity! So that is settled, we can't just wait for >> the wind to shift directions. :-) >> >> BTW, I see how several of the catago
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 Processing Engine which is getting started to provide a better-licensed alternative. There are a number of ways in which things are improving (both license-wise and in terms of technology). Cheers, Jim On 09/14/2016 03:35 PM, David Lotts wrote: Jim, thanks for the clarity! So that is settled, we can't just wait for the wind to shift directions. :-) BTW, I see how several of the catagory-X dependencies (of dependancies)* are removed -- thanks to https://github.com/locationtech/geomesa/blob/master/pom.xml : javax.media jai_codec There are a bunch of examples of this in the geomesa pom. david. On Wed, Sep 14, 2016 at 3:12 PM, Jim Hughes wrote: 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 < aaron.miha...@gmail.com> 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/ap
Re: RYA-179 Review License / Copyright notices on Rya Artifacts
Hi all, The two projects are very similar. I'd note that GeoMesa has an Apache 2 license as well [1], so that wouldn't be the main issue. Since this is a licensing issue, I'd point out that GeoMesa has been completely vetted through Eclipse's IP / license review process. GeoWave hasn't started that process at LocationTech. In my opinion, it might be useful to wait for them to work through their dependency list before sorting out an integration. The exclusions that David mentioned were due to working through Eclipse's process. The list of X licenses for Apache are also verboten in LocationTech land. Cheers, Jim 1. https://github.com/locationtech/geomesa/blob/master/LICENSE.txt On 09/15/2016 09:11 AM, Aaron D. Mihalik wrote: Geowave includes geotools [1] [1] https://github.com/ngageoint/geowave/blob/master/pom.xml#L208 On Thu, Sep 15, 2016 at 8:59 AM Puja Valiyil wrote: I guess my point is that the average user doesn't want these capabilities. We removed the profile to make build process easier, but the main reason we had it to begin with was because they are optional extensions that can complicate licensing and add a lot of unwanted dependencies. The other option we have would be to swap geomesa with geowave [1]. Geowave has an apache 2 license [2] and so all the dependencies that brings in should be ok. We've talked about adding GeoWave support a lot, so I think that there is value outside of for licensing issues. I don't think it would be trivial to bring in GeoWave for Geomesa, so that might put cutting a release on hold for a while. [1] https://github.com/ngageoint/geowave [2] https://github.com/ngageoint/geowave/blob/master/LICENSE On Thu, Sep 15, 2016 at 12:46 AM, Meier, Caleb wrote: 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&d=CwIFAg&c=Nwf-pp4xtYRe0sCRVM8_ LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8&m= USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY&s= wnYDdDdgR8EEFav9sKC7ftd6ZjSJcOXU8FISG6jJMHc&
Re: RYA-179 Review License / Copyright notices on Rya Artifacts
Geowave includes geotools [1] [1] https://github.com/ngageoint/geowave/blob/master/pom.xml#L208 On Thu, Sep 15, 2016 at 8:59 AM Puja Valiyil wrote: > I guess my point is that the average user doesn't want these capabilities. > We removed the profile to make build process easier, but the main reason we > had it to begin with was because they are optional extensions that can > complicate licensing and add a lot of unwanted dependencies. > The other option we have would be to swap geomesa with geowave [1]. > Geowave has an apache 2 license [2] and so all the dependencies that brings > in should be ok. We've talked about adding GeoWave support a lot, so I > think that there is value outside of for licensing issues. I don't think > it would be trivial to bring in GeoWave for Geomesa, so that might put > cutting a release on hold for a while. > > [1] https://github.com/ngageoint/geowave > [2] https://github.com/ngageoint/geowave/blob/master/LICENSE > > > On Thu, Sep 15, 2016 at 12:46 AM, Meier, Caleb > wrote: > > > 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&d=CwIFAg&c=Nwf-pp4xtYRe0sCRVM8_ > > LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8&m= > > USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY&s= > > wnYDdDdgR8EEFav9sKC7ftd6ZjSJcOXU8FISG6jJMHc&e= > > >> [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&d=CwIFAg&c=Nwf- > > pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHC > > geo_4WXTD0qo8&m=USEC4e6JdxuZZw
Re: RYA-179 Review License / Copyright notices on Rya Artifacts
I guess my point is that the average user doesn't want these capabilities. We removed the profile to make build process easier, but the main reason we had it to begin with was because they are optional extensions that can complicate licensing and add a lot of unwanted dependencies. The other option we have would be to swap geomesa with geowave [1]. Geowave has an apache 2 license [2] and so all the dependencies that brings in should be ok. We've talked about adding GeoWave support a lot, so I think that there is value outside of for licensing issues. I don't think it would be trivial to bring in GeoWave for Geomesa, so that might put cutting a release on hold for a while. [1] https://github.com/ngageoint/geowave [2] https://github.com/ngageoint/geowave/blob/master/LICENSE On Thu, Sep 15, 2016 at 12:46 AM, Meier, Caleb wrote: > 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&d=CwIFAg&c=Nwf-pp4xtYRe0sCRVM8_ > LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8&m= > USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY&s= > wnYDdDdgR8EEFav9sKC7ftd6ZjSJcOXU8FISG6jJMHc&e= > >> [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&d=CwIFAg&c=Nwf- > pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=vuVdzYC2kksVZR5STiFwDpzJ7CrMHC > geo_4WXTD0qo8&m=USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY&s= > ZFTL5gQzyzLvRcWrafGrCobMJ8d1DWSmZlIVz9M7EuQ&e= > >> > >> [3] https://urldefense.proofpoint.com/v2/url?u=https-3A__github. > com_apache_nifi_blob_master_pom.xml-23L1316&d=CwIFAg&c= > Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r= > vuVdzYC2kksVZR5STiFwDpzJ7CrMHCgeo_4WXTD0qo8&m= > USEC4e6JdxuZZwMB0AkZPzHtdsKWf8ep6g5BSRLQ2XY&s= > 6pMGnZxi
