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?

[ehuss]

I don't have any specific legal insight beyond what was already discussed in #125419. My understanding is that it should be fine (from a legal standpoint) for us to include the GPL parts in the source tarball. We already include code from a very wide range of licenses in there. With #133461 we now have a slightly better communication of those licenses. (Unfortunately we don't have good communication of the relationship between those licenses versus when they are used.)

But it does seem like a reasonable concern of being considerate to the people who use the source tarball to consider excluding it and making it separate. Looking at the diff from 1.82 to 1.83, the source tarball increased from 210M to 337M (+60%?) which is massive.

I'm not familiar enough with the requirements for exactly which version of gcc is needed, or if it would be possible to not include that in the source tarball (and have bootstrap fetch it from somewhere, or have the user provide their own copy). However, I think it would be nice to consider doing that.

[bjorn3]

I'm not familiar enough with the requirements for exactly which version of gcc is needed

A rather recent one I believe + a bunch of patches: gcc-mirror/gcc@master...rust-lang:gcc:master

[Kobzol]

I don't have any specific legal insight beyond what was already discussed in #125419. My understanding is that it should be fine (from a legal standpoint) for us to include the GPL parts in the source tarball. We already include code from a very wide range of licenses in there. With #133461 we now have a slightly better communication of those licenses. (Unfortunately we don't have good communication of the relationship between those licenses versus when they are used.)

But it does seem like a reasonable concern of being considerate to the people who use the source tarball to consider excluding it and making it separate. Looking at the diff from 1.82 to 1.83, the source tarball increased from 210M to 337M (+60%?) which is massive.

I'm not familiar enough with the requirements for exactly which version of gcc is needed, or if it would be possible to not include that in the source tarball (and have bootstrap fetch it from somewhere, or have the user provide their own copy). However, I think it would be nice to consider doing that.

Fair enough. Sent #135658 to remove GCC sources from the tarball.

[jieyouxu]

Reopening to track potential stable/beta backports, nominated in #135658 (comment).

[cuviper]

#136650 backported the removal to beta.