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
