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
Reply-To: mceier+kernel@gmail.com
Sender: mceier@gmail.com
In-Reply-To: <878s51e3jc.fsf@gmail.com>
References: <20210414184604.23473-1-ojeda@kernel.org> <CAJTyqKP4Ud7aWxdCihfzeZ3dQe_5yeTAVnXcKDonciez-g2zWA@mail.gmail.com>
 <878s51e3jc.fsf@gmail.com>
From:   Mariusz Ceier <mceier+kernel@gmail.com>
Date:   Thu, 29 Apr 2021 14:06:12 +0000
Message-ID: <CAJTyqKOEG1tF0YGOvNeyidjF+2MaXoY5kCo9-cZ4Ri_Jb8XV8Q@mail.gmail.com>
Subject: Re: [PATCH 00/13] [RFC] Rust support
To:     Kajetan Puchalski <mrkajetanp@gmail.com>
Cc:     ojeda@kernel.org, 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"
Precedence: bulk

On 29/04/2021, Kajetan Puchalski <mrkajetanp@gmail.com> wrote:
>
> Mariusz Ceier <mceier+kernel@gmail.com> writes:
>
>> 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.
>
> Could you explain exactly what the issue you see there is?
> Surely if someone develops a proprietary compiler and then writes
> kernel
> drivers that use that compiler, nobody else will be able to build
> them.
> Because of that, none of the maintainers will be able to run or
> test
> the code and it'll never actually get merged into the kernel.
> Surely they'd effectively be sabotaging themselves.
>

Let's assume the hipothetical corporation wants to add some
proprietary stuff to the kernel and avoid sharing the code (sharing
the code is GPL requirement) - maybe they're producing proprietary
hardware e.g. risc-v processor with proprietary ISA extension. So
"none of the maintainers will be able to run or test the code and
it'll never actually get merged into the kernel." is exactly what it
wants.

To do this they could modify any non-GPL tool required to build the
kernel e.g. flex, rust or openssl so that for files with .proprietary
extension they would execute some code (like "patch this file") taken
from database of shell codes based just on .proprietary file name (so
that the contents of .proprietary files will be freely modifiable -
citing GPL: "The source code for a work means the preferred form of
the work for making modifications to it.").

These .proprietary files can be GPL'd since they don't contain any
useful information for outsiders - all of it could be in the shell
codes. The source code of the modified tool wouldn't have to be
shared, since their license doesn't require it.

I think such modified kernel source code would still be
GPL-compatible, but not benefit the kernel community. If the tool was
GPL-licensed, corporation would have to share it's source code - and I
assume also the database of shell codes, due to:

> 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.

> --
> Kind regards,
> Kajetan
>