GCC unplugged [LWN.net]

GCC unplugged

Posted Nov 20, 2007 14:33 UTC (Tue) by Lev (subscriber, #41433)
In reply to: GCC unplugged by rlk
Parent article: GCC unplugged

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."

(Log in to post comments)

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 (subscriber, #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 (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.