Re: gnulib-tool --lgpl doesn't convert gplv3 to lgplv2.1

[Bruno Haible]

Hi Simon,

> > In the current situation (where we care about the distinction between
> > LGPLv2+ and LGPLv3+ but where GPL means GPLv3+ always),
> 
> That hasn't been clear to me: GnuTLS still uses GPLv2 for compatibility
> with other GPLv2 applications/libraries, and we can't (and don't) use
> GPLv3 gnulib modules.  Several files in gnulib have GPLv3 headers, and
> several have GPLv2 headers.  I see nothing in the gnulib manual that
> discusses this.

The doc (doc/gnulib-intro.texi section "Copyright") says that the header
in the file is irrelevant since the copyright is given by the modules file.

The gnulib modules that I see used in GnuTLS (specifically directory lgl/)
are all covered by LGPLv2+:

$ grep GPL alloca-opt crypto/arcfour crypto/arctwo vasnprintf vasprintf 
crypto/des float crypto/gc-pbkdf2-sha1 gettext-h crypto/hmac-md5 
crypto/hmac-sha1 crypto/md2 crypto/md4 crypto/md5 memmem memmove memxor minmax 
read-file realloc crypto/rijndael crypto/sha1 size_max snprintf stdbool stdint 
stdio stdlib string strverscmp sys_socket sys_stat time time_r unistd wchar 
xsize 
alloca-opt:LGPLv2+
crypto/arcfour:LGPLv2+
crypto/arctwo:LGPLv2+
vasnprintf:LGPLv2+
vasprintf:LGPLv2+
crypto/des:LGPLv2+
float:LGPLv2+
crypto/gc-pbkdf2-sha1:LGPLv2+
gettext-h:LGPLv2+
crypto/hmac-md5:LGPLv2+
crypto/hmac-sha1:LGPLv2+
crypto/md2:LGPLv2+
crypto/md4:LGPLv2+
crypto/md5:LGPLv2+
memmem:LGPLv2+
memxor:LGPLv2+
minmax:LGPLv2+
read-file:LGPLv2+
realloc:LGPLv2+
crypto/rijndael:LGPLv2+
crypto/sha1:LGPLv2+
size_max:LGPLv2+
snprintf:LGPLv2+
stdbool:LGPLv2+
stdint:LGPLv2+
stdio:LGPLv2+
stdlib:LGPLv2+
string:LGPLv2+
strverscmp:LGPLv2+
sys_socket:LGPLv2+
sys_stat:LGPLv2+
time:LGPLv2+
time_r:LGPLv2+
unistd:LGPLv2+
wchar:LGPLv2+
xsize:LGPLv2+

LGPLv2+ is compatible with GPLv2, therefore you are fine. Or what else are
you talking about?

> GnuTLS could theoretically use GPLv3 modules in the command line tools,
> and use GPLv2 modules for the GPL'd library.  I don't think there is a
> problem in using GPLv3 for the command line tools.  But right now there
> hasn't been any need for GPLv3 modules in the command-line tools only.
> It makes things more complex to distribute both GPLv2 and GPLv3 copies.
> So if possible the simplest is to only use GPLv2 gnulib modules in
> GnuTLS.

The complexity of distributing a library under one license and the
corresponding tools under another license is very manageable. I do this
for libiconv and gettext. You distribute both COPYINGv2 and COPYINGv3, and
add a statement to the README, saying that the library is under GPLv2 and
the tools are under GPLv3.

> > what is needed is that the option --lgpl takes an argument: --lgpl=2
> > means to convert to LGPLv2+, whereas --lgpl or --lgpl=3 means to
> > convert to LGPLv3+.
> 
> And --gpl=2 and --gpl=3 flags too?

You are saying that you don't have "any need for GPLv3 modules in the
command-line tools" so far. So why bother introducing an option that
affects only an empty set of modules?

> > Pieces of gnulib-tool affected: command line parsing, usage message,
> > reading and writing of the configuration, sed_transform_lib_file,
> > verification of license (lines 2210..2220).
> 
> I think we need to decide exactly how this should work, then we could
> try and solve it.  Some questions:
> 
> What license headers should gnulib *.[hc] files have?  GPLv3?

Yes, GPLv3 (at least until Brett and Paul have finished discussing the issue
that Brett has with it).

Bruno