Re: A suggestion for going forward from the RMS/FSF debate
> > > Of computer science graduates I have encountered over the last decade, I > > know few who started their journey with gcc and they were all in the > > initial part of the decade. In recent years I don't think I encountered > > any student who works on gcc; many even start with the assumption that > > gcc is in maintenance mode. > > For military focused PhDs, gcc is used. > Is this a real thing? I spent 15 year in academia (I left a few years ago), and I've never heard of a "military-focused PhD", especially in the context of computer science. I know of security-focused PhDs with intelligence applications, and I can imagine there are people out there working on AI/CV applications with military applications, but I think it's unlikely that those would require modifying a compiler. Applications in HPC might require deep compiler work and have potential military applications supporting AI/CV apps, but I wouldn't consider those "military-focused". I see things pretty much the same way as Siddhesh describes. > - Funding - llvm has a much stronger funding ecosystem than gcc. This > > includes direct funding from the foundation and development workforce > > from various organizations and universities. > > You will not get funding grants in the US if you mention free software, > because the US Department of Commerce does not allow it. > This is wildly inaccurate. Commerce has nothing to do with funding offered by other agencies. The NSF, which provides a significant portion of funding for CS research in the US, has embraced the release of research artifacts (read code) as open-source software. What's even better, the licensing on released work almost doesn't matter to the funding agency, unless they specifically enumerate limits and restrictions in their solicitations. For example, GCC's implementation of C++20 concepts was funded by NSF. I know because I was the postdoc funded to do that work. In fact, you can find NSF acknowledgments in the proposals I worked on. As a professor, I had NSF-funded work related to software-defined networking. All that code was also released open-source, albeit under an Apache or MIT license---I forget which. DoD and DoE almost certainly have restrictions. Corporate funding too, but I have less experience with those. Andrew
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Monday, April 19, 2021 at 4:58 AM > From: "Thomas Rodgers" > To: "Christopher Dimech" > Cc: "Siddhesh Poyarekar" , "GCC Development" > , "Ville Voutilainen" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 2021-04-18 00:38, Christopher Dimech via Gcc wrote: > > > Listen very carefully - In the first quarter of 2011, Keith Chuvala > > began discussing the need to drop all proprietary systems used to > > command > > the ISS. He specifically mentioned products from Microsoft and Red > > Hat. > > This was communicated to General Paul Martin, who then reported > > everything > > to the US House Subcommittee on Investigations and Oversight. > > And yet, here we are 10 years later, the ISS is still running RHEL... Like the One Laptop per Child established with the goal of transforming education for children around the world; which shut down. When you and your friends wake up in the morning you should never roll to the left because you could cause damage to the system. The right side is more stable. Good Night.
Re: A suggestion for going forward from the RMS/FSF debate
On 2021-04-18 00:38, Christopher Dimech via Gcc wrote: Listen very carefully - In the first quarter of 2011, Keith Chuvala began discussing the need to drop all proprietary systems used to command the ISS. He specifically mentioned products from Microsoft and Red Hat. This was communicated to General Paul Martin, who then reported everything to the US House Subcommittee on Investigations and Oversight. And yet, here we are 10 years later, the ISS is still running RHEL...
Re: A suggestion for going forward from the RMS/FSF debate
On 2021-04-17 20:10, Christopher Dimech via Gcc wrote: You have specified that the community does not require my approval or that of Eric Raymond. That is true of course. But many have gone through so much new age training that they ended up with a very sophisticated way of bullshitting themselves. Regards Christopher I'll see my work in GCC11 through (there's one remaining patch review to address this week); I don't like leaving things in a half assed state if I can avoid it. The work to finish out C++20 library support features which passed through the Concurrency and Parallelism study group (SG-1) in WG21 on their way to being standardized will be, for now, done in a public repo with GPL license sans-FSF assignment. Other work which I have initiated to replace the dependency on Thread Building Blocks within the Parallel STL algorithms (PSTL); something required for this part of libstdc++ to no longer be marked 'experimental' will not be done with a GPL license and will not, as a result, be assigned to the FSF. Using a GPL and assigning copyright are two different things though. Uhm, well, Duh? I guess...not sure what your point is, but mine is - I'm only going to do one of those things for the time being for libstdc++ work, and do precisely neither of those things on the runtime component I expect to eventually replace TBB with in the PSTL. It is my hope, and expectation, that that work will become part of GCC12 and GCC13 respectively, and I will know in the fullness of time if that expectation is to be met.
Re: A suggestion for going forward from the RMS/FSF debate
Some had contacted me about it. Could have sent response off the list. > Sent: Monday, April 19, 2021 at 1:05 AM > From: "Richard Kenner" > To: dim...@gmx.com > Cc: gcc@gcc.gnu.org, siddh...@gotplt.org, ville.voutilai...@gmail.com > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > It is an argument against the idea that LLVM is the default way that > > people choose. > > I don't think that anybody made the argument that LLVM is the "default" > in any sense. What's being given here are reasons why some people > prefer LLVM over GCC. > > > In those places, they don't trust Microsoft or anybody that provides > > software products that are difficult or impossible to review. Free > > software is not prohibited, since the government has access to the > > source code. Any tool that comes compiled is not acceptable there. > > For a compiler, of course, you need a compiled version of it to start > with. If you use that same compiler to build itself, having the > source code does *not* protect you from malware, as Ken Thompson > showed back in 1984. Even if you take the stance that you'll compile > GCC with LLVM and vice versa, you still have the risk that both of the > binaries have been compromised in this way. There are tools that look for code that is not supposed to be there. But people get sloppy and it's a lot of bother. That's been my experience.
Re: A suggestion for going forward from the RMS/FSF debate
But that was around 2017. Perhaps people want to cut costs again - that's not a new thing. After all, they changed their mind in 2011 only because they got in excess of 5000 attacks that year. At any time in the past, I would have decided that science was good for the Sapiens. But now, with hindsight... > Sent: Sunday, April 18, 2021 at 11:06 PM > From: "Ville Voutilainen" > To: "Richard Kenner" > Cc: "Christopher Dimech" , "GCC Development" > , siddh...@gotplt.org > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Sun, 18 Apr 2021 at 13:49, Richard Kenner > wrote: > > > > > Depends on the use cases. Not in military surveillance. And certainly > > > not > > > at Lawrence Livermore National Laboratory. At Boeing could be the same, > > > but > > > I'm not sure. Before 2011, rather than building things from scratch, > > > washington bureaucrats simply picked from among existing technology. But > > > things had really been going berserk around 2008. From 2017 onwards, > > > I'm somewhat in the dark. They could have started allowing some ownership > > > rights, but ownership rights under government contracts are very different > > > than ownership rights under commercial contracts. > > > > I can't understand your point with this version either. Sorry. > > I don't understand these ramblings either. LLNL sure seems to have > flirted with LLVM: > https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology > https://www.osti.gov/servlets/purl/1608523 > https://github.com/rose-compiler/rose/wiki/Install-ROSE-with-Clang-as-frontend >
Re: A suggestion for going forward from the RMS/FSF debate
> It is an argument against the idea that LLVM is the default way that > people choose. I don't think that anybody made the argument that LLVM is the "default" in any sense. What's being given here are reasons why some people prefer LLVM over GCC. > In those places, they don't trust Microsoft or anybody that provides > software products that are difficult or impossible to review. Free > software is not prohibited, since the government has access to the > source code. Any tool that comes compiled is not acceptable there. For a compiler, of course, you need a compiled version of it to start with. If you use that same compiler to build itself, having the source code does *not* protect you from malware, as Ken Thompson showed back in 1984. Even if you take the stance that you'll compile GCC with LLVM and vice versa, you still have the risk that both of the binaries have been compromised in this way.
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Sunday, April 18, 2021 at 10:49 PM > From: "Richard Kenner" > To: dim...@gmx.com > Cc: gcc@gcc.gnu.org, siddh...@gotplt.org, ville.voutilai...@gmail.com > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > Depends on the use cases. Not in military surveillance. And certainly not > > at Lawrence Livermore National Laboratory. At Boeing could be the same, but > > I'm not sure. Before 2011, rather than building things from scratch, > > washington bureaucrats simply picked from among existing technology. But > > things had really been going berserk around 2008. From 2017 onwards, > > I'm somewhat in the dark. They could have started allowing some ownership > > rights, but ownership rights under government contracts are very different > > than ownership rights under commercial contracts. > > I can't understand your point with this version either. Sorry. It is an argument against the idea that LLVM is the default way that people choose. In those places, gcc is used. No Microsoft (i.e. no Fortran Developer Studio, or LLVM). Before, I was using Microsoft Developer studio as a student. In those places, they don't trust Microsoft or anybody that provides software products that are difficult or impossible to review. Free software is not prohibited, since the government has access to the source code. Any tool that comes compiled is not acceptable there.
Re: A suggestion for going forward from the RMS/FSF debate
On Sun, 18 Apr 2021 at 13:49, Richard Kenner wrote: > > > Depends on the use cases. Not in military surveillance. And certainly not > > at Lawrence Livermore National Laboratory. At Boeing could be the same, but > > I'm not sure. Before 2011, rather than building things from scratch, > > washington bureaucrats simply picked from among existing technology. But > > things had really been going berserk around 2008. From 2017 onwards, > > I'm somewhat in the dark. They could have started allowing some ownership > > rights, but ownership rights under government contracts are very different > > than ownership rights under commercial contracts. > > I can't understand your point with this version either. Sorry. I don't understand these ramblings either. LLNL sure seems to have flirted with LLVM: https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology https://www.osti.gov/servlets/purl/1608523 https://github.com/rose-compiler/rose/wiki/Install-ROSE-with-Clang-as-frontend
Re: A suggestion for going forward from the RMS/FSF debate
> Depends on the use cases. Not in military surveillance. And certainly not > at Lawrence Livermore National Laboratory. At Boeing could be the same, but > I'm not sure. Before 2011, rather than building things from scratch, > washington bureaucrats simply picked from among existing technology. But > things had really been going berserk around 2008. From 2017 onwards, > I'm somewhat in the dark. They could have started allowing some ownership > rights, but ownership rights under government contracts are very different > than ownership rights under commercial contracts. I can't understand your point with this version either. Sorry.
Re: A suggestion for going forward from the RMS/FSF debate
> You will not get funding grants in the US if you mention free software, > because the US Department of Commerce does not allow it. This is not correct and I suspect is a misunderstanding of what "government data rights" means.
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Sunday, April 18, 2021 at 7:53 PM > From: "Siddhesh Poyarekar" > To: "Christopher Dimech" > Cc: "NightStrike" , "Ville Voutilainen" > , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 4/18/21 1:08 PM, Christopher Dimech wrote: > >> The cause IMO is accessibility to other projects, most notably compiler > >> researchers and students who find it a lot easier to target llvm than > >> gcc because compiler-as-a-library. License may have been a factor for > >> some of those uses (e.g. I know some who think copyleft is not free > >> enough and BSD style licensing is the *real* freedom), but concluding > >> that it is the major reason is to delude ourselves. > > > > Originally, the LLVM License was derived from the X11 License and the > > 3-Clause BSD License, both licenses conforming to the definition of > > free software. Apple officially hired Chris Lattner in 2005, giving > > him a team to work on LLVM. > > It is irrelevant to the point I'm making. If you're trying to assert > that Lattner's hiring by Apple was the driving force behind the current > llvm adoption then like I said before, it's blinkered. Read my response > again for a deeper context. > > >> It is also the reason why gcc does not even figure in situations where a > >> larger project would need AOT or JIT compilation; we had to concede that > >> ground all because of the FSF/GNU fears that companies would make > >> proprietary compilers out of a gcc compiler-as-a-library. > > > > Listen very carefully - In the first quarter of 2011, Keith Chuvala > > began discussing the need to drop all proprietary systems used to command > > the ISS. He specifically mentioned products from Microsoft and Red Hat. > > This was communicated to General Paul Martin, who then reported everything > > to the US House Subcommittee on Investigations and Oversight. > > I can't parse what you're saying in response to my point about llvm > being the default choice for all modern use cases of compiler technologies. Depends on the use cases. Not in military surveillance. And certainly not at Lawrence Livermore National Laboratory. At Boeing could be the same, but I'm not sure. Before 2011, rather than building things from scratch, washington bureaucrats simply picked from among existing technology. But things had really been going berserk around 2008. From 2017 onwards, I'm somewhat in the dark. They could have started allowing some ownership rights, but ownership rights under government contracts are very different than ownership rights under commercial contracts. > Siddhesh >
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Sunday, April 18, 2021 at 9:06 PM > From: "Jonathan Wakely via Gcc" > To: "Aaron Gyes" > Cc: "gcc@gcc.gnu.org" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Sun, 18 Apr 2021, 10:01 Christopher Dimech via Gcc, > wrote: > > > You don't have to believe me of course. Go ask any lawyer worth her > > salt and she'll tell you the same thing! > > > > > And if they don't tell you the same thing, they're obviously not a true > Scotsman. A lawyer can trick anybody to do anything. That's why you should have your own. ;)
Re: A suggestion for going forward from the RMS/FSF debate
On Sun, 18 Apr 2021, 10:01 Christopher Dimech via Gcc, wrote: > You don't have to believe me of course. Go ask any lawyer worth her > salt and she'll tell you the same thing! > And if they don't tell you the same thing, they're obviously not a true Scotsman.
Re: A suggestion for going forward from the RMS/FSF debate
You don't have to believe me of course. Go ask any lawyer worth her salt and she'll tell you the same thing! > Sent: Sunday, April 18, 2021 at 7:53 PM > From: "Aaron Gyes" > To: "Christopher Dimech" > Cc: gcc@gcc.gnu.org > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > If the purpose was to facilitate lawsuits, and these lawsuits haven’t > occurred after all these years, it seems like it didn’t work. Maybe you are > wrong about the intent? > > Aaron > > > On Apr 18, 2021, at 12:50 AM, Christopher Dimech wrote: > > > > > > I know that Apple can make some strong ownership claims. Also Red Hat, > > but I consider it minimal. Apple has a very long history of aggressive > > legal actions. > > > >> Sent: Sunday, April 18, 2021 at 7:24 PM > >> From: "Aaron Gyes" > >> To: "Christopher Dimech" > >> Subject: Re: A suggestion for going forward from the RMS/FSF debate > >> > >> Can you tell me about some of the lawsuits that resulted? > >> > >> – > >> Aaron > >> > >>> On Apr 18, 2021, at 12:08 AM, Christopher Dimech wrote: > >>> > >>> > > Sent: Sunday, April 18, 2021 at 5:46 PM > From: "Aaron Gyes" > To: "Christopher Dimech" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > Furthermore, it continues to nullify the Apache License by allowing > > patent > > treachery. The LLVM License is thus a perfidious license intended to > > allow the licensor to sue you at their choosing.= > > “Patent treachery”? And the intent of the license is to... accommodate > lawsuits? > >>> > >>> Correct. The Apache License included certain patent termination and > >>> counterclaim provisions, made void and null by the LLVM Exceptions. > >>> Originally, the LLVM License > >>> was based on the two free software licenses - the X11 license and the > >>> 3-clause BSD license. By 2005, Apple managed to hamstring the project by > >>> hiring Chris Lattner > >>> and giving him a team to work on LLVM. > >>> > That’s some very motivated reasoning you’re doing right there. > > Aaron > >> > >
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Sunday, April 18, 2021 at 7:53 PM > From: "Siddhesh Poyarekar" > To: "Christopher Dimech" > Cc: "NightStrike" , "Ville Voutilainen" > , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 4/18/21 1:08 PM, Christopher Dimech wrote: > >> The cause IMO is accessibility to other projects, most notably compiler > >> researchers and students who find it a lot easier to target llvm than > >> gcc because compiler-as-a-library. License may have been a factor for > >> some of those uses (e.g. I know some who think copyleft is not free > >> enough and BSD style licensing is the *real* freedom), but concluding > >> that it is the major reason is to delude ourselves. > > > > Originally, the LLVM License was derived from the X11 License and the > > 3-Clause BSD License, both licenses conforming to the definition of > > free software. Apple officially hired Chris Lattner in 2005, giving > > him a team to work on LLVM. > > It is irrelevant to the point I'm making. If you're trying to assert > that Lattner's hiring by Apple was the driving force behind the current > llvm adoption then like I said before, it's blinkered. Read my response > again for a deeper context. Of course not, but those who adopt it are for the most part ignorant of the actual details. Use it. I won't. > >> It is also the reason why gcc does not even figure in situations where a > >> larger project would need AOT or JIT compilation; we had to concede that > >> ground all because of the FSF/GNU fears that companies would make > >> proprietary compilers out of a gcc compiler-as-a-library. > > > > Listen very carefully - In the first quarter of 2011, Keith Chuvala > > began discussing the need to drop all proprietary systems used to command > > the ISS. He specifically mentioned products from Microsoft and Red Hat. > > This was communicated to General Paul Martin, who then reported everything > > to the US House Subcommittee on Investigations and Oversight. > > I can't parse what you're saying in response to my point about llvm > being the default choice for all modern use cases of compiler technologies. Well. You're wrong and I'm right. LLVM is for suckers. When one is ignorant, one keeps to the default. Then, when things don't work out as you think, don't blame me. > Siddhesh >
Re: A suggestion for going forward from the RMS/FSF debate
Please refer to the *Exemptions* section listed in the link below https://www.commerce.gov/about/policies/source-code - Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Sunday, April 18, 2021 at 7:46 PM > From: "Siddhesh Poyarekar" > To: "Gabriel Ravier" , gcc@gcc.gnu.org > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 4/18/21 1:15 PM, Gabriel Ravier via Gcc wrote: > > I'd like to see a source for that. It certainly seems like complete > > bullshit to me, unless you're trying to tell me that they simultaneously > > do not fund anything related to free software while also having policy > > that mandates at least 20 percent of custom-developed code (i.e. code > > they fund the production of) has to be released as OSS (see > > https://www.commerce.gov/about/policies/source-code) > > You see Free != OSS... > >
Re: A suggestion for going forward from the RMS/FSF debate
On 4/18/21 1:08 PM, Christopher Dimech wrote: The cause IMO is accessibility to other projects, most notably compiler researchers and students who find it a lot easier to target llvm than gcc because compiler-as-a-library. License may have been a factor for some of those uses (e.g. I know some who think copyleft is not free enough and BSD style licensing is the *real* freedom), but concluding that it is the major reason is to delude ourselves. Originally, the LLVM License was derived from the X11 License and the 3-Clause BSD License, both licenses conforming to the definition of free software. Apple officially hired Chris Lattner in 2005, giving him a team to work on LLVM. It is irrelevant to the point I'm making. If you're trying to assert that Lattner's hiring by Apple was the driving force behind the current llvm adoption then like I said before, it's blinkered. Read my response again for a deeper context. It is also the reason why gcc does not even figure in situations where a larger project would need AOT or JIT compilation; we had to concede that ground all because of the FSF/GNU fears that companies would make proprietary compilers out of a gcc compiler-as-a-library. Listen very carefully - In the first quarter of 2011, Keith Chuvala began discussing the need to drop all proprietary systems used to command the ISS. He specifically mentioned products from Microsoft and Red Hat. This was communicated to General Paul Martin, who then reported everything to the US House Subcommittee on Investigations and Oversight. I can't parse what you're saying in response to my point about llvm being the default choice for all modern use cases of compiler technologies. Siddhesh
Re: A suggestion for going forward from the RMS/FSF debate
If the purpose was to facilitate lawsuits, and these lawsuits haven’t occurred after all these years, it seems like it didn’t work. Maybe you are wrong about the intent? Aaron > On Apr 18, 2021, at 12:50 AM, Christopher Dimech wrote: > > > I know that Apple can make some strong ownership claims. Also Red Hat, > but I consider it minimal. Apple has a very long history of aggressive > legal actions. > >> Sent: Sunday, April 18, 2021 at 7:24 PM >> From: "Aaron Gyes" >> To: "Christopher Dimech" >> Subject: Re: A suggestion for going forward from the RMS/FSF debate >> >> Can you tell me about some of the lawsuits that resulted? >> >> – >> Aaron >> >>> On Apr 18, 2021, at 12:08 AM, Christopher Dimech wrote: >>> >>> Sent: Sunday, April 18, 2021 at 5:46 PM From: "Aaron Gyes" To: "Christopher Dimech" Subject: Re: A suggestion for going forward from the RMS/FSF debate > Furthermore, it continues to nullify the Apache License by allowing patent > treachery. The LLVM License is thus a perfidious license intended to > allow the licensor to sue you at their choosing.= “Patent treachery”? And the intent of the license is to... accommodate lawsuits? >>> >>> Correct. The Apache License included certain patent termination and >>> counterclaim provisions, made void and null by the LLVM Exceptions. >>> Originally, the LLVM License >>> was based on the two free software licenses - the X11 license and the >>> 3-clause BSD license. By 2005, Apple managed to hamstring the project by >>> hiring Chris Lattner >>> and giving him a team to work on LLVM. >>> That’s some very motivated reasoning you’re doing right there. Aaron >>
Re: A suggestion for going forward from the RMS/FSF debate
> Correct. The Apache License included certain patent termination and > counterclaim provisions, made void and null by the LLVM Exceptions. > Originally, the LLVM License > was based on the two free software licenses - the X11 license and the > 3-clause BSD license. By 2005, Apple managed to hamstring the project by > hiring Chris Lattner > and giving him a team to work on LLVM. Can you tell me about some of the lawsuits that resulted? – Aaron
Re: A suggestion for going forward from the RMS/FSF debate
On 4/18/21 1:15 PM, Gabriel Ravier via Gcc wrote: I'd like to see a source for that. It certainly seems like complete bullshit to me, unless you're trying to tell me that they simultaneously do not fund anything related to free software while also having policy that mandates at least 20 percent of custom-developed code (i.e. code they fund the production of) has to be released as OSS (see https://www.commerce.gov/about/policies/source-code) You see Free != OSS...
Re: A suggestion for going forward from the RMS/FSF debate
On 4/18/21 8:44 AM, Christopher Dimech via Gcc wrote: Sent: Sunday, April 18, 2021 at 6:09 PM From: "Siddhesh Poyarekar" To: "NightStrike" , "Ville Voutilainen" Cc: "GCC Development" Subject: Re: A suggestion for going forward from the RMS/FSF debate On 4/17/21 12:11 AM, NightStrike via Gcc wrote: 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 I think this is a blinkered view. Sure, there are companies that build proprietary toolchains using llvm as the base but I would argue that it is the *result* of the rise of llvm and not the cause. The cause IMO is accessibility to other projects, most notably compiler researchers and students who find it a lot easier to target llvm than gcc because compiler-as-a-library. License may have been a factor for some of those uses (e.g. I know some who think copyleft is not free enough and BSD style licensing is the *real* freedom), but concluding that it is the major reason is to delude ourselves. It is also the reason why gcc does not even figure in situations where a larger project would need AOT or JIT compilation; we had to concede that ground all because of the FSF/GNU fears that companies would make proprietary compilers out of a gcc compiler-as-a-library. Of computer science graduates I have encountered over the last decade, I know few who started their journey with gcc and they were all in the initial part of the decade. In recent years I don't think I encountered any student who works on gcc; many even start with the assumption that gcc is in maintenance mode. For military focused PhDs, gcc is used. So to summarize, the reasons why llvm is gaining traction *today* (I'm sure there are more): - Compiler-as-a-library - llvm is the first choice in FOSS projects and use cases are exploding with gcc nowhere in sight - Mindshare - most students and researchers are focused on it - Funding - llvm has a much stronger funding ecosystem than gcc. This includes direct funding from the foundation and development workforce from various organizations and universities. You will not get funding grants in the US if you mention free software, because the US Department of Commerce does not allow it. I'd like to see a source for that. It certainly seems like complete bullshit to me, unless you're trying to tell me that they simultaneously do not fund anything related to free software while also having policy that mandates at least 20 percent of custom-developed code (i.e. code they fund the production of) has to be released as OSS (see https://www.commerce.gov/about/policies/source-code) - License - Companies are building proprietary solutions on top of llvm. Siddhesh
Re: A suggestion for going forward from the RMS/FSF debate
- Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Sunday, April 18, 2021 at 6:09 PM > From: "Siddhesh Poyarekar" > To: "NightStrike" , "Ville Voutilainen" > > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 4/17/21 12:11 AM, NightStrike via Gcc wrote: > > 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 > > I think this is a blinkered view. Sure, there are companies that build > proprietary toolchains using llvm as the base but I would argue that it > is the *result* of the rise of llvm and not the cause. > The cause IMO is accessibility to other projects, most notably compiler > researchers and students who find it a lot easier to target llvm than > gcc because compiler-as-a-library. License may have been a factor for > some of those uses (e.g. I know some who think copyleft is not free > enough and BSD style licensing is the *real* freedom), but concluding > that it is the major reason is to delude ourselves. Originally, the LLVM License was derived from the X11 License and the 3-Clause BSD License, both licenses conforming to the definition of free software. Apple officially hired Chris Lattner in 2005, giving him a team to work on LLVM. > It is also the reason why gcc does not even figure in situations where a > larger project would need AOT or JIT compilation; we had to concede that > ground all because of the FSF/GNU fears that companies would make > proprietary compilers out of a gcc compiler-as-a-library. Listen very carefully - In the first quarter of 2011, Keith Chuvala began discussing the need to drop all proprietary systems used to command the ISS. He specifically mentioned products from Microsoft and Red Hat. This was communicated to General Paul Martin, who then reported everything to the US House Subcommittee on Investigations and Oversight. > Of computer science graduates I have encountered over the last decade, I > know few who started their journey with gcc and they were all in the > initial part of the decade. In recent years I don't think I encountered > any student who works on gcc; many even start with the assumption that > gcc is in maintenance mode. > > So to summarize, the reasons why llvm is gaining traction *today* (I'm > sure there are more): > > - Compiler-as-a-library - llvm is the first choice in FOSS projects and > use cases are exploding with gcc nowhere in sight > > - Mindshare - most students and researchers are focused on it > > - Funding - llvm has a much stronger funding ecosystem than gcc. This > includes direct funding from the foundation and development workforce > from various organizations and universities. > > - License - Companies are building proprietary solutions on top of llvm. > > Siddhesh >
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Sunday, April 18, 2021 at 6:09 PM > From: "Siddhesh Poyarekar" > To: "NightStrike" , "Ville Voutilainen" > > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 4/17/21 12:11 AM, NightStrike via Gcc wrote: > > 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 > > I think this is a blinkered view. Sure, there are companies that build > proprietary toolchains using llvm as the base but I would argue that it > is the *result* of the rise of llvm and not the cause. > > The cause IMO is accessibility to other projects, most notably compiler > researchers and students who find it a lot easier to target llvm than > gcc because compiler-as-a-library. License may have been a factor for > some of those uses (e.g. I know some who think copyleft is not free > enough and BSD style licensing is the *real* freedom), but concluding > that it is the major reason is to delude ourselves. > > It is also the reason why gcc does not even figure in situations where a > larger project would need AOT or JIT compilation; we had to concede that > ground all because of the FSF/GNU fears that companies would make > proprietary compilers out of a gcc compiler-as-a-library. > > Of computer science graduates I have encountered over the last decade, I > know few who started their journey with gcc and they were all in the > initial part of the decade. In recent years I don't think I encountered > any student who works on gcc; many even start with the assumption that > gcc is in maintenance mode. For military focused PhDs, gcc is used. > So to summarize, the reasons why llvm is gaining traction *today* (I'm > sure there are more): > > - Compiler-as-a-library - llvm is the first choice in FOSS projects and > use cases are exploding with gcc nowhere in sight > > - Mindshare - most students and researchers are focused on it > > - Funding - llvm has a much stronger funding ecosystem than gcc. This > includes direct funding from the foundation and development workforce > from various organizations and universities. You will not get funding grants in the US if you mention free software, because the US Department of Commerce does not allow it. > - License - Companies are building proprietary solutions on top of llvm. > > Siddhesh >
Re: A suggestion for going forward from the RMS/FSF debate
On 4/17/21 12:11 AM, NightStrike via Gcc wrote: 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 I think this is a blinkered view. Sure, there are companies that build proprietary toolchains using llvm as the base but I would argue that it is the *result* of the rise of llvm and not the cause. The cause IMO is accessibility to other projects, most notably compiler researchers and students who find it a lot easier to target llvm than gcc because compiler-as-a-library. License may have been a factor for some of those uses (e.g. I know some who think copyleft is not free enough and BSD style licensing is the *real* freedom), but concluding that it is the major reason is to delude ourselves. It is also the reason why gcc does not even figure in situations where a larger project would need AOT or JIT compilation; we had to concede that ground all because of the FSF/GNU fears that companies would make proprietary compilers out of a gcc compiler-as-a-library. Of computer science graduates I have encountered over the last decade, I know few who started their journey with gcc and they were all in the initial part of the decade. In recent years I don't think I encountered any student who works on gcc; many even start with the assumption that gcc is in maintenance mode. So to summarize, the reasons why llvm is gaining traction *today* (I'm sure there are more): - Compiler-as-a-library - llvm is the first choice in FOSS projects and use cases are exploding with gcc nowhere in sight - Mindshare - most students and researchers are focused on it - Funding - llvm has a much stronger funding ecosystem than gcc. This includes direct funding from the foundation and development workforce from various organizations and universities. - License - Companies are building proprietary solutions on top of llvm. Siddhesh
Re: A suggestion for going forward from the RMS/FSF debate
> Furthermore, it continues to nullify the Apache License by allowing patent > treachery. The LLVM License is thus a perfidious license intended to > allow the licensor to sue you at their choosing.= “Patent treachery”? And the intent of the license is to... accommodate lawsuits? That’s some very motivated reasoning you’re doing right there. Aaron
Re: A suggestion for going forward from the RMS/FSF debate
On 2021-04-17 12:08, Christopher Dimech wrote: Thomas, So we are decided? I am not pushing anybody down the cliff - rms, you or anybody. I simply wish that after a few world wars, people start seeing the light and things will be somewhat blissed out working on free software. In a lot of ways this is pretty simple for me. Having observed a few weeks of the FSF's ham-fisted response to the ham-fisted way in which they handled a this entire matter, makes it very easy for *me* to arrive at the stance that the *current state* of the FSF is such that I don't personally believe it has the ability to be a good steward of the work that is assigned to it going forward, and so *I* am not going to do that thing in particular as long as that remains the case. I'll see my work in GCC11 through (there's one remaining patch review to address this week); I don't like leaving things in a half assed state if I can avoid it. The work to finish out C++20 library support features which passed through the Concurrency and Parallelism study group (SG-1) in WG21 on their way to being standardized will be, for now, done in a public repo with GPL license sans-FSF assignment. Other work which I have initiated to replace the dependency on Thread Building Blocks within the Parallel STL algorithms (PSTL); something required for this part of libstdc++ to no longer be marked 'experimental' will not be done with a GPL license and will not, as a result, be assigned to the FSF. It is my hope, and expectation, that that work will become part of GCC12 and GCC13 respectively, and I will know in the fullness of time if that expectation is to be met.
Re: A suggestion for going forward from the RMS/FSF debate
On 2021-04-17 10:40, Ville Voutilainen via Gcc wrote: On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote: I do not see people really intending to fork. It explains why detractors have gone berserk. I appreciate your colorful exaggerations, but I should point out that the libstdc++ maintainer has stated his intention to fork, in unambigous terms. A helper elf of his has stated that he will follow the fork, if it occurs. I'm politely entertaining the possibility that you missed that, but Mr. Wakely is not joking when he indicates that he wishes to do a non-FSF fork of lbistdc++. On the helper elf front, I can concretely state that I will not (for the foreseeable future) be assigning copyright to FSF on *new* concurrency and parallelism related features in libstdc++ or the support libraries for this work to the FSF.
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Sunday, April 18, 2021 at 5:40 AM > From: "Ville Voutilainen" > To: "Christopher Dimech" > Cc: "Jason Merrill" , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote: > > I do not see people really intending to fork. It explains why detractors > > have gone berserk. > > I appreciate your colorful exaggerations, but I should point out that > the libstdc++ > maintainer has stated his intention to fork, in unambigous terms. A helper > elf of his has stated that he will follow the fork, if it occurs. I'm > politely entertaining > the possibility that you missed that, but Mr. Wakely is not joking > when he indicates > that he wishes to do a non-FSF fork of lbistdc++. Talk facts not rhetoric. What I have seen is people trying to resolve the problem without resorting to an actual complete fork. For this to happen, people would have to agree on things they would not be completely satisfied about. If the fork is presented as a threat, things are not going to work well. I am not complaining about a decision, whatever that is. But parading nuclear missiles means nothing - that I should know.
Re: A suggestion for going forward from the RMS/FSF debate
On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote: > I do not see people really intending to fork. It explains why detractors > have gone berserk. I appreciate your colorful exaggerations, but I should point out that the libstdc++ maintainer has stated his intention to fork, in unambigous terms. A helper elf of his has stated that he will follow the fork, if it occurs. I'm politely entertaining the possibility that you missed that, but Mr. Wakely is not joking when he indicates that he wishes to do a non-FSF fork of lbistdc++.
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Sunday, April 18, 2021 at 5:07 AM > From: "Ville Voutilainen" > To: "Jason Merrill" > Cc: "Christopher Dimech" , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Fri, 16 Apr 2021 at 19:01, Jason Merrill wrote: > > > > On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc > > wrote: > > > > Sent: Saturday, April 17, 2021 at 1:03 AM > > > > From: "Ville Voutilainen" > > > > To: "Christopher Dimech" > > > > Cc: "GCC Development" > > > > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > > > > > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > > > > The "small minority of developers" you speak of sure > > > > > > seems to consist of developers who are not in the minority > > > > > > considering how much they _actually contribute_ to the project. > > > > > > > > > > Due to their being paid for the work. Have no doubt that if others > > > > > were being paid, the contributions could likely drown the current > > > > > contributors. Thus, the claim of a power grab is valid. > > > > > > > > How convenient to make that claim and just bypass what's said in the > > > > next bit: > > > > > > > > > > > > > > > Some of them don't need to perform a "power grab"; they > > > > > > already have all the power fathomable, by virtue of being > > > > > > maintainers > > > > > > and active developers. > > > > > > > > I very much doubt your lofty hypothesis that if "others" were being > > > > paid, the > > > > contributions would "likely drown" the current contributors. Especially > > > > when we're talking about people who have submitted pretty close to ZERO > > > > patches to GCC. You can give a claim that a person $foo would contribute > > > > if being paid to do it. I'll buy that claim if you're talking about > > > > people like > > > > Nathan Sidwell and Iain Sandoe from the time before they became active > > > > contributors again, now that they've been hired to do that. I will not > > > > buy that claim about people who haven't been GCC contributors before. > > > > > > There are many users of gcc who are more qualified to know what is needed > > > in gcc, than developers. That does not mean than I want to diminish their > > > authority for gcc. But that authority was still conferred to them by the > > > the Gnu Project - which demands responsibility to carry out the assigned > > > tasks to the best of their ability, not to excoriate their obligation > > > towards > > > the project itself. > > > > > > The ultimate authority is the final responsibility of the Gnu Project, > > > not only that of gcc. > > > > Free Software means there is no ultimate authority. In Free Software, > > leadership of the development process is by the "consent of the > > governed". If there is sufficient objection to the existing > > leadership, developers can change it, either by negotiation for > > changes with the current leadership or by forking. Even when there is insufficient objection, one can fork. Progressing this to extreme, suppose one person disagrees with all the rest, he can fork. There are no qualms about that. > > The EGCS fork happened because a critical mass of developers gave up > > on the GNU GCC2 leadership model. The reconciliation happened because > > GNU agreed to accept the EGCS development model as GNU GCC. > > > > I hope to resolve the current crisis by leadership adjustments > > something along the lines of Ville's proposal, rather than forking. I do not see people really intending to fork. It explains why detractors have gone berserk. > > Jason > > That's pretty much all I ask. Jason, Jeff, Thomas, others, please > discuss this matter > among the maintainers, and if need be, among the SC, and make a decision, or > at least provide an indication of how you see these matters. I think > that indication > gives us megabytes more data than philosophical discussions will, entertaining > as they might be. >
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, 16 Apr 2021 at 19:01, Jason Merrill wrote: > > On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc > wrote: > > > Sent: Saturday, April 17, 2021 at 1:03 AM > > > From: "Ville Voutilainen" > > > To: "Christopher Dimech" > > > Cc: "GCC Development" > > > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > > > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > > > The "small minority of developers" you speak of sure > > > > > seems to consist of developers who are not in the minority > > > > > considering how much they _actually contribute_ to the project. > > > > > > > > Due to their being paid for the work. Have no doubt that if others > > > > were being paid, the contributions could likely drown the current > > > > contributors. Thus, the claim of a power grab is valid. > > > > > > How convenient to make that claim and just bypass what's said in the next > > > bit: > > > > > > > > > > > > Some of them don't need to perform a "power grab"; they > > > > > already have all the power fathomable, by virtue of being maintainers > > > > > and active developers. > > > > > > I very much doubt your lofty hypothesis that if "others" were being paid, > > > the > > > contributions would "likely drown" the current contributors. Especially > > > when we're talking about people who have submitted pretty close to ZERO > > > patches to GCC. You can give a claim that a person $foo would contribute > > > if being paid to do it. I'll buy that claim if you're talking about > > > people like > > > Nathan Sidwell and Iain Sandoe from the time before they became active > > > contributors again, now that they've been hired to do that. I will not > > > buy that claim about people who haven't been GCC contributors before. > > > > There are many users of gcc who are more qualified to know what is needed > > in gcc, than developers. That does not mean than I want to diminish their > > authority for gcc. But that authority was still conferred to them by the > > the Gnu Project - which demands responsibility to carry out the assigned > > tasks to the best of their ability, not to excoriate their obligation > > towards > > the project itself. > > > > The ultimate authority is the final responsibility of the Gnu Project, > > not only that of gcc. > > Free Software means there is no ultimate authority. In Free Software, > leadership of the development process is by the "consent of the > governed". If there is sufficient objection to the existing > leadership, developers can change it, either by negotiation for > changes with the current leadership or by forking. > > The EGCS fork happened because a critical mass of developers gave up > on the GNU GCC2 leadership model. The reconciliation happened because > GNU agreed to accept the EGCS development model as GNU GCC. > > I hope to resolve the current crisis by leadership adjustments > something along the lines of Ville's proposal, rather than forking. > > Jason That's pretty much all I ask. Jason, Jeff, Thomas, others, please discuss this matter among the maintainers, and if need be, among the SC, and make a decision, or at least provide an indication of how you see these matters. I think that indication gives us megabytes more data than philosophical discussions will, entertaining as they might be.
Re: A suggestion for going forward from the RMS/FSF debate
> >> It would be usefull to clarify with the FSF and GNU what the > >> actual relations are, > > Why? What would that gain? I go back to my analogy of the British Queen. > > What would be gained by "clarifying" that if she actually intervenes > > non-trivially in the government of any Commonwealth nation, she'd lose > > that power? > > There are differences between the queen and RMS, even if the image > has some merit. I was refering more to the FSF and GNU project here than to RMS.
Re: A suggestion for going forward from the RMS/FSF debate
Le 16/04/2021 à 19:06, Richard Kenner a écrit : >> The authority of the FSF, GNU and RMS over GCC is and has been a >> fiction for decades, > For the most part, I agree. > >> It would be usefull to clarify with the FSF and GNU what the >> actual relations are, > Why? What would that gain? I go back to my analogy of the British Queen. > What would be gained by "clarifying" that if she actually intervenes > non-trivially in the government of any Commonwealth nation, she'd lose > that power? There are differences between the queen and RMS, even if the image has some merit. For example, the UK remains a formal monarchy in part because the queen has better social skills than RMS. The supporters of software freedom in general are probably not in favour of a monarchy, even formal, even if they know their debt to RMS. Therefore, if the GNU project loves to keep this childish fictious power of the chief GNUisance, this doesn't prevent GCC to remain associated to the FSF. -- Didier
Re: A suggestion for going forward from the RMS/FSF debate
> On Apr 16, 2021, at 2:41 PM, NightStrike via Gcc wrote: > >> ... > > 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. My impression is a variation on this: that LLVM is in substantial part motivated by a desire to avoid GPL V3. And that there wasn't such a push when GPL V2 was the version in general use. paul
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, Apr 16, 2021 at 7:23 AM Ville Voutilainen via Gcc 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?
Re: A suggestion for going forward from the RMS/FSF debate
> On Apr 16, 2021, at 6:13 AM, Ville Voutilainen via Gcc-patches > wrote: > > The actual suggestion is at the end; skip straight to it if you wish. Could you shift this discussion to the gcc list where it fits better? gcc-patches is for discussion patches to the code. paul
Re: A suggestion for going forward from the RMS/FSF debate
On 4/16/2021 9:57 AM, Thomas Koenig via Gcc wrote: Hello world, realising that my e-mails may have done more harm than good, I will now unsubscribe from the gcc mailing list, so please don't expect a reply unless you copy me in. I don't think your emails have done any harm. I find them quite valuable, so I'm sad to see you dropping yourself from the gcc@ list. jeff
Re: A suggestion for going forward from the RMS/FSF debate
> The authority of the FSF, GNU and RMS over GCC is and has been a > fiction for decades, For the most part, I agree. > It would be usefull to clarify with the FSF and GNU what the > actual relations are, Why? What would that gain? I go back to my analogy of the British Queen. What would be gained by "clarifying" that if she actually intervenes non-trivially in the government of any Commonwealth nation, she'd lose that power?
Re: A suggestion for going forward from the RMS/FSF debate
From reading most of this thread, it is clear to me that - The authority of the FSF, GNU and RMS over GCC is and has been a fiction for decades, - This fiction has been erased from the official web page of the project, - It would be usefull to clarify with the FSF and GNU what the actual relations are, - This can certainly be done in a polite way without all sorts of rant, and arguments with no relation with Free Software, in particular attacks ad persona. The power is and has always been in the hands of the people doing the job (the developpers/maintainers). But those who have the power would be wise to pay attention to the opinions of the many afficionados of GCC, GNU and Free Software in general, even those who aren't contributors. These people aren't trolls; they speak up because they are concerned about the project. -- Didier
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc wrote: > > Sent: Saturday, April 17, 2021 at 1:03 AM > > From: "Ville Voutilainen" > > To: "Christopher Dimech" > > Cc: "GCC Development" > > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > > The "small minority of developers" you speak of sure > > > > seems to consist of developers who are not in the minority > > > > considering how much they _actually contribute_ to the project. > > > > > > Due to their being paid for the work. Have no doubt that if others > > > were being paid, the contributions could likely drown the current > > > contributors. Thus, the claim of a power grab is valid. > > > > How convenient to make that claim and just bypass what's said in the next > > bit: > > > > > > > > > Some of them don't need to perform a "power grab"; they > > > > already have all the power fathomable, by virtue of being maintainers > > > > and active developers. > > > > I very much doubt your lofty hypothesis that if "others" were being paid, > > the > > contributions would "likely drown" the current contributors. Especially > > when we're talking about people who have submitted pretty close to ZERO > > patches to GCC. You can give a claim that a person $foo would contribute > > if being paid to do it. I'll buy that claim if you're talking about people > > like > > Nathan Sidwell and Iain Sandoe from the time before they became active > > contributors again, now that they've been hired to do that. I will not > > buy that claim about people who haven't been GCC contributors before. > > There are many users of gcc who are more qualified to know what is needed > in gcc, than developers. That does not mean than I want to diminish their > authority for gcc. But that authority was still conferred to them by the > the Gnu Project - which demands responsibility to carry out the assigned > tasks to the best of their ability, not to excoriate their obligation towards > the project itself. > > The ultimate authority is the final responsibility of the Gnu Project, > not only that of gcc. Free Software means there is no ultimate authority. In Free Software, leadership of the development process is by the "consent of the governed". If there is sufficient objection to the existing leadership, developers can change it, either by negotiation for changes with the current leadership or by forking. The EGCS fork happened because a critical mass of developers gave up on the GNU GCC2 leadership model. The reconciliation happened because GNU agreed to accept the EGCS development model as GNU GCC. I hope to resolve the current crisis by leadership adjustments something along the lines of Ville's proposal, rather than forking. Jason
Re: A suggestion for going forward from the RMS/FSF debate
Hello world, realising that my e-mails may have done more harm than good, I will now unsubscribe from the gcc mailing list, so please don't expect a reply unless you copy me in. Best regards Thomas
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Saturday, April 17, 2021 at 1:03 AM > From: "Ville Voutilainen" > To: "Christopher Dimech" > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > The "small minority of developers" you speak of sure > > > seems to consist of developers who are not in the minority > > > considering how much they _actually contribute_ to the project. > > > > Due to their being paid for the work. Have no doubt that if others > > were being paid, the contributions could likely drown the current > > contributors. Thus, the claim of a power grab is valid. > > How convenient to make that claim and just bypass what's said in the next bit: > > > > > > Some of them don't need to perform a "power grab"; they > > > already have all the power fathomable, by virtue of being maintainers > > > and active developers. > > I very much doubt your lofty hypothesis that if "others" were being paid, the > contributions would "likely drown" the current contributors. Especially > when we're talking about people who have submitted pretty close to ZERO > patches to GCC. You can give a claim that a person $foo would contribute > if being paid to do it. I'll buy that claim if you're talking about people > like > Nathan Sidwell and Iain Sandoe from the time before they became active > contributors again, now that they've been hired to do that. I will not > buy that claim about people who haven't been GCC contributors before. There are many users of gcc who are more qualified to know what is needed in gcc, than developers. That does not mean than I want to diminish their authority for gcc. But that authority was still conferred to them by the the Gnu Project - which demands responsibility to carry out the assigned tasks to the best of their ability, not to excoriate their obligation towards the project itself. The ultimate authority is the final responsibility of the Gnu Project, not only that of gcc. > > > This whole discussion, again, at least to me, boils down to two > > > things, actually three: > > > > It can also boil down about whether people want their work to form part > > of the Gnu Project or not!!! > > Oh, sure it can. So perhaps we should do something along the lines of what > Thomas outlined: > > - ask the maintainers what they want to do > - then do that >
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, 16 Apr 2021 at 16:22, Christopher Dimech wrote: > Many do not contribute because they do not have time, resources or support. Yes? And? Even if GCC detaches itself from FSF, those who can contribute will continue to contribute. And those who talk about contributing but don't contribute will likely continue talking and not contributing. > Additionally, maintainers have always been aware that being a Gnu Maintainer > meant that coordinating activities in the GNU Project were on behalf of RMS. Fine. And if those maintainers no longer wish to be coordinating activities on behalf of RMS, they should make that decision and run with it. Or make a decision not to.
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Saturday, April 17, 2021 at 1:03 AM > From: "Ville Voutilainen" > To: "Christopher Dimech" > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > The "small minority of developers" you speak of sure > > > seems to consist of developers who are not in the minority > > > considering how much they _actually contribute_ to the project. > > > > Due to their being paid for the work. Have no doubt that if others > > were being paid, the contributions could likely drown the current > > contributors. Thus, the claim of a power grab is valid. > > How convenient to make that claim and just bypass what's said in the next bit: > > > > > > Some of them don't need to perform a "power grab"; they > > > already have all the power fathomable, by virtue of being maintainers > > > and active developers. > > I very much doubt your lofty hypothesis that if "others" were being paid, the > contributions would "likely drown" the current contributors. Especially > when we're talking about people who have submitted pretty close to ZERO > patches to GCC. You can give a claim that a person $foo would contribute > if being paid to do it. I'll buy that claim if you're talking about people > like > Nathan Sidwell and Iain Sandoe from the time before they became active > contributors again, now that they've been hired to do that. I will not > buy that claim about people who haven't been GCC contributors before. Many do not contribute because they do not have time, resources or support. Additionally, maintainers have always been aware that being a Gnu Maintainer meant that coordinating activities in the GNU Project were on behalf of RMS. > > > This whole discussion, again, at least to me, boils down to two > > > things, actually three: > > > > It can also boil down about whether people want their work to form part > > of the Gnu Project or not!!! > > Oh, sure it can. So perhaps we should do something along the lines of what > Thomas outlined: > > - ask the maintainers what they want to do > - then do that >
Re: A suggestion for going forward from the RMS/FSF debate
> Due to their being paid for the work. Have no doubt that if others > were being paid, the contributions could likely drown the current > contributors. Thus, the claim of a power grab is valid. This is a non-sequitur.
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > The "small minority of developers" you speak of sure > > seems to consist of developers who are not in the minority > > considering how much they _actually contribute_ to the project. > > Due to their being paid for the work. Have no doubt that if others > were being paid, the contributions could likely drown the current > contributors. Thus, the claim of a power grab is valid. How convenient to make that claim and just bypass what's said in the next bit: > > > Some of them don't need to perform a "power grab"; they > > already have all the power fathomable, by virtue of being maintainers > > and active developers. I very much doubt your lofty hypothesis that if "others" were being paid, the contributions would "likely drown" the current contributors. Especially when we're talking about people who have submitted pretty close to ZERO patches to GCC. You can give a claim that a person $foo would contribute if being paid to do it. I'll buy that claim if you're talking about people like Nathan Sidwell and Iain Sandoe from the time before they became active contributors again, now that they've been hired to do that. I will not buy that claim about people who haven't been GCC contributors before. > > This whole discussion, again, at least to me, boils down to two > > things, actually three: > > It can also boil down about whether people want their work to form part > of the Gnu Project or not!!! Oh, sure it can. So perhaps we should do something along the lines of what Thomas outlined: - ask the maintainers what they want to do - then do that
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Friday, April 16, 2021 at 10:16 PM > From: "Ville Voutilainen via Gcc" > To: "GCC Development" > Subject: A suggestion for going forward from the RMS/FSF debate > > Huge apologies for mis-sending this to gcc-patches, > my email client makes suggestions when I attempt > to send to a gcc list. :D > > The actual suggestion is at the end; skip straight to it if you wish. > > >Im glad there are people like you on the project Eric, because you express > exactly what a lot of people see - even if a minority of people chose to > ignore it, > > >To a lot of "non americans", the events on here appear as nothing more than > a power grab by a small minority of developers, abusing their position and > american corporate ideologies to enact change, ignoring any one who dares > question or disagree unless they fit into a clique they have built (and > want to maintain by ostracizing people they deem unworthy), > brandishing them jerks, trolls, toxic and other childish names. Im glad > there are a few devs that can see this, but it feels like they are stepping > on egg shells (despite the rhetoric about how well the people in said > clique can communicate on technical matters). > > That's a) incorrect b) beside some rather important points. > > The "small minority of developers" you speak of sure > seems to consist of developers who are not in the minority > considering how much they _actually contribute_ to the project. Due to their being paid for the work. Have no doubt that if others were being paid, the contributions could likely drown the current contributors. Thus, the claim of a power grab is valid. > Some of them don't need to perform a "power grab"; they > already have all the power fathomable, by virtue of being maintainers > and active developers. > > This whole discussion, again, at least to me, boils down to two > things, actually three: It can also boil down about whether people want their work to form part of the Gnu Project or not!!! > 1) is the technical leadership of RMS/GNU/FSF useful for > the project? Is it beneficial, or harmful? > > 2) is the PR/public-face position of RMS/FSF useful for > the project? Is it beneficial, or harmful? > > 3) Who should make decisions related to that? The developers > and maintainers, or people who are neither of those, but > are certainly vocal in these discussions? > > 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. > > On the second part, we can discuss whether the reasons > for various people not wanting RMS/FSF to be the PR department > of GCC developers are sound, or whether we agree with them, > until the cows come home. > > But that doesn't matter. Bad PR is bad PR, and it seems strikingly > simple to consider trying a PR department that doesn't have > the baggage of the previous one. > > And if you ask me, *that* should be a choice of the developers > and maintainers, and them alone. It's their work; they should > have a say in who and what the public face of the work is > to the outside world. Whether their choice is made because > they live a pampered and cosseted life is very much secondary. > > I don't have to agree with every viewpoint of the people who > have suggested that RMS shouldn't lead this project, or that > this project shouldn't necessarily be tied to FSF any more. > I don't even need to "accept" it. I don't consider it something > that needs my approval or acceptance, I'm not a maintainer > or a major contributor. > > However, I consider it something that needs even LESS > acceptance or approval of ESR or Mr. Dimech or various > other people. I happen to have Write-After-Approval permission > for this project. They don't. Because they're not members > of this project, they don't contribute code to it. > > Finally, with regards to there existing a power grab or a sinister > corporation plot to take GCC away from being "accountable > to its community": > > 1) that's just pure horseshit. The people wanting to disassociate > the project from RMS and/or FSF worked on GCC before > their current employment, and will work on GCC after their >
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, 16 Apr 2021 at 13:13, Ville Voutilainen wrote: > > The actual suggestion is at the end; skip straight to it if you wish. ..please disregard, that was a send-o, should've have been sent to the patches mailing list.
