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 library exception. 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 case-by-case basis. Hope this helps. Ian
