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
