Re: Including JTS in an Apache project

2013-05-06 Thread Ahmed Eldawy
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) 
dsmi...@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

Including JTS in an Apache project

2013-05-05 Thread Ahmed Eldawy
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

2013-05-05 Thread David Smiley (@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org