I'm conflicted...
On the one hand, I'm a big fan of the GPL3+ myself, but on the other, I would like to think that if e.g. there are alternative compiler implementations, that the trademark would be used to ensure compliance with "the specification" (well... do the extend we have one), so that e.g. implementations don't start adding a bunch of non-standard extensions or specify things we think ought not be specified. However, that might not be a practical necessity?
The GPL itself seems to allow some additional terms to material that is added to covered works. Specifically:
Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:
…
e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
…
That is, if I read it correctly, declining to grant trademark rights would not result in GPLv3 incompatibility.
Since Firefox is mentioned, is the Debian bug report relevant? It's my understanding from reading the thread that there is no special agreement between Mozilla and Debian but that Mozilla recognizes that what Debian is doing doesn't violate their trademark rules. Anyone else is free to do something similar to Debian.
I assume this is why Debian feels confident enough to patch and distribute Rust in the way they do?
Some of the Debian maintainers are Mozilla engineers, so I assume that's where the trust comes from.
I wonder if there is a way to express automatic allowance for every "Rust" where they explain the differences from Mozilla's Rust.
impl Allow for R where R: DifferenceExplained {}
Thanks for bringing this up.
Some thoughts:
I'm generally inclined to revisit and simplify the trademark policy. The original policy was adopted fairly hastily with relatively little input, and was mostly trying to CYA while following Python's lead.
I think the current policy is too complex while also being imprecise and handwavy. It requires reading the Mozilla trademark policy, and then interpreting it along with Rust's own policy, then guessing whether your usage is ok with whoever at Mozilla is responsible today, which it almost certainly is.
I think Rust should not piggy-back on Mozilla's trademark policy, which serves Mozilla's particular purposes, but should have its own that is limited to exactly what a Rust trademark policy should accomplish.
This seems to be one of the most relevantly controversial clauses:
Distributing a modified version of the Rust programming language or the Cargo package manager and calling it Rust or Cargo requires explicit, written permission from the Rust core team.
I disagree with this. I can imagine this exists to try to protect the integrity of the Rust brand by ensuring compatibility with upstream Rust; but I don't think it's worth the uncertainty that it causes.
Rust should rely on technical and social excellence to protect its image, not trademark.
Distributing an incompatible Rust can be done either accidentally or on purpose. Mostly it will be done accidentally, and the trademark policy is not the tool to combat this - somebody will point out the problem and it will get fixed.
Intentionally-, or maliciously-incompatible Rust toolchains are also ok, and probably good.
Everybody should feel entitled to write or distribute Rust compiler toolchains that use the same names as the rust tools, without getting permission. Even maliciously-incompatible toolchains are not something that the Rust team should be so fearful of that they reserve the right to legal action - if somebody creates a different Rust that gets actual adoption, then the Rust project should be forced to face the competition, and either adapt or lose control of the language. Competition is healthy.
I might prefer that Rust not maintain any trademarks at all. If not that, then protect the logo only. Or come up with an "official brand name" (e.g. "Rust Official"). Protecting the language name I suspect mostly leads to this kind of confusion without solving real problems. I'm inclined to think the cargo name and logo should not be trademarked.
I'd be interested to know if Mozilla has used the threat of legal action to resolve a Rust trademark dispute, whether they were over the name or the logo, rust or cargo.
This sounds to me like the exact opposite of what I want as a user. More specifically, Rust provides stability guaranties that are vital to many users. Those users rely on the stable interfaces of the various tools and of the language specification (as much as it was specified thus far).
Yes, competition is healthy and should be allowed, but a requirement to be open about it is just fair and allows the users clarity with regards to what exactly they are using. The user (especially in the case of a programming language) is fully able to judge and compare alternative implementations and alternative languages by their merits. On the other hand, allowing forks to masquerade as the original is a known evil corporate strategy (called EEE) to stifle competition and very much anti free software.
as a side note, People keep conflating "Rust the language" and "rustc the compiler" in these kinds of discussions, even prominent rust community members. I'd be very concerned to read that the Debian project has forked "Rust" (the language?!) for example. however, I'll be totally fine if they forked the compiler or its packaging. This is in the same vain of clarity of intent and of communication with the users.
The trademark debate should be very clear about this point - The trademark should protect "Rust the language" in order to make the compiler really free software.
Last point, regarding the complaint about Cargo's integration with rustc invocations - I'll look at what there is in C++ land as a good starting point, i.e. we should be able to support different compiler implementations & vendors of the language and as a user I should be able to specify which implementation I prefer to use by e.g. setting a common environment variable. This is a worthwhile enhancement to have instead of having different forks having the same name.
I do think that this policy needs reconsideration. Even if the trademark restrictions are kept, it's not really sensical for the name of the programming language to be covered instead of the name of the implementation. Perhaps the Rust reference implementation could be given a name instead of just being “Rust” while other implementations would still be free to call themselves “Rust compilers”.
One of the reasons that I think this is clause is controversial is that it appears at least one organization is distributing a patched rust (Debian, though probably other linux distributions are doing this too) seemingly without the required written permission.
Developers like clear and easy to follow rules or heuristics. This inconsistency (rust policy claims to require written permissions, but is seemingly OK if you don't get it) can be confusing and uncomfortable.
It's a tough problem 
I believe trademarks are a good thing. If Mozilla wants Rust to be seen as fast, reliable and stable, and someone ships a fork of Rust that is slow, buggy and incompatible, it shouldn't be allowed to be called "Rust", as that would tarnish Rust's reputation and cause fragmentation/confusion.
Unfortunately, the problem hangs on definition of what is Rust, and how much modification is too much. If Rust had a formal spec and some certification process, that could be used to define what can be called Rust and what can't.
In the Firefox codebase the name of the project is a configuration variable, so it's easy to rename it. If Rust had similarly good support for renaming, then Hyperbola could solve the problem by shipping untrademarked "hustc" and "hargo".
The trademark law allows use of trademarked names to refer to products, so it's fine to say "Hust — a fork of Rust", so that users of Hyperbola OS can still find it.
On the first day of Christmas, my language gave to me
A thought to make the software more free!
I don't think this makes sense in the long term. For widely successful programming languages with multiple implementations, this isn't considered an issue. Does GCC worry that Clang calling the language that it compiles C will tarnish GCC's reputation? I get that Rust is still young, but in the long run this is something that needs to be sorted out for there to be a thriving ecosystem with multiple implementations.
What about a rule that says "you can use the Rust name with modified code, but you must mention prominently that the code has been modified from the official Rust"
Have you never heard of the ISO standards committee?
The C and C++ languages are defined by international standards committees which defines what these languages are. There are some vendor specific extensions but when I compile my C++ code with a specific version set (e.g. standard C++ 2014) via a compiler flag I must get a compatible result no matter which compiler vendor I use (sans compiler bugs and unclear edge cases in the spec). This ISO standard is what gives me the guaranty as a user of the language stability and compatibility. The design of Rust editions is inspired by this.
There are generally two mechanisms to ensure compatibility and stability and all successful languages are protected by one of them. Either a standardization process, or trademarks, which as @kornel said, are a good thing.
For Rust to be truly successful it needs to be the best choice in the industry. That's where the effort should be. Not catering to some hackers of a niche BSD fork that practice hyperbole and spread FUD.
Moderator note: Please tone down the insults/attacks. Thanks.
(Edit: Although I recognize that "hyperbole" is literally in their name, so that much is fair game, I guess?)
That would help, but ideally users would have at least an option to install as rustc and cargo, since scripts, Makefiles, etc. exist that expect those names.
In theory we could expect scripts to use $RUSTC and $CARGO, just as scripts invoking the C compiler are supposed to use $CC, but that doesn't actually get rid of the trademark. Also, experience from C is that many people don't bother and just hardcode gcc instead – which is why, on macOS, gcc invokes Clang...
The language team should not be forced into adding extensions or specify behavior we do not want to because some alternate compiler sought to go around the RFC process and get their way that way. In particular, this is important so that no company with the financial means can take over language to suit their needs.
This is ideology, not an axiom.
There are certainly situations where competition is unhelpful and where a monopoly would be better. In situations where some competition might be helpful, oversight and regulation is usually necessary.
(In this analogy, alternate compilers are regulated by a common spec as decided by the language team.)
The language team is the equivalent body for Rust, defining what the language is.
The way I see it, the current policy works around the fact that there is no ISO Rust standard. I mean, anyone can support their own variant of C, but they wouldn't be able to call it ISO C, so "ISO C" can be used to avoid confusion. Since there is no ISO Rust, the Rust name itself is protected to avoid confusion. And similar to the way ISO C can be changed through ISO procedures, Rust can be changed through the Rust language team procedures.
In summary, I would be fine with no trademark if there was for example ISO Rust, which would be protected as an ISO standard, but I'm not keen on losing the trademark protection without some other kind of protection.
I think it's most important to have a specification (ideally in a formal, meaning mathematical, way). I prefer our way of doing things and I'm not keen on ISO or ECMA as standards bodies because of the politics (national bodies, leading to a lot of compromise changes, e.g. as in C++) or the influence of money (and the potential for corruption).
I agree with the conclusion of not losing the trademark protection, 