Re: A suggestion for going forward from the RMS/FSF debate

Re: A suggestion for going forward from the RMS/FSF debate

[Aaron Gyes]

> 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

[Aaron Gyes]

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 <dimech@gmx.com> 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" <aaronite@icloud.com>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> 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 <dimech@gmx.com> wrote:
>>> 
>>> 
>>>> 
>>>> Sent: Sunday, April 18, 2021 at 5:46 PM
>>>> From: "Aaron Gyes" <aaronite@icloud.com>
>>>> To: "Christopher Dimech" <dimech@gmx.com>
>>>> 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

[Christopher Dimech]

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" <aaronite@icloud.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> 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 <dimech@gmx.com> 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" <aaronite@icloud.com>
> >> To: "Christopher Dimech" <dimech@gmx.com>
> >> 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 <dimech@gmx.com> wrote:
> >>> 
> >>> 
> >>>> 
> >>>> Sent: Sunday, April 18, 2021 at 5:46 PM
> >>>> From: "Aaron Gyes" <aaronite@icloud.com>
> >>>> To: "Christopher Dimech" <dimech@gmx.com>
> >>>> 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

[Jonathan Wakely]

On Sun, 18 Apr 2021, 10:01 Christopher Dimech via Gcc, <gcc@gcc.gnu.org>
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

[Christopher Dimech]

> Sent: Sunday, April 18, 2021 at 9:06 PM
> From: "Jonathan Wakely via Gcc" <gcc@gcc.gnu.org>
> To: "Aaron Gyes" <aaronite@icloud.com>
> Cc: "gcc@gcc.gnu.org" <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, <gcc@gcc.gnu.org>
> 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

[Andrew Sutton]

>
> > 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

[Christopher Dimech]

> Sent: Monday, April 19, 2021 at 4:58 AM
> From: "Thomas Rodgers" <rodgert@appliantology.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Siddhesh Poyarekar" <siddhesh@gotplt.org>, "GCC Development" <gcc@gcc.gnu.org>, "Ville Voutilainen" <ville.voutilainen@gmail.com>
> 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

[Thomas Rodgers]

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

[Thomas Rodgers]

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

[Christopher Dimech]

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" <kenner@vlsi1.ultra.nyu.edu>
> To: dimech@gmx.com
> Cc: gcc@gcc.gnu.org, siddhesh@gotplt.org, ville.voutilainen@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

[Christopher Dimech]

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" <ville.voutilainen@gmail.com>
> To: "Richard Kenner" <kenner@vlsi1.ultra.nyu.edu>
> Cc: "Christopher Dimech" <dimech@gmx.com>, "GCC Development" <gcc@gcc.gnu.org>, siddhesh@gotplt.org
> Subject: Re: A suggestion for going forward from the RMS/FSF debate
>
> On Sun, 18 Apr 2021 at 13:49, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> 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

[Richard Kenner]

> 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

[Christopher Dimech]

> Sent: Sunday, April 18, 2021 at 10:49 PM
> From: "Richard Kenner" <kenner@vlsi1.ultra.nyu.edu>
> To: dimech@gmx.com
> Cc: gcc@gcc.gnu.org, siddhesh@gotplt.org, ville.voutilainen@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

[Ville Voutilainen]

On Sun, 18 Apr 2021 at 13:49, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> 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

[Richard Kenner]

> 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

[Richard Kenner]

> 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

[Christopher Dimech]

> Sent: Sunday, April 18, 2021 at 7:53 PM
> From: "Siddhesh Poyarekar" <siddhesh@gotplt.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "NightStrike" <nightstrike@gmail.com>, "Ville Voutilainen" <ville.voutilainen@gmail.com>, "GCC Development" <gcc@gcc.gnu.org>
> 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

[Christopher Dimech]

> Sent: Sunday, April 18, 2021 at 7:53 PM
> From: "Siddhesh Poyarekar" <siddhesh@gotplt.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "NightStrike" <nightstrike@gmail.com>, "Ville Voutilainen" <ville.voutilainen@gmail.com>, "GCC Development" <gcc@gcc.gnu.org>
> 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

[Christopher Dimech]

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" <siddhesh@gotplt.org>
> To: "Gabriel Ravier" <gabravier@gmail.com>, 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...
> </troll>
>

Re: A suggestion for going forward from the RMS/FSF debate

[Siddhesh Poyarekar]

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

[Siddhesh Poyarekar]

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...
</troll>

Re: A suggestion for going forward from the RMS/FSF debate

[Gabriel Ravier]

On 4/18/21 8:44 AM, Christopher Dimech via Gcc wrote:
>> Sent: Sunday, April 18, 2021 at 6:09 PM
>> From: "Siddhesh Poyarekar" <siddhesh@gotplt.org>
>> To: "NightStrike" <nightstrike@gmail.com>, "Ville Voutilainen" <ville.voutilainen@gmail.com>
>> Cc: "GCC Development" <gcc@gcc.gnu.org>
>> 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]

---------------------
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" <siddhesh@gotplt.org>
> To: "NightStrike" <nightstrike@gmail.com>, "Ville Voutilainen" <ville.voutilainen@gmail.com>
> Cc: "GCC Development" <gcc@gcc.gnu.org>
> 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

[Christopher Dimech]

> Sent: Sunday, April 18, 2021 at 6:09 PM
> From: "Siddhesh Poyarekar" <siddhesh@gotplt.org>
> To: "NightStrike" <nightstrike@gmail.com>, "Ville Voutilainen" <ville.voutilainen@gmail.com>
> Cc: "GCC Development" <gcc@gcc.gnu.org>
> 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

[Siddhesh Poyarekar]

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

[Aaron Gyes]

> 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

A suggestion for going forward from the RMS/FSF debate

[Christopher Dimech]

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. -  NightStrike

You are correct.  LLVM is under the Apache License Version 2.0, which is a
free software license compatible with the GNU GPL Version 3.0.

But the license comes with LLVM Exceptions that nullifies the Apache License,
because it then allows others to embedded their work into object form.
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.

Consequently, the LLVM Owners are being extremely dishonest, because they
are using the words "Apache License" to trick people into believing that
the LLVM License has anything to do with free software.  It does not.

Regards
Christopher

A suggestion for going forward from the RMS/FSF debate

[Christopher Dimech]

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.

> 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

[Thomas Rodgers]

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

[Thomas Rodgers]

On 2021-04-17 10:40, Ville Voutilainen via Gcc wrote:

> On Sat, 17 Apr 2021 at 20:31, Christopher Dimech <dimech@gmx.com> 
> 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

[Christopher Dimech]

> Sent: Sunday, April 18, 2021 at 5:40 AM
> From: "Ville Voutilainen" <ville.voutilainen@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Jason Merrill" <jason@redhat.com>, "GCC Development" <gcc@gcc.gnu.org>
> Subject: Re: A suggestion for going forward from the RMS/FSF debate
>
> On Sat, 17 Apr 2021 at 20:31, Christopher Dimech <dimech@gmx.com> 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

[Ville Voutilainen]

On Sat, 17 Apr 2021 at 20:31, Christopher Dimech <dimech@gmx.com> 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

[Christopher Dimech]

> Sent: Sunday, April 18, 2021 at 5:07 AM
> From: "Ville Voutilainen" <ville.voutilainen@gmail.com>
> To: "Jason Merrill" <jason@redhat.com>
> Cc: "Christopher Dimech" <dimech@gmx.com>, "GCC Development" <gcc@gcc.gnu.org>
> Subject: Re: A suggestion for going forward from the RMS/FSF debate
>
> On Fri, 16 Apr 2021 at 19:01, Jason Merrill <jason@redhat.com> wrote:
> >
> > On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc
> > <gcc@gcc.gnu.org> wrote:
> > > > Sent: Saturday, April 17, 2021 at 1:03 AM
> > > > From: "Ville Voutilainen" <ville.voutilainen@gmail.com>
> > > > To: "Christopher Dimech" <dimech@gmx.com>
> > > > Cc: "GCC Development" <gcc@gcc.gnu.org>
> > > > Subject: Re: A suggestion for going forward from the RMS/FSF debate
> > > >
> > > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech <dimech@gmx.com> 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

[Ville Voutilainen]

On Fri, 16 Apr 2021 at 19:01, Jason Merrill <jason@redhat.com> wrote:
>
> On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc
> <gcc@gcc.gnu.org> wrote:
> > > Sent: Saturday, April 17, 2021 at 1:03 AM
> > > From: "Ville Voutilainen" <ville.voutilainen@gmail.com>
> > > To: "Christopher Dimech" <dimech@gmx.com>
> > > Cc: "GCC Development" <gcc@gcc.gnu.org>
> > > Subject: Re: A suggestion for going forward from the RMS/FSF debate
> > >
> > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech <dimech@gmx.com> 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

[Richard Kenner]

> >> 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

[Didier Kryn]

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

[Paul Koning]

> On Apr 16, 2021, at 2:41 PM, NightStrike via Gcc <gcc@gcc.gnu.org> 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

[NightStrike]

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?

Re: A suggestion for going forward from the RMS/FSF debate

[Jeff Law]

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

[Richard Kenner]

> 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

[Didier Kryn]

    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

[Jason Merrill]

On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc
<gcc@gcc.gnu.org> wrote:
> > Sent: Saturday, April 17, 2021 at 1:03 AM
> > From: "Ville Voutilainen" <ville.voutilainen@gmail.com>
> > To: "Christopher Dimech" <dimech@gmx.com>
> > Cc: "GCC Development" <gcc@gcc.gnu.org>
> > Subject: Re: A suggestion for going forward from the RMS/FSF debate
> >
> > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech <dimech@gmx.com> 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

[Thomas Koenig]

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

[Christopher Dimech]

> Sent: Saturday, April 17, 2021 at 1:03 AM
> From: "Ville Voutilainen" <ville.voutilainen@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "GCC Development" <gcc@gcc.gnu.org>
> Subject: Re: A suggestion for going forward from the RMS/FSF debate
>
> On Fri, 16 Apr 2021 at 15:46, Christopher Dimech <dimech@gmx.com> 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

[Ville Voutilainen]

On Fri, 16 Apr 2021 at 16:22, Christopher Dimech <dimech@gmx.com> 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

[Christopher Dimech]

> Sent: Saturday, April 17, 2021 at 1:03 AM
> From: "Ville Voutilainen" <ville.voutilainen@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "GCC Development" <gcc@gcc.gnu.org>
> Subject: Re: A suggestion for going forward from the RMS/FSF debate
>
> On Fri, 16 Apr 2021 at 15:46, Christopher Dimech <dimech@gmx.com> 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

[Aaron Gyes]

> 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

[Ville Voutilainen]

On Fri, 16 Apr 2021 at 15:46, Christopher Dimech <dimech@gmx.com> 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

[Christopher Dimech]

> Sent: Friday, April 16, 2021 at 10:16 PM
> From: "Ville Voutilainen via Gcc" <gcc@gcc.gnu.org>
> To: "GCC Development" <gcc@gcc.gnu.org>
> 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
> current employment. There is no power grab, and there is
> no sinister corporation plot, and that wouldn't work anyway
> due to the license and due to how the project _actually works_.
>
> 2) the project isn't accountable that way today, anyway. That
> concern is pure fantasy.
>
> So, I have a moderate suggestion, and I will fairly entertain it
> being a bold suggestion for some people:
>
> A) Detach GCC from FSF (and RMS), have it be hosted on non-gnu sites,
> make it a project separate from FSF, other than
> B) Don't drop the copyright assignment requirement, at least
> not yet.
> C) Run in that mode for a while, and see what happens.
>
> This allows re-attaching GCC to FSF, it that's later deemed like a good idea.
> The codebases, in case there actually are two, which might not
> even be necessary, are not copyright-incompatible because all of
> the code still is under FSF's copyright.
>
> And another thing that it allows is to stop this endless hypothesizing
> on what the consequences of that move will or will not be.
> Let's make the move, and see what those consequences are,
> and learn from the experience.
>

A suggestion for going forward from the RMS/FSF debate

[Ville Voutilainen]

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.

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:

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
current employment. There is no power grab, and there is
no sinister corporation plot, and that wouldn't work anyway
due to the license and due to how the project _actually works_.

2) the project isn't accountable that way today, anyway. That
concern is pure fantasy.

So, I have a moderate suggestion, and I will fairly entertain it
being a bold suggestion for some people:

A) Detach GCC from FSF (and RMS), have it be hosted on non-gnu sites,
make it a project separate from FSF, other than
B) Don't drop the copyright assignment requirement, at least
not yet.
C) Run in that mode for a while, and see what happens.

This allows re-attaching GCC to FSF, it that's later deemed like a good idea.
The codebases, in case there actually are two, which might not
even be necessary, are not copyright-incompatible because all of
the code still is under FSF's copyright.

And another thing that it allows is to stop this endless hypothesizing
on what the consequences of that move will or will not be.
Let's make the move, and see what those consequences are,
and learn from the experience.