-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bootstrap vendoring requires rustc-perf
submodule (unconditionally?)
#137272
Comments
cc @pietroalbini @Kobzol: I feel like it's "more correct" (at least safer license wise) for copyright generation to collect all licenses transitively (including by explicitly checking out submodules) as done in #137020. Unless we modify the copyright generation logic to somehow keep track of what tools that some dist configuration may never use (at the risk of this diverging and oops license violation)? |
Yeah, I think that we should collect everything, just to make sure we don't miss stuff. |
@erickt can Fuchsia checkout the |
Hi - I'm working with Erick on the Fuchsia side to get this resolved. Our open source licensing approval process prevents us from checking out |
Hi, |
Hi folks, I talked with our internal opensource team, and it sounds like our internal tooling is blocked on licensee/licensee#737 / fsfe/reuse-tool#901 and so it can't interpret the I know this is a situation caused by my company and not Rust, but if it'd really help us out in the meantime if we could re-land the equivalent to rust-lang/rustc-perf#1881 to add back the top-level LICENSE. |
Well, the problem is that the previous top level license was outright wrong, and did not accurately describe what was in the repository.. :) So it would be a technical solution for your tooling to work, but it would also be inaccurate from the licensing standpoint. @Mark-Simulacrum Thoughts? |
How does this work for the top level rust repo, which also has the top-level LICENSE-APACHE and LICENSE-MIT, as well as LICENSES/ that contains a number of other licenses? Maybe something like this file COPYRIGHT would be sufficient to explain the situation? I can check with my internal team if that’d cover it. For a longer term solution, we are indirectly using GitHub’s license reporting, so I put together a PR licensee/licensee#820 that I hope will teach GitHub how to handle the REUSE |
Well, it works in a similar way as it did before for rustc-perf :) It just mentions MIT and Apache, without considering the actual complexity of the Rust compiler licensing story 🤷 |
I think if there is a strong need to avoid cloning rustc-perf I'd rather add a new config option to exclude specific submodules from vendoring. The licensing situation of rustc-perf is complex, and we shouldn't paper over it. |
Originally posted by @erickt in #137020 (comment)
The text was updated successfully, but these errors were encountered: