[ Like many others who have posted to this thread, I've contributed to GCC at various times as a hobby and at other times as a paid employee. Here I'm speaking as a personal contributor, not on behalf of my current employer. ]
I think it's misleading to talk about GCC “leaving” or “disassociating itself” from the FSF or from the GNU project. No-one can force the FSF or the GNU project to drop GCC (and I don't think anyone's trying to make it do that). I think what we're really talking about is whether there should be a fork. In some ways that would be like egcs, although perhaps this time it would be a clean break, without intending the fork to “rejoin” GNU later. If the fork takes the current gcc.gnu.org infrastructure with it, the GNU project would have to maintain its version of GCC elsewhere. But that would be a minor barrier at most. The likelihood is that there would be two versions of GCC, which for want of better terms I'll call “FSF GCC” and “new GCC”. If FSF GCC does continue as a project in any meaningful sense, new GCC would be able to cherry-pick useful contributions from FSF GCC. Cherry-picking in the opposite direction would also be technically and legally possible, but would presumably be rejected on principle by whoever the new FSF GCC maintainers turn out to be (not least because “new GCC” commits would not be FSF copyright). This should also satisfy those who believe that only an FSF-copyright GCC is trustworthy. People who only trust the FSF can contribute to and use “FSF GCC” and ignore “new GCC”. So I think the question becomes: how many GCC developers and organisations are willing to agree to follow the fork rather than stick with FSF GCC? Does anyone have any suggestions for a good procedure for testing the level of support? I don't think this mailing list is it. (It's ironic that the process of answering that question shows how misplaced a lot of the comments about the SC were. GCC is fundamentally a developer/contributor-led project, so even an important decision like this will be made by developers/contributors rather than the SC.) FWIW, again speaking personally, I would be in favour of joining a fork.[*] Mark Wielaard <m...@klomp.org> writes: > On Wed, Apr 07, 2021 at 10:04:21AM -0400, David Malcolm wrote: > > Another, transitional approach might be to find another Free Software > > non-profit and for contributors to start assigning copyright on ongoing > > work to that other non-profit. That way there would be only two > > copyright holders on the code; if the FSF somehow survives its current > > death-spiral then the other nonprofit could assign copyright back to > > the FSF; if it doesn't, well, we've already got bigger problems. > > Yes, having all new copyrights pooled together so we have just two > copyright holders would provide most of the same benefits. And makes > it easier to deal with the legacy FSF copyrights since there would be > just one legal entity having to deal with them instead of each > individual copyright holder on their own. It sounds like it could be the worst of both worlds in some ways though. There would no longer be a single entity that could relicense the code, if that became necessary for any reason, yet we would still require all contributors to go through the off-putting process of assigning copyright. I think it would be better to have voluntary aggregation of copyright (for those in a position to offer it) while also allowing contributors to retain copyright if they prefer. If enough regular contributors agree to pool copyright then that should be enough. > If it has to come to this then we could take a look at what the > Conservancy already does for aggregating copyright for their member > projects, the Linux kernel and Debian project: > https://sfconservancy.org/copyleft-compliance/ > > I like their idea of having a counsel of developers that gets involved > in any action taken on behave of the collective: > https://sfconservancy.org/docs/blank_linux-enforcement-agreement.pdf I'm not familiar with this system, but yeah, I agree that it looks on the face of it like a good approach, provided that it's strictly voluntary. Thanks, Richard [*] Not that anyone should care or is likely to care, but for the record, my reasons are: The FSF and the GNU project have had a key historical role in developing and promoting free software as a concept. But history is one thing and the future is another. Due to the success of the early advocacy work, free software now exists as a principle independently of the FSF and the GNU project. And the FSF has provided copyleft licenses that have stood the test of time. So like others have said, the question for the future is: do we as contributors gain anything by having any new work we do be owned by the FSF and associated with the GNU project? I think the recent developments, as well as the messages in this email thread that supposedly give reasons for sticking with GNU, have shown what a tarnished brand the GNU project has become. Like others have said, it's hard to escape the feeling that it's as much about the cult of the founder as it is about the principle of free software. And I think the thread has also shown that even people very familiar with the FSF and GNU project fundamentally misunderstand how GCC development currently works and how closely tied to the GNU project current GCC development really is. I think a fork would help to clarify the situation. There's undeniably a close tie between GCC and sibling projects in the “GNU toolchain”: glibc, binutils and gdb. But those GNU projects are all in the sourceware.org stable and could in principle fork at the same time. In the 20+ years I've been working on the project, there has been at most a very loose link between GCC and other parts of the GNU project besides those three. So having the name “GNU” attached to GCC development in the last 20 years or so has felt a bit like having the Union flag in the upper left corner of the Australian flag. It reflects an important part of the project's history, but it's not necessarily an important part of what the project is today. Life working on a GCC fork should be very much like the status quo, just without the increasingly toxic association.
