“Rust’s freedom flaws”

https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws

Hyperbola is an OS project aiming for maximum freedom in the ‘free software’ sense. They’ve apparently been around for two years, although I’ve only just heard of them, from their recent announcement of a pivot to “HyperbolaBSD”,

a hard fork of the OpenBSD kernel and userspace including new code written under GPLv3 and LGPLv3 to replace GPL-incompatible parts and non-free ones.

More relevantly, the announcement says they want to avoid Rust code because Rust is insufficiently free. This is apparently because:

Rust and also Cargo (the Rust package manager) violate the freedom to redistribute without “explicit” approval. Their trademark license imposes requirements for the distribution of modified versions that make it inconvenient to exercise freedom 3 .

That ultimately links to this issue:

where the OP asked:

Debian and some other distributions are applying patches against the Rust language and Cargo package. I assume this qualifies as something which requires explicit approval?

and @nikomatsakis apparently responded:

You are correct that we intended the trademark to apply when distributing a package or other binary called "Rust" -- and in particular that if modifications are made, then we would expect a trademark request outlining the sorts of changes being made (as the policy notes though, we are inclined to accept such a request).

The Hyperbola wiki page mentions that one possible solution is:

Rebranding the entire language to avoid the trademark restriction. Such as IceCat was made to replace Firefox and Iceweasel-UXP to replace Basilisk; however it is a programming language, not a browser. A rebranded version of Rust maintained by the GNU Project and FSDG-compliant distros could be the way. However, we would need patches to adapt all Rust-dependant applications to the modified version of Rust, since it is a programming language.

I think they have a point.

To be fair, Hyperbola seems to like to engage in, well… hyperbole. I certainly wouldn’t call Rust non-free.

But the Mozilla Trademark Guidelines are pretty strictly worded:

Taken literally, this suggests that every GitHub fork of rust-lang/rust which doesn't change the repo name might violate the policy. Presumably it wouldn't actually be enforced that way.

But it does concur with Niko's assessment that distros would require permission to patch rustc – as they often do to many packages, for various reasons, including dealing with distro-specific quirks. For example, Debian's rustc package currently has dozens of patches. From a technical perspective, the existence of these patches is clearly suboptimal, as they don't benefit anyone who uses official Rust builds, or other distros that package Rust. It would be better to get them upstream, and I'm actually surprised there are so many. But having some patches may be a necessary evil, given differing release cycles and priorities. Compare to how the Rust project ships a patched version of LLVM, despite aiming to get those patches upstreamed eventually.

In any case, even if there were zero valid technical merit to patching rustc, it should still be one's right as a consumer of free software.

And there are other problems.

First... I guess Debian has probably received permission to patch rustc. But are the terms of the license public (or in writing at all)? What is its scope? Presumably nobody here is approving every patch, but are there limits to what kinds of changes they're allowed to make? And does the permission only apply to the Debian project itself? If I make my own Debian fork, and ship the same Rust patches as Debian, do I need separate permission?

Second, let's say I decide to make a true fork of Rust. Not a development branch meant to be submitted upstream, not an experiment, but a fork, which I distribute to others but have no intent to upstream. To be clear, I don't actually want to do this. :slight_smile: Forking Rust would be rude to the community, since it would fragment the Rust ecosystem. But it's something anyone should be allowed to do with free software.

In such a case, it's reasonable to expect me to pick a new name for the fork, and not advertise it as "Rust". But how far does that go?

The Mozilla Trademark Guidelines say that the original name can't be used "in connection with the user-facing name or branding of your project". For something like Firefox, a GUI application that you don't need much technical knowledge to use, it's easy to make a distinction between users and developers. With Rust, it's harder. Do I have to rename all the binaries? After all, as a typical Rust user, I manually type rustup to download a toolchain, and cargo to start a build ("Cargo" is also trademarked). If I run it in verbose mode I see invocations of rustc, which I can also run manually. So it seems that all three binary names are "user-facing".

From a technical perspective, though, a fork may or may not want to change binary names. On one hand, changing them would make it easier to install MyCoolFork alongside normal Rust. But if the fork is mostly compatible with normal Rust, then using the original names would preserve compatibility with existing tooling and scripts that invoke those binaries, which is more important. The forker shouldn't be forced to make their software gratuitously incompatible to avoid infringing a trademark.

Compare to what GNU has to say about an (unrelated) license that enforces similar requirements at the copyright level:

IPA Font License (#IPAFONT)

This is a copyleft free software license, incompatible with the GPL. It has an unfortunate condition requiring that derivative works not use or include the name of the original work as a program name, font name or file name. This is acceptable for fonts as fonts can be aliased or renamed using free software tools, but it's very annoying and could be overly burdensome in other contexts.

Also, I believe that the build systems of rustc, Cargo, etc. don't currently have an option to build an "unbranded" copy, like e.g. Firefox does. The forker would have to construct that themselves, which seems rather burdensome.

Summing up

If a distro patches Rust (more desirable) or someone forks it (less desirable), they have to either get permission from Mozilla, or make some potentially invasive changes to the codebase. In practice, it's not hard to get permission (at least for patches), and the trademarks are unlikely to be vigorously enforced. But one should not need permission to modify free software, and it's hardly unreasonable to aim to be on a firm legal footing.

Again, I wouldn't call Rust non-free as a result of this. There is precedent for free software projects using trademarks to require modified versions to undergo name changes – most notably including Mozilla's other projects.

But I would say such policies at least push the boundary of what can be considered free or open source software. And Mozilla's policy is more burdensome for Rust than for its other projects, since changing the name requires more invasive changes and compatibility breaks, and there is no built-in technical mechanism for it. In addition, Rust is aimed toward a more technical audience that's less likely to be confused about the authenticity of a patched or forked version. Oh, and... since Rust is more of a community project than a Mozilla project, it's a bit strange that Mozilla holds the keys, though understandable.

I think the policy should change in two ways:

  • Projects that distribute copies of rustc/Cargo/etc. with minor patches including Linux distros and potentially others, should be allowed to use the name "Rust" and "Cargo", as long as it's clear to the user that the code is patched.
  • Any project – including forks and even Rust implementations written from scratch – should be allowed to use the binary names rustc, cargo, etc. for technical compatibility reasons, again as long as it's clear to the user what's going on.

(Actually, the latter might be considered fair use in some jurisdictions, in which case it would be allowed regardless of what the trademark holder thinks. But Rust users certainly shouldn't have to deal with untested and jusridiction-dependent legal questions.)

Thoughts?

25 Likes

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?

1 Like

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.

7 Likes

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.

32 Likes

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.

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

7 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