GCC & LLVM Developers May Begin Collaborating

[wizard69]

Well, the thing is, I think Stallman is spot on about Apple's hatred of open source (they will use BSD-licensed code while just meeting the release requirements, but having online store terms that are incompatible with the GPL).

Where do you get these ideas? Apple has been directly supporting open source code for years. CUPS is just one example. As to releasing code they are free to do so at anytime that pleases them and is compatible with the license for that code.

As for the store being incompatible with GPL who's fault is that? If anything GPL was changed to be hostile to things like the App Store. If you look at the history of VLC on iOS you will begins to see just how stupid the GPL is and the lengths that some people will go to undermine the efforts of others. To put it plainly your code isn't free at all if released under the GPL.

However, I for one (and I think quite a few others) do not consider the BSD license itself to be some big problem in and of itself as Stallman does. Merely collaborating between the LLVM and GCC developers is simply not an issue as far as I'm concerned.

Collaboration to a certain extent is OK. My problem is that I don't want either team to give up their vision for their suite just to make operation of the other easier. To much collaboration can be counter productive when it comes to innovation. It is a fine line to two camps would have to walk.

For contributors who do not object, they could go as far as dual-licensing contributions that apply to both (so GCC could use the contribution with GPL license, and LLVM with BSD license.)

I'm curious, since LLVM has been modular all along, and gcc has become more modular of late, is it possible to have a seperately-licensed "plugin" for either one?

If it is your code you can license it anyway you want.

It is here though that I begin to have problems, is it really a good idea to have plugin support that allows plugins to run on both platforms? I would say no. It not only truncated innovation it can leave compromised interfaces in place instead of optimized ones. The classic example here is web browsers where you end up with an extension interface that is more trouble than it is worth. Further the developer world already has good ways to make use of parts of a compiler suite, you pipe things together or have a make file leverage the components you want to use.

I don't have a problem with collaboration on things like command line switches, but each platform should also support a range of dedicated switches for suite only use.

[wizard69]

If I remember correctly, LLVM/Clang allows for proprietary (or separately licensed) plugins, but GCC requires plugins to be GPL.
Remember that article a little while ago where there was a guy asking the GCC devs to lessen their restrictions on plugins?

You would have to ask yourself why do the GCC developers even care what license a plug in has!😁. Really what next, will we be required to use GPL licensed text editors or IDE. Will Vim users be banned from using GCC.

In any event with all of these blatant restrictions in place you have to wonder how people even remotely feel that their code is free when released under GPL. It certainly isn't free to that plugin writer.

[wizard69]

I think this is a nice idea. The thing is, licenses are irrelevant in this context. They could just as well collaborate with Visual Studio developers. This is not about code, but about ideas. Sharing the plans of both is nice and can result in less compatibility problems down the road, as well as keep new features in sync. They will be created separately due to license and structural reasons, but that's fine as it will be possible to compare the implementations of both.

I'm not sure I buy into this, in fact I'm pretty sure I don't. There is no guarantee that sharing ideas results in wider innovation, in fact it can have the opposite effects as it channels people's energies into group think solutions. In other words we end up promoting thinking inside the box instead of outside the box.

There certainly are some advantages to look into. In the end though if the two suites end up following the same development paths from group think then what is the point in even having two free compiler suites? There has to be a level of independence so that each suite can mature in its own way. My biggest fear is that too much collaboration will lead identical systems that give up the opportunity to explore new paths.

[mrugiero]

Where do you get these ideas? Apple has been directly supporting open source code for years. CUPS is just one example. As to releasing code they are free to do so at anytime that pleases them and is compatible with the license for that code.

And they also has been directly avoiding to open source key pieces of their stack, but hey, they are the bastion of freedom.

As for the store being incompatible with GPL who's fault is that? If anything GPL was changed to be hostile to things like the App Store. If you look at the history of VLC on iOS you will begins to see just how stupid the GPL is and the lengths that some people will go to undermine the efforts of others. To put it plainly your code isn't free at all if released under the GPL.

Seriously? GPLv2 is also incompatible with Apple's store, and that's because they add extra restrictions. But of course the bad guys are the GPL guys for using an utterly restrictive and anti freedom license. Of course.

You would have to ask yourself why do the GCC developers even care what license a plug in has!😁. Really what next, will we be required to use GPL licensed text editors or IDE. Will Vim users be banned from using GCC.

In any event with all of these blatant restrictions in place you have to wonder how people even remotely feel that their code is free when released under GPL. It certainly isn't free to that plugin writer.

They care because it's still basically the same if they allow to write plugins under any license to allow any kind of extensions under any license. If they'd want non-GPL plugins, they may as well not use the GPL at all.

[GreatEmerald]

I'm not sure I buy into this, in fact I'm pretty sure I don't. There is no guarantee that sharing ideas results in wider innovation, in fact it can have the opposite effects as it channels people's energies into group think solutions. In other words we end up promoting thinking inside the box instead of outside the box.

There certainly are some advantages to look into. In the end though if the two suites end up following the same development paths from group think then what is the point in even having two free compiler suites? There has to be a level of independence so that each suite can mature in its own way. My biggest fear is that too much collaboration will lead identical systems that give up the opportunity to explore new paths.

Ignoring all of your previous posts that I completely disagree with...

Thinking inside the box is better than not thinking in the first place. Besides, this is not even that: one party thinks outside the box, then proposes the idea to the other side. The other side evaluates the idea, then proposes some changes to the idea. Discussion ensues. One party implements the idea. The other party may also implement it; they might drop the idea, if they disagree with it; or they might make a different adaptation. The two latter options mean that now we have interesting differences between them and can then test the feature to see which side has it done better. Once that is done, both parties discuss the results and decide what to do again: continue as they were or change something (drop the feature, improve the feature, or rewrite the feature using a radical new approach). Once again we have interesting diversity. In the end we have two compilers with the same functionality, but perfected to fit the individual projects the best. Then coders can use this feature and not bother with compiler differences.
Or, if one side dropped the feature along the way, we have two compilers with a different feature set, thus more diversity.

[crymsonpheonix]

No, it doesn't. The point is that the API/ABIs can (and do) break at every new release of GCC while they are stable with LLVM, but that's the only difference.

Wait what? You mean that I can just upgrade to LLVM 3.next and everything will just keep magically working? You mean I don't have to try to keep clang and gallium in lock step?

Wait, oh, right, no. LLVM blatantly breaks their APIs and ABIs between every minor release (3.3 is not compatible with 3.4). If you've ever worked with LLVM directly (not clang) it would be obvious that the LLVM developers believe that your should copy their entire codebase into yours, and update it whenever you feel like by copying the new version into your code.

[techzilla]

What what what???

No, it doesn't. The point is that the API/ABIs can (and do) break at every new release of GCC while they are stable with LLVM, but that's the only difference.

I can't speak for GCC, I'll let any aggrieved users speak for themselves. More importantly a project should never be compared to other project to justify it's own mistakes. A project should compare itself to it's aspirations, and work to achieve those ideal goals. With this said..

LLVM has more API breakage than ANY other project I know about, they would be the exact example of a project that never gives a crap about breaking an API. I'm raging again about this problem, it's like everyday I have to be mad about this when yet another project or feature is dropped. Or whenever I hear of a new project using LLVM, i think... how long can they possibly maintain that project? maintained code on LLVM requires company resources, it's just a simple fact.

[techzilla]

LLVM breaking APIs

Wait what? You mean that I can just upgrade to LLVM 3.next and everything will just keep magically working? You mean I don't have to try to keep clang and gallium in lock step?

Wait, oh, right, no. LLVM blatantly breaks their APIs and ABIs between every minor release (3.3 is not compatible with 3.4). If you've ever worked with LLVM directly (not clang) it would be obvious that the LLVM developers believe that your should copy their entire codebase into yours, and update it whenever you feel like by copying the new version into your code.

Yea, we both know you could never do that type of version upgrade.... and expect your project to finish compilation. This is actually the real problem with permissively licensed code, and is the reason they want projects to work from a full local repository. Permissively licensed code is supported for companies to develop better closed source products, it's just that simple. There is no community aspect, they're never was, hence why breaking API's is really no big concern. If you're a company developing a proprietary product, you'll have the resources to handle any of the problems. If your a community or student project, and you depend on an active community for maintenance, you're just not the concern.