GCC Runtime Library Exception

[Ian Lance Taylor <iant at google dot com>]

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