Whether you agree with the FSF or not, their whole existence stems from their beliefs about software freedom. If they compromise their principles in exchange for 'market share', then they quite literally have no purpose.
From your linked post:
> You are crossposting to two public project lists of the GNU project with inflammatory language and mischaracterizations. You have been involved with the GNU project long enough to be well aware that this kind of crowbar approach does not lead to much more than headlines about Free Software infighting.
ESR is doing little more than trolling here. He knows exactly where the FSF stands, and he knows exactly why that's not going to change (asking the FSF to do something that they believe hinders free software is like asking MADD to open a drive-through liquor store).
The FSF has always been very clear that they see the "open source" movement as complementary to (though not the same as) the free software movement, fighting for similar goals but for different reasons[1]. It's sad to see ESR, an "open source" advocate, actively try to fan the flames.
Nobody wins from this. Except advocates of closed, proprietary software.
[0] Of course, ESR knows exactly what he's doing here - the issue is that he disagrees with their principles, but instead of debating those, he'd rather attack them for executing on their principles rather than executing on his principles. It's a cheap rhetorical trick and a rather low move.
[1] "We don't think of the Open Source movement as an enemy. The enemy is proprietary software.", from https://www.gnu.org/philosophy/free-software-for-freedom.en..... (Don't be fooled by the title - the content of the article is very even-keeled).
Why should I respect someone for sticking with principles that are misguided? The whole idea that "sticking to principles" is a virtue independent of the merits of the principles involved is perverse.
Its even more perverse when the "principles" being stuck too are tactical judgments about how to best acheive strategic aims, and they are being stuck too even when they are operating against the strategic aims -- which is, precisely, the charge ESR is levelling against the anti-plugin policy vis-a-vis the stated goals of the FSF with regard to GCC.
> asking the FSF to do something that they believe hinders free software is like asking MADD to open a drive-through liquor store
ESR's argument is that FSF is wrong that this hinders free software, and in fact that FSF's status quo approach inhibits the FSF's stated goals for GCC.
But if you ask about "Free Software," and take github as data point, I'd say "Free Software" is losing, and is losing because, like proprietary software, it's "over-principled". Young people everywhere, "feel" like content, many forms of "public" data, and the tools to use, create, play, view, and store such content & data ought to be "free as in beer" (or close to it) based on the principle that the effort to copy & transfer data, content, binary, and source is "almost free". Whether there is a restriction in creating plug-ins, linking or modifying code (as in the GPL/Free Software), or copying binaries and/or content as in proprietary software, these are still restrictions.
This is the reason why I prefer the more permissive licenses for my works like the BSD and MIT licenses. Essentially, my work is a gift, in the purist sense, to the entire universe. To place restrictions on my gift is to have given the world a poison and not a gift.
The reason why is easier to understand when you consider the quote by Jim Warren from a 1976 ACM Programming Language newsletter [1], referencing Bill Gates' famous letter to the Homebrew Computing Club, "There is a viable alternative to the problems raised by Bill Gates in his irate letter to computer hobbyists concerning 'ripping off' software. When software is free, or so inexpensive that it's easier to pay for it than to duplicate it, then it won't be 'stolen'."
Said another way, people will continue to do the "wrong" thing so long as it takes less effort than to do the "right" thing. In my mind, we should be incentivizing the "right" things, like openness, sharing, technical merit, and capability.
[1] http://en.wikipedia.org/wiki/Tiny_BASIC#An_early_free_softwa...
In my opinion the FSF screwed up majorly by concentrating on local software and the GPL while ignoring the much greater danger of software as a service. The AGPL is too weak and the FSF never really pushed it. The GNU project have tried to create some online services/protocols themselves but they are a total joke (e.g. GNU Free Call).
LLVM and clang can be used in pretty much any project. They have provided every developer tools to use in anyway we wish. GCC's parts cannot be included in other projects because they are licensed in such a way that tells us that the GCC code is more important than the code we are using. Why does a 1,000 line GPL count for more than 100,000 lines of some other license?
I think the best community is a voluntary one, and with security the way it is, I would rather developers who don't want to be part of the community benefit from the code just as I like the idea of everyone (who can) being vaccinated.
GPL generates a self-selected community that has barriers to participation with other communities because the GPL code is held as more important than the rest.
Even if that is a real ideological division between the two, pragmatically I think that the permissive licenses that the FSF argues are less than ideal have done more after the initial demonstration of the value of F/OSS to promote a community of people who add to the public knowledge of software engineering than have copyleft licenses.
I think the divide over licensing approaches is as much over differing views of effective tactics and the real conditions in the environment as it is about differing views of values and strategic goals, and that permissive vs. copyleft is the real current divide more than free software vs. open source, and that, over time, the permissive side is gaining ground for reasons that have nothing to do with the main cited ideological differences between the open source and free software camps.
However, isn't this paragraph:
"I also think it bears noticing that nobody outside of Microsoft seems to particularly want to write proprietary compilers any more. GCC won its war; the cost and time-to-market advantages of hooking into open-source toolchains are now so widely understood that new processor designs support them as a matter of course."
proved wrong by Apple's Xcode? Isn't that exactly what Aplle is (partially) doing? I know Apple makes great contributions to (among other projects, clang) -- but is upstream clang the same as what comes with Xcode?
In general, the world is more than just C/C++. IBM dominates the enterprise COBOL market. (See http://www.itworldcanada.com/article/most-wanted-the-elusive... .) And there are several commercial Fortran compilers besides Intel, including that of NAG (Numerical Algorithms Group) and PGI (The Portland Group).
Since Apple has so much influence over the project they can simply get the changes they want into the project so that diminishes their need for their own changes.
The things they want to hold back almost entirely go into XCode's IDE. For instance XCode's IDE has a very nice visualization for the clang-analyzer. The visualization is just using the output from the open source analyzer. You can even replace the clang-analyzer with a newer version and use it from XCode. By keeping the visualization implementation in XCode itself they can maintain an advantage for their platform.
I'd say that this just proves his point since Apple has chosen not to produce a proprietary compiler and instead to contribute to LLVM.
As far as I know, Xcode is not an compiler, it's an IDE that uses LLVM/Clang underneath as primary option but also gcc if it is your choice. In the same way, Visual Studio uses cl.exe underneath but it can be hooked up with Clang too.
All of the fancy static analysis that Xcode does is completely tied to clang, for example. Its debugger front-end is tied to lldb's idiosyncratic interface. It's not something that you can just easily replace with non-Apple compilers.
Is there a legal reason why the requirement can only apply to the original source code and not the compiled source code? Don't the "proprietary binary" people exert some kind of license over their proprietary binaries?
And why can't the Linux Kernel have a versioned ABI? I don't know enough about it, but does it really get revised that often and by that much? I mean, Apple and Microsoft seem to be able to make this work, and everyone seems to think they aren't very capable compared to the Linux Kernel crew. The argument about "having to support old things" also doesn't seem to hold water, because one of the big reasons people use Open Source software is to leverage older, outdated hardware or to have access to older, outdated software and data that the proprietary vendors leave behind.
Well, for one thing, its dubious than ABI's are copyrightable (for much the same reasons as that is true for API's, see Oracle v. Google), so work derived from an existing products ABI quite likely doesn't need a copyright license, so therefore is unlikely to be effectively restrictable by way of a gratuitous copyright license.
This is not going to happen. I think David Kastrup's reply was pretty clear in that sense.
I cannot believe that this isn't obvious to esr, of all people. Is this just him trying to start a flame war?
edit: I'm now aware that esr is not talking about license restrictions but technical restrictions here. I have yet to find any evidence of technical restrictions for political reasons though, and it looks like the folks responding to him on the mailing list are not sure what he means either.
I don't have a strong position either, but unless you work for the FSF in their PR department, software developers should really be stating the FSF's position accurately, which is:
The Free Software Foundation only want to promote free^H^H^H^HFree Software Foundation-licensed tools, primarily tools that use its GPL license.
To the FSF, "free" is just a shorthand way of saying "Free Software Foundation-licensed". It doesn't mean "free" as normally understood. Just because the FSF wants to conflate the two to obscure what's going on doesn't mean the rest of the world should go along with the ruse.
(And it is clearly non-standard, which is easily demonstrated by how often FSF people have to explain what "free" means. As they say in politics, if you're explaining, you're losing. If there was no difference from the standard usage, no explanation would be needed. Therefore, the FSF usage is non-standard. QED)
FWIW I doubt anyone has a problem with the FSF's actual mission, since people are free (normal usage) to do what they want (and even encouraged to do so). It's the rhetorical duplicity of their PR that we shouldn't be supporting. Let the FSF's mission stand on it's own merits, rather than by trying to gain credibility/respectability by association with something else (in this case, our pre-existing affinity for freedom).
Not entirely true; the FSF recognizes lots of other licenses as "free".
Its true that the FSF thinks that its licenses are the most appropriate for promoting software freedom.
I think they're wrong: if you can convince people that Free Software has value, you don't need a copyleft license forcing them to give back, and if you can't convince them of that, a copyleft license doesn't help you get them to create free software, it just prevents them from engaging with it at all, gets them to commit to an alternative, and makes them less likely to to commit back even if they later realize a value in Free (since if they commit to a non-Free third-party alternative, the cost of switching it out is higher.)
And so you are losing. You are trying to explain what "free" is, and QED, your usage is non-standard.
GCC authors clearly want that users can modify and share the compiler, regardless which version of the program the user got. The idea that someone would then try to use their work as a springboard to sue individuals who attempt modify or share an specific version is clearly seen as abhorrent behavior.
Yet, again and again, people disrespect the wishes of the authors and keep try to pressure them to change their views. "Allow us to sue some users by using your work" they say. No they get back, and yet they keep asking again and again and again.
The GCC has an plugin system, but not one that allows proprietary modules. The people that care about that distinction only do so because of the licensing difference between GPL and proprietary licensing.
And I don't see how the FSF could ever have furthered their political goals by making it technically hard to use GCC in free software tools, quite the contrary. Would be quite interested in evidence of that.
So if nothing will be changes in GCC politics then it will become unnecessary in the future. Of course some will still use it but only as political reasons.
By design.
> And yes License matters, GPL just does not allow to use GCC in most cases.
By design.
The gcc project is ancient and while I don't know the code base well, I'd assume that the fact doesn't necessarily help make it more approachable for new developers. Why can't a newer version of gcc be based on parts of LLVM, if the latter is considered superior by so many people? The licenses seem to allow it.
I think one problem is that many developers on Apple systems think the Apple GCC was state of the art. When in fact the latest release (a patched 4.1?) was rather old and obsolete. The Clang homepage still used to compares itself to GCC 4.1 instead of 4.8.2 or 4.9. It was similar when Chrome was released and Firefox was stuck on 3.6.1 waiting for 4.0. Sure Chrome was a lot faster but Firefox quickly caught on. But still people seem to think otherwise.
There is a GCC for LLVM, called DragonEgg http://dragonegg.llvm.org/. It is a _plugin_ (yes GCC has those since 4.5) for GCC. But I don't know what huge advantage it's supposed to bring. Especially when GCC seems to have the better backend (at least for my projects) at the moment.
I think the GCC folks should make the GCC Python plugin official because it provides a more stable and clean API (mentioned by ian lance taylor here: http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html). They should continue with the transition for C++ (which will help to clean up the code base a lot, no matter what the C++ haters say) and increase the work towards modularization (http://gcc.gnu.org/wiki/ModularGCC that would probably allow making the frontend available as a library similar to libclang). Libgccjit could be very interesting as well http://gcc.gnu.org/wiki/JIT
Is that actually going to happen though? RMS is very clear that he doesn't want it to happen, and continues to argue against it. He knows that the decision to keep the architecture monolithic and only expose unstable internal data structures limits functionality, and he is happy to make that sacrifice:
https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00...
The GNU Project campaigns for freedom, not functionality. Sometimes freedom requires a practical sacrifice, and sometimes functionality is part of that sacrifice.
https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00...
Part of the reason why clang/llvm weakens our commnity, compared with GCC, is that the clang front ends can feed their data to nonfree tools.
Using clang/llvm for this is a breeze. They were concieved for that from the get go. Using gcc's AST to do anything is an horrible nightmare, and you pretty much have to fork the whole gcc code base to do that anyway.
Using gcc to implement a backend for a new language is possible, but still a lot harder than doing so with LLVM, which actually has a spec for its IR, and is well documented.
Those things are not going to be easy to change because GCC wasn't designed to account those needs.
But honestly, after seeing the error messages of Clang compared to those of GCC, I have zero intention of going back to GCC.
It may be that GCC generates better code (to be honest, I don't know) but 99% of the time that I'm using a compiler, I'm interacting with the error messages. The quality of the error messages has a real, significant impact in my development time. And if I want better code, I can always use GCC for the final compilation after doing all the debugging work with Clang.
As I said, I can't say I hate GCC, it's a free product and many, many wonderful projects have been compiled with it. But I honestly don't understand why, after all these years of development, the error messages are still that bad.
gcc has an explicit policy against making the code modular and reusable, for political reasons (to make it hard to use individual pieces of GCC as independent programs, which could form part of a proprietary compiler toolchain). The point is, this political policy has made gcc's code technically inferior in some ways to clang (modular code, with separation of concerns and clearly defined interfaces between components, is a technically good thing). GCC can't resolve this technical problem without abandoning this policy.
> Why can't a newer version of gcc be based on parts of LLVM, if the latter is considered superior by so many people?
That would inherently mean abandoning this policy. And the answer is that while it's possible, the GCC codebase is still good, it still outperforms clang in many cases, and pulling in parts of clang would already require cleaning up and modularizing the GCC codebase - at which point we'd quite possibly end up with a compiler that's better than clang in all respects. So why not just do that?
It seems to have been abandoned. GCC supports plugins and is working towards modularization.
This is because the FSF deliberately designed gcc not for technical goals, but to prevent access to intermediate formats without merging the compiler, because that would allow non-free plugins (as they wouldn't be derivative works of the gcc and so could choose their own license). Unfortunately, these choices not only restrict non-free work, but the technical decisions made prevent a lot of useful things from being made, and makes contributing to the project much harder than contributing to LLVM/Clang.
What do you mean exactly? GCC plugins provide access to all internal data structures.
"Then I don't understand why David Kastrup's question was even controversial.
"If I have failed to understand the background facts, I apologize and welcome being corrected.
"I hope you (and others) understand that I welcome chances to help the FSF's projects when I believe doing so serves the hacker community as a whole. The fact that I am currently working full-time on cleaning up the Emacs repoaitory for full git conversion is only one instance of this."
(I haven't been following ESR (not being part of his tribe and all), nor have I really been following Emacs. Do the other Emacs folks know about his "clean-up" there? Is it going to go any better than his clean up of the Linux kernel build system?)
ESR is just trolling. What his bug is, I don't know. Seems like he's dancing around something that might be interesting and more inline with the social observation that he's a little better at. I assert that GCC doesn't actually compete and doesn't need to compete. It just has to be available and it simply has to have hackers that are willing to work on it for the principle. Let's just assume that clang takes over the world, consistently produced better code than GCC, etc.. What exactly does that matter to GCC? Presumably hackers will stop working on GCC, but guile, hurd, and numerous other GNU projects show that that isn't always the case. I think that as long as GNU exists and they have some money and fans, there will be GCC contributors. Is there some other fear of what will happen if people use a different tool chain? Conversely, BSD has depended upon GCC for decades and I'm not convinced that that has affected it in any way and their switch to clang I suspect isn't going to radially alter things either. If we go back a week or two, I don't know that emacs' choice of revision control software makes any difference to its use, it may have some amount of impact on people contributing to it but I don't think that is clear cut either, there are A LOT of emacs contributions that aren't in the main tree... Also these projects don't want 'drive by' contributions, they want actively involved supporters.
Seems like he's dancing around some social observations that he wants to be true but can't prove or they might not be true. People hack on stuff because they have an itch, that itch might be technical need, it might be some sense of aesthetic that they think isn't being answered, it could also be related to something like freedom. When do other factors outweigh the itch? Now maybe GCC is GNU's most important software asset and there is some larger social thing ESR is worried about or has observed.
That's a strange conspiracy theory that has been posted here several times and debunked as well. It seems particularly odd to me because when I worked at a university 15 years ago, everyone in the compiler research world would occasionally hack on gcc to add features, retarget it, add optimizations etc. ... It didn't seem prohibitively difficult.
http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html / http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html
"That GCC plugin interface is not sufficiently stable for major uncoordinated developments by third-parties is just as true as that Linux's module interface is constantly changing, and complaints about its lack of stability in it are often responded with such phrases as contribute your driver and we'll even help you keep it up-to-date".
I don't know about the subject but it seems a quite reasonable stand and it certainly doesn't hinder the Linux kernel development, I don't see why it wouldn't work in GCC.
If people switch from GCC to Clang/LLVM in enough numbers that Apple think they can get away with it, Apple will, in a heartbeat, close the development of Clang/LLVM and make all new versions proprietary. (https://news.ycombinator.com/item?id=6146066)
This is still true, and this is the reason we cannot allow GCC to give up or declare “victory” and move on.
This is what happens when you don’t read the license, think that things like copyright doesn’t apply to things you get off the internet, and dig yourself into a hole – your options are limited. But releasing the code as GPL was never their only option, is what I’m saying.
Followed shortly by Google, Microsoft, IBM, and Oracle. Classic prisoners' dilemma.
And speaking of closing; just look at Android with its complete anti-GPL, purged system. Only Linux remains there.
Of course, I (or you) can’t prove anything either way, but I have the feeling of Google, Apple, and the rest of the permissive license promulgators all the time going “Relax, it’s fine now, the war is over, you can all go home! You won!” And if we turn our backs, if we relax in our supposed victory, we will slowly find that all the contributors to these better (completely coincidentally non-GPL) projects are mostly employees of these same companies, and they all have CLAs. And one fine day they will turn off the freedom and turn it all proprietary. We then cannot hope of competing with the current project owners, since they have all the experience and infrastructure.
FSF lives on an island and worries that even one contaminated inhabitant will infect everybody. They seem to hold that non-free is a contagious disease that will overtake and destroy their freedom. FSF is worried about diminishing: what they have is perfect and it can only be reduced. FSF are Tolkein's Elves.
ESR would welcome contaminated people to that island, believing strongly in it's restorative properties. He seems to hold that open-source is more powerful and will stamp out closed software whenever they meet. ESR is worried about not expanding quickly enough and dying of stagnation. ESR would probably be Aragorn.
That's how I see this argument.
Without GCC staking out the position it has clang wouldn't have its middle ground to stake out. The middle ground would instead be a lot more proprietary than it is now.
Without Stallman being as radical as he is, there would be no Linus' who bridge the gap between completely free and completely proprietary software. There would be nothing to react to.
Many wrongs actually do make a right, as long as we're all wrong in opposite directions.
Someone should tell Intel that. Don't they still do things to intentionally make AMD CPUs look bad?
Beliefs don't need them, but I don't see a rational argument supporting that. IMO, clang developers just won't cripple their product to prevent the potential collateral damage to gcc.
