GCC Runtime Library Exception doubt

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

http://gcc.gnu.org/viewcvs/tags/gcc_4_3_3_release/gcc/config/i386/linux-unwind.h?revision=143643&view=markup

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 future GCC 4.4.0 release seems likely
to be under these terms.

http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/gcc/config/i386/linux-unwind.h?revision=145866&view=markup
http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/COPYING.RUNTIME?revision=145866&view=markup
http://www.gnu.org/licenses/gcc-exception.html
http://www.gnu.org/licenses/gcc-exception-faq.html

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 I don't
see how that could apply when ELinks and GCC are being
distributed as part of the same operating system.

What to do?

(a) Find some creative interpretation that allows binaries to be
    distributed.

(b) Stop distributing binaries.  Well we don't have any at
    http://elinks.cz/ anyway.

(c) Keep compiling ELinks with older versions of GCC.

(d) Switch to some other compiler entirely.  Perhaps TCC, or the
    pcc in NetBSD, or LLVM.

(e) Relicense ELinks so it becomes GPLv3 compatible: most likely
    under GPLv2-or-later.  This would also allow using
    libsmbclient.  In the process, it might be feasible to add an
    exception for OpenSSL too.  (There are notes in AUTHORS about
    some people already allowing such relicensing.)

(f) Relicense ELinks so it becomes GCC compatible even though not
    GPLv3 compatible in general.  For example, add an exception
    saying that ELinks binaries can be distributed even if they
    contain compiler-specific library code whose source is not
    available under GPLv2, as long as that source is available
    under some other version of GPL.

(g) Convince the FSF to allow distributing GCC runtime library
    sources under some GPLv2 compatible licence.  I guess it
    can't be the same licence as in GCC 4.3.3 because of the
    perceived problem with plugins.  Plain GPLv2 without
    exceptions might have the best chance of being accepted by
    the FSF but it would also nullify any OpenSSL exception added
    to ELinks in the future.

(h) Make sure that ELinks does not use any libraries from GCC.
    With "gcc -Wl,-M", I'm seeing __divdi3, __moddi3, and
    __udivdi3 from libgcc.a; __do_global_dtors_aux from
    crtbegin.o; and __do_global_ctors_aux from crtend.o.

_______________________________________________
elinks-dev mailing list
[email protected]
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJ5lH2Hm9IGt60eMgRApRaAKDdGoyWt3yqnCSmbgkUjEu5YNDVmgCfW79Z
0kLVjXtCV3IrPj+y0PsKfSs=
=jBFB
-----END PGP SIGNATURE-----