Hacker News new | past | comments | ask | show | jobs | submit login
Debian Violating Rust Trademark (debian.org)
29 points by johnklos on July 17, 2022 | hide | past | favorite | 22 comments



Seems a justified policy for a compiler. If you are distributing a patched version of a compiler that is not from upstream you absolutely need to make users aware of that fact, so that they can decide whether they want to trust you or not. It is a security issue, because the effects of using a broken compiler can go beyond one machine.

Also, Rust needs some legal mechanism to shut down malware. Otherwise someone could throw up a build of "Rust" that does bad things to compile products and they would have no legal recourse to shut that down.


It's odd to try and enforce something like this through something as broad as a copyright clause on an open-source project. If it was restricted to commercial distributions of Rust a copyright restriction would make sense. Consumers could be confused into thinking it was officially connected to or endorsed by the Rust project which is really what copyright violations come down to legally.

Debian is open-source, open about the patches it applies and not in any way purporting it's the 'official' upstream Rust distribution or the patches are official upstream patches. I don't see how someone could make the argument the Debian project is somehow legally acting in bad faith with intent in a way that could either confuse consumers or cause financial damage and/or harm the Rust projects reputation.

To me claims like this just set a bad precedence in the open-source software ecosystem. The broadness of the clause has serious potential for abuse. It seems like a way to leverage the benefits of the open-source community while still protecting IP through copyright claims. That's how we ended up with the Oracle/Java debacle. Don't get me wrong I'm not saying the Rust project is just flat out evil like Oracle but the potential for abuse is there and definitely not in the spirit or intention of open-source software.


> Otherwise someone could throw up a build of "Rust" that does bad things to compile products and they would have no legal recourse to shut that down.

If someone is distributing malicious software, 1) I don’t think they care about whether anyone has legal recourse to stop them, partly because 2) they’ve already taken steps to become anonymous and resist takedowns.


A busted compiler is no more serious than a busted kernel, or busted shell. And yet so many shells can provide /bin/sh. Good thing or my shebang would have to be customized a million times for different people.



I know that distributions commonly do this, but what exactly are they changing?


My understanding is that it would just be reconfiguring the package to work with the package manager and to say that it came from debian official sources, etc.

I don't think anything other than a Mozilla distribution would comply?


Distributions are mostly patching software for (not specific for Rustc):

* Paths - distro don't need to keep path detection and can simplify it (ex: headers detections)

* Archs that upstream don't care about (ex: m86k).

* Kernel that upstream don't care about (kfreebsd)

* Some old CPU support. example: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de...

* simplification of the build system (ex: skipping windows support)

* Use libraries provided by the system (ex: compiler-rt for rustc: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de...). This could be forwarded upstream.

* Some minor doc changes - for example, https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de... will use the local css file and not a remote css file (for offline support)

* Cherry-pick upstream fixes before the next upstream release: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de...

* etc

As you can see, these patches do not impact the quality of Rustc itself. Some could be forwarded upstream (it is a pain for packagers to maintain patches - so, we do have strong incentives to contribute upstream).


> failure to do so is also extremely serious because Unlawful Distribution may still be considered grounds for financial compensation as well as a Legal Notice to Cease and Desist, and also to remove all public and private use of the Trademark from all Records. mailing lists, bugtracker, debian archives - everything.

Luke Kenneth Casson Leighton apparently knows nothing about how trademark law works.

Having something trademarked does not mean the owner of the trademark has absolute control over its use and force you remove any mention of said trademark. Trademark protects your mark from being used by others, commercially, to describe or name their products.

I cannot open a burger stand and call it McDonalds. I absolutely can have a "McDonalds Enthusiasts website", and there is fuck-all McDonalds can do about it in court, because my use of the trademark is descriptive. I can have a mailing list for fast food enthusiasts for said website, and we can discuss McFlurries and Big Macs and all manner of McDonalds products that are trademarked. I can sell a "Big Mac Storage Container."

And further: no, there's no grounds for financial compensation because Rust would have to prove damages, and good luck with that.

Further demonstration that Luke Kenneth Casson Leighton apparently knows nothing about how trademark law works:

> and no, the existence of the Copyright License does not invalidate or override the Legal requirement to also comply with Trademark Law. it is astonishing the number of FOSS developers who genuinely believe that they can blatantly disregard Trademark Law "Because Open Source"

>> For instance, here is an excerpt without context from Debian's policy: >> "You cannot use Debian trademarks in a company or organization name or >> as the name of a product or service."

>this is standard fare as part of Trademark Law. it causes "confusion".

Debian can say that all it likes, and corporations do often try to give people the impression that they have less rights than granted to them under fair use doctrines.

I can still open and operate a company called KennyBlanken's Debian Consultancy Shop and there is fuck all the Debian project can do about it, because it is descriptive.


Trademark law is set up so that people do get a Mcdonalds burger when it says Mcdonalds on the package. Similarly, people expect to get the Rust compiler when the "rustc" package says "Rust systems programming language". The name is not used in a descriptive sense. The package promises to deliver the goods, but they are (slightly) modified goods.

I'm optimistic that a solution will be found. But brushing this aside with "it's descriptive" is not helpful.


So Rust gets thrown out of Debian & derivatives, not a big deal. But soon the Linux kernel will depend on a non-free compiler? Huge.


Rust isn't any less "free" than Debian. If you forked Debian, you also would need to change the name, due to the trademark.


Is there anything from the FSF or some other authoritative or reliable source that says rustc is actually non-free because of this?


rust is still free.

just debian prefers to ship a stripped variant and calls it rust and cargo, which violates the rust trademark. debian can call it debrust, and the kernel can choose to support this and the official rustc.


It sounds like this controversy could be solved if Mozilla registered Rust as a certification mark and reserved trademark use for their own Rust stickers, shirts, and other swag.


Note that the issue has been resolved.

The Rust foundation has added explicit provisions for porting, path fixes, and applying upstreamed patches.


rust and cargo are a command line interface. That is, a terminal api that will be used in countless scripts. Google vs Oracle [0] was a fight over whether an api could be copyrighted. Maybe, maybe not, but re-implementing it could be considered fair use according to the supreme court. Now, apparently some want to test whether it can instead be trademarked. I think that's very unfortunate. The freedom to make drop-in-replacements is worth defending.

This goes way beyond the Iceweasel situation.

[0] https://bit.ly/3RH3zdn (Link goes to, https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_.... but HN strips the trailing dot).


Or just ship two version, call one oxidationweasel or whatever, add your patches, continue using it for important stuff, and ship normal rust as rust, for people who are into that.


Shouldn't that be Reductionweasel? The other thing was called Iceweasel instead of Firefox.


Mozilla wants full control over the official Rust binaries, which I guess is reasonable. Google also wants full control over Chrome binaries, which I guess is reasonable, too.

I think Debian should just move Rust over into "non-free" and call it a day. Most people are OK with installing non-free software. And those that aren't are probably skilled enough to compile their own Rust binaries.

As for having Rust in the kernel, I believe that either needs a special permit from Mozilla or there shouldn't be Rust in the kernel. It would feel very icky to open the door to using non-free products in the kernel, because that will surely invite me-toos.


I'm particularly interested in whether the Rust Foundation has anything to say about this situation. I believe they're now the owners of the trademarks.


This work has been coordinated with the Rust Foundation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: