From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id DFC2C3858436 for ; Mon, 18 Jul 2022 21:01:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DFC2C3858436 Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-644-daOLn9P4N8e--vcac82W6w-1; Mon, 18 Jul 2022 17:01:10 -0400 X-MC-Unique: daOLn9P4N8e--vcac82W6w-1 Received: by mail-qv1-f72.google.com with SMTP id oo28-20020a056214451c00b004732e817c96so6247695qvb.22 for ; Mon, 18 Jul 2022 14:01:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=q5zcB7IHo5TD/6WHLjKK6TLE4pcdMnI/vkPVuGLsO8k=; b=JJ0ccaPwRKdyzf5qVfzyZ1a1HETII5KN77E26CWI9XOz0C5d7O8bIJMmxh8PDtMBVZ Rj8ZHZm6h8n6Rfv/ro+L0iiiXu8AEMvLz3Xz3qhcfbt2f9bc7nPD9Mk5B7zgMNZL/NSz ONcOiTu/cSZUv6oz6ilb/RHjwFwIzhvrIVDsnEMVkJ49VYHvctP9cLgYJxpMd5f4Mh+S P1Z1LxOdlIS5tS66Prkxj/oztkTyAd+ILP2pAMD8zQJrlOWvYAwrbaklygOzbv1tLa81 qjOhp3diEL3PEF0z7FkLqd4mL+06FmqKWwfa498kh86JNmqDmjq3Ppt0tEleXZ4S55km 4C1g== X-Gm-Message-State: AJIora/GTGaraocsJmotnRa+xlADmGCcXsQvY61BOV4W7KRc6vhKNjs8 T8N3uT/NAMNv5Y/IAmZ4IaxOn3xN4XnrgKu4hLxUEJcFqFGxLxUjQj8RYAZWVI8TusM2XjyXu5C AeHdbA6U= X-Received: by 2002:a05:620a:bcb:b0:6a9:8f2a:ecf9 with SMTP id s11-20020a05620a0bcb00b006a98f2aecf9mr18586898qki.351.1658178069452; Mon, 18 Jul 2022 14:01:09 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vEv7YEhEWKSPIfJvJwKRIcleusVAmQnO6uG3Vvj94Hya0EQYMutRmdSDi5zzfZOvJPJs2imA== X-Received: by 2002:a05:620a:bcb:b0:6a9:8f2a:ecf9 with SMTP id s11-20020a05620a0bcb00b006a98f2aecf9mr18586828qki.351.1658178068696; Mon, 18 Jul 2022 14:01:08 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id r2-20020ac87ee2000000b0031ed590433bsm8733494qtc.78.2022.07.18.14.01.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Jul 2022 14:01:07 -0700 (PDT) Message-ID: Subject: Re: rust non-free-compatible trademark From: David Malcolm To: lkcl , Florian Weimer , lkcl via Gcc Date: Mon, 18 Jul 2022 17:01:06 -0400 In-Reply-To: <8F5B23E9-BC92-4BFC-A829-AF818CA2C170@gmail.com> References: <87wncaw9ty.fsf@oldenburg.str.redhat.com> <8F5B23E9-BC92-4BFC-A829-AF818CA2C170@gmail.com> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2022 21:01:15 -0000 On Mon, 2022-07-18 at 20:35 +0100, lkcl via Gcc wrote: > (apologies top-posting, strange mobile mailer). i would expect in that > case that the Rust Foundation to work closely with Certification Mark > Licensees, and to come to an accommodation, defining a subset if > necessary. > > if the gcc developers can clearly enunciate why shipping a "borrow > checker" (whatever that is) is unreasonable, the Certification Mark > Holder has to take that into consideration.  without knowing full > details i would expect it to be a third party library of some kind > (rather than libgcc.a) > > Certification Mark Holders *have* to act FRAND otherwise they lose the > Certification Mark > > aside: it is reasonable for a Certification Mark Holder to require full > compliance, they are after all the Custodians of the Language, and one > would not expect a broken (non-compliant) compiler to actually be > distributed, regardless of a Certification Mark. > > thus i think you'll find that the usual "pre-alpha alpha beta" release > cycles which would and would not naturally be released for distribution > fit directly and one-to-one with what a Certification Mark Holder would > and would not authorise. > > regarding missing tests: well, tough titty on the Certification Mark > Holder.  if they cannot define the Compliance Test Suite they cannot > tell people they are non-compliant, can they! > > thus although quirky it all works out. > > (whereas telling people what patches they can and cannot apply just > pisses them off). I've been trying to ignore this thread, but unfortunately it seems to still be going on. Luke: you appear to me to be the one who is telling people what patches they can and cannot apply, and it's pissing me off. You seem to me to be constructing elaborate arguments for why there's some kind of legal problem here, and elaborate purported workarounds, when it isn't at all clear to me that there are any problems. Are you a lawyer? If so please consider volunteering your time to the GCC Steering Committee *privately*. If not, it seems to me to be a terrible idea to try to get the developers to pontificate in public about alleged legal issues with the project, their implications, and supposed workarounds. The GCC Steering Committee has approved merging the rust frontend into GCC. It's a big project, so I fully expect that the frontend that we ship in GCC 13.1 will have bugs, missing functionality, and slight differences compared to rustc. I'm guessing we'll need to have some kind of in the release notes for GCC 13 to set people's expectations - perhaps the GCC 13 release of the rust frontend will be considered just of "alpha" quality, for people to "kick the tyres" - but I leave that judgement call to Philip and the other gcc rust developers. There are no doubt "unknown unknowns" (to misquote Donald Rumsfeld), and shaking these out will make help both the GCC and Rust communities - but please can we leave the technical issues to the developers doing the work (I'm a gcc developer, but merely a rust "fanboy"). The gcc rust frontend is an ambitious one with lots of technical challenges, but which has the potential to make the GCC and Rust development communities stronger; this discussion seems to me to be a pointless attempt to pick a fight between the two. These opinions are my own, and not those of my employer, etc etc Dave > > l. > > > > On July 18, 2022 7:32:25 PM GMT+01:00, Florian Weimer < > fweimer@redhat.com> wrote: > > * lkcl via Gcc: > > > > > if the Rust Foundation were to add an extremely simple phrase > > > > > >    "to be able to use the word rust in a distributed compiler your > > >     modifications must 100% pass the test suite without modifying > > >     the test suite" > > > > > > then all the problems and pain goes away. > > > > No.  It would actually make matters worse for GCC in this case > > because > > the stated intent is to ship without a borrow checker (“There are no > > immediate plans for a borrow checker as this is not required to > > compile > > rust code”, , retrieved 2022-07-18). > > There > > are of course tests for the borrow checker in the Rust test suite, > > and > > those that check for expected compiler errors will fail with GCC. > > > > Thanks, > > Florian >