[geos-devel] GEOS Usage

Greg Troxel gdt at ir.bbn.com
Mon Oct 21 04:56:06 PDT 2013

Paul Ramsey <pramsey at cleverelephant.ca> writes:

> 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.

First, let me be clear that I'm not trying to tell you what to do.  I
have done portability testing, but don't consider myself one of the
copyright holders.  Also, I realize you in particular know most if not
all of what I'm saying, but I'm hoping it's helpful to have a larger

The LGPL's intent, as I see it (being a little fuzzy with details), is:

  1) the recipient of the library in binary or source form will receive
  the source, and will receive the source under the LGPL

  2) the recipient of the library and a proprietary program that uses
  the library will be able to make bug fixes to the library, and use
  that fixed version together with the proprietary program

I don't think the software freedom promised in (2) can be dismisssed as
theoretical, but I don't have an example (mostly because I pay nearly
zero attention to proprietary software that isn't professionally
relevant, and my field is networking -- geo is a hobby).

Point 1 remains important, even with a static linking exception.

My impression is that this entire discussion is happening because of
Apple's App Store terms.  There are two key points to them:

  static linking only, which is a valid technical argument trading off
  storage space and runtime RAM vs the complexity of managing

  there is no Free Software in the App Store, or perhaps more
  pedantically no Free Software can be obtained from the App Store,
  because those who obtain software are prohibited from installing it on
  more than N computers, from giving it to their friends, etc.

The desire to avoid dependency management does not actually require
static linking.  It merely requires specifying an exact version to link
against and allowing multiple versions to coexist.   PCBSD's pbi format
does something this, as I understand it.

A static linking exemption for a LGPL library would straightforwardly
allow a proprietary derived work that used static linking, but it will
would still require that the source be provided and that the recipient
have rights under the LGPL to modify and redistribute the source.  But
that is still inconsistent with the App Store terms.  The real issue is
that the App Store terms are inherently in conflict with any notion of
Software Freedom, and the conflict is not about static linking.

So if the copyright holders are small enough to be able to act as a
group, then one option is to change the license to permit App Store
distribution, while requiring source code to be distributed outside of
the Apple App store.  Another option would be to offer proprietary
licenses to use geos in App Store for a fee, and use that to fund free
software development.

Howard makes a good point about software being "routed around" by people
who wish to engage wth Apple's App Store and thus are precluded from
using GPL/LPGL libraries.  The GPL family has always had an explicit
realization of whether it was better to have more use under a less
restrictive (LGPL) license, or to be under a strong copyleft in order to
force the choice of using the library and placing the derived works
under copyleft or not using the library.  The advice was that essential
libraries for which there was not a lot of competition should have the
strong copyleft.

Where we are now is a situation where people want to use GEOS, and
wouldn't mind complying with the weak copyleft, but are claiming Apple
won't let them, yet they want to deal with Apple.  I personally would
not be inclined to yield on licensing for that reason (compromise isn't
a fair word; Apple isn't budging); it's a slippery slope to the end of

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20131021/c7f6b963/attachment-0001.pgp>

More information about the geos-devel mailing list