db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Spatial Functionality
Date Wed, 07 May 2008 15:00:25 GMT
Hi Peter,

I asked the legal discussion list for advice on how to proceed. Ian 
Holsman, on the Lucene team, sent the following response. This may help 
you untangle the licensing issue. Please keep the Derby list informed so 
that we can  help out as necessary. Patrick's email is 
"Patrick.OLeary@corp.aol.com"

Thanks,
-Rick

Hi Rick.
I'd like to introduce you to Patrick. the maintainer of local lucene.
We're in the process of contributing locallucene 
http://www.nsshutdown.com/projects/lucene/whitepaper/locallucene.htm 
(waiting on some internal meetings with lawyers). One of the features 
they plan on adding is a ASL version of the geo spatial code. as they 
are also using the same library as you guys.

I thought you two might like an introduction as your probably doing the 
same kind of thing.

Regards
Ian


Peter Yuill wrote:
> Hi Rick,
> <Richard.Hillegas@Sun.COM> said:
>   
>> Peter Yuill wrote:
>>     
>>> Hi,
>>>
>>> I responded to a recent post on the derby-user list on this topic. I am
>>> working on a project to add spatial functionality to Derby through user
>>> created tables and procedures. I am interested in taking the next step
>>> and looking at incorporating spatial functionality in Derby.
>>>
>>> The biggest issue I see is one of licensing. The concept of 'spatial
>>> datatypes' might seem simple enough, but there is no real point without
>>> spatial functions to go with them. The Open Geospatial Consortium (OGC)
>>> http://www.opengeospatial.org published a standard set of these, and
>>> there are a handful of high grade open source implementations. There is
>>> a huge amount of work in these implementations, and they rely on very
>>> specialized expertise. In the Java world there is just one that has
>>> stood the test of time, the JTS Topology Suite
>>> http://sourceforge.net/projects/jts-topo-suite/ . However JTS is LGPL,
>>> and the prospect of re-engineering the functionality just to get an
>>> Apache 2.0 license is mind boggling. Even worse, two of the OGC spatial
>>> filters (Distance Within and Beyond) require Coordinate Reference System
>>> (CRS) transformation if the database features are stored in a geographic
>>> CRS. The obvious choice for that functionality is Geotools
>>> http://geotools.codehaus.org/ , again LGPL. The Apache web site
>>> indicates there are unresolved questions about the compatibility of
>>> Apache 2.0 and GPL. Does anyone have more information on the status of
>>> LGPL?
>>>   
>>>       
>> Hi Peter,
>>
>> Thanks for working on this valuable contribution. We can ask the 
>> legal-discuss list for advice about the licensing issues. Do you know 
>> which version of the LGPL is used by the geospatial work? A quick glance 
>> at the Geo Tools website indicated LGPL without specifying which 
>> version. There are apparently two versions (2.1 and 3) according to the 
>> Free Software Foundation: 
>> http://www.fsf.org/licensing/licenses/index_html#LGPL
>>     
>
> Both Geotools and JTS use LGPL 2.1
>
>   
>> Thanks,
>> -Rick
>>     
>>> One alternative is to take the route that MySQL went. Leave out all the
>>> secondary filtering and just support Minimum Bounding Rectangle (MBR)
>>> queries. However the same question keeps surfacing on the MySQL spatial
>>> list with monotonous regularity: when will MySQL get 'real' spatial
>>> functionality. Personally I think a user-space solution is preferable to
>>> a half-way solution like MySQL.
>>>
>>> Regards,
>>> Peter
>>>   
>>>       


Mime
View raw message