[geos-devel] GEOS Usage

[Paul Ramsey]

To answer my question, reading through the discussion of LGPL linking,
it seems like the *theory* is that, with dynamic linking you can
*replace* the library underneath the proprietary code with one that
conforms to your wishes/desires, thereby continuing to exercise your
software freedom. Obviously, this is impossible w/ static linking.
Hopefully equally obviously, this never happens in practice.

P.

On Sun, Oct 20, 2013 at 12:21 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> Given that we're already OK with dynamic linking, why wouldn't
> continuing w/ LGPL with a linking exception be acceptable? The
> philosophy of the project remains the same, all we're doing is
> acknowledging a new technical use pattern as valid. I find it hard to
> get exercised about static vs dynamic linking. We already have plenty
> of proprietary dynamic linkers out there, why would be care about
> proprietary static linkers as some special case to avoid?
>
> P.
>
> On Sat, Oct 19, 2013 at 8:11 PM, Howard Butler <howard at hobu.co> wrote:
>>
>> 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
>>
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geos-devel