Re: rust non-free-compatible trademark

[lkcl via Gcc]

On Mon, Jul 18, 2022 at 10:01 PM David Malcolm  wrote:

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

1) please don't you dare put words into my mouth that i did not state.
first and only warning.
2) i'm sorry you're annoyed. Asperger's interactions with neuro-typical
individuals who are not used to the same typically do not go well:
this conversation has all the hallmarks i'm used to being subjected
to (and, frankly, shouldn't have to put up with).
as you can probably imagine in 25 years it's pretty tiresome
for me to be constantly subjected to abuse based solely on
misunderstandings that, with the tiniest bit of tolerance, could
easily have been avoided.
  3) as you work for redhat, you should be able to speak to HR and
  request Diversity training for how to interact with people with
  Asperger's.  [or, at least, how to recognise them and not get
  pissed off by how they speak].  given that it was "neurodiversity month"
  only a few weeks ago you should be able to find references on linkedin.

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

i'm a Libre Ethical Technology Specialist.  i expect a project such as
gcc to be held accountable publicly for its decisions and actions,
and to act responsibly.  this conversation will be watched by a hell
of a lot of people and if there are private conversations on this topic
being held behind closed doors then how the hell can anyone have
any confidence and trust in gcc?

i'm publicly and fully accountable in the FOSS projects that *i* manage,
including the full financial records, and given how massively high-profile
gcc is, i expect it to be held publicly accountable to a far greater degree.


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

or, if done incorrectly, screw absolutely everyone who ever tries
to distribute gcc or attempt to contribute to it.

> this discussion seems to me to be a
> pointless attempt to pick a fight between the two.

wrong, sorry.  read again the parts where i recommend a workable
solution that is based on a past real-world case: the ADA Certification
Mark.  here is the link again:

http://archive.adaic.com/pol-hist/policy/trademrk.txt

what you *might* be referring to is that i have absolutely no qualms
at all about calling out the Mozilla Foundation's Rust Trademark as,
frankly, "bloody stupid".  given their past handling of iceweasel this
should be no surprise to anyone familiar with that fiasco.

i have absolutely no problem with the Python Software Foundation
Trademark because the PSF Trademark does not attempt such a
kak-handed, heavy-handed and draconian imposition.

i mean, for god's sake, the attempt to hide the efforts to demand
that people contact them if they perform any kind of "unauthorised"
patches is hidden in a document entitled "Logo and Media Policy Guide".
this in no way should inspire confidence!

please understand: if they *actually* did a decent job and *actually*
listened by converting the Trademark to a proper Certification Mark
(just as ADA did in 1987), i would be the first person to very loudly
praise them for such an astoundingly forward-thinking strategic
move to protect the Rust Language from harm in a very natural
and logical way.

from me you will always get the blunt truth as i see it.  no gloves,
no sugar-coating.  no diplomacy, no lying by omission.  it's... not
popular, but serves an extremely valuable purpose: cuts through
a lot of crap on topics that people were either not aware of or
were deeply uncomfortable bringing up, often for years.

you might not feel comfortable *admitting* that (certainly not publicly)
but after some [considerable] time and calm and considered
investigation, and once your feathers have de-ruffled, you'll
appreciate what i've done.

l.

Re: rust non-free-compatible trademark

[David Malcolm via Gcc]

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

Re: rust non-free-compatible trademark

[lkcl via Gcc]

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

l.



On July 18, 2022 7:32:25 PM GMT+01:00, Florian Weimer  
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

Re: rust non-free-compatible trademark

[Arthur Cohen via Gcc]

Hi Florian,

On Mon, Jul 18, 2022, 20:33 Florian Weimer via Gcc  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).


The website is not up to date and we do have to change that. We do have
plans for borrow-checking, which revolve around using and contributing to
the Polonius project.

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


Thanks,

-- 
Arthur Cohen

Re: rust non-free-compatible trademark

[Florian Weimer via Gcc]

* 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

Re: Marc Poulhies appointed Ada co-maintainer

[Arthur Cohen via Gcc]

Congratulations Marc!

Very happy for you. You deserve all the best.

Félicitations :)

-- 
Arthur

On Mon, Jul 18, 2022, 19:35 David Edelsohn via Gcc  wrote:

> I am pleased to announce that the GCC Steering Committee has appointed
> Marc Poulhies as Ada co-maintainer.
>
> Please join me in congratulating Marc on his new role.
>
> Marc, please update your listing in the MAINTAINERS file.
>
> Happy hacking!
> David
>

Marc Poulhies appointed Ada co-maintainer

[David Edelsohn via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed
Marc Poulhies as Ada co-maintainer.

Please join me in congratulating Marc on his new role.

Marc, please update your listing in the MAINTAINERS file.

Happy hacking!
David

Re: rust non-free-compatible trademark

[Richard Kenner via Gcc]

> A Certification Mark is the proper way to formally and legally enforce such
> requirements. 

BTW, nobody is or was at all confident that the Ada mark was legally
enforcable.  I'm in the camp that it isn't.

> telling people they cannot patch the source code without permission

Nobody is telling people that.  What they're saying is the same thing as
the GPL does: it you distribute modified code, you need to be clear that
what you're distributing is a modification.

Re: rust non-free-compatible trademark

[Richard Kenner via Gcc]

> In order to be a validated Ada compiler, a compiler must pass
> an extensive suite of programs called the Ada Compiler Validation
> Capability (ACVC).

FYI: the current name for this is ACATS: Ada Conformity Assessment Test
Suite.

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

What does "in" mean here?  Is "rust" modifying "language" or "compiler"
in this case?  As was stated, that's a significant difference.

> a thorough investigation of how it was done for ADA should reveal
> how it can be properly done for gccrs and rustc.

It's a very different situation.  Ada was a standardized language via
a very formal process.  And it was a very different time.

Re: rust non-free-compatible trademark

[lkcl via Gcc]

a (private) discussion has, fascinatingly, uncovered this, from 1987:
http://archive.adaic.com/pol-hist/policy/trademrk.txt

In order to be a validated Ada compiler, a compiler must pass
an extensive suite of programs called the Ada Compiler Validation
Capability (ACVC).  The AJPO has adopted a certification mark to show
that a compiler has passed the ACVC and is a validated compiler or
a compiler derived from a validated base compiler as defined in the
Ada Compiler Validations Procedures and Guidelines (version 1.1 of
which was issued in January 1987).  The certification mark may also
be used on certain literature accompanying or documenting a validated
compiler.  Information concerning the proper use of the certification
mark was distributed to interested parties during the summer of 1987.

what that tells us is that there is precedent for a Computer Language
to apply for and be granted a *Certification Mark* which was enforced
through the extremely simple process of running an Authorised
Certification Suite.

the modern name for such is "test suite".

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.

as i said: the Rust Foundation is the world's first FOSS Project
attempting to create a Certification Mark (and doing a poor-man's
job of it).

a thorough investigation of how it was done for ADA should reveal
how it can be properly done for gccrs and rustc.

i feel reasonably confident in saying that if i had the time to look
up discussions on this topic, there would almost certainly be requests
from the Rust Foundation that gccrs pass the exact same test suites
as provided with rustc.

A Certification Mark is the proper way to formally and legally enforce such
requirements.  telling people they cannot patch the source code without
permission is a troublesome and tiresome and non-trusting way to attempt
the same objective.

l.

RE: [EXTERNAL] Re: Inquiry: Country of Origin for gfortran

[Zhang, Cynthia X. (GSFC-710.0)[TELOPHASE CORP] via Gcc]

Thank you for your help!

-Original Message-
From: Thomas Koenig  
Sent: Sunday, July 17, 2022 4:55 AM
To: Zhang, Cynthia X. (GSFC-710.0)[TELOPHASE CORP] ; 
fort...@gcc.gnu.org; gcc mailing list 
Subject: [EXTERNAL] Re: Inquiry: Country of Origin for gfortran


Hi Cynthia,

 > Hello, my name is Cynthia and I am a Supply Chain Risk Management  > Analyst 
 > at NASA. NASA is currently conducting a supply chain  > assessment of 
 > gfortran. As stated in Sections 208 and 514 of the  > Consolidated 
 > Appropriations Act, 2022, Public Law 117-103,  > enacted March 15, 2022, a 
 > required step of our process is to  > verify the Country of Origin (CoO) 
 > information for the  > product (i.e., the country where the products were 
 > developed,  > manufactured, and assembled.)

 > As gfortran is open source, we understand that this inquiry is  > not 
 > directly applicable, as contributions may be made from  > individuals from 
 > around the world. In this case, NASA is  > interested in confirming the 
 > following information:

 > 1.  Is there an organization which sponsors/publishes the project, or  > a 
 > primary developer who audits the code for potential vulnerabilities, > 
 > errors, or malicious code? Y/N

gfortran is not an independent project, it is part of the Gnu Compiler 
Collection, 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2F&data=05%7C01%7Ccynthia.x.zhang%40nasa.gov%7C6cc48038caed4c1e908a08da67d211b3%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637936449313898438%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NxQtCichrdJBdyRR6ZIlmttE72yqSXE6rIxWUEQoMHQ%3D&reserved=0
 .  As such, any evaluation you may already have made of gcc also should also 
apply to gfortran, and I am also addressing this mail to the gcc mailing list, 
where it is more appropriate, especially since I personally am unclear about 
the current relationship with the Free Software Foundation.

Regarding gfortran specifically:  Code changes are reviewed by the individuals 
listed in the file

https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dblob_plain%3Bf%3DMAINTAINERS%3Bhb%3DHEAD&data=05%7C01%7Ccynthia.x.zhang%40nasa.gov%7C6cc48038caed4c1e908a08da67d211b3%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637936449313898438%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PUhKlistyKpWB%2BvknwbesKHucw3uohnDMBqL66%2BrVkI%3D&reserved=0

(where you can search for Fortran).

 > 2.  Does gfortran have an overseeing organization or individual
 >   along these lines? Y/N

See my previous reply.

 > 1.  If so, please provide the name of the organization and country
 > they are established in

 > If the information above is unknown or cannot be provided, we  > request 
 > that you provide the country or list of countries where  > the majority of 
 > contributions originate from to satisfy Sections  > 208 and 514 of the 
 > Consolidated Appropriations Act, 2022, Public  > Law 117-103, enacted March 
 > 15, 2022.

Main contributions to gfortran, i.e. the Fortran front end to gcc and its 
supporting library, came (in no particular order) from the UK, the US, France, 
Finland, Germany, the Netherlands and the Czech Republic.
Up to 2006, there were also some contributors from China.

Best regards

Thomas

[RFC] Function Multi Versioning on Arm

[Daniel Kiss via Gcc]

Hello,

We are going to add Function Multiversioning [1] support to Arm architectures.
The specification is made public as beta[2] to ensure toolchain that follows Arm
C Language Extension will implement it in the same way.

A few tweaks considered to make the developers' life easier.
Since the `target` attribute is used widely on Arm, we would like to introduce a
new attribute `target_version` to avoid confusion and possible deployment
problems. The `target_clones` attribute will be supported too. Also the 
“default”
version to be made optional.

We are looking for feedback on the specification (reply, github works too).

Thanks so much,
Daniel

[1] https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html 
[2] 
https://github.com/ARM-software/acle/blob/main/main/acle.md#function-multi-versioning

Re: rust non-free-compatible trademark

[lkcl via Gcc]

On Mon, Jul 18, 2022 at 9:50 AM Jonathan Wakely  wrote:

> You haven't been ignored. People have expressed reasonable
> disagreements with your interpretation.
>
> Just because every line of your email hasn't been explicitly responded
> to with positive acknowledgement of receipt doesn't mean you've been
> ignored.

if i feel that i've been ignored, and it makes me upset and frustrated
i have every right to say so, and whilst i know that you are trying to
help you are unfortunately at risk from telling me that my feelings
are invalid, which is a line that i trust you understand is completely
and utterly inappropriate that you cannot cross.

bottom line is that you're giving a perfectly reasonable justification
for Mark's lack of empathy.

[sadly this is extremely common in Technical discussions]

i know exactly what Mark's doing: he's only superficially skim-reading
reading (citing the Java case without even acknowledging that i'd
raised it already - twice), wants to take control of the conversation and
wants it shut down as quickly as possible (telling me to "go contact the
Rust Foundation directly").

i'd very much like to see Mark read - and follow - this
https://www.crnhq.org/cr-kit/#empathy

i'm already at this:
https://www.crnhq.org/cr-kit/#assertiveness

l.

Re: rust non-free-compatible trademark

[Jonathan Wakely via Gcc]

On Mon, 18 Jul 2022 at 09:07, lkcl via Gcc  wrote:
> which is why i said - and have been ignored - that the gcc developers
> need rather urgently to seek proper legal counsel and get a proper
> legal opinion.

You haven't been ignored. People have expressed reasonable
disagreements with your interpretation.

Just because every line of your email hasn't been explicitly responded
to with positive acknowledgement of receipt doesn't mean you've been
ignored.To keep insisting that sounds silly, and IMHO will increase
the chance of being ignored in future.

Re: rust non-free-compatible trademark

[lkcl via Gcc]

On Mon, Jul 18, 2022 at 8:09 AM David Brown  wrote:

> Speaking as someone who is neither a lawyer, nor a GCC developer, nor
> even (as yet) a Rust user, it seems to me that step 1 would be to hear
> what the Rust Foundation has to say on the matter:
>
> 

this is their Trademark License.  like a Patent License or a Copyright
License it comprises *additional* terms and conditions with which
You *must* Comply.

[you *can* attempt to ignore it but exactly like ignoring a Copyright License
 you risk operating Unlawfully and place yourself at risk of being sued
 at best in a Civil Court, and there are some circumstances in Trademark
 Law where you can end up in a Criminal Court as well].

the objectionable section of that Trademark License is:

Uses that do not require explicit approval #

Distributing a modified version of the Rust programming language or the
   Cargo package manager, provided that the modifications are limited to:
   - porting the software to a different architecture
   - fixing local paths
   - adding patches that have been released upstream
   - adding patches that have been reported upstream, provided that the
 patch is removed if it is not accepted upstream

Uses that require explicit approval #

Distributing a modified version of the Rust programming language
[or the Cargo package manager] with modifications other than those
permitted above and calling it Rust or Cargo requires explicit,
written permission from the Rust Foundation.

so any optimisations made by anyone are Unlawful.

any additional documentation is Unlawful.

any addition of Copyright notice files (debian/copyright) is Unlawful.

why?

because none of those "patches" are "permitted" by the Rust Foundation
under their Trademark License.


> As far as I can tell, if they have been happy with the current gccrs
> project, they should in principle be happy with its integration in gcc
> mainline.  And they are also happy to talk to people, happy to promote
> rust, and happy to work with all kinds of free and open source projects.
>   The key thing they want to avoid would be for GCC to produce a
> compiler that is mostly like rust, but different - leading to
> fragmentation, incompatibilities, confusion, bugs in user code.  /No
> one/ wants that.

yes, absolutely.  it's quite obvious that that was the intent of the
clause that they added, which explicitly prohibits patching without
consent [and still having the right to use the word "rust'].

however that prohibition is - as i have said many times and been ignored
as many times - is in *direct* violation of the GPL, and of Debian's DFSG
(on multiple counts), and is also completely Un-Reason-Able.

in addition - and this was not acknowledged either - any developer
*not* considered to be "part of the gcc team" - i.e. anyone who wants
to modify and then further distribute - patched versions of gcc containing
gccrs - also does so at the risk of violating the Rust Trademark.

> I would think that the long term aim here is that the gcc implementation
> of rust (may I suggest "grust" as a name, rather than "gust"?) be
> considered "official" by the Rust Foundation - with links and
> information on their website, their logo on the GCC website, and
> coordination between GCC and the Rust Foundation on future changes.
> That may be ambitious, or far off, but it should be the goal.

at which point although the gcc team is fine, the ongoing distribution
of gcc by anyone and everyone still is not.

actually, it occurs to me that under the terms and conditions of the GPL,
even the gcc developers may not be able to comply with the GPL *and*
those above Trademark Conditions, because the restriction on
what can and cannot be patched is in direct conflict with *granting
the right to modify*.

if this is in fact the case then the only choice left for the gcc developers
would be to cease and desist distribution of gcc, because they cannot
comply with both Licenses simultaneously.

which is why i said - and have been ignored - that the gcc developers
need rather urgently to seek proper legal counsel and get a proper
legal opinion.

l.

Re: rust non-free-compatible trademark

[David Brown]

On 17/07/2022 18:31, Mark Wielaard wrote:

Hi Luke,

On Sun, Jul 17, 2022 at 04:28:10PM +0100, lkcl via Gcc wrote:

with the recent announcement that rust is supported by gcc


There is just a discussion about whether and how to integrate
(portions) of the gccrs frontend into the main gcc repository. Nobody
claims that means the rust programming language is supported by gcc
yet. There is a lot of work to be done to be able to claim that.


has it been taken into consideration that the draconian (non-free-compatible)
requirements of the rust Trademark make the distribution of the gcc
compiler Unlawful?

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920


That looks to me as an overreaching interpretation of how to interpret
a trademark. I notice you are the bug reporter. It would only apply if
a product based on gcc with the gccrs frontend integrated would claim
to be endorsed by the Rust Foundation by using the Rust wordmark. Just
using the word rust doesn't trigger confusion about that. And
trademarks don't apply when using common words to implement an
interface or command line tool for compatibility with a programming
language.

If you are afraid your usage of gcc with the gccrs frontend integrated
does cause confusion around the Rust word mark then I would suggest
contacting the Rust Foundation to discuss how you can remove such
confusion. Probably adding a README explicitly saying "this product
isn't endorsed by and doesn't claim to be endoresed by the Rust
Foundation" will be enough.

Good luck,

Mark



Speaking as someone who is neither a lawyer, nor a GCC developer, nor 
even (as yet) a Rust user, it seems to me that step 1 would be to hear 
what the Rust Foundation has to say on the matter:




As far as I can tell, if they have been happy with the current gccrs 
project, they should in principle be happy with its integration in gcc 
mainline.  And they are also happy to talk to people, happy to promote 
rust, and happy to work with all kinds of free and open source projects. 
 The key thing they want to avoid would be for GCC to produce a 
compiler that is mostly like rust, but different - leading to 
fragmentation, incompatibilities, confusion, bugs in user code.  /No 
one/ wants that.


I am sure that if the Rust Foundation foresaw a big problem here, they'd 
already have contacted the gccrs and/or GCC folks - the project is not a 
secret.


I would think that the long term aim here is that the gcc implementation 
of rust (may I suggest "grust" as a name, rather than "gust"?) be 
considered "official" by the Rust Foundation - with links and 
information on their website, their logo on the GCC website, and 
coordination between GCC and the Rust Foundation on future changes. 
That may be ambitious, or far off, but it should be the goal.


In the meantime, as far as I can see it is just a matter of writing 
"rust" without capital letters, and a documentation disclaimer that 
grust is not (yet) endorsed by the Rust Foundation.


David