Comment by surrealize | Hacker News Reader

Comment by surrealize | Hacker News Reader

This message conflates two issues in an unfortunate way. One issue is the licensing of GCC, the other issue is the architecture of GCC (how modular it is).

No one is arguing that GCC should change licenses. But he seems to think that making GCC more modular would somehow make it less free:

> If GCC were to change from a free compiler into a platform for nonfree compilers, it would no longer serve the goal of freedom very well.

There are two embedded assumptions here. First, that making GCC more modular would result in people creating non-free compilers with it (presumably by connecting a non-free component with GCC using an IR rather than linking directly, to get around the GPL). And second, that such use would become more prevalent than just using GCC itself (which is what would "change" GCC from a free compiler into a platform for nonfree compilers).

I imagine a few people would use GCC components that way, if it became more modular. But would that use be a significant one? That's unknown. And would that use "no longer serve the goal of freedom"? If a large number of nonfree tools appear that generate and consume a GCC IR, that could boost GCC as well.

The GPL seems to be able to defend freedom just fine for all the other gnu software, even the modularly-architected projects. I don't see why it can't ultimately do the same for GCC.

I've seen the argument made that somehow RMS and the gcc developers are against making gcc more modular. Where is everyone getting that idea, because that's not what I'm reading.

Indeed, this quote from David Edelsohn in response to ESR seems to indicate they are interested in making the gcc more modular:

>GCC is working toward re-factoring its code base toward a more compositional approach for "toolification". One can look at presentations from the recent GNU Cauldron 2013 for discussion of the topic.

So what am I missing?

[1] -- http://gcc.gnu.org/ml/gcc/2014-01/msg00212.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."

http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html

That's 14 years old. The GP's message is from this year.

This is a good take on the deficiencies of Stallman's position here really.

Linus stands directly against this sort of idea - his whole take on licensing has always been that he wants to make sure people contribute code back if they modify it, but otherwise can include the kernel in whatever they want - which provides a similar benefit - more people using Linux kernels, more people likely to want to improve Linux kernels.

More people using GCC would be great - especially since any 'magic' blackbox components that became useful would start to expose their workings anyway since they'd have to speak to GCC.

>Linus stands directly against this sort of idea

Linus and the rest of the Linux kernel developers make it intentionally hard to keep out-of-tree modules working against the kernel for the same reason that GCC does, which is to have the code included into the main project where it will benefit all end users instead of having proprietary/out-of-tree modules/plugins which are available to a select audience.

I can't see how you can claim that Linus stands 'directly against this sort of idea'. They seem very much aligned to me.

That's a different problem - namely that they don't want to tie Linux to having a stable ABI.

The side-effect is that it makes it difficult to maintain out-of-tree modules, because people don't fix things as they edit the kernel (if it builds, it builds etc.)

No they are deliberately adding GPLONLY symbol restrictions to prevent proprietary linking with the kernel, which has nothing to do with keeping a stable ABI.

They can keep the ABI as unstable as they want while still allowing proprietary linking, they don't have to provide any maintenance help to proprietary vendors who wants to link to the kernel.

Reply on news.ycombinator.com