Rust's Freedom Flaws | Hacker News Reader

Rust's Freedom Flaws

wiki.hyperbola.info

66 pointsbased266 comments

The restrictions are so reasonable that even the GPL would allow supplementing similar terms (if I understand it correctly):

https://www.gnu.org/licenses/gpl-3.0.en.html#section7

Quoting the relevant bit:

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:

…

c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or

…

e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or

…

This is not the same as the Rust restrictions:

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

So, either you distribute something you can't call Rust; or you need explicit permission. It is not good enough that you mark is as modified.

There is an explicit controlling motivation here:

> The Rust and Cargo names and brands make it possible to say what is officially part of the Rust community, and what isn’t. So we’re careful about where we allow them to appear.

(From the Rust media guide.)

The GPL does also say "e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks" as the parent noted. This is basically that, you can't distribute a modified rust and call it rust, just like you can distribute a modified Chrome and call it Chrome. I don't see the issue here.

But Chrome is a branding of a basic, branding-less, project - Chromium. With Rust, I'm guessing the nae "Rust" is used all over the place. "Some trade names and marks" is not "basically the entire work".

I don't get how you get to the point of seeing the rust trademark as "the entire work". If you modified rustc and called it "FeO, a compiler for rust", you'd be fine. Just don't call what isn't rust "rust" and it's OK.

Nothing in the FOSS ethos gives you a right to misrepresent a product, you get the right to modify software, not to say it's something it isn't.

Let's consider two cases:

1. I forked rust, made a bunch of changes that are not compatible with upstream and setup rust.engineering (which is free right now) to say my fork is the rust then the rust devs should be able to tell me to not use their name for my product.

2. I forked rust, made a bunch of changes that are not compatible with upstream and setup feo.engineering (which is free right now) to point to my fork and say "feo is a rust-derived language" then that should be fine.

My reading of the license allows for the second use case, but not the first, which I feel is the right way. What is the problem with not allowing people to misrepresent the source of the code?

In practice forks change the name anyway. Trademarks don't exist simply because they're intellectual property; the market is quite confused by differences.

For example, ImageMagick and GraphicsMagick, or FFmpeg and Libav. When these things use the same name, but they diverge, it just means hassle for everyone downstream. So a different name makes sense.

Debian makes slight modifications all the time to packages. It patches bugs and removes non-free components, for example. These count as "modifications" but they're usually trivial enough that people don't consider them "forks".

In the past, Mozilla's defense of similar trademark guidelines for Firefox resulted in a weird revoking of the "Firefox" trademark for Debian, so Debian rebranded Firefox to "Iceweasel" for a while. But then, what I think happened (I'm guessing here) is that the browser got so big and complicated that Debian ran out of geekpower to patch it, so just redistributed whatever Mozilla did verbatim. Mozilla then re-granted Debian the right to use the Firefox trademark.

If Debian starts distributing Rust with bugfixes, I wonder if Mozilla is going to tell them again to change the name.

I'd prefer if Debian-packaged stuff came with fewer modifications to stock where possible; I think they're a little bit too eager to poke at things.

I'm thinking of some auto-maintenance stuff for MySQL, and a Debian change to atop which made it log to /var/run (an in-memory file system) - see https://bugs.launchpad.net/ubuntu/+source/atop/+bug/1393175 .

I like Debian's changes. I don't like it when some software thinks it should be putting runtime data in /etc or configuration in /var. Or when an executable doesn't have a manpage, not even a brief one. Debian has a Policy that describes how packages should behave, and I appreciate the consistency it enforces.

The atop changes are a showstopper, they caused an outage.

No need to guess about Firefox/Debian, the bug report is preserved here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006

As noted by steveklabnik, Debian already does ship Rust with their own patches without issue.

I don't find that very descriptive. I still don't understand why Mozilla changed its mind about how much the Debian patches changed. I think it's just about changing of the guard at Mozilla or something.

I guess we'll have to hope someone at Mozilla doesn't get picky again and decide to enforce their trademark policy, which I think says Debian is in violation of, but being tolerated.

The main license problem that Debian had was the _license of the logo_. This flaw is remedied. (and Rust hasn't made that mistake)

There was no change of guard, just a very long discussion on how you can make some of the stars align: Mozillas interest that things shipped as "Firefox" are something they can vouch for and Debians interest to use them as free software.

If the problem was the logo, why change the name?

Debian felt they couldn't ship the logo because of its licensing restrictions.

Mozilla felt changing the logo fell outside their trademark guidelines to still call it Firefox.

One of the control motivations here is that rustc and cargo have _explicit_ interface stability guarantees.

Imagine a vendor shipping rustc and cargo + 20 subcommands that are not behind the -Z flag. People may start relying on them and be annoyed of the Rust project if that happens. For that reason, you need explicit permission here, because we want to discuss with you how to phrase the messaging to avoid these situations.

This is a bit hyperbolic but there is an underlying issue here. The Rust project wants to keep control of the Rust name. They're more than happy for, e.g. Debian to fork it for inclusion into their repositories or for other forks to exist.

However, if a company creates a hard fork of Rust but still insists on calling it Rust, they want the ability to say "don't use our name".

The problem is, what's the best license to express that intent? Reusing the Firefox one makes sense in some ways (it's been well studied) but perhaps Rust would benefit from a custom license?

IMNAL but...

Rust the name is a trademark and the software licenses deal with copyright. Someone can hard fork under a different name and the copyright carries but the trademark wouldn't. Plus, this isn't an EULA where more info is conveyed.

Not sure there is a clean way to fit multiple separate things into a copyright policy and maybe IP grant. Trademark law works a little different, right?

This was my understanding on how these things worked as well. But again, not a lawyer.

In Kubernetes-land, the code is all standard Apache 2 but the trademark is governed by a custom set of policies the community decided on.

For example, companies must pass the conformance program before they can use the name in marketing.

Wouldn't the zlib licence fit here?

> 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.

Possibly calling both the compiler implementation and the language Rust is the issue here.

The compiler implementation is rustc.

There's a reasonably complete alternative (it compiles most code but doesn't enforce borrow checker rules so is more permissive than rustc) called mrustc.

The project and language are called Rust. The compiler is rustc. You could make an alternative compiler under a different name than rust or rustc with this trademark restriction.

Cpython and Python are similar here.

> You could make an alternative compiler under a different name than rust or rustc with this trademark restriction

But would you be allowed to call it a Rust compiler, even if it compiled a slightly modified version of the Rust language ?

There are many C/C++ compilers, often they have some compiler-specific extensions, but they still call themselves C/C++ compilers. Would a similar situation be possible for Rust with the current license?

IANAL, but precedent says you can use "for Rust" in your description without issue. Though the Rust trademark could still be used to request a removal of association if you were doing something untoward in the eyes of the rust project.

So it's not necessarily an unchecked freedom but it's also not limiting in most cases either.

> But would you be allowed to call it a Rust compiler, even if it compiled a slightly modified version of the Rust language ?

AFAIK Rust is not specified by a fixed standard. Thus, it would be hard if not practically impossible to comply with a definition of what Rust is if none was ever done.

Why not? I think that wouldn't infringe trademark. IANAL

The domain name is quite adequate, this is hyperbola indeed. Since when do the 4 freedoms include the right to fork under the same name? This is a rude thing to do anyway (hostile, even).

It is not about having the right to fork under the same name only, but also having the ability to apply small patches to the code without going to the great lengths of rebranding everything---of course we can discuss if changing a single bit from the source code would qualify the result as a fork or not.

Right, and I guess this is in particular a problem that Linux/BSD distributions face, where they want to apply small patches for interoperability and the like, but still want to offer it to their users as "Rust".

That’s not explicitly allowed but de facto allowed. I don’t know how else it could be done. Unless there is a definition for what is a minor change (sounds nearly impossible), the choice is to either disallow it and not enforce it (current way) or allow things that aren’t rust to be marketed as rust (worse).

Ah, thanks for the precision. How do distributions typically handle that? And why does GNU feel the need to patch rustc, is it for things that can't be upstreamed?

Somebody with better knowledge of that will hopefully chime in. My impression is that most of the distributions either don't patch upstream besides the build recipes, and upstream maintainers turn a blind eye to that. The ones that do, though (e.g. Debian), take the approach described on the OP and rebrand it (e.g. https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_... ).

I’m not aware of any distro that rebrands Rust.

You can see Debian's patches to rustc here: https://sources.debian.org/patches/rustc/1.34.2+dfsg1-1/

I feel like the expression "turn a blind eye" is overstating things a bit. My understanding is that Mozilla can permit whatever they please with their trademarks. There's no expectation that they should be particularly strict. (Unlike, say, law enforcement, where there is an expectation that they should be strict, and turning a blind eye is a gray area.) Maybe I'm splitting hairs here though.

Hey folks!

So, yes, the intention of this policy is basically to prevent people from confusion around forking the language itself. It would be very bad if, for example, a distro would strip out the borrow checker and still called the language “Rust.”

Distributions do make some patches to Rust, and still call it Rust. The team is fine with this. Nobody has explicitly asked to do so either. The only trademark inquiries we get are around things like “can I sell this tshirt”, honestly.

Now, there is one thing of interest here. Mozilla does own these trademarks. I often comment here about how Mozilla does not run Rust governance, and that’s true, but this is the one single way in which they do have some leverage. However, I can’t imagine a world in which they do something against the will of the team. When discussing the idea for a foundation, a place for these trademarks is often one of the largest pros of doing such a thing.

I will note that a lot of people have brought up Iceweasel; this issue resolved itself long ago and distros like Debian ship Firefox now.

Is it very bad that https://github.com/thepowersgang/mrustc calls itself a Rust compiler?

From the Rust Media guide, under "Uses that do not require explicit approval":

* Stating accurately that software is written in the Rust programming language, that it is compatible with the Rust programming language, or that it contains the Rust programming language, is allowed. In those cases, you may use the Rust trademarks to indicate this, without prior approval. This is true both for non-commercial and commercial uses.

I would call a compiler that compiles Rust, but does not name itself "rustc" falling under that explicit approval.

(Full disclosure: I'm part of the Rust community and core team and often handle trademark decisions)

No, because it is very clear that it's not an actual Rust compiler yet, and so is extremely unlikely to generate said confusion.

Having total freedom like the author appears to want would be a big negative in my book. Why would we want a bunch of different variations of Rust that have different capabilities and may not compile the same "Rust" source code? If you want to make changes to the underlying language you can either work through the accepted Mozilla path to language acceptance or create your own language based off of it with different name. I'm not quite sure what the author is hoping to gain.

One use case would be for example a patch set to provide compatibility for architectures not supported by upstream. It can take years of heavy usage to get changes like that merged. For example Xtensa LLVM is still out of tree and Rust support would be for a long time as well.

Rust provides the ability to use your own LLVM already in-tree, no need to patch.

I do not think Rust will “just work” on a completely new architecture without any changes. Xtensa is not a hypothetical example - there is a fork of Rust to support it: https://github.com/MabezDev/rust-xtensa

Yes, this is a good point, sometimes you need frontend changes too.

I'm not sure why python is called out as being better here. The PSF came calling for a rename pretty quickly when tauthon (https://github.com/naftaliharris/tauthon) was launched as it was initially describing itself as python 2.8

From the article:

> They do prohibit abuse of their trademarks, e.g. you cannot create a company called “Python”, but this does not effect your ability to modify their free software and/or apply patches.

I’m not seeing the difference to Mozilla here.

Python's license allows patched redistribution without explicit permition. Rust's doesn't.

And yet when one tried to do it the PSF did not grant the right to the trademark and the operiert had to change the name.

Many other open source projects have registered their trademarks. Even unregistered trademarks are protected in the US and elsewhere, and one of the specific things trademark law lets you do is prevent people from misrepresenting the origin of a product bearing that name. So unless the license or the trademark owner (like the Linux Mark Institute) explicitly grants you the right to use the trademark you have no guaranteed right to use it. So rust is really no different from the vast majority of open source projects.

https://news.ycombinator.com/item?id=21867639

Exactly this issue of "you're free to make changes but please don't use the same name" keeps cropping up again and again -- take a look at the case of TeX/LaTeX: https://www.latex-project.org/publications/2011-FMi-TUB-tb10... ("Reflections on the history of the LaTeX Project Public License (LPPL)", by Frank Mittelbach, leading the LaTeX project since 1989.)

I think it is reasonable for certain kinds of software to have an expectation that users get the same results anywhere they use software by that name, and (therefore) that incompatible changes will not be distributed under the same name. Whether (1) that applies to Rust, and (2) that makes it non-free software, is the question here.

This... seems reasonable? If you want to modify and distribute Rust/Cargo then you have to call your distribution something else. Call it Oxide/Freight and you’re set.

I agree, but still think it might be considered reasonable not to want to rebrand in some cases—like patching Cargo to try and check with the package manager first when installing packages. It obviously won’t (and shouldn’t) get accepted mainstream, but it doesn’t also seem confusing enough to warrant a necessarily different name.

So you would make a thing called "Cargo" that was almost the same as Cargo except for some custom patches? That sounds pretty confusing to me.

This is the bread-and-butter of what Linux distributions do. A large number of larger software are slightly altered in order to integrate this or fix that, but they are close enough to the original that there's little confusion in practice that e.g. Debian's Mesa is still Mesa, and Debian's kernel is still Linux, despite alterations.

Is it very different than the Linux kernel? There are thousands of custom versions, old versions, and strange architectures and they're all called "Linux" and it's worked fine so far. Some organizations even backport security fixes without changing the version number. As long as you're clear about what you're doing, why is this any more confusing?

For some definition of fine =P

The word “Linux” no longer has a singular meaning. And distributions have their own branding.

If someone wants to release DebianRust and DebianCargo that would be perfectly fine and non-confusing. A distribution could also make an agreement to use the Rust/Cargo trademark under some mutually agreeable terms. Likely having to do with no major changes and staying updated.

Most Linux distributions apply patches to software they distribute (e.g. for integration or security fixes). That is expected. If trademark forbids that, then it adds problems and confusion (like Firefox renamed to Iceweasel in Debian, until they reached some agreement with Mozilla Foundation).

> until they reached some agreement with Mozilla Foundation

Sounds like a fair and reasonable outcome?

It still does the same thing, but now in a non-general, distro-specific way. Hundreds of distributions customize their software like that: for example, I believe it is actually more common to find gnome-terminal with patched-in transparency than the vanilla one without it.

For ages prior to the LibreOffice fork, OpenOffice in Linux package managers was actually go-ooo

Is there an existing project that does allow for forks with the same trademark? (that is not in the public domain and similar licenses)

This is a follow-up to yesterday's thread: https://news.ycombinator.com/item?id=21867202

IMNAL. How about GNU asks Mozilla for a permission to call any modifications it makes "GNU Rust"?

That would just kick the can down the road, no? What should modified versions of "GNU Rust" call themselves?

IMO it's better that alternative distributions just don't call themselves rust unless they actually are the upstream rust.

Make your branch & call it Tsur Ekil.

Reply on news.ycombinator.com