On Fri, Apr 16, 2021 at 7:23 AM Ville Voutilainen via Gcc <gcc@gcc.gnu.org> wrote: > On the first part, other people have touched on it already, > but the fear of a dreaded non-free software vendor co-opting > GCC as a library to a non-free project has resulted in GCC > being unsuitable to be used as a library in free software > projects. This approach alone made sure that the meteoric > rise of LLVM happened; there are recorded statements > from LLVM developers trying to talk about this to RMS, > and the answer, as they phrased it, "wasn't useful", because > RMS decided that GCC shouldn't be a library to make it > harder to use it in conjunction with non-free programs. > > Congratulations, it remains hard to use in conjunction > with free programs, and everybody who wants to do something > like that looks at LLVM first. RMS made a lofty attempt to > promote copyleft software for such purposes, and failed > miserably, leading us into a situation where such problems > are not solved with copyleft software, but with LLVM instead.
I was under the (likely incorrect, please enlighten me) impression that the meteoric rise of LLVM had more to do with the license allowing corporate contributors to ship derived works in binary form without sharing proprietary code. Intel, IBM, nVidia, etc. are migrating towards LLVM for this purpose. To do so using GCC would (I believe; again, please correct me) require that they share more source code than they would have to under LLVM. This licensing model makes working on LLVM more attractive to companies that wish to keep proprietary code hidden, and thus LLVM garners a lot of corporate backing. It seems to me that technical differences (easier porting, or early claims of better diagnostics, for instance) and culture differences (let's just say that LLVM developers are more friendly, although I've never encountered a mean GCC developer) are not the driving force behind such strong support. As usual in the world, follow the money. If the idea is that GCC-as-a-Library would enable Intel, for example, to use GCC for their ICX OneAPI compiler the way they are now using LLVM, with significant portions of it hidden from the user, it seems to me that not supporting this is a very consistent GNU view. Allowing derived works that don't publish the full source code seems to be against the very spirit of GNU. If the GCC project opts to distance itself from various three letter acronyms, as a user, I have to wonder what that means in the future regarding the strict adherence to software freedoms that GCC has had for a long time now. I don't think I would suggest that there would be an immediate knee jerk reaction to change everything. Instead, it seems that https://en.wikipedia.org/wiki/Creeping_normality would take place to slowly change the "Freedom first" ideology over time. Maybe I'm jaded by the recent changes to CentOS, where RedHat applied a Microsoft tactic to embrace, extend, and extinguish it (at least in the form we previously knew). That took about ten years, but I can easily see how the same thing could happen over a long period of time to GCC (note that often when this has happened in history, including outside of the computing world, it was difficult or impossible to predict how it could end poorly. Padme's "thunderous applause" cheats, in that we saw the sequels first :) ) It would be good, therefore, to address upfront how the software freedoms of GCC users would be as consistently guaranteed in the future as they are now. Would a future GCC be committed to universally blocking any hypothetical positive technical improvement that also reduced user freedom?
