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
