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

[Jose E. Marchesi]

ping @ licensing@gnu.org

> 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?