linux-kernel - Re: [PATCH 00/13] [RFC] Rust support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJTyqKP4Ud7aWxdCihfzeZ3dQe_5yeTAVnXcKDonciez-g2zWA@mail.gmail.com>
Date:   Wed, 28 Apr 2021 18:34:07 +0000
From:   Mariusz Ceier <mceier+kernel@...il.com>
To:     ojeda@...nel.org
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        rust-for-linux@...r.kernel.org, linux-kbuild@...r.kernel.org,
        linux-doc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/13] [RFC] Rust support

Hello,
  First of all IANAL, so I might be wrong regarding the issue below.

On 14/04/2021, ojeda@...nel.org <ojeda@...nel.org> wrote:
>
> ## Why not?
>
> Rust also has disadvantages compared to C in the context of
> the Linux kernel:
>
>
>   - Single implementation based on LLVM. There are third-party
>     efforts underway to fix this, such as a GCC frontend,
>     a `rustc` backend based on Cranelift and `mrustc`,
>     a compiler intended to reduce the bootstrapping chain.
>     Any help for those projects would be very welcome!
>
>   - Not standardized. While it is not clear whether standardization
>     would be beneficial for the kernel, several points minimize
>     this issue in any case: the Rust stability promise, the extensive
>     documentation, the WIP reference, the detailed RFCs...
>

After reading the interview referenced by https://lwn.net/Articles/854740/
I think there might be issue with licensing - few quotes from the interview:

> And on the other hand, I've seen a lot of BSD (or MIT or similar) licensed open source projects that just fragment when they become big enough to be commercially important, and the involved companies inevitably decide to turn their own parts proprietary.

> So I think the GPLv2 is pretty much the perfect balance of "everybody works under the same rules", and still requires that people give back to the community ("tit-for-tat")

> So forking isn't a problem, as long as you can then merge back the good parts. And that's where the GPLv2 comes in. The right to fork and do your own thing is important, but the other side of the coin is equally important - the right to then always join back together when a fork was shown to be successful.

Rust compiler license doesn't require for people to give back to the
community - corporation can create their own version of rust compiler
adding some proprietary extensions, develop drivers with it and even
if the drivers code will be GPL'd they won't be buildable by anyone
but that corporation. The rust compiler license doesn't require
sharing changes when you modify it. The similar problem has flex and
openssl required to build the kernel, but so far no one thought about
abusing them afaik.

That "single implementation based on LLVM" uses a mix of MIT, Apache,
BSD-compatible and other licenses. It doesn't use strong copyleft
license in contrast to almost every tool required to build the kernel,
except for flex (BSD, no (L)GPL alternative afaik) and openssl (Apache
license, gnutls could be used instead).

I suggest to wait until featureful GPL implementation of rust language
is made (assuming GNU Rust is on the way) before merging any rust code
in the kernel and when that implementation is done make a requirement
that all rust code must be buildable by at least GPL implementation.

Maybe it would also be worthwhile to make the requirement that the
kernel must be buildable with free software (not just open source
software) explicit ?

Best Regards,
Mariusz Ceier