Skip to content
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

Consider relicensing to "MIT OR Apache-2.0" to be compatible with Rust. #34

Open
kjetilkjeka opened this issue Apr 25, 2022 · 4 comments

Comments

@kjetilkjeka
Copy link

My assumption is that it will be simpler to merge this project into Rust if it is licensed the exact same way (https://listed.to/@cmr/7767/the-great-relicensing).

It seems like you @denzp is the only person with creative contributions to this project, will you be willing to add the Apache 2.0 license? If so add the necessary changes or if you prefer me to open the PR just state "I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option." and I will open it for you.

@kjetilkjeka
Copy link
Author

@denzp I will give you a little nudge here as it would make it possible to make progress on integrating this project into rust if you decided to do the re-licensing above.

@workingjubilee
Copy link

We are going to be adding a requirement for cross-compiled assembly tests for every architecture and enabling this would make it so we can actually require this in CI. While I deliberately left an out in my proposal of not requiring running those tests in CI, to allow tier 3 targets to continue to be ignored or buggy in CI at our whim, as nvptx64-nvidia-cuda is tier 2 and thus a "guaranteed to build" target, it is somewhat silly to relieve it of that obligation.

@kjetilkjeka
Copy link
Author

@workingjubilee my current understanding is that a re-implementation of this linker is unfortunately the best approach going forward. A fork would solve the maintainer issues, but not the licensing issues.

My ambitions is to make it slightly more generic in terms of targets to potentially make it useful for other GPU targets. LLVM recently got a SPIR-V target which is very exciting, but I have not had the chance to look into it yet. I have previously gotten indications that there are interests for letting such crate live in the rust repo (it seems like there are precedent for using a GIT subtree for "these kind of crates").

My intentions have been to contribute this work for a while now. Using Rust and cuda together is both of personal interest to me, and something my workplace are invested in. If there's anything around this approach that anyone would like to discuss I'm very interested in that.

@workingjubilee
Copy link

Yeah, it's ultimately a T-compiler / T-infra decision but historically we're pretty happy to subtree essential tooling for a target and ship it with rustc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants