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