[geos-devel] GEOS Usage

[Howard Butler]

On Oct 16, 2013, at 5:51 PM, Greg Troxel <gdt at ir.bbn.com> wrote:

> 
> Howard Butler <howard at hobu.co> writes:
> 
> You make a good point that a BSD-licensed geos equivalent would be
> useful to those who wish to create proprietary derived works.
> 
>> That this community is hostile to contribution from organizations such
>> as yours is an opportunity.
> 
> As I read the mail, people simply pointed out that the geos license
> (which can only be changed by agreement of *all* of the copyright
> holders) and the app store terms are inconsistent, so the notion of
> using geos in an iOS program and distributing it through Apple simply
> does not work.  I don't think this is hostile, but just a calm
> recognition of how the geos and Apple license terms interact.

I agree Apple's position isn't very nuanced, but it is easy to understand their desire to lay a clear boundary down so as to not put themselves in any sort of liability chain. 

> Specifically, I haven't seen any contributions rejected.
> 
> Given that, can you explain what you mean by "hostile to contribution"?

The hostile I'm referring to is the attitude of some GEOS developers that folks doing proprietary software development activities are freeloaders looking to profit off of their hard labor. The zealotry casts a long shadow, and some people choose not to participate because of this.

I would add that JTS (GEOS' parent in mind and spirit, if not body) is currently relicensing to BSD https://locationtech.org/proposals/jts-topology-suite This should open up the algorithmic heft of JTS to be spread around throughout all the other geometry algebra libraries without the detritus of faithfully porting all of the javaisms along the way. Plenty of work to catch up to GEOS to be sure, but it wouldn't be an effort of complete greenfield redevelopment.

>> Maybe you could get ESRI to release the C++ library on which
>> https://github.com/Esri/geometry-api-java is ported from under the
>> same Apache license :)
> 
> Indeed, that could on someone's TODO list, along with getting Apple to
> have app store terms that are consistent with the GPL :-)

As an aside, the App Store's position toward statically-linked, full-bodied executables ends up being the only sane one to take in platform-type deployments. Many of the cloud toolkits are going this way as well for compiled executables (give us the whole ball, dependent on libc/libc++ only). The LGPL is going to continue to rub up against this paradigm without linking exceptions, and libraries that are unable to grant this execution are going to be routed around.

Howard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20131019/a41ce778/attachment.pgp>