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: <YIrLZ8Siip0C0d9b@zeniv-ca.linux.org.uk>
Date:   Thu, 29 Apr 2021 15:06:15 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Mariusz Ceier <mceier+kernel@...il.com>
Cc:     Kajetan Puchalski <mrkajetanp@...il.com>, ojeda@...nel.org,
        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

On Thu, Apr 29, 2021 at 02:06:12PM +0000, Mariusz Ceier wrote:

> > You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, *to be licensed as a whole* at no charge to all third parties under the terms of this License.
> 
> 
> The issue here is, non-GPL tools enable development and distribution
> of GPL-compatible yet proprietary versions of the kernel, unless I'm
> mistaken.

And?  For your argument to work, we'd need to have the kernel somehow
locked into the use of tools that would have no non-GPL equivalents
*and* would be (somehow) protected from getting such equivalents.
How could that be done, anyway?  Undocumented and rapidly changing
features of the tools?  We would get screwed by those changes ourselves.
Copyrights on interfaces?  Software patents?  Some other foulness?

I honestly wonder about the mental contortions needed to describe
something of that sort as "free", but fortunately we are nowhere
near such situation anyway.

I don't like Rust as a language and I'm sceptical about its usefulness
in the kernel, but let's not bring "gcc is better 'cuz GPL" crusades
into that - they are irrelevant anyway, since we demonstrably *not*
locked into gcc on all architectures your hypothetical company would
care about, Rust or no Rust.