Why did it? Emacs is a great development environment. It allows you to focus on the code and supports debugging right next to your code, same as an ide. It is an ide.
Emacs lacks some features of xcode/eclipse et al but in exchange it has power they lack. Why shouldn't it gain some of their features?
(I am assuming you loled because you considered emacs weaker. My apologies if I got the sense backwards).
I've been programming in emacs since 1992, 2014 was the year I finally gave up and started to move into IDEs (having to target android was the primary motivation for using something else, but I'm rapidly getting spoiled, and am going to shell out for clion once it's done).
There's stuff I miss about emacs, and I'll keep using it for text files and r code and other stuff (it's still my primary python editor until I get around to trying pycharm), but by and large I think I'm done with it for c/c++.
Here on HN, Xcode bashing is second only to C++ bashing.
What's wrong with xcode? It has static analysis complete with annotations, integration with instruments for thread / network / CPU / memory monitoring, integration with lldb, code completion, code folding, quick navigation, details about callers and callees from any function, details about generated code (so you can look at the preprocessed code), the same with assembly (if you so desire!), test integration, class hierarchies, documentation for relevant functions (same as man, documentation for Apple SDKs) but IS missing refactoring for C++ (it does C and Obj-C).
Which bit about all of that is missing?? (other than refactoring C++)
I am using 6.1.1 and I haven't had it crash for the past 6 months, using it 7.5 hours a day (and 3 hours a night too). 6.0 was buggy as anything but 6.1.1 is rock-solid for me.
LLVM's design looks very attractive, but for scientific computing Fortran is really important, and AFAICT, LLVM doesn't have an intermediate representation comparable to Gimple: LLIR seems to be at the level of the registers rather than the nice abstract Gimple, but perhaps I just haven't looked deep enough.
I should mention that the only problem we have this approach is that neither the AST structure nor the plugin API is guaranteed to be stable between releases, so if you want to use Renjin's full tool chain, you have to be able to install a copy of GCC 4.6.x locally, which only gets more difficult over time.
This is the actual point of debate: RMS wants to keep these APIs moving targets in order to discourage Intel or whoever from writing a compiler that just shells out to gcc to handle all of the parsing.
Unfortunately, fully GPL'd, open-sourced projects like our own (and who knows how many others that were never even started because of these artificial hurdles) are the ones most affected.
> LLVM doesn't have an intermediate representation comparable to Gimple: LLIR seems to be at the level of the registers rather than the nice abstract Gimple
LLVM variables are sometimes called registers but they are machine independent. The bit width is arbitrary (e.g., you can create a 129-bit integer). The use of the term register is a misleading analogy; often LLVM-IR is compared to assembly language so the use of the term register was also used.
I do not know GIMPLE and couldn't find a good description of the IR instructions. But, it seems that LLVM IR is somewhat similar to low GIMPLE.
As far as I know, LLVM does exactly the same thing; the LLVM representation of that code would have a different syntax of course, but semantically would be exactly equivalent to the Gimple version you've presented.
As much as I love GNU tools "universe", I feel that this ideological position of RMS regarding GCC future is hurting more libre software than it does good.
The GPL principle of "all your code belongs to everyone" is infuriating to say the least, and the efforts of those to force this on people is even more damaging to the open-source community.
Free, open-source software has helped considerably in the last twenty years. That's why I think licenses like MIT or BSD help keep software free and truly open: Use it for what you see fit without any obligation on your part.
Just let GCC die already. Not only is LLVM free from this issue, it's technically superior across the board. The general replacement of GCC with LLVM in most applications appears sufficiently inevitable that investing more effort into GCC is wasteful.
I'm pretty sure no one is working hard to fix that right now because GCC does, and for many many more backends, especially solidly.
We'll really know things are at a tipping point when LLVM starts to acquire a bunch of solid back ends. I will personally count it as all over if/when Atmel AVR 8 bit is supported.
"llvm cant build a working Linux kernel from unmodified sources, using the .config from a major distribution"
It's getting closer; I believe it won't be long until clang/llvm can build a Linux kernel from unmodified sources (getting Linus to accept the remaining patches is a valid tactic).
Isn't GCC itself GPL with all the source available? IANAL, but AFAIK that means as long as you release your modifications under GPL too, it doesn't violate any license. Or are they saying that GCC doesn't actually use an AST somehow, which doesn't match at all with my (admittedly limited) knowledge of it?
I'm someone who has experience with what can be done in terms of extending/modifying software even without any source code, so my perspective on things like this are more like... "you have the source and an explicit license to modify it, and no intention of keeping your changes proprietary, so just do it!"
Either that or move to clang/LLVM, which I think would be better in the long term.
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 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.
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.
> 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.
---
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 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 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).
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.
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.
History. RMS was worried that "someone" (basically, Intel) would be able to take the gcc frontend and attach the icc (very fast, proprietary) backend to it, thus creating a compiler which could compile the whole GNU stack, producing very fast code. This would entice people to use a non-free compiler.
Since then LLVM came along and made the whole point moot, since it has a modular front end which can parse all the gcc extensions.
While Stallman's intent is the opposite, this is sounds awfully like the kind of thinking of big companies that are so easy to hate, where one can "misuse" a binary by reverse-engineering it.
It was my understanding that people have already extended emacs in the usual way to do lots, using llvm or clang, and that this argument is only about trying to do things that can make it into emacs proper. Is that not right?
He played this game with precompiled headers a decade ago and there's STILL barely any support for it in the GNU tools. When a debate around implementing precompiled headers ten years after everyone else gets them requires lawyers to get involved, maybe freedom isn't ringing as clearly as we were promised.
There's something fundamentally weird about the whole dev ecosystem wrt developer productivity. Next time you're sitting in front of an 8 CPU box with an SSD trying to solve a CPAN or library dependency, watching one C file compile once every three seconds, perhaps think about why things always wind up like this.
I super respect Stallman's position but at some point you have to look around (and beyond!) and say "why are we working with crippled tools?" With few exceptions all the core projects are uncontributable at this point. And RMS isn't even the worst; he's just the most consistent and predictable.
The tools really aren't that bad. There are many common open source c projects, most notably the linux kernel, which can easily use all your cores and compile tens of objects a second.
Compiling crazy c++ codebases are painful for everyone, and in fact were a primary inspiration for the handful of people at Google who created Go, with a primary goal of fast compiles, at some reasonable expense to disk and run-time efficiency.
Because RMS' stance has nothing to do with your productivity, and has everything to do with giving you the right to look at every single detail of GCC and make it work better for yourself.
If he did open it up for a proprietary component to make its way into GCC (while avoiding the licensing terms), and it becomes mainstream, you have lost that right to view and modify the software that runs on your box, and that is something he does not view as acceptable.
Ultimately, it's his decision; it's based on his work, and the contributors agreed to his terms. That he makes it freely available with the condition that it remains freely available is a bonus, not a right.
> And yet, the referenced discussion breaks down into RMS on one side and people who want to make gcc work better for themselves on the other.
At the risk of someone building a closed backend off an artifact of the GCC frontend; at the risk of someone profiting off RMS' work without following his conditions for making that work free.
It's important to remember that he isn't against Emacs getting the information it needs to do its work. In fact, this mirrors a common discussion in computer security, and system administration in general: you give applications and users only the permission they need, to protect against bad actors. If Emacs doesn't need the full AST, why would you give it to them?
You're certainly free to keep typing this stuff however the irony is that we all understand RMS clear, consistent position on the matter. The issue is that, by his own admission, he doesn't understand the other side.
> we all understand RMS clear, consistent position on the matter.
Then why are "we" all still using his software (which was given a license to match his philosophy) and complaining when he maintains his "clear, consistant position on the matter" and refuses to compromise his beliefs.
To use a poor analogy, it's like going to church and complaining when they talk about God.
There are lots of other options out there for editors, compilers, and OSes. If "we" really do understand his position, and disagree with it to the point that "we" want to make changes incompatible with his position, "our" time and energy would be better served working with an OS and software which better matches "our" ideology (like FreeBSD; awesome software under the BSD license).
> The issue is that, by his own admission, he doesn't understand the other side.
That seems like his problem, not ours. And he's not making it our problem; we're making it our problem by trying to use FSF software in a way other than what they intended.
EDIT: Scare quotes around We and Our are used because I, personally, agree with RMS. I didn't used to, but over the years I have grown to appreciate the GPL, the FSF, and the openness these extreme ideologies have brought about for us.
RMS popularity among newer programmers is always low (for the exact reasons outlined here, his software isn't "free" enough), and yet I find that after years of experience, we begin to appreciate that without his staunch support, we would be developing software in a very different world.
A world which we have a taste of now, in the Apple, Microsoft, Google and Facebook walled gardens: I don't know how Swift works. I can't fix bugs in Swift's implementation, and I can't build upon Swift for the betterment of all, should I so desire.
The fundamental issue is that for RMS (and perhaps you?), using software is like going to church and accepting the the moral code of whomever produced that software. However, for most people, that is not the case whatsoever. My baker can have all sorts of moral codes that I don't endorse when I eat his bread.
I don't support the FSF, I do support access to source code, and the freedom to extend the source code. Sometimes the FSF supports our shared goal, sometimes the FSF sees it other ways than I do, but that doesn't mean that I'm going to stop using emacs because I disagree with poor management of GCC.
The world is big enough for a plurality of ideologies.
Responding to your edit: >RMS popularity among newer programmers is always low (for the exact reasons outlined here, his software isn't "free" enough), and yet I find that after years of experience, we begin to appreciate that without his staunch support, we would be developing software in a very different world.
I find this to be an exceptionally unconvincing argument, because my experience has always been exactly the reverse. Newer programmers get excited about having access to source code, and they see RMS as the one saying the most about it, and just assume that RMS is responsible. After a while, they learn about the history of BSD and open source and realize that shared access to source code is a very natural way for software projects to develop. Without RMS being a frontman, we'd still the BSDs, we'd probably still have Linux. We'd have needed a compiler like GCC, but that void would probably have been filled sooner than Clang did it.
Perhaps a better (yet still poor) analogy would be going into an Islam Mosque and telling them to install some crosses.
Or complaining that your baker won't make bagels because he's doesn't approve of using lye on human consumables.
> The fundamental issue is that for RMS (and perhaps you?), using software is like going to church and accepting the the moral code of whomever produced that software
RMS and the FSF are pretty lenient in this case (there are licenses which literally wrap the use of the software in a moral code); you have no need to accept his moral code when you use the software. His licensing (and moral code) only matter when you want to change the code and distribute those changes.
Fortunately for all of us, there are plenty of licenses, and plenty of tools which use licenses which better match the "free with no restrictions whatsoever" point of view.
Bringing up food and morality might be a bad pick if you are arguing that people do not care. Ecological food, humanly treated animals for meat and eggs, and fair trade, is all concepts which carries large market shares and is believed by many people to be superior moral choices.
Using products like those does not mean you have to accept or endorse the the moral code that the products represent. However, for most people, morality do play a part of why they pick those products.
>If Emacs doesn't need the full AST, why would you give it to them?
Because the range of ways people might want to process code is vast. It's impossible to predict in advance what all those possibilities might be. The only way to allow the full range of transformations is to provide the full AST. Denying people the ability to manipulate code using code is to deny them a very important and powerful tool in computing. It reminds me a lot of when Apple tried to restrict what languages people could use when developing for iOS.
Emacs does need the full AST. The whole point of Emacs is to allow users to write applications that were UNANTICIPATED by its developers. You can't predict exactly what sort of information users will need, so you can't make some "safe" amount of information available.
It's mind boggling that this even needs to be explained. I get the sense that rms doesn't really grok the Emacs philosophy anymore.
Urk! You might well be right, I've been assuming he doesn't grok C++, which he doesn't use.
This would be terrible, for as far as I'm concerned, his single greatest contribution to computing is the EMACS philosophy that he developed out of a primitive set of TECO macros. (I believe everything else would have happened more or less, e.g. without Linux, BSD would be ruling now after a 2 year pause for that AT&T lawsuit.)
Imagine RMS's argument if the developers of a proprietary software asked "well, which part exactly of our software would you like to alter? We'll study how to give you restricted access to those."
Defective by Design is a FSF commentary about about how you should be able to use digital media in the same ways you would use physical media.
They say nothing about the existing limits on your ability to re-distribute software or media (in fact, the FSF and GPL depend on copyright protections).
But it sure sounds to me like the shoe fits. Enough that GCC is now existentially threatened by LLVM. ADDED: and I believe this is ~95% because of RMS's stewardship of the project (which already semi-died and was replaced by a fork), not the GPL, which is not a bad fit for a complete work like a compiler.
RMS's stewardship of GCC most certainly includes re-licencing it under the GPLv3, it's all one of a part.
And don't one or more of the BSDs have problems with the GLPv3 GCC? It's just not eeevil Apple (and that's part of why I swore off their products in 1987).
It's not defective because you are not the "user" to Stallman. The GPL is about limiting coders freedoms to maximise the freedom of end users (to see code, recompile it, alter the product they purchased).
For Stallman a program/tool is "defective" if it enables programmers to limit end users access to code, .e.g. by enabling proprietary addons to the compiler.
By acting on his own fears RMS is hurting the project. World doesn't stop because he doesn't like something. It feels like RMS lost touch with reality. Companies that care for things impossible with gcc already use LLVM, and will continue doing so. Some don't work openly but that doesn't mean useful code won't be pushed upstream. What's relevant to all - more often than not will.
This is bad news for everyone because competition is good. I want two solid open source compilers. Look what happened with gcc error messages when Clang showed up: they were horrendous compared to what LLVM/Clang had to offer. So gcc had to catch up. But if it's impossible to compete in the race because RMS doesn't want to - everyone gets screwed. But I guess that for RMS it's a win-win situation: he'll have his proof that BSD-licensed software can kill one on GPL.
This is why I prefer the BSD license for everything I do. In Stallman's universe, "freedom" only exists as long as it furthers his cause. What a waste. As far as I'm concerned, if I write something and release the source, I'm more than happy with people using it for whatever they want.
This seems analogous to the stable kernel ABI difference between Linux and FreeBSD. But I haven't seen any particularly deep articles comparing them, and our treatment of the respective project leaders.
> It took many years before the GNU Compiler Collection (GCC) changed its runtime library exemption in a way that allowed for GCC plugins, largely because of fears that companies might distribute proprietary, closed-source plugins.
Am I the only one who finds it ironic that purported "free as in freedom" software is/was being held back because of fears of what someone can do with that freedom?
Though once useful, the GPL and especially the AGPL are harmful, restrictive licenses that have outlived their usefulness and in no way represent "freedom".
Stallman's held this view for a very long while. About fifteen years ago, he told someone to memory hole a GCC target to emit JVM bytecode [1] because of the vague threat that someone could take that, create a theoretical frontend that worked on JVM bytecode, and feed /that/ result into a proprietary compiler. Stallman's fear of the proprietary bogeyman has hamstrung GCC and Free toolchains from being a platform anywhere near as decent as other projects in providing realtime feedback into program design.
The most free world is not the one where there are the fewest restrictions. Restricting peoples' natural freedom to kill each other or steal from each other, for example, arguably makes everyone more free. The GPL is based on the same principle. Restricting certain antisocial behavior increases net freedom.
Although that's not a binary thing, I have the natural and legal right to kill in legitimate self-defense. In rare situations, stealing is allowed to prevent a greater loss.
In this case, most of us, even those of us who don't like the GPL in practice like me, are not primarily arguing the GPL, but RMS's stewardship of GCC and GNU Emacs about something that's allowed in I believe every FOSS license.
Just not in these two projects under the aegis of the FSF. Unless and until they fork, or RMS is somehow convinced, whic history says is not the way to bet.
> In this case, most of us, even those of us who don't like the GPL in practice like me, are not primarily arguing the GPL
However, people are making the argument that this proves that GPL<BSD, and so it needs to be rebutted until they stop making it. Speaking of which, it's particularly strange for people to take the position that RMS's behaviour here is anti-freedom and thus obnoxious, and therefore GPL sucks. It shouldn't be necessary to point out that he could pull the same stunt just as easily if GCC were under a BSD license. In fact he could achieve the same effect even more easily, because he wouldn't have to rely solely on constantly changing the AST interface, or the threat of doing that: he could put future official versions of GCC under a new license which tried to put up legal barriers to AST access, or threaten to do so. More broadly, it's hard to imagine any consistent position under which RMS attempting to exert some de facto proprietary control over GCC is tyrannical, but licenses which would have given him the authority to make future official GCC versions de jure completely or semi-proprietary are upholding freedom! Of course, you can argue that RMS' behaviour here proves that he is being hypocritical when he denounces others for exercising proprietary control of software, through proprietary works derived from FOSS software or by other means. But just as obviously, catching someone in hypocrisy doesn't necessarily mean that they were wrong.
Moreover, it needs to be addressed not only because people are drawing incorrect conclusions about GPL vs. BSD, but because it shows that they don't understand what's going on here. The problem here isn't licensing terms, it's Too Big To Fork https://news.ycombinator.com/item?id=6810259 . "Freedom of the press is guaranteed only to those who own one." Speaking of which, it's strange. Here RMS is using his position to exert some de facto proprietary control over GCC, a big, hard-to-replace hairball of code with lots of clients locked in to its interface, and widespread anger is (quite appopriately) the result. Yet the Web browser vendors have honed this kind of behaviour into a routine, regularly exerting their de facto power over the Web, and sometimes in nakedly self-serving and destructive ways, and people have been conditioned to hail and venerate this as the Open Web.
My only quibble is that since RMS has wrapped himself and this issue in the flag of the GPL and "the [foundation] for which it stands", in terms of the instant controversy, and e.g. conflicts with OpenBSD, they are indivisible.
But I hope I've made it very clear that I indeed view this solely as a stewardship issue that could be true under any FOSS licence, and I repeat that the GPL is a tolerable licence for something like the GCC (well, it might doom serious Ada to the proprietary world, but, eh).
The one freedom the GPL doesn't have is the freedom to take the freedom away. In BSD and similar you easily can. It is the taking away of freedom that is at the crux of all this.
Nope. My taking BSD code and producing a proprietary, closed source product it in no way impacts someone else's freedom to do the same, nor does it remove some freedom they previously had.
There was never any freedom on the derived work to begin with, so no freedom can be taken away. Especially considering that in practice people don't just take a look at a project they might derive a project from, see the GPL license and go "Huh, I guess I have to use GPL then".
The GPL nerd imagination in play here is as the ridiculous as the imagination of crypto nerds[1].
You have to understand the perspective of the FSF. They view non-free software as fundamentally morally evil. In the same way that most people today view slavery as fundamentally wrong. The comparison to slavery is one RMS and the FSF often make themselves.
To extend the analogy: if picking cotton was only economically viable if done with slave labour, then most people would agree we are better off not picking cotton at all. Similarly the FSF position is that if solving a problem using computers is only possible in a way that uses or enables non-free software, then we are better off not using computers to solve that problem at all.
In his inimitable style, Theo de Raadt, extremely annoyed by a 2007 effort to GPL a driver that OpenBSD reverse engineered with much sweat, notes that RMS has been perfectly fine with GCC having code to run on, and built binaries for, closed platforms....
This GCC stuff is very much a shades of grey situation in practice.
Its hard for me to come up with a way in which this is not RMS advocating restricting the freedom of users of GCC.
If he is so opposed to proprietary software using GCC output why not use a license that prohibits that? Its not even too late for new versions since the FSF owns the copyright to all GCC code.
That's the great irony of the copyleft movement -- it's about restricting what people can do under the guise of "freedom". RMS doesn't want people to "misuse" his software, but his version of misuse is "use it for a purpose that doesn't advance GNU." He's willing to cripple his software so that some theoretical entity that doesn't actually exist and does not agree with his politics can't misuse it.
On a practical level, if people wanted to execute that particular "misuse" (IE use it in non-GPL software, which I would just call a "use"), they would obviously use clang. Clang is basically better at this point anyway.
Basically what I'm trying to say is that RMS is a nutcase.
It is ironic, but not necessarily nuts. Another case of removing freedoms to promote freedom is much of criminal law. Why does the state restrict my freedom to kill people?
When your freedom reduces the global "freedom", the sum of everyone's freedoms after your action, it might make sense to prevent it.
In spite of, and because: freedom.
Not saying the way RMS is doing it is good, that's a different matter. But restricting freedom, for freedom? Yes, very possible.
RMS may be nuts, that doesn't stop him from being right. Which, by the way, he turns out to have been on many more counts than some of us initially thought.
And this is why some call it liberty. You can give a slave freedom by helping them to escape, but you have not provided liberty if the slaver can just hunt down and recapture the free'ed slave.
John Locke said on the subject of liberty: "Freedom is constrained by laws in both the state of nature and political society. Freedom of nature is to be under no other restraint but the law of nature. Freedom of people under government is to be under no restraint apart from standing rules to live by that are common to everyone in the society and made by the lawmaking power established in it. Persons have a right or liberty to (1) follow their own will in all things that the law has not prohibited and (2) not be subject to the inconstant, uncertain, unknown, and arbitrary wills of others."
> This is extremely misleading: Copyleft is about making sure everyone has the same rights.
In theory... except in this case, the point is ensuring that people who don't share his political leanings can't use the product in a way he doesn't like (to generate an AST). It's not even about modifying gcc in this context, he doesn't want people to "misuse" it. It's entirely about telling people what they can and can't do with their software. Where is the freedom in that?
> And here you prove you have no serious argument, by devolving to insults.
I'm calling him a nutcase because he's being paranoid by crippling his own software to prevent a thing that people can already easily do with a competitor (clang). It's not like people are like "oh no gcc can't emit an AST I guess I'll give up and forget the entire venture" they just go "well I guess I'll go use clang instead"
I should have the "freedom" to block off my street at night, because the traffic keeps me awake. But dang society (and laws) don't let me do that! Clearly, my "freedom" is being impinged by others! Right?
Thing is, society gives you several options to deal with the real problem short of enclosing a public commons:
Don't move into such a place.
If it becomes such a place, leave (it'll be more valuable, so you should be able to make a profit if an owner, or pay less in rent).
If it's people illicitly making too much noise, sic the authorities on them (although now in the US I'd hesitate to do that unless the situation is life and death, and often even not then).
If I take a piece of software and keep my changes to myself, it would be fair to say that I'm antisocial and selfish, but overall I have not negatively impacted anything -- I've simply refused to reciprocate the benefit I've received. That makes me a jerk, but objectively nothing bad has happened. Whereas if you were to block off your street, you're actively depriving people of a service, etc.
In this case RMS is actively refusing a feature that would be a boon for many people, because he want's to make sure it doesn't help people he dislikes. IMO, that's on the same level of companies obfuscating file formats so people can't build off their products. That's not defending freedom, it's just being a prick.
> If I take a piece of software and keep my changes to myself, it would be fair to say that I'm antisocial and selfish, but overall I have not negatively impacted anything -- I've simply refused to reciprocate the benefit I've received. That makes me a jerk, but objectively nothing bad has happened.
The GPL explicitly allows you to be a jerk in this way.
It just doesn't allow you to then jerk other people around by sending the software you've modified to other people without the same rights that you exercised in order to be a jerk in the first place. Because then something objectively bad would have happened.
> In this case RMS is actively refusing a feature that would be a boone (sic) for many people, because he want's to make sure it doesn't help people he dislikes.
Phrasing this emotionally ("dislikes") is weak. These are not people rms (or anyone else) "dislikes", they are people who want to remove your freedom to use software.
> That's not defending freedom, it's just being a prick.
Well no. It's preventing non-free software from being written. Which is defending freedom.
You're simply arguing for different collateral damage. rms is happy to have less software written if it prevents the production of non-free software. He's preventing harm. You're happy to have more software written but don't care if that includes software that doesn't let people use it freely. You're allowing harm.
Neither of you is being a prick, at least not in your politics.
> Phrasing this emotionally ("dislikes") is weak. These are not people rms (or anyone else) "dislikes", they are people who want to remove your freedom to use software.
How is disallowing a feature for political reasons any different than this? This is a useful feature that he's refusing, that people want, because it might help out the bad guys. He's basically willing to screw over his customers (the users), to make a point.
> You're happy to have more software written but don't care if that includes software that doesn't let people use it freely. You're allowing harm.
Lol. I make software. I want people to use it, and I want to make money for my efforts. I have zero interests in their politics. To me, that's freedom. If that's "allowing harm" I will happily do it.
Let me give some credentials here. I make a plugin for unity 3d. I sell it. It's not my day job, but I do make some money from it. When I sell it, I also include the source code, because I realize that developers are sometimes going to need to customize this product for their own needs. Even if they distribute what they do (which I hope they do! That's the point right?), I don't ask that they contribute their changes back, because that was their blood sweat and tears and they already paid their due (IE, the price of the product). Good for them. I'd be incredibly appreciative if they contributed their changes back, but they already paid their due, so I ask nothing of them. To me, although this particular thing is not the BSD license, I feel like it's in the spirit of that. "Here's some code, contribute back if you can". The GPL license on the other hand seems pretty un-inclusive. It's basically like, "here's some software... You can use it I guess but we mostly meant this for people that follow our cause..." The entire thing seems incredibly political, which makes me uninterested since I don't subscribe to their cause for various reasons.
He is opposed to proprietary software using his code which he gave to the world on the condition that it, and derivative work, remains open for its users to view and modify.
The work belongs to the FSF, so it's ultimately their decision what happens with it, in pursuit of the goal of software which you can legally inspect and modify for yourself.
Yes, but is he throwing the baby out with the bathwater here? Does crippling GCC in this aspect make using alternate toolchains more palatable, as they expose the interfaces needed to do the decently complicated actions a lot of modern developers count on. If people abandon gcc because of restrictions like this, is the FSF really acting in its own best interest?
There are 2 different kinds of outputs here. A license that restricted or applied GPL to the object code emitted by the compiler would create gigantic waves.
The compiler's AST isn't usually an output. This does seem like a dated issue, 20 years ago, there weren't as many C and C++ parsers, now there are a number of free ones. I feel pretty confident that 20 years ago, there would have been some proprietary compilers derived from GCC if they could emit the AST in an unrestricted sort of way. On more than a couple embedded projects I worked on some vendor distributed an absolutely PoS compiler because they had to to sell their parts and couldn't or wouldn't play ball with GCC. Honestly, now I'd think GCC's real value is in the optimizer, not so much the parser.
Seems like a fairly simple addendum to the license could GPL the GCC intermediate representation and their usage outside of GCC. That does create a logical loophole in that you don't want code compiled with GCC to be considered intermediate output and then GPLed by definition.
> I feel pretty confident that 20 years ago, there would have been some proprietary compilers derived from GCC if they could emit the AST in an unrestricted sort of way.
Your confidence is 100% justified, because Open64 exists. It always has been possible to emit AST from GCC by simply modifying GCC yourself to do so. GCC is a free software after all. Open64 did that, and AMD used to sell a compiler using GCC frontend together with highly optimizing proprietary backend. More on http://tirania.org/blog/archive/2004/Apr-18.html
What has not been possible is not to emit AST from GCC, but to emit AST from GCC and continue to benefit from GCC changes after that.
Typically, it's not a good idea to argue with RMS. The pragmatic approach would be to just write the plugin for GCC, and keep it separate. GNU can certainly control what is mainlined, but the GPL is not violated simply by creating a GPL plugin that provides a useful output target.
If Emacs were enhanced to support a standardized file format which contains the relevant information, then it could accept this format from any tool. The GCC plugin could output this format, as could Clang/LLVM. Because the format is universal, it likely would be mainlined.
Then, it's up to the user. If the user wants to integrate the two, the user can apply the appropriate patch to GCC to incorporate this independent plugin. Likely, many downstream package maintainers would add this as a standard option if demand were high enough. This is the very freedom that RMS has advocated for. It can be done without poking the bear.
You're ignoring that a lot more work needs to be done in GNU Emacs, and that's another program under RMS's stewardship, and one where he could be much more obstructive.
The only outstanding threat to fork that I know of is coming from a GNU Emacs maintainer, to I believe fork GNU Emacs. Again. Oh boy, again to support C++ development! How could I have forgotten that?!?!?!!!
But you're right, arguing with RMS on this is likely to be completely unproductive. But it is morally necessary before potentially disastrous forking of GNU Emacs and maybe GCC.
Actually, I didn't ignore that in my original comment. I mentioned that the GNU Emacs work should make use of a file format which is independent of the plugin work. There is no reason why GNU would refuse to mainline such an enhancement if it had merits outside of the GCC dependency.
RMS wishes to restrict possible proprietary use of the GCC front-end. That's his prerogative. However, he can't prevent the existence of such a tool. He can only prevent it from being mainlined.
EDIT: Also, it may be easier to make a case for mainlining if the functionality is demonstrable. As I've learned throughout my career, it's often better to ask forgiveness than to ask permission. RMS excels in the idealistic and theoretical. If he has to consider the practical -- such as whether to mainline already existing functionality -- then he may find ways of suggesting changes to the plugin than ways of saying "no."
"There is no reason why GNU would refuse to mainline such an enhancement if it had merits outside of the GCC dependency"
Except everyone who knows RMS well enough knows he'd be extremely obstructionist and indeed GNU would refuse to maintain/mainline such an GNU Emacs enhancement. That's one of the reasons I believe the GNU Emacs maintainer threatened to fork it, he obviously knows RMS well enough.
(So do I in the 1979 to late '80s period, and he's not changed in this sort of thing. And he was reliably reported to be like this before I showed up on the scene, by among others one of the two initial ITS TECO EMACS beta-testers. And others I knew less well.)
Stallman appears to make himself out to be a Capitalist with positions like this -- he simply takes profits in the furtherance of his cause rather than in dollars, and uses procedural controls like the GPL rather than technological controls like obfuscated binaries to do so.
That said, personally, I think the GPL has both helped and harmed the evolution of computing.
111 comments
[ 5.3 ms ] story [ 171 ms ] threadWhy did it? Emacs is a great development environment. It allows you to focus on the code and supports debugging right next to your code, same as an ide. It is an ide.
Emacs lacks some features of xcode/eclipse et al but in exchange it has power they lack. Why shouldn't it gain some of their features?
(I am assuming you loled because you considered emacs weaker. My apologies if I got the sense backwards).
There's stuff I miss about emacs, and I'll keep using it for text files and r code and other stuff (it's still my primary python editor until I get around to trying pycharm), but by and large I think I'm done with it for c/c++.
What's wrong with xcode? It has static analysis complete with annotations, integration with instruments for thread / network / CPU / memory monitoring, integration with lldb, code completion, code folding, quick navigation, details about callers and callees from any function, details about generated code (so you can look at the preprocessed code), the same with assembly (if you so desire!), test integration, class hierarchies, documentation for relevant functions (same as man, documentation for Apple SDKs) but IS missing refactoring for C++ (it does C and Obj-C).
Which bit about all of that is missing?? (other than refactoring C++)
I am using 6.1.1 and I haven't had it crash for the past 6 months, using it 7.5 hours a day (and 3 hours a night too). 6.0 was buggy as anything but 6.1.1 is rock-solid for me.
https://github.com/bedatadriven/renjin/blob/master/tools/gcc...
This little plugin simply dumps GCC's gimple to JSON, yielding for example:
https://github.com/bedatadriven/renjin/blob/master/tools/gcc...
LLVM's design looks very attractive, but for scientific computing Fortran is really important, and AFAICT, LLVM doesn't have an intermediate representation comparable to Gimple: LLIR seems to be at the level of the registers rather than the nice abstract Gimple, but perhaps I just haven't looked deep enough.
This is the actual point of debate: RMS wants to keep these APIs moving targets in order to discourage Intel or whoever from writing a compiler that just shells out to gcc to handle all of the parsing.
Unfortunately, fully GPL'd, open-sourced projects like our own (and who knows how many others that were never even started because of these artificial hurdles) are the ones most affected.
LLVM variables are sometimes called registers but they are machine independent. The bit width is arbitrary (e.g., you can create a 129-bit integer). The use of the term register is a misleading analogy; often LLVM-IR is compared to assembly language so the use of the term register was also used.
I do not know GIMPLE and couldn't find a good description of the IR instructions. But, it seems that LLVM IR is somewhat similar to low GIMPLE.
Gimple variables have types comparable with C types - you get pointers, arrays.
For example:
is compiled down to:That's a bit saddening.
Free, open-source software has helped considerably in the last twenty years. That's why I think licenses like MIT or BSD help keep software free and truly open: Use it for what you see fit without any obligation on your part.
That's free.
We'll really know things are at a tipping point when LLVM starts to acquire a bunch of solid back ends. I will personally count it as all over if/when Atmel AVR 8 bit is supported.
So, yeah, I should gather my robes and prepare to deliver a Biblical "Repent, sinner, for the end is nigh!"
"llvm cant build a working Linux kernel from unmodified sources, using the .config from a major distribution"
It's getting closer; I believe it won't be long until clang/llvm can build a Linux kernel from unmodified sources (getting Linus to accept the remaining patches is a valid tactic).
I'm someone who has experience with what can be done in terms of extending/modifying software even without any source code, so my perspective on things like this are more like... "you have the source and an explicit license to modify it, and no intention of keeping your changes proprietary, so just do it!"
Either that or move to clang/LLVM, which I think would be better in the long term.
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.
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!
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.
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.
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.
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.
> 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 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.
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.
You are free to compete, but have run the whole marathon.
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.
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...
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.
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).
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.
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.
Since then LLVM came along and made the whole point moot, since it has a modular front end which can parse all the gcc extensions.
See here:
https://www.gnu.org/philosophy/free-sw.html
There's something fundamentally weird about the whole dev ecosystem wrt developer productivity. Next time you're sitting in front of an 8 CPU box with an SSD trying to solve a CPAN or library dependency, watching one C file compile once every three seconds, perhaps think about why things always wind up like this.
I super respect Stallman's position but at some point you have to look around (and beyond!) and say "why are we working with crippled tools?" With few exceptions all the core projects are uncontributable at this point. And RMS isn't even the worst; he's just the most consistent and predictable.
Compiling crazy c++ codebases are painful for everyone, and in fact were a primary inspiration for the handful of people at Google who created Go, with a primary goal of fast compiles, at some reasonable expense to disk and run-time efficiency.
If he did open it up for a proprietary component to make its way into GCC (while avoiding the licensing terms), and it becomes mainstream, you have lost that right to view and modify the software that runs on your box, and that is something he does not view as acceptable.
Ultimately, it's his decision; it's based on his work, and the contributors agreed to his terms. That he makes it freely available with the condition that it remains freely available is a bonus, not a right.
And yet, the referenced discussion breaks down into RMS on one side and people who want to make gcc work better for themselves on the other.
At the risk of someone building a closed backend off an artifact of the GCC frontend; at the risk of someone profiting off RMS' work without following his conditions for making that work free.
It's important to remember that he isn't against Emacs getting the information it needs to do its work. In fact, this mirrors a common discussion in computer security, and system administration in general: you give applications and users only the permission they need, to protect against bad actors. If Emacs doesn't need the full AST, why would you give it to them?
Then why are "we" all still using his software (which was given a license to match his philosophy) and complaining when he maintains his "clear, consistant position on the matter" and refuses to compromise his beliefs.
To use a poor analogy, it's like going to church and complaining when they talk about God.
There are lots of other options out there for editors, compilers, and OSes. If "we" really do understand his position, and disagree with it to the point that "we" want to make changes incompatible with his position, "our" time and energy would be better served working with an OS and software which better matches "our" ideology (like FreeBSD; awesome software under the BSD license).
> The issue is that, by his own admission, he doesn't understand the other side.
That seems like his problem, not ours. And he's not making it our problem; we're making it our problem by trying to use FSF software in a way other than what they intended.
EDIT: Scare quotes around We and Our are used because I, personally, agree with RMS. I didn't used to, but over the years I have grown to appreciate the GPL, the FSF, and the openness these extreme ideologies have brought about for us.
RMS popularity among newer programmers is always low (for the exact reasons outlined here, his software isn't "free" enough), and yet I find that after years of experience, we begin to appreciate that without his staunch support, we would be developing software in a very different world.
A world which we have a taste of now, in the Apple, Microsoft, Google and Facebook walled gardens: I don't know how Swift works. I can't fix bugs in Swift's implementation, and I can't build upon Swift for the betterment of all, should I so desire.
I don't support the FSF, I do support access to source code, and the freedom to extend the source code. Sometimes the FSF supports our shared goal, sometimes the FSF sees it other ways than I do, but that doesn't mean that I'm going to stop using emacs because I disagree with poor management of GCC.
The world is big enough for a plurality of ideologies.
Responding to your edit: >RMS popularity among newer programmers is always low (for the exact reasons outlined here, his software isn't "free" enough), and yet I find that after years of experience, we begin to appreciate that without his staunch support, we would be developing software in a very different world.
I find this to be an exceptionally unconvincing argument, because my experience has always been exactly the reverse. Newer programmers get excited about having access to source code, and they see RMS as the one saying the most about it, and just assume that RMS is responsible. After a while, they learn about the history of BSD and open source and realize that shared access to source code is a very natural way for software projects to develop. Without RMS being a frontman, we'd still the BSDs, we'd probably still have Linux. We'd have needed a compiler like GCC, but that void would probably have been filled sooner than Clang did it.
Or complaining that your baker won't make bagels because he's doesn't approve of using lye on human consumables.
> The fundamental issue is that for RMS (and perhaps you?), using software is like going to church and accepting the the moral code of whomever produced that software
RMS and the FSF are pretty lenient in this case (there are licenses which literally wrap the use of the software in a moral code); you have no need to accept his moral code when you use the software. His licensing (and moral code) only matter when you want to change the code and distribute those changes.
Fortunately for all of us, there are plenty of licenses, and plenty of tools which use licenses which better match the "free with no restrictions whatsoever" point of view.
Using products like those does not mean you have to accept or endorse the the moral code that the products represent. However, for most people, morality do play a part of why they pick those products.
Because the range of ways people might want to process code is vast. It's impossible to predict in advance what all those possibilities might be. The only way to allow the full range of transformations is to provide the full AST. Denying people the ability to manipulate code using code is to deny them a very important and powerful tool in computing. It reminds me a lot of when Apple tried to restrict what languages people could use when developing for iOS.
It's mind boggling that this even needs to be explained. I get the sense that rms doesn't really grok the Emacs philosophy anymore.
This would be terrible, for as far as I'm concerned, his single greatest contribution to computing is the EMACS philosophy that he developed out of a primitive set of TECO macros. (I believe everything else would have happened more or less, e.g. without Linux, BSD would be ruling now after a 2 year pause for that AT&T lawsuit.)
They say nothing about the existing limits on your ability to re-distribute software or media (in fact, the FSF and GPL depend on copyright protections).
And don't one or more of the BSDs have problems with the GLPv3 GCC? It's just not eeevil Apple (and that's part of why I swore off their products in 1987).
For Stallman a program/tool is "defective" if it enables programmers to limit end users access to code, .e.g. by enabling proprietary addons to the compiler.
This is bad news for everyone because competition is good. I want two solid open source compilers. Look what happened with gcc error messages when Clang showed up: they were horrendous compared to what LLVM/Clang had to offer. So gcc had to catch up. But if it's impossible to compete in the race because RMS doesn't want to - everyone gets screwed. But I guess that for RMS it's a win-win situation: he'll have his proof that BSD-licensed software can kill one on GPL.
It never did function bodies, but then we never needed it to.
This was over 10 years ago now; frustrating that GCC has ever made clang necessary :(
Am I the only one who finds it ironic that purported "free as in freedom" software is/was being held back because of fears of what someone can do with that freedom?
Though once useful, the GPL and especially the AGPL are harmful, restrictive licenses that have outlived their usefulness and in no way represent "freedom".
[1] http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html
Although that's not a binary thing, I have the natural and legal right to kill in legitimate self-defense. In rare situations, stealing is allowed to prevent a greater loss.
In this case, most of us, even those of us who don't like the GPL in practice like me, are not primarily arguing the GPL, but RMS's stewardship of GCC and GNU Emacs about something that's allowed in I believe every FOSS license.
Just not in these two projects under the aegis of the FSF. Unless and until they fork, or RMS is somehow convinced, whic history says is not the way to bet.
However, people are making the argument that this proves that GPL<BSD, and so it needs to be rebutted until they stop making it. Speaking of which, it's particularly strange for people to take the position that RMS's behaviour here is anti-freedom and thus obnoxious, and therefore GPL sucks. It shouldn't be necessary to point out that he could pull the same stunt just as easily if GCC were under a BSD license. In fact he could achieve the same effect even more easily, because he wouldn't have to rely solely on constantly changing the AST interface, or the threat of doing that: he could put future official versions of GCC under a new license which tried to put up legal barriers to AST access, or threaten to do so. More broadly, it's hard to imagine any consistent position under which RMS attempting to exert some de facto proprietary control over GCC is tyrannical, but licenses which would have given him the authority to make future official GCC versions de jure completely or semi-proprietary are upholding freedom! Of course, you can argue that RMS' behaviour here proves that he is being hypocritical when he denounces others for exercising proprietary control of software, through proprietary works derived from FOSS software or by other means. But just as obviously, catching someone in hypocrisy doesn't necessarily mean that they were wrong.
Moreover, it needs to be addressed not only because people are drawing incorrect conclusions about GPL vs. BSD, but because it shows that they don't understand what's going on here. The problem here isn't licensing terms, it's Too Big To Fork https://news.ycombinator.com/item?id=6810259 . "Freedom of the press is guaranteed only to those who own one." Speaking of which, it's strange. Here RMS is using his position to exert some de facto proprietary control over GCC, a big, hard-to-replace hairball of code with lots of clients locked in to its interface, and widespread anger is (quite appopriately) the result. Yet the Web browser vendors have honed this kind of behaviour into a routine, regularly exerting their de facto power over the Web, and sometimes in nakedly self-serving and destructive ways, and people have been conditioned to hail and venerate this as the Open Web.
But I hope I've made it very clear that I indeed view this solely as a stewardship issue that could be true under any FOSS licence, and I repeat that the GPL is a tolerable licence for something like the GCC (well, it might doom serious Ada to the proprietary world, but, eh).
Nope. My taking BSD code and producing a proprietary, closed source product it in no way impacts someone else's freedom to do the same, nor does it remove some freedom they previously had.
The GPL nerd imagination in play here is as the ridiculous as the imagination of crypto nerds[1].
[1]: http://xkcd.com/538/
If so this seems like a very strange position to take to me.
To extend the analogy: if picking cotton was only economically viable if done with slave labour, then most people would agree we are better off not picking cotton at all. Similarly the FSF position is that if solving a problem using computers is only possible in a way that uses or enables non-free software, then we are better off not using computers to solve that problem at all.
This GCC stuff is very much a shades of grey situation in practice.
If he is so opposed to proprietary software using GCC output why not use a license that prohibits that? Its not even too late for new versions since the FSF owns the copyright to all GCC code.
On a practical level, if people wanted to execute that particular "misuse" (IE use it in non-GPL software, which I would just call a "use"), they would obviously use clang. Clang is basically better at this point anyway.
Basically what I'm trying to say is that RMS is a nutcase.
When your freedom reduces the global "freedom", the sum of everyone's freedoms after your action, it might make sense to prevent it.
In spite of, and because: freedom.
Not saying the way RMS is doing it is good, that's a different matter. But restricting freedom, for freedom? Yes, very possible.
RMS may be nuts, that doesn't stop him from being right. Which, by the way, he turns out to have been on many more counts than some of us initially thought.
John Locke said on the subject of liberty: "Freedom is constrained by laws in both the state of nature and political society. Freedom of nature is to be under no other restraint but the law of nature. Freedom of people under government is to be under no restraint apart from standing rules to live by that are common to everyone in the society and made by the lawmaking power established in it. Persons have a right or liberty to (1) follow their own will in all things that the law has not prohibited and (2) not be subject to the inconstant, uncertain, unknown, and arbitrary wills of others."
This is extremely misleading: Copyleft is about making sure everyone has the same rights.
> Basically what I'm trying to say is that RMS is a nutcase.
And here you prove you have no serious argument, by devolving to insults.
Many of us who know him well would not object to the essential meaning of that word, even if we don't ourselves use it.
In theory... except in this case, the point is ensuring that people who don't share his political leanings can't use the product in a way he doesn't like (to generate an AST). It's not even about modifying gcc in this context, he doesn't want people to "misuse" it. It's entirely about telling people what they can and can't do with their software. Where is the freedom in that?
> And here you prove you have no serious argument, by devolving to insults.
I'm calling him a nutcase because he's being paranoid by crippling his own software to prevent a thing that people can already easily do with a competitor (clang). It's not like people are like "oh no gcc can't emit an AST I guess I'll give up and forget the entire venture" they just go "well I guess I'll go use clang instead"
I should have the "freedom" to block off my street at night, because the traffic keeps me awake. But dang society (and laws) don't let me do that! Clearly, my "freedom" is being impinged by others! Right?
/s
Don't move into such a place.
If it becomes such a place, leave (it'll be more valuable, so you should be able to make a profit if an owner, or pay less in rent).
If it's people illicitly making too much noise, sic the authorities on them (although now in the US I'd hesitate to do that unless the situation is life and death, and often even not then).
If I take a piece of software and keep my changes to myself, it would be fair to say that I'm antisocial and selfish, but overall I have not negatively impacted anything -- I've simply refused to reciprocate the benefit I've received. That makes me a jerk, but objectively nothing bad has happened. Whereas if you were to block off your street, you're actively depriving people of a service, etc.
In this case RMS is actively refusing a feature that would be a boon for many people, because he want's to make sure it doesn't help people he dislikes. IMO, that's on the same level of companies obfuscating file formats so people can't build off their products. That's not defending freedom, it's just being a prick.
The GPL explicitly allows you to be a jerk in this way.
It just doesn't allow you to then jerk other people around by sending the software you've modified to other people without the same rights that you exercised in order to be a jerk in the first place. Because then something objectively bad would have happened.
> In this case RMS is actively refusing a feature that would be a boone (sic) for many people, because he want's to make sure it doesn't help people he dislikes.
Phrasing this emotionally ("dislikes") is weak. These are not people rms (or anyone else) "dislikes", they are people who want to remove your freedom to use software.
> That's not defending freedom, it's just being a prick.
Well no. It's preventing non-free software from being written. Which is defending freedom.
You're simply arguing for different collateral damage. rms is happy to have less software written if it prevents the production of non-free software. He's preventing harm. You're happy to have more software written but don't care if that includes software that doesn't let people use it freely. You're allowing harm.
Neither of you is being a prick, at least not in your politics.
How is disallowing a feature for political reasons any different than this? This is a useful feature that he's refusing, that people want, because it might help out the bad guys. He's basically willing to screw over his customers (the users), to make a point.
> You're happy to have more software written but don't care if that includes software that doesn't let people use it freely. You're allowing harm.
Lol. I make software. I want people to use it, and I want to make money for my efforts. I have zero interests in their politics. To me, that's freedom. If that's "allowing harm" I will happily do it.
Let me give some credentials here. I make a plugin for unity 3d. I sell it. It's not my day job, but I do make some money from it. When I sell it, I also include the source code, because I realize that developers are sometimes going to need to customize this product for their own needs. Even if they distribute what they do (which I hope they do! That's the point right?), I don't ask that they contribute their changes back, because that was their blood sweat and tears and they already paid their due (IE, the price of the product). Good for them. I'd be incredibly appreciative if they contributed their changes back, but they already paid their due, so I ask nothing of them. To me, although this particular thing is not the BSD license, I feel like it's in the spirit of that. "Here's some code, contribute back if you can". The GPL license on the other hand seems pretty un-inclusive. It's basically like, "here's some software... You can use it I guess but we mostly meant this for people that follow our cause..." The entire thing seems incredibly political, which makes me uninterested since I don't subscribe to their cause for various reasons.
He is opposed to proprietary software using his code which he gave to the world on the condition that it, and derivative work, remains open for its users to view and modify.
The work belongs to the FSF, so it's ultimately their decision what happens with it, in pursuit of the goal of software which you can legally inspect and modify for yourself.
The compiler's AST isn't usually an output. This does seem like a dated issue, 20 years ago, there weren't as many C and C++ parsers, now there are a number of free ones. I feel pretty confident that 20 years ago, there would have been some proprietary compilers derived from GCC if they could emit the AST in an unrestricted sort of way. On more than a couple embedded projects I worked on some vendor distributed an absolutely PoS compiler because they had to to sell their parts and couldn't or wouldn't play ball with GCC. Honestly, now I'd think GCC's real value is in the optimizer, not so much the parser.
Seems like a fairly simple addendum to the license could GPL the GCC intermediate representation and their usage outside of GCC. That does create a logical loophole in that you don't want code compiled with GCC to be considered intermediate output and then GPLed by definition.
Your confidence is 100% justified, because Open64 exists. It always has been possible to emit AST from GCC by simply modifying GCC yourself to do so. GCC is a free software after all. Open64 did that, and AMD used to sell a compiler using GCC frontend together with highly optimizing proprietary backend. More on http://tirania.org/blog/archive/2004/Apr-18.html
What has not been possible is not to emit AST from GCC, but to emit AST from GCC and continue to benefit from GCC changes after that.
One could argue that Stallman is not acting within the spirit of this right by being deliberately obstructive and obfuscatory.
If Emacs were enhanced to support a standardized file format which contains the relevant information, then it could accept this format from any tool. The GCC plugin could output this format, as could Clang/LLVM. Because the format is universal, it likely would be mainlined.
Then, it's up to the user. If the user wants to integrate the two, the user can apply the appropriate patch to GCC to incorporate this independent plugin. Likely, many downstream package maintainers would add this as a standard option if demand were high enough. This is the very freedom that RMS has advocated for. It can be done without poking the bear.
The only outstanding threat to fork that I know of is coming from a GNU Emacs maintainer, to I believe fork GNU Emacs. Again. Oh boy, again to support C++ development! How could I have forgotten that?!?!?!!!
But you're right, arguing with RMS on this is likely to be completely unproductive. But it is morally necessary before potentially disastrous forking of GNU Emacs and maybe GCC.
RMS wishes to restrict possible proprietary use of the GCC front-end. That's his prerogative. However, he can't prevent the existence of such a tool. He can only prevent it from being mainlined.
EDIT: Also, it may be easier to make a case for mainlining if the functionality is demonstrable. As I've learned throughout my career, it's often better to ask forgiveness than to ask permission. RMS excels in the idealistic and theoretical. If he has to consider the practical -- such as whether to mainline already existing functionality -- then he may find ways of suggesting changes to the plugin than ways of saying "no."
Except everyone who knows RMS well enough knows he'd be extremely obstructionist and indeed GNU would refuse to maintain/mainline such an GNU Emacs enhancement. That's one of the reasons I believe the GNU Emacs maintainer threatened to fork it, he obviously knows RMS well enough.
(So do I in the 1979 to late '80s period, and he's not changed in this sort of thing. And he was reliably reported to be like this before I showed up on the scene, by among others one of the two initial ITS TECO EMACS beta-testers. And others I knew less well.)
That said, personally, I think the GPL has both helped and harmed the evolution of computing.