Hacker News Reader

Comment by tspiteri | Hacker News Reader

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

…

View on HN

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.

Reply on news.ycombinator.com