I remember being somewhat excited about the "GCC Introspector" project, which was a modification of GCC that allowed it to dump XML from various stages of GCC. I also remember that it was very negatively received on various occasions. You can use this situation to find non-RMS examples.
By your own words, you've been working for three years on trying to get information out of GCC for use in other tools. Even if you have no intent of trying to attach proprietary back ends to GCC, you are working very hard to enable others to do so.
...
> I think the GCC list has to ask itself how long are we going to wait before addressing the issues at hand, and not just ignoring the problem to death.
As long as possible, because as long as there isn't a really clean way to attach proprietary front ends and back ends, people who are on the fence about going proprietary or submitting their code back will choose the latter.
(To note: James Michael Dupont, the person doing the work on Introspector, himself was perfectly fine with the licensing even being quite explicit that things attached to his XML data feeds would have to be themselves GPL. This was clarified, and people seemed to understand; however, his work was still being explicitly rejected as it could lead to proprietary backends.)
You still think that I think you're a bad guy. I don't.
Long-term, GCC is going to have to open up the interfaces.
Our current policy is that we don't accept patches that do
this, but we can't prevent others from doing it.
(Honestly, I'm not even certain this is the wrong attitude for the FSF to take, although it certainly is a futile one: you can always build in your own mechanisms to do this, or hell, use one of the new alternatives. It really seems somewhat important that the FSF has been around as long as they have been taking a stance that they refuse to water down; yes, it would be better if we all could work together without this kind of inanity, but the world isn't perfect.)
By your own words, you've been working for three years on trying to get information out of GCC for use in other tools. Even if you have no intent of trying to attach proprietary back ends to GCC, you are working very hard to enable others to do so.
...
> I think the GCC list has to ask itself how long are we going to wait before addressing the issues at hand, and not just ignoring the problem to death.
As long as possible, because as long as there isn't a really clean way to attach proprietary front ends and back ends, people who are on the fence about going proprietary or submitting their code back will choose the latter.
-- Joe Buck, http://gcc.gnu.org/ml/gcc/2002-02/msg01823.html
(To note: James Michael Dupont, the person doing the work on Introspector, himself was perfectly fine with the licensing even being quite explicit that things attached to his XML data feeds would have to be themselves GPL. This was clarified, and people seemed to understand; however, his work was still being explicitly rejected as it could lead to proprietary backends.)
You still think that I think you're a bad guy. I don't. Long-term, GCC is going to have to open up the interfaces. Our current policy is that we don't accept patches that do this, but we can't prevent others from doing it.
-- Joe Buck, http://gcc.gnu.org/ml/gcc/2002-06/msg01392.html
(Honestly, I'm not even certain this is the wrong attitude for the FSF to take, although it certainly is a futile one: you can always build in your own mechanisms to do this, or hell, use one of the new alternatives. It really seems somewhat important that the FSF has been around as long as they have been taking a stance that they refuse to water down; yes, it would be better if we all could work together without this kind of inanity, but the world isn't perfect.)