According to the Apache documentation Adam pointed to, then JTS is a no-no. I'm not sure how the optionality (if that is a word), modifies this. I would probably read it as "the binaries that can be downloaded can't have it, but here are instructions on how to include it if you want to build it yourself", much the same way that GDAL does with other GPL libraries, like it's support for PDF using popplr. Any thoughts?
Joe On Mar 5, 2012, at 4:17 PM, Adam Estrada wrote: > http://www.apache.org/legal/resolved.html From there it looks like LGPL is > a definite no no...Does this mean that it can't be included as an option > when being built? > > Adam > > On Mon, Mar 5, 2012 at 4:09 PM, Joe White <[email protected]> wrote: > >> I think this would be a great addition to SIS. I did a cursory search on >> JTS and Maven and didn't turn up anything other than a feature request from >> 2008 asking for JTS to be added to iBiblio as a Maven repo. There may be >> some additional ugliness getting it and Maven working together, but it >> shouldn't be too bad, and there is already a request out there for it. >> >> Joe >> >> On Mar 5, 2012, at 3:30 PM, Adam Estrada wrote: >> >>> Hi Ryan! I for one would love to see this integrated in to SIS. The fact >>> that JTS is "optional" is a huge benefit for those who >>> could potentially need its capabilities. And yes...in time, there will be >>> an Apache version that resides in trunk but for now I like that there is >>> optional support for it. How do you propose that it gets built? Can JTS >>> install/build through Maven? I honestly have not looked through the JTS >>> sources. >>> >>> Adam >>> >>> On Mon, Mar 5, 2012 at 3:09 PM, Ryan McKinley <[email protected]> wrote: >>> >>>> Hello- >>>> >>>> We have been working for a while to build better spatial support into >>>> Lucene. While integrating with lucene, we separated out the core >>>> spatial code from the lucene specific stuff. Since the code has >>>> compile/test dependencies on JTS, we hosted it at github. See: >>>> https://spatial4j.com/ >>>> >>>> The code itself is ASL, but we want to enable complex polygon support >>>> for people who choose to include the LGPL library JTS. In time, there >>>> may be pure ASL polygon solutions. >>>> >>>> From previous discussions, my believe this is a non-starter for SIS. >>>> Is this accurate? Or should we investigate how this code can work >>>> together? >>>> >>>> Thanks >>>> Ryan >>>> >> >>
