bug-gnulib
[Top][All Lists]
Advanced

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

Re: The "regex" module brings in GPLv3 code even with --lgpl


From: Bruno Haible
Subject: Re: The "regex" module brings in GPLv3 code even with --lgpl
Date: Mon, 08 May 2017 21:43:08 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-75-generic; KDE/5.18.0; x86_64; ; )

Ævar Arnfjörð Bjarmason wrote:
> > When you use the --lgpl option to gnulib-tool, it should replace the
> > copyright headers of the files accordingly. If not, that's a bug in 
> > gnulib-tool.
> 
> That wasn't  happening in the latest gnulib.git today:
> 
> ---cut---
> $ rm -rf /tmp/rx.tmp; ./gnulib-tool --version; ./gnulib-tool --lgpl 
> --create-testdir --dir=/tmp/rx.tmp regex >/dev/null

Well; I should have said "When you use the --lgpl option to gnulib-tool,
together with the --import / --add-import / --remove-import / --update
options". --create-testdir does not do this processing, because it's not
useful for a testdir.

> As an aside, is there a way to make gnulib-tool emit just the *.c &
> *.h files needed for e.g. the regex module in some target directory?

Well, you can "rm -rf glm4" after having run gnulib-tool. But this mode
of using gnulib-tool is not supported, because there is *plenty* of
autoconf macro processing that prepares the subsequent build.

> I'm using gnulib-distributed files in a project that doesn't use the
> autoconf/automake/m4 macros

In this situation I would suggest to create a subdirectory of the
project, with a configure.ac file of its own, just for building the
libgnu.a. This way, the configuration of the project stays the same
way as it is, i.e. the way the developers know it and like it, and
the subdirectory's Makefile.am and configure.ac deal only with gnulib.

> But if the license header in the files themselves can't be trusted

The license header in the files can be trusted _after_ you have used --lgpl
in combination with --import / --add-import / --remove-import / --update.

> Aside from me not finding some invocation to the tool that surely
> exists to do this, is there a reason the file in git wouldn't just
> have the most permissive license it's licensed under in the header
> itself?

The way we do the license handling in gnulib is the result of lengthy
discussions and lots of considerations. Of course your suggestion was
one of the approaches that were discussed, but it was not the one that
was adopted.

Bruno




reply via email to

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