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, 
At risk of derailing the thread on an analogy, the Systembolaget page doesn't seem to mention any purported advantages versus non-monopolistic sale of alcohol; do you happen to have another link or at least an elevator-pitch?
I think there's a big difference between not being able to claim that your C compiler is standards-compliant and not being able to call your Rust compiler a Rust compiler at all without someone's permission. The Rust team has already shown that they will be very lenient with the trademark and won't go around shutting down people's projects for no good reason, but a tendency is not a guarantee.
If someone created a compiler that could compile any existing Rust application, but, could also compile a superset of Rust, would they/should they be able to say they are a Rust compiler? What about if it uses only the subset that is "Rust" when invoked as "rustc" or with a "--rustc-compatibility" flag, but, if called as say, "uberrustc" (without the compatiblity flag) it would allow for extended syntax and/or semantics? Should they be able to say, "We are a "Rust" compiler"?
Personally, I would think "YES"; however, they should not be able to say, "We are the Rust compiler," or, "We are Mozilla Rust", or, "We are "Rust"". A packager/installer should allow the user to install such a package with soft or hard-links from "rustc" -> "uberrustc" and from "cargo" -> "ubercargo" and permit the user to use it "AS IF" if were Rust. No?
Not offering that choice could be a good thing IMO. Sometimes redistributors change the software sufficiently to break expectations, and when it happens upstream usually takes the blame. Debian for example repackage Python with built-in libraries debundled into separate packages (e.g. python-venv), crashing build scripts expecting that. Most users would proceed to report this to CPython, who can do nothing about it. Forcing a rename would be a way to make the situation and responsibilities absolutely clear.
One thing that I find odd about the trademark situation: the Rust teams have rightly been proud to grow the governance and community around the project well beyond Mozilla, who still owns the trademark. Seems like that portion of this discussion may be in-scope for the governance WG's eventual goals?
Ideally, there should be a process such that if a compiler adheres to Rust's language definition it should be granted permission to use the "Rust" name, see Java for example of such a process. If Rust is indeed open-source and the Rust core team is already lenient, there shouldn't be a problem granting such permission to compatible compilers, I would think.
I also see no problem with having one compiler supporting multiple languages, GCC is already such a compiler collection. I would want the "Rust superset" to be named differently - call it UberRust or Rust++ or whatever, but it is not Rust.
In so much as providing symlinks and such, this should at most allowed when using the official Rust spec. i.e
rustc -> uberrust --mozRust # This ought to be Ok.
RUST="uberust --mozRust" $RUST my_file.rs # This is my preferable option
rustc -> uberrust # Definitely violates T&Cs as not rust per spec
In any case, these are all implementation details. The real question is that of policy: What does the name "Rust" represent, Mozilla's reference compiler implementation or the language itself? As a user I would like to see the latter - "Rust" is the language, and not a specific implementation. At least some people of the Rust leadership seem to agree.
Last Edit: I agree that this should be adressed as part of the project's governance, rather sooner than later as this is already an issue. There are already additional implementations of Rust - is mrustc a Rust compiler? What about the idea to develop a GCC alternative that have been floating around this year?
Enforcing compliance. From that page:
The minimum age to purchase beverages above 3.5% alcohol is 20 years of age. A main reason to have Systembolaget as a monopoly is to enforce this age limit. Several tests have shown that food shops often sell 3.5% beer to people below the minimum legal age of 18.
(In this case, also that profits go to the state.)
This would work the same as cc->gcc and sh -> bash etc. The actual binary checks the name it was invoked as, and for example, with bash if is was invoked as sh it behaves in a manner compliant with sh and all bash extensions are disabled. I could imagine the hypothetical uberrustc working in the same fashion.
It is true that C++ and bash allow this. The downside is that it can obfuscate the difference. While skimming through a makefile it should be easy to spot those few places where we compile a C file in a C++ project, for instance. Source files should be clearly designated as either C or C++. I know at least one C++ project with files ending with .c extension confusing the casual reader as well as any modern tooling (e.g. IDEs).
Don't even get me started on bash - I have no idea where sh ends and bash extensions begin. Given that the script can specify a shebang but have a misleading file extension, I reckon it is possible to cause confusion and breakage. I could for instance provide a bash script to a support person to run in a limited environment that has only sh and they'll be confused as to why the command to run: sh script.sh failed. Perhaps the developer (me) wasn't aware the environment is that restricted? Perhaps the support person only knows to copy/paste the script and command and doesn't understand shell scripting? This would be immediately obvious had the file was named script.bash and/or the command to run it was bash script.bash. it may sound a construed scenario and one which quickly we can learn to avoid. However, IMO these are all misleading and bad practices which go against Rust's goals of prefering explicit over implicit and verified safety over unchecked conventions.
And Rust should do better. It should be explicit and clear to the user at all interface points if compilation is rust compatible or not and whether the source code is strictly rust or not.
Perhaps. But in a distribution like Debian, almost every major package has at least some patches. From a moral rather than legal perspective: Should Debian rename every binary on the system? Or is Rust special?
I suppose someone could argue that Debian shouldn't be patching so many packages in the first place. Debian and its derivatives do tend to be on the patch-happy side compared to other distros. But I just checked the first two other distros that came to mind, Fedora and Gentoo, looking for the patches they apply to rustc. For the latest version of Rust, Fedora has 3 patches and Gentoo has 1: both far fewer than Debian's 20 patches, but not zero. It seems like it's more or less a technical necessity for distros to do at least some amount of patching – with rustc, and with packages in general.
The problems that Rust seeks to avert with the trademark policy are not hypothetical, and they are not uncommon. You've already been told about Python. The XScreenSaver upstream has complained about outdated distributed versions, we've all heard about the Debian OpenSSL bug, and in case you think I'm just complaining about Linux, I've also heard about “hopelessly outdated” software in macOS.
Rust is not special, except not wanting to go through the same stream of fail that other upstreams deal with. It is not technically necessary, and it's not okay.
I think I’m missing some critical background knowledge here, so time to ask the stupid question:
How does a trademark policy do anything to protect against Debian or some other distro from mis-patching Rust in a way that creates serious bugs? And since this kind of distro-specific patching is apparently already going on with rustc, are we actually getting any of that protection in practice?
Since the name Rust is trademarked, you can't distribute something and call it "Rust" without permission from the trademark holder. What counts as calling it Rust is not entirely clear and would be up to a court, but may include things like:
rustrustc(The name Cargo is also trademarked; in addition, there are separate trademarks for the Rust and Cargo logos.)
Mozilla's trademark policy provides the necessary permission, but only when distributing unmodified copies of software. (This is the same policy that caused Debian to ship Firefox renamed to "Iceweasel", until Mozilla gave Debian explicit permission to distribute patched versions.)
This is all separate from copyright, which covers the code itself; the code is distributed under the MIT and Apache 2.0 copyright licenses, but those don't grant trademark permission. (Probably.)
We are not.
According to the thread I linked above, I don't think this is quite true. Debian devs seemed very keen to emphasise that there wasn't a special or exceptional agreement with Mozilla. They were convinced that the Mozilla trademark terms allowed for anyone patching in the way that Debian does and Mozilla were convinced that Debian's patching didn't break the terms. So there wasn't (to my reading) explicit permission, merely an agreed understanding of what the terms mean.
That's really thin ice upon which to tread. What happens if Mozilla decides to sell all assets to a "For-Profit" at some point (Yes, that CAN happen)? Let's say, I don't know, Oracle for example? Then what?
Well, from that thread:
This was sent by sylvestre@mozilla.com, and I interpret it as an explicit permission grant on Mozilla's behalf. It covers both Debian and its derivatives, which I think is why it was enough to satisfy them.
I also think that it'd be wrong to "force" a spec now, only to prevent some possible breakage with some Groups (Hyperbola).
As far as I understood the last posts about a rust spec, we're still far away from making this happen. And I wouldn't want to rush this, even though the current state may not be perfect. Of course: as long as rustc is de-facto the "spec", we're always referring to rustc & rust as the same. Changing rustc changes rust, the language right now.
But the current state has worked pretty fine for now and I'm not sure if we're able to just throw out a spec for the sake of narrowing down the rust language trademark requirements.
It is a grey area. For example, when distros unbundle Rust-patched LLVM, they can end up with a Rust version that produces slower or even buggy executables.
Even more subtly, it's possible to cause problems without patching anything. Debian's annual release schedule (and even longer uptake of Debian versions) is at odds with Rust+rustup regular 6-week updates. It causes a real problem where the "Debian Rust" is almost incompatible with the ecosystem of crates written for "Mozilla Rust".
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.