Re: [Hamlib-developer] Licensing

[Nate B. <n0...@n0...>]

CC'ing the list as the discussion started there.

* On 2016 04 Sep 11:48 -0500, Black Michael wrote:
> I can't quite tell for sure but it appears to me that getopt can end
> up in libhamlib.soAt that point GPL takes over the library whether the
> functions are linked into an app or not since you're distributing a
> shared library with the routines in it.The libham.a with getopt file
> would be GPL...but if you did not link the GPL functions from the
> static lib your app would not inherit the license.That was one of the
> bad things about GPL which led to LGPL.

I honestly do not see the difference between the object code being in an
archive or the source file being in the same tarball as it is
essentially the same thing.  The source is human readable and the object
is machine readable.  Nothing magical happens to the license just
because a file is run through a compiler despite the fact the some seem
to claim otherwise.  To use the same logic would require that we
distribute the source files in separate tarball archives to avoid having
GPL sources in the same tarball as LGPL sources.  Such a claim is so
nonsensical that not even the GNU project does it.

> So...at the moment...my patch says if android or getopt or getopt_long
> then library is GPLV2 otherwise LGPL.

I strongly disagree.  Of course, I am not an expert in copyright law.

The fact is that we as original authors can license things as we wish.

If you feel as strongly about this issue as I do on the other side, then
I would be comfortable with the following compromise, we include a file
that declares that the files in question are not an integral part of
libhamlib.* and their inclusion in an object archive only results in
the objects derived from those specific files being licensed under the
GPL v 2 or later while the rest of the archive remains licensed under
the LGPL v 2.1 or later.

But, see below as well.

> If we move getopt.c into the tests directory and compile directly with
> the apps then only android causes a problem right now (I'm waiting to
> hear from Lada if we can switch to LGPL).

If your only intention is to statically link the files in question to
the apps that need them AND that those functions are then available when
otherwise not available on the host platform, then disregard the above
and proceed with your patch.  While the odds of finding a system without
the getopt/getopt_long functions are getting less these days, they're
out there and we should continue to support Hamlib on them as support
already exists.

> de Mike W9MDB

73, Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us