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