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

2021-04-16 Thread Koning, Paul via Gcc-patches



> 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

2021-04-16 Thread Ville Voutilainen via Gcc-patches
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.


A suggestion for going forward from the RMS/FSF debate

2021-04-16 Thread Ville Voutilainen via Gcc-patches
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