[Proj] Geo Transfoms and calculations

Charles Wilson proj at cwilson.fastmail.fm
Tue Jan 6 22:56:59 EST 2009

Gerald I. Evenden wrote:
> On Tuesday 06 January 2009 5:56:52 pm Charles Karney wrote:
>> Code your programs without readline but suggest that the user invoke
>> them with rlwrap(1) which intercepts the keyboard input and does the
>> readline magic on it.  E.g.,
>>     rlwrap proj +proj=utm +lon_0=112w +ellps=clrk66 -r
>>     45d15.55N -111d30
>>     ...
> rlwrap sounds interesting and I can download it to my Kubuntu but I see that 
> it uses readline and would be having the same problems as if I had included 
> readline within the program.  That is, the eventual user of the program is 
> still faced with GPL ... but with another package.

Nope -- there is no "infection" in this case: because your
program/library -- which is linked without any reference to a GPLed lib
(I'm ignoring gsl, for the moment) -- is a "separate work".

*rlwrap* is GPLed -- either intrinsically or by virtue of linking to
libreadline and thus being a "derived work" of readline.  So if you
wanted to distribute the rlwrap binary, you'd have to make available the
rlwrap sources.  If your rlwrap binary was linked to a static
libreadline, then you'd also have to make available the readline
sources.  But by virtue of being a separate executable from lproj, it
has no impact on lproj or libproj's license.

And if you simply tell your users "hey, that rlwrap utlity over there,
it makes using lproj a lot easier" -- no licensing implications with
that, either.

Separate executables == separate (e.g. not derived) works. Usually.
IANAL. etc. etc.

> OK.  I guess this solves the problem except for M$ users but what else do they 
> expect. ;-)

Dunno if rlwrap has been ported, but there is a readline port (and
pdcurses) over here:
so they are not completely out of hope.


More information about the Proj mailing list