People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.
As someone who works within LLVM professionally, I don't think this is particularly likely -- compilers are massive and complicated beasts, and the "moat" for proprietary improvements is small: they're either niche and therefore not of interest to the majority of programmers, or they're sufficiently general and easiest to maintain by releasing back upstream (where Apple, Google, and Microsoft will pay a small army of compiler engineers to keep them working).
Your concern is the one that kept GCC from stabilizing its various intermediate representations for decades, which is why virtually all program analysis research happens in LLVM these days.
Edit: To elaborate on the above: neither Apple, nor Google, nor Microsoft wants to individually maintain LLVM. Microsoft appears (to this outsider) to be actively looking to replace (parts of) MSVC/cl with the LLVM ecosystem, because they're tired on maintaining their own optimizing compiler.
(Rust does maintain a fork of LLVM, but it's just a couple minor patches that typically get upstreamed eventually)
Of course none of it goes back to LLVM because updating your production copy of LLVM is just as messy and broken as the non-stable GCC IR you complain about and the fact that OSS development is still fundamentally incompatible with 1-year industry release schedules that shift all the time.
And you think if they didn't have the option of using LLVM they would have released an open source driver instead? That makes no sense to me.
But that's the exact choice Apple faced in 2005 and they did not choose gcc. They paid Chris Lattner and his team to develop an alternative compiler. Excerpt from wikipedia[1]:
>"Finally, GCC is licensed under the terms of GNU General Public License (GPL) version 3, which requires developers who distribute extensions for, or modified versions of, GCC to make their source code available, whereas LLVM has a BSD-like license which does not have such a requirement.
>Apple chose to develop a new compiler front end from scratch, supporting C, Objective-C and C++. This "clang" project was open-sourced in July 2007."
For some reason, the enthusiastic focus on the benefits of GPL principles seems to ignore the actual game theoretic behavior of actors in the real world to not choose GPL at all.
Of course the answer then reveals that this was only possible because there was comfy GCC to fall back on all along. They started in 2005, Clang became default in XCode with the 4.2 release in October 2011.
Ask yourself if you can sell your manager on 6 years of effort for no functional difference, likely even inferior.
Personally I don't care, but I bet many FOSS anti-GPL advocates will eventually care.
_ph_ meant to write "This way, they can at least upstream everything which doesn't fall under these restrictions." (note the deleted comma before "which"), i.e., they can at least upstream something instead of nothing.
As mentioned I don't care, after university my main UNIX platforms were HP-UX, Aix and Solaris with their respective system compilers anyway.
Linux is already getting replacement candidates in IoT space via Zephyr, NuttX, mbed, RTOS, Azure RTOS, and who knows if Fuchsia will eventually get out of the lab, so be it.
No, for practical purposes, there is not. You can only enforce delivery of the source when a product based on GPL software gets delivered. But of course companies, which create software, know about this. Any usage of GPL software for delivered products only happens after the decision to publish the created software has been made. In doubt, companies tend to not use GPL software as part of deliveries.
GPL advocates try to claim otherwise of course.
I keep wondering if Microsoft opens up the Windows Kernel ( And Kernel only ), would it change the landscape much.
On Android Linux is an implementation detail, most of it isn't exposed to userspace, not even on the NDK as Linux APIs aren't part of the stable interface specification.
And ART is being ported to run on top of Fuchsia as well (https://android-review.googlesource.com/q/fuchsia), so...
So the current options are: these companies don't open-source anything (which is what you get with GPL), or they open-source something (which is what you get with BSD, and in practice they open source a lot).
The claim that with the GPL they would open source _everything_ isn't true; they would just not open source anything instead. I also don't see any current legal framework that would allow them to opens ource everything without loosing a significant competitive advantage, and am very skeptical that such a framework can be conceived.
Since I am a commercial software user for most part, this is more of a philosophical question than anything else.
Lets see how long Linux will hold out against the new generation of IoT OSes all being MIT/BSD based, and what the bazaar will get out of them.
Or how long GCC will hold, when all major OSes use clang as their default compiler, and then how the baazar will go from there on.
I'm not sure this is true. See LLVM as an example. GCC existing and being GPL only meant that, e.g., Apple couldn't properly use it. Apple could have bought LLVM and kept it private, or develop their own proprietary solution and not make it open source, or fork the open source project into a private project and never contribute anything back, etc. There were many options.
Open source software has always existed, if anything, the GPL demonstrated that a particular open source model does not work well for a big part of the industry, while it works well for other parts, and non industrial usage.
Linux being successful seems incidental to it being GPL'ed, at least to me. Other open source OSes, like BSD 4.x, have also been quite successfull (powering the whole MacOS and iOS ecosystems, after a significant frankenstransform into Mach). Maybe Linux would have been even more succesfull with a BSD license, or maybe it would be dead.
I wouldn't consider BSD layer from NeXTSTEP an example of success for BSD's market adoption, given that not everything goes upstream, by now it hardly represents the current state of affairs.
If anything it represents what would have happened without Linux, all major UNIX vendors would continue to take pieces of BSD and not necessarily contribute anything back.
Its essentially what happens if (1) only one company wants to use the open source product, and (2) the open source product has a tiny community where no development happens.
In that scenario, there is no benefit from anybody forking the open source project (a private company or an individual) for upstreaming anything. It just costs time, but adds no value for them.
Linux and GCC never was like this (not even early days), and I think this is independent of its license. LLVM never was like this either.
In fact, there are many private companies that maintain a GCC fork, like arm, and due to the GPL need to provide its sources with a copy, which they do. But they are not required to reintegrate anything upstream, which they very often don't, and ARM support in gcc-arm from ARM is much better than on GCC upstream. A volunteer can't merge (review, rebase, ...) a 200k LOC patch on their free time, so once these forks diverge, its essentially game over. You'll need a team of volunteers equal in man power to what the private company provides.
So while the license affects which companies can use an open source project in practice, and what they can or cannot contribute. The GPL2 and GPL3 licenses are not a good tool to actually allow everybody to benefit from those contributions.
Maybe a GPL4 could require companies to upstream and get their contributions accepted, but IMO that would just get even less companies to use those projects.
BSD is Older than Linux:
https://en.wikipedia.org/wiki/History_of_the_Berkeley_Softwa...
Ah and there was that small legal issue back in the early 90's.
BTW: Market-share means nothing, you know Android is NOT Gnu/Linux
EDIT: Maybe your too young..but do you remember that SCO/Microsoft thingy with Linux
I surely remember it, except BSD did not ever had anyone like IBM jumping into the battle. :)
As for being young, thanks for the compliment
> ...as anyone coding since mid-80's....
And as information, during the early days, the Internet ran on commercial UNIXes.
They did not...the opposite is true, they shat their pants because shortly before they said "yes" to Linux, that's why SCO came...first time you had really big money (IBM) behind Linux, please don't change the timeline...it's kind of important.
>And as information, during the early days, the Internet ran on commercial UNIXes.
What do you wanna say with that? During the early days of Smartphones they ran on commercial OS's??
RIOT OS is LGPLv2.1.
Exactly; maintaining a fork is a big pain. The ongoing cost of keeping it up-to-date is a pretty big incentive to merge it, even if there's not a legal requirement.
with GPL you need a legal team to decide and plan how much to use, with BSD/MIT it can be an afterthought.
...keep them working for their use-cases.
Are you under the impression that C and C++ code within Apple, Microsoft, and Google is fundamentally different from C and C++ code elsewhere? Because it isn’t. Google’s engineers maintain LLVM’s ASan for their purposes, but those purposes happen to be everybody else’s as well.
This is not to say that I am not appreciative of all the work Google/Apple/etc engineers do in LLVM (I will be eternally grateful for the Clang targeting MSVC work).
The necessity of open source for industry has both negative and positive implications for those of us who care about open source / free software as an ideal and not simply a tool of capitalism. The negative one (which GCC's leadership failed to really internalize) is that the number of engineer-hours at the command of for-profit companies is much higher than the number of engineer-hours at the command of community-driven projects. If you deliberately build a worse product to prevent corporations from using it for profit, given enough time, the corporations will replace it. The positive one, though, is that those engineer-hours are generally more valuable when pointed at some common cross-company codebase unless it is the specific thing that makes you money, and FOSS as an ideal provides a well-accepted model under which they can organize cross-company work (doubly so when they employ idealists like us as implementors). A compiler makes very few people money directly. It's generally a tool that you want to work well, and it's helpful to have other people run into the majority of problems and fix them before they cause trouble for the things that do make money.
So it's not surprising that LLVM is catching up with GCC, nor is it surprising that LLVM is and remains open source. If you are concerned about the LLVM monoculture, build a competitor such that it is cheaper / more profitable for companies to work on your competitor than to either work on LLVM or build their own compiler. Figure out what will make companies want to contribute and encourage it. (GCC did not do this, but it is perhaps slowly relaxing here.) If you are concerned about LLVM becoming proprietary, make it so that is cheaper / more profitable for companies to release their changes instead of holding onto them; that is, figure out what will make companies feel like they must contribute and encourage it. (One common strategy, used by Linux itself, is to maintain a high level of internal API churn coupled with genuinely good improvements in that churn and a policy that people must update in-tree callers; at that point, the more API surface you use in your private fork, the farther behind you get, and you'll watch competing companies outpace you.)
Interesting angle that I had never thought of as deliberate. As someone who works on a (bespoke) integration/embedding of Chromium, I could say exactly the same thing about it too.
So that the ppl at Google would keep your code working? And you didn't need to spend time resolving git merge conflicts, and compilation errors?
But you cannot, because some of those bespoke changes are "secret" and what you make money from? (And maybe some changes are off topic to Google)
I wonder how much time does it take to merge a new chromium version into your repo? Like, hours? Days? Weeks
Also, the fact that Chromium is a high profile security critical software with occasional emergency security updates for bugs exploited in the wild, doesn't help at all when you want to maintain your own fork.
Furthermore, many non-GPL OSS projects have eventually gone proprietary (e.g. MongoDB's switch from AGPL to SSPL).
Every time it happens people are upset and then forget everything a day later. To me non-GPL + corporate involved is a huge flag, especially if it's a more complex or niche project that'd be difficult to fork.
https://www.linuxfoundation.org/membership/members/
and that:
https://www.linuxfoundation.org/blog/2016/08/the-top-10-deve...
Half the linux foundation's funding comes from 6 companies. Not to mention the full time employees paid to work on it. And I find that there's similar patterns in a lot of other widely used gpl software. Similarly, MIT/Apache software gets tons of contributions from non-corp people too.
LLVM is just a proprietary-able version of GCC. And thus compiler authors mostly focus on benchmarks while not caring about other metrics such as compilation speed, correctness and codebase quality / ease of contribution. There appears to be some tribal knowledge requirement to add a new target.
With all the hype and apple funding LLVM gets, it could have been better.
It isn't just that. It's also a compiler framework, somewhat usable as a library without being part of its codebase. And I really do mean somewhat usable; the LLVM experience for use as a library is not great, but it's wildly better than GCC's. I think that, not just the license, is a big part of what made LLVM successful.
The license was the biggest deal.
Sometimes in life it's better to be a bit heterodox, but have influence and leverage, than being alone on your high castle. GCC can be as open as it gets, but pushing people away in the name of freedom has actually only given reasons to the industry to move away from it, which is sad and could be avoided.
Sometimes in order to achieve your goals you must compromise or risk loosing the footing you already have, because you have close to zero chances of succeeding.
If RMS had compromised on GCC in the '00s, i.e. if GNU had spun off the C/C++/ObjC front end as a separate GPLv2-or-later library upon which something like clangd could have been made, Clang would have never existed. Yes, LLVM would have still been present, but as a special-case backend that used GCC as its frontend instead than its own, as they were planning to do since the beginning. All these improvements you talk about would have been done under the GPL, and not BSD licenses or proprietary. IDEs like Xcode and such would still be proprietary like they are nowadays, because there was a 0% chance of getting Apple or whomever to release them under the GPL.
It doesn't matter how much strong your moral principles are, or how much you value integrity. The world is definitely more pragmatic about software and values different things than RMS; while this might or might not be beneficial to our overall society, that's the way it is. Ignoring it is myopic, if it does not outright amount to shooting yourself in the foot.
The FSF is shooting themselves in the foot with the way they handle many of their projects today, GCC is no exception. Free software purity is a great goal and all, but what use is it when nobody uses it or it falls behind more permissively licenses projects.
If he could just stop being a zealot for a split second and actually tried to understand the situation, he could have maybe been able to foresee that Apple had the people, resources and will to reimplement a whole compiler infrastructure that could threaten GCC's dominance, but he neglected it (it famously didn't care about Apple's offer to merge LLVM into GCC under the GPL).
Sometimes even the best of intents are shadowed by people's inability to compromise.
Sometimes the hate for a license prevents people to grasp what is ahead of them.
https://www.phoronix.com/scan.php?page=news_item&px=Sony-Tha...
or that:
There are some talks from Sony at LLVM meetings regarding those.
That PR from Apple has nothing to do with the bitcode reference I made.
I don't know, maybe other AMD users would like to get them?
>might provide clues how to bipass PS 4 security
>AMD users would like to get them
They got em:
https://www.phoronix.com/scan.php?page=news_item&px=Sony-Tha...
https://www.phoronix.com/scan.php?page=news_item&px=LLVM-10-...
https://www.phoronix.com/scan.php?page=news_item&px=Sony-LLV...
Why do i want ANY PS4 specific security feautures in the Compiler??
LLVM's license was certainly a factor, and I'd never suggest otherwise, but there were many other reasons that GCC couldn't help kick off a wave of language design and experimentation the way LLVM did.
GNU Pascal, Modula-2, Modula-3, BASIC and plenty of OEM derived ones were never part of GCC source tree.
I had to study GIMPLE and GCC integration as part of my compiler design studies back in the 90's, using those nice Walnut Creek CD-ROMs.
No, some bits are open, and some bits track what's actually being shipped. Much of what is open sourced lags behind what is running on end user machines by several years. iOS modifications to XNU and Darwin were never made open source.
Apple is also dropping GPL internals in favor of open source but not copyleft licenses so that they don't have to release source code changes to the software they release.
Although this is probably not the best example because this is sold by the company that largely funds the open source project. Although that is a big conflict of interest.
https://blog.cloudflare.com/nginx-structural-enhancements-fo...
As commercial software user, I don't have much issue with it, after all I have been coding since the early 80's.
And in spite of it and my occasional Linux rants, I am thankful for GPL, because without it there wouldn't be a UNIX to install at home to get my university work from DG/UX done without having to spend one hour traveling into the campus and fighting for a terminal.
Without Linux + GNU based userspace, the commercial UNIXes would all be around.
Can you prove that? EMC, Netflix and Sony thinks otherwise.
EDIT: And please stop with that LMAO (Sound like a childish Child from reddit)
?? What?
>guess why
Because protecting your games is kind of important for a Gaming-Console.
Your answered your own question:
>No, something like the PS4 CPU features that don't get upstreamed because they might provide clues how to bipass PS 4 security.