Strange philosophy, imo. Feels very much like saying "My version of free is best, and I must force you to implement it yourself".
Ultimately Stallman was against a kind of digital feudalism, where whoever developed software had power over those that didn't
To which none can answer how it creates freedom without mass adoption to actually get the software into end users' hands. The great contradiction in FSF philosophy is to create highly pure software within a monastery of programmer-users while simultaneously insisting to focus on end-user freedoms without reconciling programmer incentives to build what these end users need.
So there doesn't need to be an answer. He can just show it to you.
It is Free Software whether it is BSD or GPL3. By all measures, Free Software as originally envisaged has been a massive success. It's just the goalposts have expanded over the years.
You clearly did not read the FSF manifestos and don't understand their positions. They will call the BSD license "permissive" and will correct you if you attempt to call BSD "free/libre".
> Why would it matter
The FSF didn't build "open source." They actively work to discredit open source. Let's not give them credit for what they tirelessly denounce.
Linux is open source, but did not adopt the GPL3. Firefox is open source but uses MPL. If the FSF is a leader who is responsible for all of these great projects, why doesn't anyone want to use their license?
Wrong. https://www.gnu.org/philosophy/categories.en.html
> The FSF didn't build "open source." They actively work to discredit open source. Let's not give them credit for what they tirelessly denounce.
Where did I ever use that term in this conversation?
You didn't because you glossed over my central point. Open source's success in the last twenty years came in spite of the FSF, not because of it.
If reality disproves your theory, it's not reality that's wrong.
What is your criteria for judgement here? The FSF GPL licenses, in reality have worked quite well, if the criteria is longevity, high usage, popularity, utility and maintained.
If your only criteria is "Well, they're only #2", then sure, by that criteria they did not "work".
What are you talking about? GCC usage is well ahead of LLVM usage.
And even if it wasn't ahead, it's still the default compiler for almost every production micro controller in use.
GCC is the default on most deployed systems today.
LLVM: 5k GCC: 1k
This is not what sustainability looks like:
https://trends.google.com/trends/explore?date=today%205-y&q=...
The crossover will more likely be driven by silicon trends providing an opportunity for LLVM's velocity to translate to enough competitive advantage for casual users to want LLVM. Once that happens, you will see some Linux distributions switch over. Hard liners will fork and do what they do, but asking people to use a compiler that gives them a worse result or is harder to work with isn't going to hold the gates.
Linus prefers LLVM for development.
People need to get out of the 90s and look at some data.
I can't see the future, but I can tell you without a doubt that, as things stand right now, the GPL has been a runaway success for users' rights.
Will that change in the future? Who knows? But that wasn't your claim nor my counterclaim.
As RMS indicated, this strategy had already resulted in the development of C++ front ends for the Free software ecosystem, that would otherwise likely not have come about.
At that time the boom in MIT/BSD-licensed open source software predominantly driving Web apps and SaaS in languages like Rust and Javascript was still far away. GCC therefore had very high leverage if you didn't want to be beholden to the Microsoft ecosystem (it's no accident Apple still ships compat drivers for gcc even today) and still ship something with high performance, so why give up that leverage towards your strategic goal for no reason?
The Linux developers were more forward-leaning on allowing plugins despite the license risks but even with a great deal of effort they kept running into issues with proprietary software 'abusing' the module APIs and causing them to respond with additional restrictions piled atop that API. So it's not as if it were a completely unreasonable fear on RMS's part.
(Not knocking them, i think sometimes being obnoxiously stubborn is the only way to change the world)
However, I quite value their stand. It's principled and they are, more or less, sincere about it. Many of their concerns about "open source" (as contrasted to free software) being locked up inside proprietary software etc. have come true.
The statement in question was issued during a period in which software vendors routinely demanded several hundred — and in some cases, thousands — of dollars[0] for access to a mere compiler. More often than not, the product thus acquired was of appalling quality — a shambolic assembly marred by defects, instability, and a conspicuous lack of professional rigour.
If one examines the design of GNU autoconf, particularly the myriad of checks it performs beyond those mandated by operating system idiosyncrasies, one observes a telling pattern — it does not merely assess environmental compatibility; it actively contends with compiler-specific bugs. This is not a testament to ingenuity, but rather an indictment of the abysmal standards that once prevailed amongst so-called commercial tool vendors.
In our present epoch, the notion that development tools should be both gratis and open source has become an expectation so deeply ingrained as to pass without remark. The viability and success of any emergent hardware platform now rests heavily — if not entirely — upon the availability of a free and competent development toolchain. In the absence of such, it shall not merely struggle — it shall perish, forgotten before it ever drew breath. Whilst a sparse handful of minor commercial entities yet peddle proprietary development environments, their strategy has adapted — they proffer these tools as components of a broader, ostensibly cohesive suite: an embedded operating system here, a bundled compiler there.
And yet — if you listen carefully — one still hears the unmistakable sounds of malcontent: curses uttered under breath and shouted aloud by those condemned to use these so-called «integrated» toolchains, frustrated by their inability to support contemporary language features, by their paltry libraries, or by some other failure born of commercial indifference.
GNU, by contrast, is not merely a project — it is a declaration of philosophy. One need not accept its ideological underpinnings to acknowledge its practical contributions. It is precisely due to this dichotomy that alternatives such as LLVM have emerged — and thrived.
[0] Throw in another several hundreds for a debugger, another several hundreds for a profiler and pray that they are even compatible with each other.