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. Many members of the gcc community, including myself, think they are very important. The FSF doesn't want plugins because they are concerned that people will start distributing proprietary plugins to gcc. I personally think this is a fear from twenty years ago which shows a lack of understanding of today's compiler market, but, that said, the FSF wants to cover themselves for the future as well. 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? It's not an easy problem to solve. Using the runtime library license to solve it is a nice little bit of legal jujitsu. Presumably we could go ahead and use a simple runtime library license, similar to the existing one, which doesn't address the plugin issue. But we still want plugins, and then how do we get them? Separating the problems doesn't make them easier to solve. You are clearly right that the runtime license is potentially damaging to the GCC community. However, it's not like the people working on this are stupid, and it's not like they are going to force it on everybody without accepting comments. So I think it's premature to worry overly much about this. The FSF has not yet made a major licensing mistake. Ian