From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9AB04C433B4 for ; Thu, 29 Apr 2021 15:06:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 64C02613F8 for ; Thu, 29 Apr 2021 15:06:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240448AbhD2PH0 (ORCPT ); Thu, 29 Apr 2021 11:07:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233290AbhD2PHW (ORCPT ); Thu, 29 Apr 2021 11:07:22 -0400 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0768AC06138B; Thu, 29 Apr 2021 08:06:36 -0700 (PDT) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94 #2 (Red Hat Linux)) id 1lc8F5-009J9w-Rq; Thu, 29 Apr 2021 15:06:16 +0000 Date: Thu, 29 Apr 2021 15:06:15 +0000 From: Al Viro To: Mariusz Ceier Cc: Kajetan Puchalski , ojeda@kernel.org, Linus Torvalds , Greg Kroah-Hartman , rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org, Linux Kernel Mailing List Subject: Re: [PATCH 00/13] [RFC] Rust support Message-ID: References: <20210414184604.23473-1-ojeda@kernel.org> <878s51e3jc.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.