Re: additional license file in libffi source distribution?

[Bruno Haible <bruno at clisp dot org>]

Hi Anthony,

> msvcc.sh and
> testsuite/libffi.bhaible are both covered by licensing terms that are
> different from the libffi license, and that we need to (a) remove them, or
> (b) include the license text.

Correct. Including the license text is sufficient because
  - build tools like msvcc.sh do not store copyrightable contents in the
    generated binaries,
  - the presence or absence of a test suite does not have an effect on the
    generated binaries.

> I'd rather include the license text (GPLv2),
> as they are convenient to bundle and maintain along with the libffi source
> code.   To that end, I just added a LICENSE-BUILDTOOLS file with the GPLv2
> license,

Regarding the libffi.bhaible: For the files
  test-call.c
  test-callback.c
  testcases.c
you may use
  * GPLv2+ with Copyright 1993-2017 Bill Triggs, Bruno Haible (as it is now),
or - at your choice -
  * the MIT/BSD license, as formulated in the LICENSE file, with
    "Copyright (c) 1996-2014  Anthony Green, Red Hat, Inc and others"
    replaced with
    "Copyright 1993-2017 Bill Triggs, Bruno Haible"

Bill Triggs and I are agreeing on this relaxed license on 2017-10-23, following
my offer in <https://sourceware.org/ml/libffi-discuss/2017/msg00023.html>.

However, the file alignof.h is from gnulib, thus under LGPLv2+ [1]. If you would
want it to be MIT/BSD licensed as well, you need to ask for it on the bug-gnulib
mailing list (relevant authors are Paul Eggert and me).

And then there's still the msvcc.sh...

> msvcc.sh an testsuite/libffi.bhaible are both distributed under the
> terms of the GNU GPL version 2, as below.

Inside testsuite/libffi.bhaible:
  - The *.c and *.h files are distributed under GNU GPL version 2 or later
    (GPLv2+).
  - The .exp file that you added is under GNU GPL version 3 or later (GPLv3+).

> I wonder about this because some tools, like config.sub and ltmain.sh say
> they are GPLv2 _except_ when bundled with other programs, in which case
> they assume the other program's license.   Why do they need to do that?

I think the FSF formulated it like this so that
  * on one hand, the licensing for packages that use Autoconf & Automake is
    clear to everyone, without need to consult a lawyer,
  * on the other hand, if config.sub and ltmain.sh ever get integrated in
    a new generation of build system, this new build system must be under GPL.
    It is one of the policies of the FSF to increase the use of the GPL
    whenever possible.

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/Copyright.html