6 ms·

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

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]
    - ChrisSD 7y ago
      No need to guess about Firefox/Debian, the bug report is preserved here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006 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.
      - jordigh 7y ago
        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.
- 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.

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]
  - ChrisSD 7y ago
    No need to guess about Firefox/Debian, the bug report is preserved here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006 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.
    - jordigh 7y ago
      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.
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.