`rustc-1.83` tarball contains a GCC checkout

[maurer]

While I understand the motivation for putting a GCC in dev environments / CI (it's good to keep the GCC backend tested), I think it might be overkill to ship it in the source tarball. This has a number of downsides:

1. It puts GPL source code into the rustc release tarball.
2. It's a significant increase in the size of the tarball (part of the reason we noticed was that one of the ingestion systems was unhappy with the file count).
3. To the best of my knowledge, the GCC backend is not stable - providing the ability to build it out of the stable tarball without an additional library doesn't seem necessary.
4. I suspect that most people who want the GCC backend (e.g. distros, specialized environments) will want to provide their own GCC.

[jieyouxu]

cc @rust-lang/wg-gcc-backend

[GuillaumeGomez]

As far as I know, this is not supposed to happen.

cc @Kobzol

[Kobzol]

Well, it's true that right now it's probably not necessary. But my assumption was that once we integrate the GCC backend into bootstrap more, we will in fact also include GCC's source code in this tarball, same as we do for LLVM. The source tarball includes pretty much all the source code from our repo, including submodules and vendored crates.

[GuillaumeGomez]

Ah I thought we were planning to do it only once GCC support in bootstrap was done. My bad.

[Kobzol]

I mean, I cannot say that the inclusion was fully intentional, I'm not sure where/how it started happening (probably just by us adding GCC as a submodule or something?). I just wanted to say that eventually, it would happen anyway.

[GuillaumeGomez]

This is fate, no trying to fight against GCC future. 😛

[maurer]

LLVM is offered under an Apache license like the Rust compiler - GCC is not. I think it is a potential accident waiting to happen for people to download the source for something that is supposedly Apache-2.0/MIT licensed and accidentally download something GPL'd.

I would think that #63232 would lead to more caution when introducing a component with a license like this that is potentially dangerous to users.

If this is the long term intention of upstream, we're going to have to build a filter on our end to find and delete any potentially GPL'd files during tarball import, and I suspect we won't be the only ones required to do this.

[Kobzol]

We don't currently actually use the GPL code in our binary artifacts, we just put GPL source code into the tarball archive (same as we have it in our git repository). But IANAL, and this situation is indeed quite complicated and unclear.

CC @ehuss - Do you know if this is something that has been cleared by the Foundation's lawyers already?