LLVM & GCC Compiler Developers To Begin Collaborating
An anonymous reader writes "While RMS is opposed to LLVM over its BSD-like license rather than the GPL, LLVM/Clang and GCC developers have agreed to try to start cooperating in an "open compiler initiative" to jointly tackle common issues that plague both compilers and issues that can be better served by working together rather than creating fragmentation between the two popular open-source compilers."
I'm not sure how GCC could benefit from this.
While theoretically GPL could subsume BSD code produced from the collaboration, I reckon it's more likely that brains are going to migrate rather than code. And I don't see those working on LLVM (for commercial interest) migrating to GCC.
If I were RMS I'd be worried.
RMS knows that (and has made statements to that effect): GPL exists precisely because it's not a perfect world.
While you may call it a freedom, "freedom" to kill would not be a beneficial one.
Speaking metaphorically, that's what BSD license grants you: A way to murder free software in the black hole of proprietary software.
Do companies contribute back? Sure, some do, some of the things. But everything else is competition.
And therein lies the real difference: GPL is against proprietary software, it aims to provide free software to everyone. BSD isn't and doesn't.
Kinda like free vs open.
TL;DR: No.
One of the areas where the licensing of gcc have been very successful is within embedded hardware. Gcc has gained a high reputation within this field which has lead to adoption by several vendors of embedded systems. These firms are not known for their generosity or cooperability, so without the GPL it is unlikely that the changes they needed had been contributed back upstream. This is of course only speculation, but I would say that the GPL has overall been advantages to gcc.
I would be very interested in seeing real statistics on this, because my experiences with companies using BSD style licensed code in their software suggests the exact opposite. There are a number of reasons to use open source software in your project, the chief among them being "not reinventing the wheel". The problem is, the moment you generate your own proprietary fork, you're back to reinventing the wheel. Chances are, you made the changes because the software in question didn't quite do what you wanted it to do, or to fix a bug. Great, so now you've got your own branch, and every time you update this software with the latest "official" version for whatever reason (including perhaps, not reinventing the wheel for some new feature) you have to apply your patches and changes, and hope that the patches you built against version X are still valid against version Y.
In my experience, the only time companies don't give back is when they've made such massive changes that they would be maintaining their own branch anyway. And with changes that large, it's extremely unlikely the main branch would ever integrate them all back in, which means the company is maintaining their own fork, regardless of whether or not they've released the code. Now, you can argue (as RMS does) that regardless, the important thing is whether the new code is open, not whether it's ever merged back, but there are considerations to be had as well. Forks split and consume development resources. Different projects all doing the same thing slightly differently create more work for people trying to target those projects, such that writing new useful software that takes advantage of other available resources either requires multiple code paths to handle each resource (think vendor specific CSS tags but worse) or can't be meaningfully built without someone writing additional code.
What do you think the purpose of copyleft (of which GPL is just a manifestation) was? The problems it adressed persist.
Now let me address the "freedoms" you're defending. There's always the quote "your freedom to wave your fist ends where my nose begins", but I'm not going to argue that in this case - let's assume users don't have freedoms like FSF asserts. Let's listen to you and focus on corporate freedoms:
You're saying people should have the "freedom" to leech, because this technically means the least amount of restrictions on a code. But in fact, what you're really defending is the right of authors of derivatives to restrict what their users can do. And you know what? I agree that they have that freedom: They built it, they should be able to do with it whatever they want. But the dissonance in your opinion is this: The author of the original piece of code which they built on also has the same right! So if you're going to defend people who impose restrictions that hurt end-users, why attack those that use the same right in the purpose of maximizing the freedoms of those same end-users?
So there are restrictions in both stories, just that BSD is asocial and GPL isn't: BSD says "do what thou wilt" and that inevitably favors the bully. Mind you, the bully (=the warlord in the case of anarchy) is going to impose his own rules. GPL says instead: Fair play rules are valid for everyone.
Having read TFA, this collaboration appears to be partly about build compatibility. So far, it sounds like LLVM/Clang has been imitating GCC options. But what happens when one or the other of them adds a new option or feature? That might break builds designed for the other one. So, it sounds like the two groups would like to start communicating and coordinating so that both systems can be compatible at a build level in the future. Implicit in this is that both would continue to exist as independent entities and that build compatibility would be a primary goal for both. Perhaps some deeper form of technical collaboration might even be possible in the future.
Then again, I may have that all wrong. I know nothing about it except what I learned from reading TFA. If that causes a problem, I'll try not to do it again.
RMS has been one of the most important men of the last 50 years or so.
His contribution to society is immense.
We need more like him to fight for our freedom.
Just imagine a world with only proprietary software.
Locked into golden prisons.
No thanks.
I'm not sure how GCC could benefit from this.
You are not reading history.
GCC moves too damn slow and doesn't include features that developers (and more importantly: the companies which pay developers) want. These days, that includes the changes between the GPLv2 and GPLv3 not being wanted by the people who pay the bills.
GCC was more or less started in 1984: http://www.gnu.org/gnu/thegnup...
GCC was almost replaced by the EGCS fork in 1997, and it took two years before RMS finally gave up on the idea of having the ultimate editorial control over the language implementation, and "blessed" EGCS as the replacement for GCC. When he did that, he gave up on limiting the OSs that the compiler worked on, and limiting the inclusion of things like #pragma (which used to exec "nethack" because RMS didn't like it), and some of the language front ends that are now included, like g77, which RMS didn't want.
GCC is on the verge of being marginalized again by LLVM; all the sexy compiler work is happening in LLVM, all the bright young minds in the compiler world are going to LLVM because it's a lot easier to make a front end for a new language or a back end for a different processor or embedded controller or virtual machine. LLVM is the "go-to" compiler for academic projects involving compiler research.
It makes sense; GCC: 1984; +15 years = EGCS: 1999; +15 years = ????: 2014.
RMS' recent appeal *might* be able to attract a bunch of new ideologues to the GCC project, and have them forsake LLVM work, but more likely course and project requirements for a degree, and after that, an employer, probably mean that LLVM is going to remain the "go-to" compiler for the new blood.
The idea that GCC can leverage some of the new blood by making it easier for them to work with code in both contexts, rather than leaving GCC in the ashbin of history, is about the *only* way to give GCC the transfusion of new blood it's going to need to survive another 15 years.
It also couldn't hurt to expand the number of (or replace) members of the "GCC steering committee" so that GCC can get a little more forward momentum. You can get forward momentum one of two ways: (1) more specific impulse, or (2) take off the parking brake.
Would they have BSD-licensed clang if there had not been the competing GPLed GCC? Who knows ...
The Tao of math: The numbers you can count are not the real numbers.
Actually, no. You may use GPL'd code any way you like (that's freedom 0) and share with others (freedom 2). You can likewise modify the software any way you like (freedom 1). And all this time, you need not release source code. The condition to release the source only kicks in with freedom to distribute your changes (freedom 3), so only when there is a third person involved with your derivative you have to grant them the same freedoms you've been given by the original author.
In fact, this was a problem with SaaS: You could've modified free software, and run it in the back on your servers, and say that you're simply providing a service to the end user, and since he's not getting the modified program, he doesn't get to have its source either. This is what AGPL is designed to address, and thus it's mostly used for web software. So with AGPL, as soon as you use a program, whether you have a copy, or are executing it online, you get access to the source.
On the contrary, that point is exactly *why* we GPL advocates advocate it. We don't want to enable companies which have no intention whatsoever to be part of the community. They're free to do everything themselves, and good luck to them. But giving them a leg up to get off the ground just so they can be selfish assholes with their ideas? Why should we? And yes, sharing your *ideas* and *implementations* is what we mean by being part of the community. If this isn't for you, then don't let the door hit you on the way out, thanks.
Except that you did it wrong.
BSD gives the author freedom, but screws the user. (1-1=0)
GP gives the author freedom, and preserves it for the user also. (1+1=2)
Really, this is simple math, there is no excuse for such a fundamental mistake.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.