Relicensing (most of) binutils/libctf to LGPLv3+?

[Nick Alcock]

When we contributed libctf to binutils, we made it GPL because we didn't
know of a use case for making it LGPL. Since then, however, a large
number of uses have turned out to need it, from uses in the kernel's
build system (GPLv2-only) all the way to use in libside to potentially
allow entirely arbitrary programs containing libside probes to translate
their own CTF info into the libside type system. These programs might be
licensed under anything at all.

It has become clear that at least the read side of libctf is really a
sort of compiler runtime library component: it's reading things GCC can
emit into arbitrary binaries, and surely those arbitrary binaries should
be allowed to read the type system describing their own code!

There is a split here that we should consider. libctf.so links against
libbfd, so it must remain GPLv3+, as does libctf/ctf-open-bfd.c: these
pieces implement ctf_open() and ctf_fdopen(), which read CTF out of an
executable object using libbfd.

But there is also libctf-nobfd.so, which does not include this feature
(specifically because some consumers don't need or want BFD). This
component uses nothing but libiberty (and on some platforms libz and
libintl). This, and its source constituents -- everything under libctf/
other than the build scripts and libctf-open-bfd.c, and
include/ctf{-api,}.h -- can be LGPLv3+'d without issue, and I think
should be.

The CTF generator in GCC obviously remains GPL, exactly as it is now.
This is purely about libctf.

(The only substantive contributors to non-build-system libctf pieces
since its integration into binutils are Cc:ed, or are reading
binutils@sourceware.org and thus will spot this mail anyway. I do hope
they don't object to this change, but if so, please do say.)

Is licensing@gnu.org happy with this idea?