Discussion:
The "regex" module brings in GPLv3 code even with --lgpl
(too old to reply)
Ævar Arnfjörð Bjarmason
2017-05-08 10:38:03 UTC
Permalink
Raw Message
The regex.c module depends on regex_internal.h, which depends on
intprops.h, which depends on verify.h, which is GPLv3, not LGPL like
the rest of the regex module.

I'm using the equivalent of the patch at the end of this E-Mail to
import the engine into a GPLv2 only project, but this seems like a
general bug in gnulib.

$ git diff -U2
diff --git a/lib/intprops.h b/lib/intprops.h
index c31a455e4..c14c90ea7 100644
--- a/lib/intprops.h
+++ b/lib/intprops.h
@@ -22,5 +22,7 @@

#include <limits.h>
+#if 0
#include <verify.h>
+#endif

/* Return a value with the common real type of E and V and the value of V. */
@@ -78,4 +80,5 @@
#endif

+#if 0
/* This include file assumes that signed types are two's complement without
padding bits; the above macros have undefined behavior otherwise.
@@ -99,4 +102,5 @@ verify (TYPE_MAXIMUM (long long int) == LLONG_MAX);
verify (TYPE_WIDTH (unsigned int) == UINT_WIDTH);
#endif
+#endif

/* Does the __typeof__ keyword work? This could be done by
Paul Eggert
2017-05-08 17:39:34 UTC
Permalink
Raw Message
Thanks for reporting that. I installed the attached, which I hope fixes
the problem.
Ævar Arnfjörð Bjarmason
2017-05-08 17:57:11 UTC
Permalink
Raw Message
Thanks for reporting that. I installed the attached, which I hope fixes the
problem.
Great, that looks much better than my monkeypatch & solves the
problem. I.e. no GPLv3 header dependency anymore.
Bruno Haible
2017-05-08 19:09:47 UTC
Permalink
Raw Message
Hi Paul,

The modules
argmatch
count-leading-zeros
c-vasnprintf
dfa
exclude
fma
fmaf
fmal
ino-map
i-ring
malloca
mbrtowc
mbsinit
mktime
nanosleep
parse-datetime
pipe2
relocatable-prog-wrapper
sleep
stat
strerror
strtoimax
strtoumax
unistdio/u8-u8-vasnprintf
unistdio/u8-vasnprintf
unistdio/u16-u16-vasnprintf
unistdio/u16-vasnprintf
unistdio/u32-u32-vasnprintf
unistdio/u32-vasnprintf
unistdio/ulc-vasnprintf
utimecmp
vasnprintf
xbinary-io
also depend on 'verify'. It is perfectly OK to do compile-time verifications in
a non-tests module.

Bruno
Paul Eggert
2017-05-08 23:33:03 UTC
Permalink
Raw Message
Post by Bruno Haible
It is perfectly OK to do compile-time verifications in
a non-tests module.
Thanks, in hindsight the change isn't needed for Gnulib. However, the
change also helps in another thing I'd like, which is to encourage the
use of intprops.h in glibc internals and the like, and where I'd rather
not have to also assume verify.h. So I think I'll leave in the change,
just for intprops.
Bruno Haible
2017-05-08 18:22:24 UTC
Permalink
Raw Message
Hi Ævar,
Post by Ævar Arnfjörð Bjarmason
The regex.c module depends on regex_internal.h, which depends on
intprops.h, which depends on verify.h, which is GPLv3, not LGPL like
the rest of the regex module.
verify.h is under LGPLv2+. As described in
<https://www.gnu.org/software/gnulib/manual/html_node/Copyright.html>
the license for gnulib modules is written in the module description file,
'modules/verify' in this case.

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.

Bruno
Ævar Arnfjörð Bjarmason
2017-05-08 18:47:23 UTC
Permalink
Raw Message
Post by Bruno Haible
Hi Ævar,
Post by Ævar Arnfjörð Bjarmason
The regex.c module depends on regex_internal.h, which depends on
intprops.h, which depends on verify.h, which is GPLv3, not LGPL like
the rest of the regex module.
verify.h is under LGPLv2+. As described in
<https://www.gnu.org/software/gnulib/manual/html_node/Copyright.html>
the license for gnulib modules is written in the module description file,
'modules/verify' in this case.
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; find /tmp/rx.tmp/
-name 'verify.h' -exec head -n 20 {} \;
gnulib-tool (GNU gnulib 2017-05-07 19:09:25) 0.1.1330-eb5c6
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Bruno Haible, Paul Eggert, and Simon Josefsson.
configure.ac:8: installing 'build-aux/compile'
configure.ac:4: installing 'build-aux/install-sh'
configure.ac:4: installing 'build-aux/missing'
gllib/Makefile.am: installing 'build-aux/depcomp'
parallel-tests: installing '../build-aux/test-driver'
/* Compile-time assert-like macros.

Copyright (C) 2005-2006, 2009-2017 Free Software Foundation, Inc.

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.

---cut---

It still produces the same output but with Paul's d9c44b2b3 the header
dependency isn't there anymore.

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?

I'm using gnulib-distributed files in a project that doesn't use the
autoconf/automake/m4 macros gnulib seems to expect any project that
wants to use it to use. So currently I've just been copying the
relevant files from gnulib.git manually.

But if the license header in the files themselves can't be trusted,
and instead the license is really in some other file that method isn't
so good anymore.

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?
Bruno Haible
2017-05-08 19:43:08 UTC
Permalink
Raw Message
Post by Ævar Arnfjörð Bjarmason
Post by Bruno Haible
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.
---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.
Post by Ævar Arnfjörð Bjarmason
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.
Post by Ævar Arnfjörð Bjarmason
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.
Post by Ævar Arnfjörð Bjarmason
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.
Post by Ævar Arnfjörð Bjarmason
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
Ævar Arnfjörð Bjarmason
2017-05-09 07:26:16 UTC
Permalink
Raw Message
Post by Bruno Haible
Post by Ævar Arnfjörð Bjarmason
Post by Bruno Haible
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.
---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.
Post by Ævar Arnfjörð Bjarmason
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.
Post by Ævar Arnfjörð Bjarmason
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.
Post by Ævar Arnfjörð Bjarmason
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.
Post by Ævar Arnfjörð Bjarmason
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.

Loading...