Re: rust non-free-compatible trademark

[David Malcolm <dmalcolm@redhat.com>]

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”, <https://rust-gcc.github.io/>, 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
>