Re: [Hamlib-developer] Licensing

[Jae S. (K5JAE) <k5...@st...>]

I just downloaded the latest glibc source
(http://ftp.gnu.org/gnu/glibc/) and getopt.h is listed as LGPL.
Perhaps we just need to upgrade?

de Jae K5JAE

On Sun, Sep 4, 2016 at 12:21 PM, Nate Bargmann <n0...@n0...> wrote:
> 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
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer