Bruno Haible <[EMAIL PROTECTED]> 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.
