Re: [Bug-gnulib] missing licenses in gnulib / m4
Bruno Haible <firstname.lastname@example.org> writes:
> Some m4 files are shared between GPLed and LGPLed packages,
Yes, and for these files the more-permissive license makes sense.
> and it is frequent to copy m4 macros from one file to another (much
> more frequent than copying source code between .c files).
The m4 files tend to be less-well-engineered than the source files,
and so it's more common to copy m4 code rather than share it. But in
principle, the stuff that is shared is either so large that it should
be split off into a separate m4 file (with a more permissive license,
if it needs to be shared among GPLed and LGPLed code) or so small
that it's not really copyrightable. So I don't think this undermines
the overall principle that GPLed modules should have GPLed m4 files.
> The purpose of the "special exception" clause is so that also non-GPLed
> packages can use autoconfiguration.
Yes. However, that purpose doesn't apply to GPLed modules, as they
can't be linked with non-GPLed packages.
> We want to encourage the use of configure scripts and of portable
That is an important goal, but (putting my RMS hat on :-) it is a
secondary one for the GNU project. The main goal is freedom, not
popularity. For example, the GNU project wants to encourage the use
of GNU Emacs Lisp too; but Emacs's .el files are GPLed nonetheless.
This is because, for .el files, the secondary goal of popularity
doesn't outweigh the primary goal of keeping derivative works free.
The question here is whether these m4 files are more like Emacs's .el
files, or more like Autoconf's m4 files. It is not a trivial
question: I don't see an easy decision either way. Being more
conservative, I'd prefer to use the GPL if there's reasonable doubt,
as we can always change it to a more-permissive license later.
Another possibility is that we could ask RMS for his opinion.
> I see this "special exception" clause mostly as a clarification: Since
> *.m4 files are never linked into executables or libraries, they could
> also be used in non-LGPLed packages. But if the license doesn't explicitly
> say so, the authors of such packages will be afraid to use it.
But for GPLed modules, this is intentional. We don't want people to
use GPLed modules in non-GPLed applications.