| |||||||||||
GCC unpluggedGCC unpluggedPosted Nov 21, 2007 22:15 UTC (Wed) by Max.Hyre (subscriber, #1054)In reply to: GCC unplugged by Lev Parent article: GCC unplugged 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,
(Log in to post comments)
GCC unplugged Posted Nov 22, 2007 2:39 UTC (Thu) by rlk (subscriber, #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.
|
|||||||||||