The issue is not that the plugin wouldn't be gpl; it would. The concern is that the AST dumped is not code, but an artifact, and thus can be used by proprietary software and make proprietary software better.

I could write a program that compiles your gcc-produced AST for a new architecture, and not GPL it because the AST itself probably isn't GPL protected. That's the fear.

The fear that someone else might be "better" than you so you're intentionally going to make it impossible for them to even compete is a really dumb argument. Imagine if this was done in sports.

And that seems to have been the whole intention behind this. Make sure no non-GPL backend can be used because god forbid it's better than ours. The shame!

The fear isn't that there will be competition, it is that there will be competition that sits on your back for the first 90% of the marathon and then outsprints you on the final 400m.

You are free to compete, but have run the whole marathon.

> The fear that someone else might be "better" than you so you're intentionally going to make it impossible for them to even compete is a really dumb argument. Imagine if this was done in sports.

It is done in sports. Most sports forbid you from taking drugs that enhance your performance, or are seggregated by sex in order to account for the "natural" (?) unequal distribution of muscular mass across sexes, because we think these would be unfair advantages.

The idea here is that the big proprietary software companies are not playing on a level field, since they are not disclosing their source code. The GPL, as I understand rms's intentions, is designed to inhibit that advantage and force everyone to play fairly: if you take code, you must give back code.

I don't understand much about the particulars of this case, and public opinion seems to be heavily slanted against rms. Nobody seems to agree with him here, but he's been considered a fool in the past when he was more of a Cassandra. His positions usually come from past experiences he's had.

Someone else mentioned elsewhere in this thread that historically the fear was of Intel using gcc as a frontend for icc. Seeing how Intel still contributes code to gcc and how they still maintain icc and how they still love publishing non-free software, perhaps this is still a valid fear. Or perhaps everyone is just using LLVM already for this purpose and it's not likely they would use gcc instead. I don't know.

I don't want to cast an opinion on this case beyond what I've already said. Maybe rms is wrong or maybe he's right.

"if you take code, you must give back code."

That's not the intention. It's a forward mechanism, not a backwards one. If you distribute code to person/company/entity X then you must also distribute the source code, or provide a way for X to get the source code.

If you make changes but never distribute the code then you don't need to distribute your modified code to anyone. If you only provide a service then you don't need distribute the code to anyone. Even if you modify gcc, sell me a copy, and distribute the changed source code to me, that doesn't mean you or I need to give the changes back to the gcc project.

The "fear", as I understand it, is that the Linux kernel and gcc are the two biggest GPL-based projects. If gcc is diminished, then fewer people will be aware of, much less agree with or advance, the ideals of software freedom. The technical advantages of gcc are used as marketing for software freedom.

Hiding GNU projects behind commercial and proprietary solutions front-ends reduces the marketing. Hence also the issue about "GNU/Linux" as "Linux" diminishes the marketing of the GNU project.

While incidentally true and pursuant to his real goal, I don't believe this is his ultimate goal. His goal is, and always has been, to make sure that you as the user of the software built upon his work, are always capable of opening it up and looking under the hood, and making adjustments as you see fit.

Throw a proprietory module on the end which relies on his work but gets around the GPL, and you've lost that right. That's not acceptable to him.

I believe you've just restated what I wrote.

Quoting from the Free Software Definition page at https://www.gnu.org/philosophy/free-sw.html :

> You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist. If you do publish your changes, you should not be required to notify anyone in particular, or in any particular way.

There is nothing that obligates giving back code. Rather, that obligation is against the four freedoms of the free software. Hence, "if you take code, you must give back code" is not, as jordigh understood, one of rms's intentions.

True! Sorry, I was responding mostly to this phrase:

> If gcc is diminished, then fewer people will be aware of, much less agree with or advance, the ideals of software freedom. The technical advantages of gcc are used as marketing for software freedom.

"but he's been considered a fool in the past when he was more of a Cassandra."

But he's also now considered a fool in the past when he indeed turned out to be a fool. GNU has 3-4 marque projects, GCC etc., Gnu Emacs, userland, and HURD, and he has total control over at least the first two (and he personally has used the third only for ill, "GNU/Linux").

His stewardship of them has been all but catastrophic, he could have earned a lawsuit that he would have lost from how he started GNU Emacs (fortunately the rightsholders were menches). Both have had painful forks and are facing that again.

Intel is indeed moving to LLVM for this reason and being totally transparent about it.

From https://software.intel.com/en-us/blogs/2009/05/27/why-we-cho...

--- LLVM is distributed under the Illinois Open Source License, which is nearly identical to the BSD license and is very open for use both by open-source and proprietary projects. Some other projects, such as Open64, are licensed under more restrictive licenses like the GPL, which were not compatible with our own licensing model. ---

So, what RMS feared is exactly what's happening with Clang, and he's right in terms of pushing the GPL to prevent this sort of thing.

Now, whether or not this is actually bad is another question. Personally, I think this sort of bleeding between proprietary and open source ultimately improves the ecosystem as a whole.

The fear is not that proprietary code will become better than FOSS code. The fear is that proprietary code will become better than previously-existing proprietary code. RMS considers closed-source code to be so immoral, that open-sourcing code in a way that proprietary code may potentially derive some benefit from it is immoral.

GCC has multiple, rich ASTs that you can access by modifying (and freely distributing) the source, or you can build a plugin that access the AST through the API.

The debate hinges on a very subtle point: GCC does not commit to keeping the plugin API nor the AST structure stable between releases, making it difficult to maintain any software that relies on a specific shape of the plugin API or the ASTs.

And the absolute certainty that without getting buy-in from RMS, the API would be constantly changed to frustrate such a AST dumping API. Unless GCC and/or EMACS (using LLVM) gets forked. Again.

True, but it takes effort to change the API, and even if they did something obfuscatory to it automatically with every new version, it wouldn't be all that hard to write something that parses GCC's source code or compiles programs specifically designed to exercise the right paths - and grabs the right bits automatically; a meta-AST-extractor. Similar techniques are already in use for automatically generating wrapper code to handle interfacing to unstable APIs, so it's definitely possible.

I realise that such a system would probably scare the hell out of RMS, but he should know well enough that any obfuscatory changes are easily undone. In some ways, it's like the war between software protections and crackers - once the crackers developed tools to analyse and automatically bypass any local serial-number type protections, they solved the problem generally and DRM was forced to go online. I'd be interested to see what RMS would try if faced with such a solution...

Indeed, but that route requires forking GNU Emacs and earning RMS's eternal hostility, along with his fanbois and girls. Which I can attest is no fun (I worked for UniPress on the EMACS that he illicitly forked GNU Emacs from, I went from a LMI Lisp Machine ally, and later roommate when he started GNU, to a "Software Hoarder" (note UniPress shipped their Emacs with undistributeble source)). It's a very big thing to split one or more communities like that, a potentially fatal thing, and this discussion has brought out that GNU Emacs is already losing a lot of mind share in the otherwise sort of natural for it C and C++ communities.

One problem here is that RMS is not a C++ programmer (not an entirely unwise decision!), the languages he programs in, to the extent he does anymore, don't require this sort of thing, and apparently doesn't appreciate how this is a deal breaker for modern C++ programming. Or doesn't care, and how that's decreasing GCC mindshare as well.

Because of this policy with GCC, 99.999% plus of the the academic mind share is with LLVM, and the only thing keeping it from taking over is it's relative paucity of backends.

The only counter I have to "it wouldn't be all that hard to..." statements is that it is 2015, emacs can't even refactor things like xcode can do. And xcode is considered horrible by refactoring standards.

If it were so easy it would have happened by now. One can only conclude gcc and its stewardship have no real desire to allow for such a thing to occur at all.

Which means llvm will likely be the future for being able to handle large complex code bases and interactivity with editors like emacs or vim, or whatever else. Why we have to reparse c/c++ in every editor alive when the compiler already does such things and would just need to dump out the information needed to understand it is beyond me.

I only see 2 solutions to this situation. First is gcc gets left behind as a backwater compiler that won't interact with the real world due to religious reasons. Second is it gets forked and like ecgs before it, the fork becomes the canonical version (likely ignored by the gnu/fsf folks as being a heathen fork or whatever).

Xcode cannot refactor C++ at all. Not in the slightest. It'll only do C and Obj-C.

It's a pity because it is quite an enjoyable IDE to use every single day for my C++ work (I'm on 6.1.1, doesn't crash unlike the 6.0 series), but missing a feature like that stinks.

Not that I've ever had need to use it so far, but still, it is a pity.

And GNU Emacs has to fork, absent getting RMS's buy-in, which is now not the way to bet. That's where the serious fork has to occur, I presume it could get by with LLVM output, right? Which of course would not be ideal if you're using GCC in your project....

Oh, if only they'd ignore the heathen fork of one of their marque projects. Not going to happen with EMACS, 99+% of its greatness is due to RMS by universal acclimation as of the very early '80s.

I think the point is that people are trying to avoid a fork situation like we had with EGCS and GCC from 1997 to 1999.