|| ||Ian Lance Taylor <iant-AT-google.com>|
|| ||GCC Runtime Library Exception|
|| ||Fri, 30 Jan 2009 11:14:06 -0800|
|| ||Article, Thread
After the e-mail flurry, here is my personal summary of the issues
regarding the GCC Runtime Library Exception
(http://www.gnu.org/licenses/gcc-exception.html). I personally think
that this includes all the substantive issues which were raised,
though I understand that others may disagree.
* The definition of "Independent Module" does not appear to include
source code which neither requires the runtime library nor makes use
of an interface provided by the runtime library. This applies to a
lot of source code, such as code written originally in assembler.
It does not seem to be a goal of the exception to restrict the
combination of the GCC runtime library with source code which does
not use the library, provided of course that the source code in
question is compiled via an Eligible Compilation Process.
Therefore, it would seem useful to clarify that arbitrary source
code which is not based on the runtime library, does not use the
runtime library, and indeed has nothing to do with the runtime
library at all, fits the definition of an Independent Module.
* The gcj compiler, which is part of gcc, can compile Java byte code
into machine code. It is normal practice to generate the Java byte
code using a Java compiler which is not GPL compatible. That is,
the Java source code is compiled into Java byte code via a non-GPL
compiler, and then gcj is used to compile the Java byte code into
machine code. However, Java byte code is probably not a
"high-level, non-intermediate language". Therefore, this
combination of compilers is not an Eligible Compilation Process.
This means in effect that any binary generated in this way by gcj
does not fall under the Runtime Library Exception. This does not
seem to be a desirable consequence, as it severely limits the cases
in which gcj may be used.
One way to resolve this might be to say that a compilation process
is Eligible so long as the input to GCC was produced exclusively
using programs which are not themselves derived from GCC. I don't
think that this approach would weaken the goals of the runtime
Another way to resolve this might be to simply declare that for the
purposes of the exception, Java byte code is treated as a
high-level, non-intermediate language. I think this would be an
acceptable minimal approach, since there will always be very few
examples of intermediate representations which gcc can compile but
which are not generated by gcc.
* People raised questions about LLVM byte code or GIMPLE byte code.
In both cases it is normal for a tool to generate byte code, and
then for a compiler to compile that byte code into machine code.
The case of GIMPLE byte code seems clear to me: if the GIMPLE byte
code is generated by GCC, and then modified by a non-GPL-compatible
tool, then we do not want to permit the exception to apply. While
it is conceivable that other people will someday write tools other
than GCC which generate GIMPLE byte code, it remains the case that
GIMPLE is defined by GCC, and I don't see any reason to apply the
runtime library exception if the tools which generate the GIMPLE
byte code are not GPL compatible.
LLVM byte code is generated by LLVM, not gcc. The question here is
whether it is desirable to permit using LLVM to generate LLVM byte
code and to then use GCC to turn that byte code into machine code.
(It will not be desirable to apply the exception if GCC is someday
used to generate LLVM byte code, nor if LLVM is someday used as an
optimization plugin to GCC). This question is hypothetical, as I
don't know of any plans to create such a tool. Moreover, LLVM is in
any case licensed under a GPL-compatible license. That said, LLVM
byte code is clearly documented, is higher level than assembly
code,and some people write it by hand. Should it be treated as a
"high-level, non-intermediate language" or not?
If the Java byte code issue is addressed by saying that the
compilation process is Eligible so long as the input to GCC was
produced exclusively using programs which are not themselves derived
from GCC, then this issue is moot.
Otherwise, it may possibly to useful to try to clarify the
difference between a "compiler intermediate representation" and a
"high-level, non-intermediate language." Or, since this issue
remains hypothetical, it may be preferable to address it on a
Hope this helps.
to post comments)