Re: [Bug-gnulib] Any objection to changing from LGPL to GPL in gnulib?

[Jim Meyering]

Hmm... I like the idea of keeping them exactly the same as the ones
in libc (or wherever the master sources are), but do see your point.

What do you think about setting up a little framework
to check out the affected files from libc and to change
the copyright automatically?

Karl already has some scripts to compare what's in gnulib
with the `master' sources in other places.

Paul Eggert <address@hidden> wrote:
> Several gnulib modules (e.g., error.c, getopt.c) are taken from the
> GNU C library.  They are normally used in GNU applications like
> coreutils and diffutils, and in this normal use they should refer to
> the GPL.  However, the gnulib copies currently refer to the LGPL.
> This causes confusion; for example, coreutils currently ships with the
> LGPL'ed copies of these files, and these copies state "You should have
> received a copy of the GNU Lesser General Public License", but
> coreutils doesn't have a copy of that license.
>
> One way to work around the problem is for each maintainer to change
> the LGPL reference to a GPL reference when importing from gnulib.
> This is what I've done with diffutils, but it's a pain.
>
> Another way to work around this problem would be for coreutils etc. to
> ship a copy of the LGPL too, but this would be even more confusing,
> since people might incorrectly conclude that coreutils can be
> distributed under either the GPL or the LGPL.
>
> A simpler solution, and the solution that used to be used in the old
> days, is for the gnulib copies to refer to the GPL and not the LGPL.
> I think this solution makes the most sense, as applications that need
> LGPL'ed copies can get them directly from glibc.
>
> So would there be any objection if I changed these files to point
> to the GPL instead of the LGPL?
>
> The affected files are the following files under gnulib/lib:
>
> error.c
> getopt.c
> getopt.h
> getopt1.c
> obstack.c
> regex.c
> regex.h
> strdup.c
> strtoll.c
> tempname.c