Chris Lattner <[EMAIL PROTECTED]> writes: > On Sep 24, 2008, at 12:57 PM, Ian Lance Taylor wrote: > >> Chris Lattner <[EMAIL PROTECTED]> writes: >> >>> 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. >> >> Here's the problem: the FSF doesn't really want to permit plugins. > >> So, how do we permit plugins while prohibiting proprietary plugins, >> and how do we do it while staying within the bounds of copyright law >> which is the basis of the GPL? > > Does the obvious answer work?: add it to the license that covers the > code in question. Specifically, I think that it would be much more > reasonable to add "plugin" wording to the license that covers the GCC > compiler code itself. This means that you couldn't use *GCC* if you > did something the FSF found objectionable, closing an easy > work-around.
This doesn't work, because it breaks out of the basic framework of copyright law. Nobody signs anything or accepts any terms in order to use gcc. The FSF wants to stop people from distributing proprietary binary plugins to gcc. The copyright on gcc does not apply to those plugins. If gcc got a new, non-GPL, license which attempted to control those plugins, that license would only be binding to the extent that people explicitly accepted it. There is no shrinkwrap EULA on gcc. Or, perhaps I should say, we could perhaps make that work, but we would give up other desirable properties of the current regime. Ian
