Repository navigation
rustc-1.83 tarball contains a GCC checkout #135606
Description
Activity
cc @rust-lang/wg-gcc-backend
- added and removed
on Jan 17, 2025 As far as I know, this is not supposed to happen.
cc @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.
Ah I thought we were planning to do it only once GCC support in bootstrap was done. My bad.
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.
This is fate, no trying to fight against GCC future. 😛
Reacted by Jakub BeránekLLVM 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.
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?
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
gccis 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.Reacted by Chris Wailes and Jakub BeránekI'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
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
gccis 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.
- added a commit that references this issue
on Jan 20, 2025 Reopening to track potential stable/beta backports, nominated in #135658 (comment).
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:
rustcrelease tarball.