Hi Adam, It's not really about deprecation -- it's about the legal framework of Apache and the fact that it's not what the goals of the project are/were. Goals can evolve that's fine but that wasn't my goal when we set about on this effort.
See: http://wiki.apache.org/incubator/SpatialProposal for the rationale. Cheers, Chris On Mar 5, 2012, at 1:50 PM, Adam Estrada wrote: > Chris, > > Optional support today means that it could potentially be deprecated in > later releases, right? The same is true with including GDAL and Proj4. Both > of them are very liberally licensed but have to buckle down because of EPSG > support. Thoughts on that? > > Adam > > On Mon, Mar 5, 2012 at 4:47 PM, Mattmann, Chris A (388J) < > [email protected]> wrote: > >> Hi Greg, >> >> On Mar 5, 2012, at 1:33 PM, Greg Reddin wrote: >> >>> On Mon, Mar 5, 2012 at 3:17 PM, Adam Estrada <[email protected]> >> 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? >>> >>> I think it is a definite no no for "inclusion" in a project, meaning >>> we can't include any LGPL wok in SIS. But I think we are talking about >>> an optional dependency here. See the following blurb from the >>> above-linked page: >>> >>> "Can Apache projects rely on components whose licensing affects the >>> Apache product? >>> Apache projects cannot distribute any such components. However, if the >>> component is only needed for optional features, a project can provide >>> the user with instructions on how to obtain and install the >>> non-included work. Optional means that the component is not required >>> for standard use of the product or for the product to achieve a >>> desirable level of quality. The question to ask yourself in this >>> situation is: >>> >>> Will the majority of users want to use my product without adding the >>> optional components?" >>> >>> So, if I understand everything correctly, I don't see this as a >>> roadblock. It is possible that I don't understand it correctly though >>> :-) >> >> Unfortunately I do see it as a roadblock. The goal of SIS was to write >> a pure ALv2 licensed (or compatible) spatial library and toolkit, which >> in my mind does *not* include any dependencies (even optional) on >> LGPL components. >> >> As I understand it, in this case, JTS is providing the polygon support. >> Polygon support is something we'd really like to support in SIS, so >> to me, this dependency (though optional in e.g., Lucene) is a core >> feature of SIS and something most of the eventual users of the system >> would want. >> >> Cheers, >> Chris >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Chris Mattmann, Ph.D. >> Senior Computer Scientist >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >> Office: 171-266B, Mailstop: 171-246 >> Email: [email protected] >> WWW: http://sunset.usc.edu/~mattmann/ >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Adjunct Assistant Professor, Computer Science Department >> University of Southern California, Los Angeles, CA 90089 USA >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
