[
https://issues.apache.org/jira/browse/LUCENE-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610056#comment-14610056
]
Nicholas Knize commented on LUCENE-6607:
----------------------------------------
(I'm not a lawyer so this is added purely for discussion purposes)
com.spatial4j.core.shape.jts.* imports com.vividsolutions.jts.geom.*
The POM marks JTS as optional, the code comment notes:
{code}
/**
* Wraps a JTS {@link Geometry} (i.e. may be a polygon or basically anything).
* JTS does a great deal of the hard work, but there is work here in handling
* dateline wrap.
**/
{code}
And effectively uses JTS for all DE9IM spatial relation computations (which is
quite expensive anyway).
The good news is, while JTS is still currently LGPL its my understanding that
Martin Davis is *close* to having this converted to dual EPL/BSD licensed under
the LocationTech umbrella. What very little I do know about the legal issues
for LGPL is from the license:
bq. Applications which link to LGPL libraries need not be released under the
LGPL. Applications need only follow the requirements in section 6 of the LGPL:
allow new versions of the library to be linked with the application; and allow
reverse engineering to debug this.
>From the early incubation site:
>http://incubator.apache.org/ip-clearance/local-lucene-solr.html
bq. There is a dependency on LGPL code that will be removed before release
Someone much more knowledgeable than me in the licensing area could provide
better insight. I'm under the impression wonky licensing issues and "wrapping
tricks" like this is one (of many reasons) core avoids dependencies altogether.
> Move geo3d to Lucene's sandbox module
> -------------------------------------
>
> Key: LUCENE-6607
> URL: https://issues.apache.org/jira/browse/LUCENE-6607
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
>
> Geo3d is a powerful low-level geo API, recording places on the earth's
> surface in the index in three dimensions (as 3 separate numbers) and offering
> fast shape intersection/distance testing at search time.
> [~daddywri] originally contributed this in LUCENE-6196, and we put it in
> spatial module, but I think a more natural place for it, for now anyway, is
> Lucene's sandbox module: it's very new, its APIs/abstractions are very much
> in flux (and the higher standards for abstractions in the spatial module
> cause disagreements: LUCENE-6578), [~daddywri] and others could iterate
> faster on changes in sandbox, etc.
> This would also un-block issues like LUCENE-6480, allowing GeoPointField and
> BKD trees to also use geo3d.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
