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

[Ævar Arnfjörð Bjarmason]

On Mon, May 8, 2017 at 9:43 PM, Bruno Haible <address@hidden> wrote:
> Æ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.

All makes sense. Thanks a lot for your help.