You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Ahmed Eldawy <as...@gmail.com> on 2013/05/06 01:57:29 UTC
Including JTS in an Apache project
Hi all,
I saw that Apache solr uses JTS (Java Topology Suite) [
http://www.vividsolutions.com/jts/JTSHome.htm] for supporting a spatial
data type [http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4].
Using JTS in an Apache project is not a straight forward thing as JTS is
licensed under LGPL which has some compatibility issued when included in an
Apache project. Now, I need to dome something very similar in another
Apache project (Pig [http://pig.apache.org/]) and I'm faced with the
licensing issue. I'm asking for your advice for the best way we can do to
use JTS without breaking the license issue. Does referring to JTS classes
from the code of an Apache project without actually including the classes
violate the license? Do we have to load the classes dynamically (using
Class#forName) or there is another way to do it?
Thanks in advance
Best regards,
Ahmed Eldawy
Re: Including JTS in an Apache project
Posted by Ahmed Eldawy <as...@gmail.com>.
Thanks Dave for the detailed response. As I understand, spatial 4j is a
separate project that acts as a plugin to solr and Lucene. However, it is
still licensed under Apache license. Does including it as is inside Lucene
or solr break the Apache license or you have it as a separate project for
another reason?
I took a loot at spatial 4j and it looks very nice. I like the idea that
you define your own interface and use JTS as another implementation for
that interface. However, I don't think I will be able to use it in Pig for
one reason. As per their website, JTS conforms with the OGC standard for
SQL [http://www.opengeospatial.org/standards]. It is important to follow
the OGC for the addition I'm proposing to Pig as it makes it more
acceptable in the GIS community which I'm targeting. I talked with people
from different industrial and research organizations and they all said that
they can only use it if it conforms with OGC standards just as JTS and
PostGIS [http://postgis.net/] do.
What I can do for now is to make this extension as a separate open source
project under the Apache license. However, as far as I understand, I cannot
merge this extension with Apache Pig unless we resolve the license issue.
Thanks
Ahmed
Best regards,
Ahmed Eldawy
On Sun, May 5, 2013 at 11:38 PM, David Smiley (@MITRE.org) <
DSMILEY@mitre.org> wrote:
> Hi Ahmed,
>
> I faced your conundrum with JTS early last year. As you know, the Apache
> Software Foundation doesn't like it's projects depending on GPL and even
> LGPL licensed libraries. The ASF does not have clear unambiguous language
> on how its projects can depend on them in a limited sense. Different PMCs
> (projects) have different standards. I've heard of one project (CXF?) that
> uses Java reflection to use an LGPL library. I think another downloads the
> LGPL library as part of the build, and then the code has a compile-time
> dependency (I could be mistaken). If memory serves, in both cases the
> dependency fit an optional role and not a core purpose of the software.
> The
> Lucene PMC in particular didn't formally vote to my knowledge but there was
> a time when it was clear to me that such approaches were not acceptable.
>
> The approach that the Lucene spatial developers took (me, Ryan, Chris) was
> to create a non-ASF project called Spatial4j that is ASL licensed.
> Spatial4j *optionally* depends on JTS -- it's only for advanced shapes
> (namely polygons) and for WKT parsing.
> https://github.com/spatial4j/spatial4j BTW, WKT parsing will be handled
> by
> Spatial4j itself in the near future without JTS. Spatial4j is not a subset
> of JTS; it critically has things JTS doesn't like a native circle (not a
> polygon approximation) and the concept of the world being a sphere instead
> of flat ;-) That's right, JTS, as critical as it is in the world of
> open-source spatial, doesn't have any geodetic calculations, just
> Euclidean.
> Spatial4j adds dateline wrap support to JTS shapes so you can represent
> Fiji
> for example, but not yet Antarctica (no pole wrap). So I encourage the
> Apache Pig project to take a look at using Spatial4j instead of directly
> using JTS for the same reasons that the Lucene project uses it. If you
> ultimately decide not to then please let me know why, as I see Spatial4j
> being an excellent fit for ASF projects in particular because of the
> licensing issue.
>
> So your statement "Apache Solr *uses* JTS" is incorrect. No it doesn't,
> and
> nor does Lucene; not at all. Instead, those projects use Spatial4j, which
> has an abstraction (Shape), and it has an implementation of that
> abstraction
> that depends on JTS. It also has implementations that don't depend on JTS.
>
> p.s. Last week I did a long presentation on Spatial in
> Lucene/Solr/Spatial4j
> and I'd be happy to share the slides with you. The organizers will but they
> haven't yet.
>
> ~ David Smiley
>
>
> Ahmed El-dawy wrote
> > Hi all,
> > I saw that Apache solr uses JTS (Java Topology Suite) [
> > http://www.vividsolutions.com/jts/JTSHome.htm] for supporting a spatial
> > data type [http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4].
> > Using JTS in an Apache project is not a straight forward thing as JTS is
> > licensed under LGPL which has some compatibility issued when included in
> > an
> > Apache project. Now, I need to dome something very similar in another
> > Apache project (Pig [http://pig.apache.org/]) and I'm faced with the
> > licensing issue. I'm asking for your advice for the best way we can do to
> > use JTS without breaking the license issue. Does referring to JTS classes
> > from the code of an Apache project without actually including the classes
> > violate the license? Do we have to load the classes dynamically (using
> > Class#forName) or there is another way to do it?
> > Thanks in advance
> >
> > Best regards,
> > Ahmed Eldawy
>
>
>
>
>
> -----
> Author:
> http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Including-JTS-in-an-Apache-project-tp4060944p4060969.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Including JTS in an Apache project
Posted by "David Smiley (@MITRE.org)" <DS...@mitre.org>.
Hi Ahmed,
I faced your conundrum with JTS early last year. As you know, the Apache
Software Foundation doesn't like it's projects depending on GPL and even
LGPL licensed libraries. The ASF does not have clear unambiguous language
on how its projects can depend on them in a limited sense. Different PMCs
(projects) have different standards. I've heard of one project (CXF?) that
uses Java reflection to use an LGPL library. I think another downloads the
LGPL library as part of the build, and then the code has a compile-time
dependency (I could be mistaken). If memory serves, in both cases the
dependency fit an optional role and not a core purpose of the software. The
Lucene PMC in particular didn't formally vote to my knowledge but there was
a time when it was clear to me that such approaches were not acceptable.
The approach that the Lucene spatial developers took (me, Ryan, Chris) was
to create a non-ASF project called Spatial4j that is ASL licensed.
Spatial4j *optionally* depends on JTS -- it's only for advanced shapes
(namely polygons) and for WKT parsing.
https://github.com/spatial4j/spatial4j BTW, WKT parsing will be handled by
Spatial4j itself in the near future without JTS. Spatial4j is not a subset
of JTS; it critically has things JTS doesn't like a native circle (not a
polygon approximation) and the concept of the world being a sphere instead
of flat ;-) That's right, JTS, as critical as it is in the world of
open-source spatial, doesn't have any geodetic calculations, just Euclidean.
Spatial4j adds dateline wrap support to JTS shapes so you can represent Fiji
for example, but not yet Antarctica (no pole wrap). So I encourage the
Apache Pig project to take a look at using Spatial4j instead of directly
using JTS for the same reasons that the Lucene project uses it. If you
ultimately decide not to then please let me know why, as I see Spatial4j
being an excellent fit for ASF projects in particular because of the
licensing issue.
So your statement "Apache Solr *uses* JTS" is incorrect. No it doesn't, and
nor does Lucene; not at all. Instead, those projects use Spatial4j, which
has an abstraction (Shape), and it has an implementation of that abstraction
that depends on JTS. It also has implementations that don't depend on JTS.
p.s. Last week I did a long presentation on Spatial in Lucene/Solr/Spatial4j
and I'd be happy to share the slides with you. The organizers will but they
haven't yet.
~ David Smiley
Ahmed El-dawy wrote
> Hi all,
> I saw that Apache solr uses JTS (Java Topology Suite) [
> http://www.vividsolutions.com/jts/JTSHome.htm] for supporting a spatial
> data type [http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4].
> Using JTS in an Apache project is not a straight forward thing as JTS is
> licensed under LGPL which has some compatibility issued when included in
> an
> Apache project. Now, I need to dome something very similar in another
> Apache project (Pig [http://pig.apache.org/]) and I'm faced with the
> licensing issue. I'm asking for your advice for the best way we can do to
> use JTS without breaking the license issue. Does referring to JTS classes
> from the code of an Apache project without actually including the classes
> violate the license? Do we have to load the classes dynamically (using
> Class#forName) or there is another way to do it?
> Thanks in advance
>
> Best regards,
> Ahmed Eldawy
-----
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/Including-JTS-in-an-Apache-project-tp4060944p4060969.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org