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

[Arsen Arsenović]

Hi Nick,

Nick Alcock <nick.alcock@oracle.com> writes:

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

Note that source files utilizing GPLv3+ APIs do not have to be GPLv3(+),
and can be LGPLv3+.  I have a preference for keeping all files GPLv3+,
but if that is not workable for whatever reason, keeping a uniform
license across the entire (sub)project might be desirable.
-- 
Arsen Arsenović
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 381 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20240919/523ad6d0/attachment.sig>