Apple, iPhone, and GPLv3 troubles

Chris Lattner
Wed Sep 24 19:58:00 GMT 2008

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.


More information about the Gcc mailing list