I am a developer of the ELinks web browser, which was originally
licensed under GPLv2-or-later but has been GPLv2-only since
ELinks 0.10.0 (released on 2004-12-24).  It seems the licence of
libgcc in GCC 4.4.0 has been made incompatible with this.

In GCC 4.3.3, libgcc was licensed under GPLv2-or-later with extra


In the recent GCC 4.4 branch, this has been changed to
GPLv3-or-later with the rather complicated GCC Runtime Library
Exception version 3.1.  The GCC 4.4.0 release was then made under
these terms.


When I build ELinks with GCC 4.3.1, several functions from
libraries provided by GCC end up in the elinks executable:

- __divdi3, __moddi3, and __udivdi3 from libgcc.a
- __do_global_dtors_aux from crtbegin.o, and
- __do_global_ctors_aux from crtend.o.

The last two functions are defined in the aforementioned
crtstuff.c.  I don't know where the others are defined, or how
many inline functions get included from GCC header files.

Now suppose we build ELinks with GCC 4.4.0 and the Compilation
Process is Eligible as described in the GCC exception.  With the
GCC exception, the Free Software Foundation then appears to give
permission to distribute the resulting binary under terms of our
choice.  ELinks being licensed under GPLv2 only, those terms
would have to be GPLv2.

However, it seems to me that subsection 3. a) of GPLv2 requires
all the source code corresponding to the binary to be available
under GPLv2.  If some of the source code comes from libgcc and
that is under GPLv3-or-later, then that requirement of GPLv2
becomes difficult to satisfy.  The GCC exception only gives
permission to propagate output from the compiler; it does not
grant any permission on the source code.

GPLv2 section 3 has the "major components" exception but it does
not apply when "that component itself accompanies the
executable", which appears to be the case when e.g. Debian
distributes GCC and ELinks together.  So, my understanding is
that an elinks executable built with GCC 4.4.0 cannot be legally
distributed in this way.  Furthermore, dynamically linking ELinks
with libraries built using GCC 4.4.0 may be problematic too.

Is this analysis correct?

Is this an intended consequence of the GCC 4.4 licence change?

Might the FSF be willing to keep providing libgcc also under
GPLv2 (perhaps without any GCC-specific exception)?

Attachment: pgp5rgcubKGT7.pgp
Description: PGP signature

elinks-dev mailing list

Reply via email to