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.
pgpyWc8n9zRlB.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
