additional license file in libffi source distribution?

additional license file in libffi source distribution?

[Anthony Green]

Several people have pointed out that 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.  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, and a short preamble included below.  IANAL, but my intent is to
make sure that nobody can credibly claim that libffi should be covered by
the GPL.  Any comments or suggestions on improving this?:

---- cut here ---------------------------------------
The libffi source distribution contains certain code that is not part
of libffi, and is only used as tooling to assist with the building and
testing of libffi.  This includes the msvcc.sh script used to wrap the
Microsoft compiler with GNU compatible command-line options, and the
libffi test code distributed in the testsuite/libffi.bhaible
directory.  This code is distributed with libffi for the purpose of
convenience only, and libffi is in no way derived from this code.

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

[text of GPLv2 redacted]
---- cut here ---------------------------------------

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?

Thanks,

AG

Re: additional license file in libffi source distribution?

[Bruno Haible]

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

Re: additional license file in libffi source distribution?

[Anthony Green]

I agree that these license scanning tools are problematic.   Fossology is
the one I'm familiar with, and it really dumbs things down to the point
that it is pretty much useless.  I hate the fact that I've even considered
removing GPL build-time tools in order to cater to these broken scanners.
I've reached out to Fossology a few times, but no response to date.

AG


On Tue, May 1, 2018 at 12:22 PM, Kaz Kylheku (libffi) <
382-725-6798@kylheku.com> wrote:

> On 2018-05-01 05:09, Bruno Haible wrote:
>
>> 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 think the combination is a bad idea.
>
> Organizations nowadays use scanning tools to classify the license of
> packages. If you have a GPL in there anywhere, the package may be falsely
> classified as GPL and people will leave it at that.
>
> Someone's program will end up being falsely regarded as "radioactive"
> because it depends on libffi.
>
> Nobody is going to manually inspect thousands of packages to pick apart
> which one of the included licenses actually applies to the executables.
>
>