“Rust’s freedom flaws”

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.

8 Likes

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.

1 Like

It's a tough problem :frowning:

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.

1 Like

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.

4 Likes

On the first day of Christmas, my language gave to me

A thought to make the software more free!

3 Likes

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.

8 Likes

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.

1 Like

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?)

5 Likes

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

3 Likes

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.

11 Likes

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.

3 Likes

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, :+1:

10 Likes

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?

1 Like

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.

6 Likes

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?

2 Likes

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.

1 Like

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?

10 Likes

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?

1 Like