On Sun, 11 Apr 2021, 16:56 David Brown, wrote: > > The big problem with a fork, rather than an amiable split (where FSF/GNU > accepts that gcc wants to be a separate project) is the name. If the > FSF keep their own "gcc" project, then calling the new fork "gcc" as > well would cause confusion.
Packagers for Linux distros and BSD ports collections (and similar like MinGW distros) are unlikely to be confused for long. The GNU project can have the "GNU C Compiler" name, as far as I'm concerned. The "GNU Compiler Collection" name dates from the time when EGCS replaced the original GCC so I would argue that the FSF couldn't claim ownership of a new twist on it like "GCC Compiler Collection". And Apple already got away with shipping clang as the "gcc" and "g++" executables (albeit causing much confusion) so even if the project changed name, the shipped products wouldn't need to. Your point is valid, but I've been thinking about the practicalities a lot. I still think losing the gcc.gnu.org DNS records would be the biggest drawback. And calling it something else would also > confuse people - many would use the FSF gcc because of its name, not > realising that there is a better fork. You can see that in the > OpenOffice / LibreOffice split - I think a large proportion of people > downloading OpenOffice do so without realising that LibreOffice exists > and is way ahead of it on features. > Only a small minority download GCC (we don't provide binaries for a start, so most people use the binary package from their OS, or a semi-automated build like portage or MacPorts). So I'm not terribly concerned about that problem. > A fork may be unavoidable in the end, but a more diplomatic change of > structure would have many advantages if it can be achieved. > I would be very happy if the FSF took that view and let us walk away. If not, I don't think it's a huge problem.
