GCC unplugged
GCC unplugged
Posted Nov 20, 2007 13:32 UTC (Tue) by rlk (guest, #47505)Parent article: GCC unplugged
I *hope* the FSF isn't making the mistake of deliberately crippling a product to hinder creation of closed plugins. That's implied here, although the article also notes that there's no record known of RMS actually stating that. Hopefully this is a misinterpretation. Deliberately crippling a product to manage usage is exactly what DRM (and other tactics) is all about: a business strategy grounded on restricting what users can do, which is antithetical to any principles of freedom that I'm aware of. Furthermore, if there is a real demand for a plugin architecture, it isn't going to work, because ultimately someone else will find a way to do it, and the FSF cannot prevent anyone else from doing this. It would simply lead to a hostile fork, which wouldn't do the free software community any good. egcs was basically a friendly fork; this would be more like the XFree86/Xorg situation, and we can see where that one ended up. It's one thing not going out of one's way to help would-be closed extensions (e. g. the Linux kernel not freezing the module API), but making technical decisions on affirmative grounds of blocking closed extensions crosses a line. If the GCC simply has more important things to do and doesn't have the time to implement something deemed to be of lesser importance then that's a valid technical decision. The problem would be if the decision is not based on technical merit or resource limitations, but rather a desire to inhibit certain uses of GCC. All that said, this is all second or third hand, and nobody seems to have an actual record of RMS, or anyone else who can speak for the FSF or GCC, actually stating that a plugin architecture should not be done because it would make proprietary extensions easier. Until there's any clear proof of that, we have to give the FSF the benefit of the doubt.
(Log in to post comments)
GCC unplugged
Posted Nov 20, 2007 14:33 UTC (Tue) by Lev (subscriber, #41433) [Link]
In response to: "All that said, this is all second or third hand, and nobody seems to have an actual record of RMS, or anyone else who can speak for the FSF or GCC, actually stating that a plugin architecture should not be done because it would make proprietary extensions easier. Until there's any clear proof of that, we have to give the FSF the benefit of the doubt." Please see: http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html "Anything that makes it easier to use GCC back ends without GCC front ends--or simply brings GCC a big step closer to a form that would make such usage easy--would endanger our leverage for causing new front ends to be free. Because of this, the GNU Project will in all probability not install such changes, should they be available. This statement reflects a firm conclusion based on a decade of thought."
GCC unplugged
Posted Nov 20, 2007 15:12 UTC (Tue) by nix (subscriber, #2304) [Link]
This *was* from seven years ago, and RMS's attitude is slowly evolving in this area (since it was obvious that a rigid approach to this would make it nearly impossible to do cross-translation-unit optimizations properly; the compiler has to be able to write out intermediate state in some form).
GCC unplugged
Posted Nov 21, 2007 19:44 UTC (Wed) by landley (guest, #6789) [Link]
Are you aware of a single instance where Stallman got _more_ flexible with time, instead of less? I'm honestly curious. Examples, please?
GCC unplugged
Posted Nov 22, 2007 0:41 UTC (Thu) by gdt (subscriber, #6284) [Link]
Two examples that spring to mind: the output of Bison can be used in non-free programs; and support for the GPL to BSD license change of Ogg Vorbis. I am sure there are more.
GCC unplugged
Posted Nov 22, 2007 10:15 UTC (Thu) by nix (subscriber, #2304) [Link]
Well, there's the case we were just discussing: RMS shifted from a strict 'no non-FSF-copyrighted code in GCC' to allowing it for ecj; he shifted from a 'no writing out internals' to allowing it for link-time optimizations... he's not completely dogmatic: if the choice is between useful free software that incorporates stuff copyrighted by other people or makes things easy for GPL violations, and between free software that lags behind and is outcompeted by other stuff, he has a track record of not taking the route that will kill the free software. You just have to convince him that this will happen unless he bends, which is kind of hard. (Part of this is probably the perfectly normal pride-in-project: nobody wants to see something they started get thrashed by something else if it can be avoided.)
GCC unplugged
Posted Nov 21, 2007 22:15 UTC (Wed) by Max.Hyre (subscriber, #1054) [Link]
Also from that e-mail:I ask anyone who would like to make such changes in GCC to please contact me privately. I would like to talk with you about the ideas you are interested in working on, to look at the magnitude of their potential benefits, and consider other possible ways of achieving them.So,
- he's not ruling it out completely, and
- in case anyone hasn't noticed, RMS is purely and always about freedom. He wants function, but it comes in second.
GCC unplugged
Posted Nov 22, 2007 2:39 UTC (Thu) by rlk (guest, #47505) [Link]
I'm certainly aware that RMS puts freedom first, and I personally agree with that priority in general. The classic example is DRM: while in the short term accepting the use of DRM gets us access to more movies or such, but in the long(er) run that comes with a high price, and it ultimately results in less function. Wasn't it Ben Franklin who said that those who sacrifice liberty for security soon find themselves with neither? This is a rather different situation, though; it's a case of deliberately restricting the capabilities of free software to prevent a certain type of use, which could be either free or non-free (this plugin interface would have substantial free use as well as potential non-free use). Leaving aside the fact that the FSF cannot prevent someone else from implementing this functionality, this kind of decision making seems a bit backward; it's denying people the freedom to implement free GCC plugins to prevent others from implementing non-free ones. Again, there are plenty of other reasons why the FSF might not implement this -- there might be higher priorities, or the specific proposed interface might have technical problems -- but this particular reason just strikes me as particularly unfortunate.