RISC-V implementation contains likely GPL-3 code

[brson]

From riscv32.rs:

intrinsics! {
    // Implementation from gcc
    // https://raw.githubusercontent.com/gcc-mirror/gcc/master/libgcc/config/epiphany/mulsi3.c
    pub extern "C" fn __mulsi3(a: u32, b: u32) -> u32 {
        let (mut a, mut b) = (a, b);
        let mut r = 0;

        while a > 0 {
            if a & 1 > 0 {
                r += b;
            }
            a >>= 1;
            b <<= 1;
        }

        r
    }
}

That link contains a GPL-3 license.

It's not ok to read GPL code and then reimplement it for Rust, let alone copy it verbatim.

[mati865]

Compiler Rt provides Apache-2.0 version of this function but in assembly: https://github.com/llvm-mirror/compiler-rt/blob/7a739a0dfb6d408c6d587e5c7b52abd89fc3fdd3/lib/builtins/riscv/mulsi3.S

[gnzlbg]

This was submitted in #251 by @dvc94ch and reviewed by @japaric .

I don't think we can just delete the code without providing a replacement because I recall that Debian ships rust for riscv-32 (cc @infinity0, is that correct?).

[infinity0]

@gnzlbg no, Debian doesn't ship any riscv-32. we are beginning to ship riscv-64 for some things like gcc, but are blocked on llvm for rustc. Would be nice to eventually get riscv-64 for rustc though.

• https://buildd.debian.org/status/package.php?p=rustc
• https://buildd.debian.org/status/package.php?p=llvm-toolchain-9

[skade]

Is this the only instance of this happening in RISC-V? @dvc94ch, can you confirm that this is the only instance of copied/ported gcc code?

[skade]

Note: The copyright holder of this code is Embecosm.

[dvc94ch]

@brson how do you suggest impl compatible implementations? To me __mulsi3 does not constitute a specification. So anyone who has ever looked at gcc code can't impl a c compiler for the rest of their career? I find it absurd

[bjorn3]

This code is equivalent to the llvm compiler-builtins riscv asm implementation: https://github.com/llvm/llvm-project/blob/57b08b0944046a6a57ee9b7b479181f548a5b9b4/compiler-rt/lib/builtins/riscv/mulsi3.S#L15

[dvc94ch]

Also if someone wants to sue I can take the heat. I'm moving to Phuket in Feb I doubt that's in a US or European jurisdiction

[gnzlbg]

@dvc94ch I'm not a lawyer and this isn't legal advice, but the problem isn't you getting sued. The problem would be if a company which has a product that uses Rust gets sued, since it's their job to check that their product licenses comply with the regulations they operate in. It doesn't really matter what happens afterwards (*) since that alone would probably severely hurt the Rust project and make it unviable in the eyes of many for any commercial application. Particularly if we knew about the issue and didn't do anything about it.

EDIT: also @dvc94ch, the purpose of finding if there is more code like this anywhere is to be able to fix things and protect the project, not to assign blame. Stuff like this happens on every big project, that's kind of unavoidable. The main difference is whether the project appropriately reacts to these issues or "ignores" them.

(*) Such a company could try to sue the Rust project, and the Rust project could maybe try to sue you, but that's kind of pointless if there isn't much money to be obtained from any of that, and also none of that would repair any damage done to the Rust project.

[dvc94ch]

Well it's not plagiarism, since the source was accredited. Copyright or patent infringement, are vague concept, which are completely divorced from questions of morality

[gnzlbg]

Nobody is talking about plagiarism. We tell Rust users that they can compile a Rust binary and by default no GPL licensed source code will be embedded into the binary, which allows them to sell the binary without having to provide any source code. Your patch silently includes GNU licensed source code in all Rust binaries on RISC-V, making anyone producing those binaries without releasing the source code liable in many jurisdictions.

You have been asked twice whether this is the only case where you have submitted GNU licensed source code to the Rust project, and you have deflected the question twice.

If you don't want or can't help fixing this issue, that's ok, please just say so, so that we can factor that in the discussion of possible solutions.

[dvc94ch]

The cabi references the spec, targets do not reference the cortexm targets, rt I think references cortexm rt and the official sdk, e310x references the spec, board support crates reference their schematics

[dvc94ch]

I'll submit a PR to remove it

[gnzlbg]

I'll submit a PR to remove it

Waait! Let's wait and see what the others think. We might need to replace this code with something else, or maybe that GCC code came from somewhere else (e.g. LLVM also has it) or that GCC code is available under multiple licenses or probably other things.

The cabi references the spec, targets do not reference the cortexm targets, rt I think references cortexm rt and the official sdk, e310x references the spec, board support crates reference their schematics

Maybe we should open other issues to re-check these as well and make sure that they are ok ?