Re: rust non-free-compatible trademark

[lkcl <luke.leighton@gmail.com>]

On Mon, Jul 18, 2022 at 8:09 AM David Brown <david.brown@hesbynett.no> 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:
>
> <https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/>

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.