Re: [Hamlib-developer] Licensing

[Greg T. <gd...@le...>]

Nate Bargmann <n0...@n0...> writes:

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

I see where you are coming from -- that linking with a libham.a archive
which contains some GPL members does not, if one does not use the
functions in the GPL files, lead to a GPL executable.  A case, perhaps
slightly more arguable, can be made for the same situation with dynamic
linking.  The overall point is not about linking but about what
constitutes a "work based on the program".

All that said, it could be nice to avoid confusion by not having
GPL-proper files in libham.a, so that the library itself could be
treated entirely under LGPL, and thus understanding the situation would
be simpler.

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

I don't follow.  To distribute a library, one needs permission from all
the copyright holders, and if part of a library is GPL, that permission
is only granted if the entire library is licensed under the GPL.
Alternatively, I think you are saying that the inclusion of getopt
library is mere aggregation, and that one can license a .a library
piecewise, just like multiple programs on a CDROM.

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

As a more or less disinterested license geek (but IANAL, TINLA as
always), that sounds ok.

Part of the point is that getopt and getopt_long appear in many
operating systems, so programs that use the interface are not derived
From any particular implementation.

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

That sounds like the best answer to me; the test programs will be GPL
sometimes, but that shouldn't bother anyone, and there will be no
confusion about the licensing of the main hamlib library.

Also, NetBSD's libc (not derived in any way from glibc) has
getopt/getopt_long under a BSD license.  So another option, probably
more work than it's worth, would be to switch to that.


Somewhat separately, what platforms are known to actually need this?  I
wonder how reasonable it would be to just drop the getopt
implementation, but it sounds like it's not.

73 de n1dam