On Sep 24, 2008, at 10:50 AM, Ian Lance Taylor wrote:
I'm not speaking for Apple here, and I am not a lawyer. However, the
last draft of the runtime library exception clause (which is quite
old
by now) imposed licensing restrictions on the executables generated
by
GCC (due to linked runtime libraries) if you did certain things to
the
compiler. I'm personally very eager to see the final wording,
because
the draft I saw (again, which is old and has certainly changed) was
extremely aggressive.
I do not know what draft you saw, but I don't think I ever saw it,
unless we disagree on the meaning of "extremely aggressive."
In the general sense, you are most likely correct: if you modify gcc
by adding GPL-incompatible software used to generate code, it is
likely that you will not be granted any exception to the GPL when
using the runtime library. In other words, if you 1) add an
optimization pass to gcc using the (hypothetical) plugin architecture,
and 2) that optimization pass is not licensed under a GPL-compatible
license, and 3) you generate object code using that optimization pass,
and 4) you link that generated object code with the gcc runtime
library (e.g., libgcc or libstdc++-v3), then you will not be permitted
to distribute the resulting executable except under the terms of the
GPL.
Again, speaking for myself as an individual:
This was many months ago, and I did not retain a copy of the draft.
In any case, it doesn't really matter because the draft probably has
changed. However, the intent of pieces of the exception clause was
pretty much what you said above.
This does not of course affect LLVM, which is not under a
GPL-incompatible license.
Right. However, the wording I saw was much broader than just the
plugin model. It was vague and poorly worded, and you could interpret
it as saying that use of a non-GPL assembler or linker was also not
allowed to build or link the libraries.
My personal feeling on the matter is that it seems very strange to
talk about *compiler plugins* in the license for *runtime libraries*.
Considering that there are already widely available alternative
libraries (e.g. the apache stdc++ library and many others) it seems
potentially damaging to the GCC community to try to address the plugin
issue this way.
In any case, this thread should probably be killed, as we won't know
until the FSF publishes the final proposed wording what the end result
will be. I am (personally) looking forward to this, and I
(personally) wish that the FSF was a lot more transparent on this
issue, for the sake of the GCC community.
-Chris
