Factor out rustc_apfloat into a standalone crate

[sunfishcode]

librustc_apfloat is a Rust translation of LLVM's APFloat library, written in C++, and provides software implementations of f32, f64, and other floating-point types, which are useful for performing host-independent floating-point computation. We made a standalone crate of this for use in Cranelift, however other compiler projects could make use of such a library as well, and in general it'd be good to have only one copy of this code.

Where's the best place for the code live?

• Create a new repository under the rust-lang organization.
• Use the repository that Cranelift is currently using here.

What should the crate be called?

• rustc_apfloat -- the current name. "apfloat" isn't very descriptive, except that it's the name of the upstream code this crate is based on. And the crate isn't specific to rustc :-).
• software_float -- a more descriptive name, and not yet claimed on crates.io
• other ideas?

cc @eddyb @lachlansneff

[eddyb]

software_float is a bit long, I'd rather expect something like softfloat.

cc @rust-lang/compiler

[eddyb]

Also, I think we need to figure out copyright. I remember talking to a few people about it and our licensing setup deals with LLVM, but I'm not sure about a crate in isolation.
cc @alexcrichton

[bstrie]

What's there about copyright to figure out? The copyright header of that LLVM file implies it's licensed under the Illinois Open Source License, which is an FSF- and OSI-approved permissive license. Surely the Rust translation should be licensed as the same, unless somebody has a good reason for wanting to change it?

[eddyb]

@bstrie rustc_apfloat is not currently explicitly licensed in any way different from any of the other Rust code in the repo, but apparently this is okay because of the COPYRIGHT file or something.
IANAL so no clue what we'd need to do here, I just remember being told things are okay.

[bstrie]

Ah, I see. I'm also not a lawyer, but I'm fairly confident that it isn't compliant with the license for us to create a derivative work of apfloat that doesn't use the Illinois license, at least not without explicit permission of the copyright holder. Those license headers claiming that rustc_apfloat is MIT/Apache seem somewhat dubious.

On the one hand I want to say that we should just change the license headers to be compliant (under this interpretation this doesn't count as relicensing, since we didn't have permission to use a different license in the first place); shipping more Illinois-licensed code when we already ship all of LLVM isn't a problem.

However--and here's the thing you might really need a lawyer for--if there's anyone who's contributed to rustc_apfloat while it's been erroneously licensed, I have absolutely no idea what license their contributions are actually licensed under. The conservative response would be to reach out to anyone who's ever contributed to it and ask them if they're okay with their contributions being licensed as Illinois.

[eddyb]

@bstrie Wasn't it decided that we can just remove copyright headers?
I assumed what we'd have to figure out is the license specified in the Cargo.toml.

[eddyb]

if there's anyone who's contributed to rustc_apfloat while it's been erroneously licensed, I have absolutely no idea what license their contributions are actually licensed under

Looking at https://github.com/rust-lang/rust/commits/master/src/librustc_apfloat, it's mostly sweeping changes across the the codebase, with only a few apfloat-specific changes.

Some of the more specific ones, like fixing comments, need to be upstreamed to LLVM as well, IMO.
I should've enforced a stricter policy of keeping the two in sync (modulo language/library minutiae).
(but I don't necessarily have a way to force apfloat changes to require my review)

[eddyb]

Note to self: write an email to Mozilla legal about this situation.
(please ping me on IRC/Discord next week until this comment gets removed)

[eddyb]

Oops, this really slipped through the cracks. I remembered about it at the All-Hands in Berlin (back in February IIRC), but forgot about it again.

Also, this is now completed: https://llvm.org/foundation/relicensing/ - LLVM moved to the Apache2 license.
So that might change the legal calculus a bit. But it seems likely we can just use Apache2 now.

[eddyb]

Once we move this out of tree we might want to have (as per #63416 (comment)):

• one branch for the port (where LLVM->Rust backports would go into)
• one branch for the crates.io version, based on the other branch, with some other patches on top

This would even allow upstreaming some of the changes to LLVM, but at our own pace.