6 ms·

Rust's Freedom Flaws

66 points by based2 7y ago

tspiteri 7y ago
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 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 …
- einpoklum 7y ago
  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.)
  - barrkel 7y ago
    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.
    - jordigh 7y ago
      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.
      - barrkel 7y ago
        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 https://bugs.launchpad.net/ubuntu/+source/atop/+bug/1393175 .
        jordigh 7y ago
        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.
        barrkel 7y ago
        The atop changes are a showstopper, they caused an outage.
      - deleted 7y ago
        [deleted]
  - SahAssar 7y ago
    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.
    - einpoklum 7y ago
      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".
      - SahAssar 7y ago
        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?
  - Argorak 7y ago
    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.
bryanlarsen 7y ago
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 https://news.ycombinator.com/item?id=21867639
Macha 7y ago
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 https://github.com/naftaliharris/tauthon) was launched as it was initially describing itself as python 2.8
- hu3 7y ago
  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.
  - the_mitsuhiko 7y ago
    I’m not seeing the difference to Mozilla here.
    - hu3 7y ago
      Python's license allows patched redistribution without explicit permition. Rust's doesn't.
      - the_mitsuhiko 7y ago
        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.
c-cube 7y ago
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).
- tmcb 7y ago
  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.
  - c-cube 7y ago
    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?
    - tmcb 7y ago
      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_Debian#Iceweasel https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_... ).
      - steveklabnik 7y ago
        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/ https://sources.debian.org/patches/rustc/1.34.2+dfsg1-1/
      - oconnor663 7y ago
        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.
forrestthewoods 7y ago
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.
- Althorion 7y ago
  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.
  - DangerousPie 7y ago
    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.
    - ghostpepper 7y ago
      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?
      - forrestthewoods 7y ago
        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.
    - zajio1am 7y ago
ChrisSD 7y ago
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?
- leni536 7y ago
  Possibly calling both the compiler implementation and the language Rust is the issue here.
  - Macha 7y ago
    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.
  - dagmx 7y ago
    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.
    - Aaargh20318 7y ago
      > 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?
      - 7y ago
deleted 7y ago
[deleted]
based2 7y ago
Make your branch & call it Tsur Ekil.
omneity 7y ago
Is there an existing project that does allow for forks with the same trademark? (that is not in the public domain and similar licenses)
CuriousReader13 7y ago
IMNAL. How about GNU asks Mozilla for a permission to call any modifications it makes "GNU Rust"?
- SahAssar 7y ago
  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.
steveklabnik 7y ago
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.
- tedunangst 7y ago
  Is it very bad that https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc calls itself a Rust compiler?
  - steveklabnik 7y ago
    No, because it is very clear that it's not an actual Rust compiler yet, and so is extremely unlikely to generate said confusion.
  - Argorak 7y ago
    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)
destitude 7y ago
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.
- jeremyjh 7y ago
  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.
  - steveklabnik 7y ago
    Rust provides the ability to use your own LLVM already in-tree, no need to patch.
    - jeremyjh 7y ago
      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 https://github.com/MabezDev/rust-xtensa
      - steveklabnik 7y ago
        Yes, this is a good point, sometimes you need frontend changes too.
svat 7y ago
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-tb100mittbach-lppl-history.pdf 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.
dang 7y ago
This is a follow-up to yesterday's thread: https://news.ycombinator.com/item?id=21867202 https://news.ycombinator.com/item?id=21867202

66 points by based2 7y ago

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

einpoklum 7y ago
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.)
- barrkel 7y ago
  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.
  - jordigh 7y ago
    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.
    - barrkel 7y ago
      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 https://bugs.launchpad.net/ubuntu/+source/atop/+bug/1393175 .
      - jordigh 7y ago
        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.
        barrkel 7y ago
        The atop changes are a showstopper, they caused an outage.
    - deleted 7y ago
      [deleted]
- SahAssar 7y ago
  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.
  - einpoklum 7y ago
    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".
    - SahAssar 7y ago
      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?
- Argorak 7y ago
  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.

bryanlarsen 7y ago

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 https://news.ycombinator.com/item?id=21867639

Macha 7y ago

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 https://github.com/naftaliharris/tauthon) was launched as it was initially describing itself as python 2.8

hu3 7y ago
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.
- the_mitsuhiko 7y ago
  I’m not seeing the difference to Mozilla here.
  - hu3 7y ago
    Python's license allows patched redistribution without explicit permition. Rust's doesn't.
    - the_mitsuhiko 7y ago
      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.

c-cube 7y ago

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

tmcb 7y ago
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.
- c-cube 7y ago
  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?
  - tmcb 7y ago
    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_Debian#Iceweasel https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_... ).
    - steveklabnik 7y ago
      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/ https://sources.debian.org/patches/rustc/1.34.2+dfsg1-1/
    - oconnor663 7y ago
      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.

forrestthewoods 7y ago

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.

Althorion 7y ago
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.
- DangerousPie 7y ago
  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.
  - ghostpepper 7y ago
    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?
    - forrestthewoods 7y ago
      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.
  - zajio1am 7y ago

ChrisSD 7y ago

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?

leni536 7y ago
Possibly calling both the compiler implementation and the language Rust is the issue here.
- Macha 7y ago
  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.
- dagmx 7y ago
  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.
  - Aaargh20318 7y ago
    > 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?
    - 7y ago

deleted 7y ago

[deleted]

based2 7y ago

Make your branch & call it Tsur Ekil.

omneity 7y ago

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

CuriousReader13 7y ago

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

SahAssar 7y ago
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.

steveklabnik 7y ago

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.

tedunangst 7y ago
Is it very bad that https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc calls itself a Rust compiler?
- steveklabnik 7y ago
  No, because it is very clear that it's not an actual Rust compiler yet, and so is extremely unlikely to generate said confusion.
- Argorak 7y ago
  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)

destitude 7y ago

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.

jeremyjh 7y ago
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.
- steveklabnik 7y ago
  Rust provides the ability to use your own LLVM already in-tree, no need to patch.
  - jeremyjh 7y ago
    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 https://github.com/MabezDev/rust-xtensa
    - steveklabnik 7y ago
      Yes, this is a good point, sometimes you need frontend changes too.

svat 7y ago

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-tb100mittbach-lppl-history.pdf 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.

dang 7y ago

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