bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Simon Josefsson
Subject: Re: gnulib-tool --lgpl doesn't convert gplv3 to lgplv2.1
Date: Mon, 22 Oct 2007 08:12:42 +0200
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)

Bruno Haible <address@hidden> writes:

> 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.

Ok.

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

The GPLv2 part of GnuTLS uses some GPL'ed modules, in gl/:

address@hidden:~/src/gnulib/modules$ grep GPL arpa_inet error fdl gendocs 
getaddrinfo getline getpass gpl-2.0 inet_ntop inet_pton lgpl-2.1 
maintainer-makefile progname readline version-etc-fsf
arpa_inet:LGPLv2+
error:LGPL
gendocs:GPLed build tool
getaddrinfo:LGPLv2+
getline:LGPLv2+
getpass:LGPLv2+
inet_ntop:LGPLv2+
inet_pton:LGPL
maintainer-makefile:GPLed build tool
progname:GPL
readline:GPL
version-etc-fsf:GPL
address@hidden:~/src/gnulib/modules$ 

>> 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.

Ok.  I think that would solve all of the problems.

>> > 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?

If I need GPLv2 modules in the GPL'ed part of the library, the option
seems to be necessary.

However, by using a COPYINGv2+COPYINGv3, I believe I don't need any
gnulib modules under GPLv2.

>> > 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).

Is there any point in patching files to say GPLv3 consistency until the
discussion has finished?

/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]