Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210414184604.23473-1-ojeda@kernel.org>
In-Reply-To: <20210414184604.23473-1-ojeda@kernel.org>
Reply-To: mceier+kernel@gmail.com
From:   Mariusz Ceier <mceier+kernel@gmail.com>
Date:   Wed, 28 Apr 2021 18:34:07 +0000
Message-ID: <CAJTyqKP4Ud7aWxdCihfzeZ3dQe_5yeTAVnXcKDonciez-g2zWA@mail.gmail.com>
Subject: Re: [PATCH 00/13] [RFC] Rust support
To:     ojeda@kernel.org
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org,
        linux-doc@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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

On 14/04/2021, ojeda@kernel.org <ojeda@kernel.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) license=
d open source projects that just fragment when they become big enough to be=
 commercially important, and the involved companies inevitably decide to tu=
rn their own parts proprietary.

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

> So forking isn't a problem, as long as you can then merge back the good p=
arts. And that's where the GPLv2 comes in. The right to fork and do your ow=
n 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 su=
ccessful.

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