Re: [Bug-gnulib] missing licenses in gnulib / m4

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> But since *.m4 files are often copied from one module to another,

Isn't this much like saying source code is often copied from one *.c
file to another?  The FSF can do this, even if the code movement
crosses the LGPL/GPL boundary, since the FSF has the copyright.  It
shouldn't be a real problem in practice, if we do a similar thing for
*.m4 files.

>> The question here is whether these m4 files are more like Emacs's .el
>> files, or more like Autoconf's m4 files.
>
> They are more like Autoconf's m4 files, IMO.

If we want to migrate some of that code into Autoconf, that would be
fine.  We can change the license then, as the FSF owns the copyright.
In the meantime, the m4 files are useful only for GPLed packages, so
the GPL is appropriate and is the more-conservative choice.

> But we certainly want to have the license clause to be as clear as possible,

If we distribute GPLed modules under the terms of the GPL, that's
pretty clear.  It's somewhat more confusing if some of the module
is GPLed and the rest is distributed under different terms.

> The question does come up: The vim author doesn't want to use *.m4 files
> from GNU because he thinks it would infect vim with GPL. So he makes up
> his own autoconf tests for iconv() and gettext(), which then don't work
> on half of the platforms or in half of the configurations.

The gettext module is LGPLed.  vim-like issues shouldn't arise in a
GPLed module, since the source code is GPLed and people who are
worried about "infection" won't use it.

I realize that having some .m4 files under the GPL, and others under a
more-permissive license, is confusing.  But this sort of confusion is
inevitable in a mixed-license software group like gnulib.  The GNU
project purposely tries to lean in the GPL direction, and discourages
the use of the LGPL.  Since we already have to deal with the problem
with .c files, we might as well use a similar solution for .m4 files.