[Proj] Geo Transfoms and calculations
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
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