[Proj] libproj4 license and related hassles

Charles Wilson proj at cwilson.fastmail.fm
Thu Nov 13 14:09:41 EST 2008

Gerald I. Evenden wrote:

> The GPL dilemma will arise again as I embark on building a better proj/lproj 
> mouse trap but in this case software requiring GPL licensed material is a 
> critical element of the program and cannot be simply edited out.

And this was the precise aim when the FSF began promoting the GPL even
for libraries -- when they renamed the "LGPL" from "Library GPL" to
"Lesser GPL".

They WANT to force clients of Free Software to themselves be Free.  And,
this forcing function works transitively -- existing projects that
depend on libproj4 will, in the future, suffer reduced functionality
compared to Free (that is, GPLed) applications.

This gives GPLed libproj4 clients a competitive advantage against
proprietary ones.

All part of the RMS plan.

Now, if you believe as RMS does that "All Software Should Be Free",
that's great. If you don't...or existing contractual and/or national
security considerations prevent you from "opening" your code...tough.

Disclainer: IANAL.

> My last comment relates to my pausing on the Wikipedia page related to the MIT 
> license ( http://en.wikipedia.org/wiki/MIT_license ) and the comment in the 
> second paragraph stating thst the MIT license is "GPL-compatible."  Not being 
> a lawyer I am note sure that I understand all of the ramification but I am 
> going to stop worrying about future encounters with GPL and consider any 
> problems between libproj4 and GPL non-existant.

"GPL-compatible" doesn't mean what you think it means.

By linking libproj4 against a GPL library, you are creating a "derived
work". Effectively, libproj4 as distributed is subject to the terms of
the GPL license.  There is nothing in the MIT license that prevents this
"effective re-licensing" -- therefore, the MIT license is "GPL-compatible".

OTOH, if libproj4 was using the original 4-clause BSD license, which
included this clause:
  3. All advertising materials mentioning features or use of
     this software must display the following acknowledgement:
     This product includes software developed by the <original
     project sponsors>.
Then you would NOT be allowed to use GSL -- because you would then be
creating a "derived work", and such derived works must satisfy the GPL.
Because the GPL does not allow the addition of restrictions beyond those
it already imposes, the advertising clause is incompatible, and you
would not allowed to distribute a "derived work" containing the 4-clause
BSD software (e.g. libproj4 in this example) and GPL software like the GSL.

So, in that example, you could modify libproj4 to require and use GSL --
but then NO ONE would be allowed legally to distribute binaries (unless
the binary was compiled in such a way as to disable all GSL usage).

>From WIKI: http://en.wikipedia.org/wiki/License_compatibility
"GPL compatibility

Many of the most common free software licenses, such as the original
MIT/X license, the BSD license (in its current 3-clause form), and the
LGPL, are "GPL-compatible". That is, their code can be combined with a
program under the GPL without conflict

[[[[ ed. THIS BIT IS KEY: ]]]]
(the new combination would have the GPL applied to the whole).

However, some free/open source software licenses are not GPL-compatible.
Many have strongly advocated that free/open source software developers
use only GPL-compatible licenses, because doing otherwise makes it
difficult to reuse software in larger wholes[4]."


Effectively, what you're proposing, Gerald, is to relicense libproj4 itself:
  compiled with full (GSL-dependent) functionality, libproj4 is for all
intents and purposes, GPLed as well. This has serious implications for
any clients of libproj4.

  compiled with crippled functionality, libproj4 is still MIT/X. But
this crippling ALSO has serious implications for any clients of libproj4.

Again, all part of the FSF/RMS plan...


More information about the Proj mailing list