There are plans to add namespaces AFIK, they are just quite early stage.
Through for a long time (part of rust developers) haven't been very happy with the idea. a stuff like `abcde/bar` vs. `abcbe/bar` are a total pain. But there where two points which pushed things in the direction of having them. 1) Differentiating between 1st and 3rd party extensions of a project (e.g. is actix-XXXX "blessed" by actix or not) 2) companies want this for a bunch of reasons.
This subject is a touchy one because it usually attracts a lot of people who are upset because they think they’ve lost something they had. A lot of those comments start with “I’m not a lawyer but …”
Then all of these upset people writing angry comments creates an impression of drama. Then reaction streamers on YouTube read these comments out and get their viewers riled up over a non issue. That’s when the real drama starts.
I’d urge people to remember that this policy is very similar to the Python Foundation. If Rust is doomed to be only as successful as Python that’s not a terrible outcome.
Oh, Rust will definitely not fail because of trademark policies like this, anymore than Python succeeded because of trademark policies. In fact I think it's literally the opposite; seeing policies like this being set up is a sign that the project is wildly successful. I suspect Guido van Rossum was not worried about uses of the non-existent Python trademark in the late 80s.
The Rust foundation would have a hard time destroying Rust's momentum even if they wanted to.
I definitely think this policy is a step in the right direction.
My reference to python is a response to people claiming that rust will fail because of this trademark policy. If Python didn’t fail because of their similar policy, then Rust won’t either.
I didn't misread your comment: I'm not really concerned with whether or not the policy is considered a step in the right direction or not, just suggesting that it really doesn't matter at all to the success or failure of Rust.
Furthermore, Python is a pretty bad example. The Python Software Foundation has had multiple high-profile instances of reasonable outcry. See: DjangoCon Africa, or the banning of Tim Peters. The Python Software Foundation exists because of the tremendous success of Python, not because of the tremendous success of their policies.
Yeah I read your top level comment complaining about a “power grab”. You’re welcome to get worked up over a non issue. I won’t spend any time convincing you otherwise.
we're not on reddit. I see nothing like what you're talking about here.
Like most legalese CYA, the rules sound fine as long as they don''t use it to copyright troll everything under the sun. So it's more on how/where Rust enforces this than on the rules themselves. Those who profit from drama will find drama no matter what, so their opinions aren't worth consideration.
> This whole thread went to hell. There's like 2-3 people that are really vested about this situation and have made posts, and articles elsewhere that make their viewpoints seem bigger. Also the biggest comment thread is about a gun rights tangent. GG.
Are you convinced now? Or do you still stand by your "we're not on reddit"?
I apologize for missing a thread from 18 months ago.
>Are you convinced now? Or do you still stand by your "we're not on reddit"?
I still stand by it. Even taking that comment at face value it's saying that it's a matter of 2-3 people who fit my description of "they are incentivized to cause drama". I am a bit saddened that so many "took the bait" (the blog post that post links to really didn't offer much insight nor curiosity), but no forum will be perfect.
> Using the Rust trademarks for social and small non-profit events like meetups,
tutorials, and the like is allowed for events that are free to attend. Your materials for the event must not imply that the event is officially endorsed or run by the Rust Project or Rust Foundation unless you have written permission. For commercial events (including sponsored ones), please check in with us.
It sort of reminds me of Nintendo's awkward rules for community-ran tournaments of their games (which, well, pretty much make it impossible to do sustainably.)
I see their point (someone might mistake something called e.g. "New York Rust Conference" for being official) but using trademark to enforce rules on unofficial events is an interesting maneuver that seems to me to be relatively recent.
Go's trademark policy has a similar looking rule:
> The Go word mark may be used referentially in events, community groups, or other gatherings related to the programming language, but it may not be used in a manner that implies official status or endorsement.
At this point, it sounds more permissive: seems like it blanket allows uses to just refer to it if it's clear that it's not official.
> [...] Events and community groups may be subject to the Go programming language’s Code of Conduct, and violations of the Code of Conduct may be deemed incompatible with use of the Go Trademarks.
But then there's this, which seems to imply that your ability to use the Go trademark in reference to Go in a way that doesn't make your event sound official still obligates you to adhere to their Code of Conduct when conducting your event.
So it seems like this is a new part of the metagame.
I've not paid attention to policies like these. Could someone with more experience help me understand the context here? Specifically:
- Is this a new tactic, at least in terms of open source communities? It seems like it to me. In ~2010 it felt like open source was more fork-happy, ad-hoc and less governance-oriented, but now every other project has corporate backing, multiple committees, Code of Conducts, etc. Is the use of trademark and brand rules to exercise some control over the ecosystem new? Did someone pioneer it?
- Also, is there an inspiration for this tactic? e.g. is it inspired by a specific incident or state of affairs? Have these rules actually ever been used to do anything?
I'm guessing the real answer is that they just don't want to explicitly give up the ability to exercise these rules, but I'm not sure and I don't know how to look.
Either way, it's interesting to see committees and foundations going for these sorts of power grabs. It doesn't look like this is the case for all programming languages which have trademarks owned by some entity; C++ has a trademark policy, but it doesn't seem to have any restrictions regarding uses of the name that don't imply direct affiliation.
That's not a fair characterization. Large open source projects haven't even existed forever! And none of the obvious large open source projects from the earlier days started out having foundations or trademarks. Clearly, it had to have a genesis somewhere.
I don't know if this is the genesis, but the first time this came to my attention was with Linux. Basically: a third-party trademarked Linux several years after the project's origin, then started going after companies that were distributing Linux. Legal battle ensued. Linus Torvalds was eventually assigned the trademark. Innocence lost.
Trademarks likely existed for (what we would now call) open source software prior to that, but I think Linux was a turning point since it meant that community (rather than commercial) software now had to consider such prospects.
Yes, which is sort of my point, of course things didn't start this way. No trademark means no trademark policy, after all.
And more to the point, there was definitely a first time that an open source project instituted a trademark policy that says "You can use this name for unofficial events as long as it's clear its not official, but you must adhere to these additional rules when doing so." This sits somewhere between more and less restrictive trademark and brand policies that either allow it for a certain use case without much other consideration or disallow it without permission without much other consideration. It's hard to know exactly when it would even be considered enforceable, since referring to something by its name is usually not a violation of trademark in any case.
> Either way, it's interesting to see committees and foundations going for these sorts of power grabs.
I really hate thinking of this sort of stuff as a power grab. Unlike copyright, trademarks are something that is useful for the consumer/user. I want to know whether something is official or not, and throwing a trademark around ruins that.
For uses of trademarks that make it clear that they are not official uses, it doesn't even matter what the trademark owner's policy is because they don't have a legal leg to stand on. People have the right to refer to you no matter what you think. That being said, when you're not talking about FOSS stuff, people have the right to pull your licensing if you don't abide by their policies. But when it's FOSS, there's nothing they can do about it.
There is nothing to any of these FOSS foundations other than their trademarks. They exist to decide what they approve of and what they disapprove of, and allowing the mark is how they make that clear. You can fork everything that they have, change "Rust" to "Bust," register the "Bust Foundation," and name yourself president, all in the same day. The Bust Foundation will be no less legitimately a steward of the code than the Rust Foundation. But I'll be sticking with the Rust Foundation, at least for now, and the mark helps me do that.
It sounds like a powergrab to me, but there's some nuance to it. Look at it this way:
> Your materials for the event must not imply that the event is officially endorsed or run by the Rust Project or Rust Foundation unless you have written permission.
You can't imply an event is official without permission. Very reasonable. Not a powergrab. This is the same sort of thing that Firefox does to prevent modified versions of Firefox from being called Firefox.
> For commercial events (including sponsored ones), please check in with us.
But then there's this. This implies that there are extra rules for an event that is "commercial" even if it does not try to pretend to be an official event; merely using the trademark and being a commercial event would compel you to adhere to some other set of rules, which they didn't even write in the policy.
On its face, that doesn't sound unreasonable, but I imagine the net cast over what counts as "commercial events" probably makes very few reasonable events possible that wouldn't fall under this umbrella.
I'm going to go out on a limb and suggest that this has more to do with grifters and griefers than it does about power. Those are people who have the potential to create a lot of expensive headaches or public relations headaches for the organizations supporting their respective languages since the grifters and griefers are only concerned about their own motivations (profit or otherwise).
C++ is an entirely different thing. Even though it is backed by a standards body, it is far less centralized. Most people associate C++ with a language and I doubt that there are very many people who view it as a project backed by a particular organization.
This is the first thing that came to mind for me too. However, I am distinguishing this particular case (e.g. enforcing that you don't use trademarks in a way that would imply something is official) with the Rust/Go/Python trademark policies (e.g. enforcing a set of rules when using a trademark to refer to something in a clearly unofficial context.)
It's completely standard practice now, but since when? It didn't start this way because open source projects didn't used to be so big that they had foundations and trademarks.
Furthermore, I think there's a bit of nuance that people continue to miss: I'm not referring to having trademark rules. I am familiar with Linux and Mozilla, arguably the earliest "open source" organizations to deal with trademarks and have trademark policies.
What I'm referring to more specifically is what Go and Rust are doing for events: they seem to be applying additional rules for events that use the trademark in a way that does not imply affiliation. I think this is something that has not generally been the case for open source trademarks.
It's not entirely a new thing for Rust, at any rate. The current trademark policy [1] is very similar:
> Using the Rust trademarks (even in modified form) for social events like meetups, tutorials, and the like is allowed for events that are free to attend.
The part of the policy about distributing modified versions of the Rust compiler seems interesting:
> Publicly distributing a modified version of the Rust programming language, compiler,
or the Cargo package manager, provided that the modifications are limited to:
> - code adjustments for the purpose of porting to a different platform, architecture,
or system, or integrating the software with the packaging system of that platform
It looks like distributing a modified version with any change that isn't related to compatibility with a different platform/architecture/system is not allowed. This would probably make almost all GitHub forks of Rust non-compliant.
I don't think we can argue in good faith that those forks are publicly distributing a modified version of the rust programming language, unless they actually publish releases.
I don't know, to me it just seems like a plausible interpretation:
- In GitHub, forks of public repositories are themselves public repositories.
- GitHub repositories can be cloned, which is a form of distribution.
- Therefore any fork that implements, for example, a change to the programming language itself, but still uses the name "Rust", is distributing a modified version of the programming language in a manner that is not allowed.
I sincerely hope that this is not the interpretation taken by the Rust Foundation, but I cannot know for sure. It seems very open to selective enforcement.
It's an argument a lawyer could make in court with a straight face. But that's not the same as an argument likely to win in court. The fundamental purpose of trademark is protecting commercial purity of a product; a GitHub fork whose relation to the original is pretty clearly stated and isn't trying to present itself as a viable alternative to the original is just unlikely to be seen as in the purview of trademark protection in the first place.
Arguing that it's covered because it's distribution requires chaining through a few overly literal definitions to achieve that result, and that isn't likely to be winning argument against a gut instinct of "no, it's just not."
But legalities have its costs as well. is it worth it to go after some random student project with no stars on it? Absolutely not. I imagine that's the bulk of those github forks.
The way I read it the intent is to ensure there is one sanctioned version of Rust, if you change the compiler to accept other syntax, different file types etc you have to call it by another name. You can still say that it's written in rust and compatible to rust, but you can't call it rust. A weaker version of that policy Firefox had for a while.
Maybe the exact wording needs some refinement. Allowing repositories that are marked as forks for example.
> The way I read it the intent is to ensure there is one sanctioned version of Rus
basically that
Through it's very annoying that it needs refinement _again_ and _again_ every f* time they update the trademark policy.
Like why
- is there no exception for research (i.e. science) use, as long as explicitly labeled at such
- public development forks which are used to prototype directions rust could go into, again if clearly labeled as such and not maintained as forks (through to be fair the line between a public experimental rust development fork and an early rust "full" fork are thin)
- wrt. software compatibility allowance why is it limited to the "packaging system of that platform" can't I fork to idk. create compatibility with a code analysis tool, changes I then later want to upstream but first need to test so need to distribute to various people?
and sure you will normally get written permission for all the cases above, just the chance that someone could abuse this preventing you from doing very reasonable thing is IMHO an issue. I really don't want to see a headline like "rust forbids <company> from creating a compatible code analysis tool because <some stupid issue>".
This is a trademark policy, not a copyright license (Rust is distributed under MIT and Apache licenses, which are quite liberal in what you are allowed to do). You're welcome to make changes and distribute the modified versions, but you do have to be clear to people that it's not Rust, but DathinabRust etc.
but if you distribute something containing a trademark and the trade mark policies don't allow distribution it is pretty much automatically a gray area of trade mark infringement
i.e. you do a clone of the rust repo and a some changes is with the current form of the draft trade mark infringement as long as you don't also at least 1. rename the repo, 2. update the readme
but even if you do it might still not be enough
trademark law as it currently is can easily be ab-used as an additional form of copy right protection and as long as you don't replace any occurrences of rust/cargo you are always trading in a potential gray area of law which can be abused
and who wants to contribute under such circumstances?
also who wants to contribute if they have to change the readme/repo name just to make a bug branch but then also not have it in the PR you submit, but also needing to have this changes in any branch including the PR ...
> if you distribute something containing a trademark and the trade mark policies don't allow distribution it is pretty much automatically a gray area of trade mark infringement
The whole world is shades of gray, but this is more like a wispy cirrus cloud than a dark cumulonimbus. If it's clear that there's no intent to cause confusion (and I suspect that if you're not creating releases in that repo that would be a pretty easy case) then there's not really much of a trademark infringement case to be made.
In the absence of such a trademark policy you'd have the exact same concerns. Them trying to go after people who fork on github would be a waste of time for everyone concerned: there would be no damages unless they went through the trouble of finding someone who had somehow actually been confused, and a C&D would accomplish nothing positive for the Rust Foundation anyway.
> - is there no exception for research (i.e. science) use, as long as explicitly labeled at such
It's fine, researchers won't be harmed by having to find a cheesy name for their rust-based project. Actuality they probably don't even need a trademark policy for doing this.
You need a name for your project when writing papers anyway.
The word “Rust” is all over the code repo, you’d need to do a massive change and you’ll lose the ability to merge upstream changes. “Rename the repo if you’re doing something meaningfully new with no intent to merge it upstream” is fine, but it’s not enough to avoid saying “Rust” in the version you distribute.
What I am missing here is something like the Java TCK or ISO C: You can call this a compiler that implements the rust language iff it adheres to this specification and passes this suite of test. I really want to see things like a gcc rust be viable, even in a hypothetical universe where the rust foundation would do everything to thwart their existence (to be clear: I am not saying they are).
No one is thwarting anything. You want a GCC implementation of Rust? Check out this blog post published on the official Rust blog 3 days ago - gccrs: An alternative compiler for Rust (https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-c...). They are perfectly welcome to create this alternate compiler.
The phrasing around events is especially weird given that “non-commercial” would only imply “free to attend” in some sort of communist utopia where venues, catering, transfer and other stuff you need to actually host an event is free. The only kind of event this policy allows without an explicit approval is “get a beer with friends and talk about Rust”, and only if the price of the beer doesn’t count.
51 comments
[ 3.2 ms ] story [ 104 ms ] threadGosh they really should have used namespaces, huh.
Through for a long time (part of rust developers) haven't been very happy with the idea. a stuff like `abcde/bar` vs. `abcbe/bar` are a total pain. But there where two points which pushed things in the direction of having them. 1) Differentiating between 1st and 3rd party extensions of a project (e.g. is actix-XXXX "blessed" by actix or not) 2) companies want this for a bunch of reasons.
Then all of these upset people writing angry comments creates an impression of drama. Then reaction streamers on YouTube read these comments out and get their viewers riled up over a non issue. That’s when the real drama starts.
I’d urge people to remember that this policy is very similar to the Python Foundation. If Rust is doomed to be only as successful as Python that’s not a terrible outcome.
The Rust foundation would have a hard time destroying Rust's momentum even if they wanted to.
I definitely think this policy is a step in the right direction.
My reference to python is a response to people claiming that rust will fail because of this trademark policy. If Python didn’t fail because of their similar policy, then Rust won’t either.
Furthermore, Python is a pretty bad example. The Python Software Foundation has had multiple high-profile instances of reasonable outcry. See: DjangoCon Africa, or the banning of Tim Peters. The Python Software Foundation exists because of the tremendous success of Python, not because of the tremendous success of their policies.
What's the point of a reply like this?
Like most legalese CYA, the rules sound fine as long as they don''t use it to copyright troll everything under the sun. So it's more on how/where Rust enforces this than on the rules themselves. Those who profit from drama will find drama no matter what, so their opinions aren't worth consideration.
Check out this one (https://news.ycombinator.com/item?id=35583089) which is summarised by the top comment
> This whole thread went to hell. There's like 2-3 people that are really vested about this situation and have made posts, and articles elsewhere that make their viewpoints seem bigger. Also the biggest comment thread is about a gun rights tangent. GG.
Are you convinced now? Or do you still stand by your "we're not on reddit"?
>Are you convinced now? Or do you still stand by your "we're not on reddit"?
I still stand by it. Even taking that comment at face value it's saying that it's a matter of 2-3 people who fit my description of "they are incentivized to cause drama". I am a bit saddened that so many "took the bait" (the blog post that post links to really didn't offer much insight nor curiosity), but no forum will be perfect.
There's plenty of drama around, but I don't really see this kind of trademark policy sparking much. But, maybe I misunderestimate the drama seekers.
> Using the Rust trademarks for social and small non-profit events like meetups, tutorials, and the like is allowed for events that are free to attend. Your materials for the event must not imply that the event is officially endorsed or run by the Rust Project or Rust Foundation unless you have written permission. For commercial events (including sponsored ones), please check in with us.
It sort of reminds me of Nintendo's awkward rules for community-ran tournaments of their games (which, well, pretty much make it impossible to do sustainably.)
I see their point (someone might mistake something called e.g. "New York Rust Conference" for being official) but using trademark to enforce rules on unofficial events is an interesting maneuver that seems to me to be relatively recent.
Go's trademark policy has a similar looking rule:
> The Go word mark may be used referentially in events, community groups, or other gatherings related to the programming language, but it may not be used in a manner that implies official status or endorsement.
At this point, it sounds more permissive: seems like it blanket allows uses to just refer to it if it's clear that it's not official.
> [...] Events and community groups may be subject to the Go programming language’s Code of Conduct, and violations of the Code of Conduct may be deemed incompatible with use of the Go Trademarks.
But then there's this, which seems to imply that your ability to use the Go trademark in reference to Go in a way that doesn't make your event sound official still obligates you to adhere to their Code of Conduct when conducting your event.
So it seems like this is a new part of the metagame.
I've not paid attention to policies like these. Could someone with more experience help me understand the context here? Specifically:
- Is this a new tactic, at least in terms of open source communities? It seems like it to me. In ~2010 it felt like open source was more fork-happy, ad-hoc and less governance-oriented, but now every other project has corporate backing, multiple committees, Code of Conducts, etc. Is the use of trademark and brand rules to exercise some control over the ecosystem new? Did someone pioneer it?
- Also, is there an inspiration for this tactic? e.g. is it inspired by a specific incident or state of affairs? Have these rules actually ever been used to do anything?
I'm guessing the real answer is that they just don't want to explicitly give up the ability to exercise these rules, but I'm not sure and I don't know how to look.
Either way, it's interesting to see committees and foundations going for these sorts of power grabs. It doesn't look like this is the case for all programming languages which have trademarks owned by some entity; C++ has a trademark policy, but it doesn't seem to have any restrictions regarding uses of the name that don't imply direct affiliation.
Large open source projects have trademarks since forever. Nothing seems particularly novel here.
Trademarks likely existed for (what we would now call) open source software prior to that, but I think Linux was a turning point since it meant that community (rather than commercial) software now had to consider such prospects.
And more to the point, there was definitely a first time that an open source project instituted a trademark policy that says "You can use this name for unofficial events as long as it's clear its not official, but you must adhere to these additional rules when doing so." This sits somewhere between more and less restrictive trademark and brand policies that either allow it for a certain use case without much other consideration or disallow it without permission without much other consideration. It's hard to know exactly when it would even be considered enforceable, since referring to something by its name is usually not a violation of trademark in any case.
I really hate thinking of this sort of stuff as a power grab. Unlike copyright, trademarks are something that is useful for the consumer/user. I want to know whether something is official or not, and throwing a trademark around ruins that.
For uses of trademarks that make it clear that they are not official uses, it doesn't even matter what the trademark owner's policy is because they don't have a legal leg to stand on. People have the right to refer to you no matter what you think. That being said, when you're not talking about FOSS stuff, people have the right to pull your licensing if you don't abide by their policies. But when it's FOSS, there's nothing they can do about it.
There is nothing to any of these FOSS foundations other than their trademarks. They exist to decide what they approve of and what they disapprove of, and allowing the mark is how they make that clear. You can fork everything that they have, change "Rust" to "Bust," register the "Bust Foundation," and name yourself president, all in the same day. The Bust Foundation will be no less legitimately a steward of the code than the Rust Foundation. But I'll be sticking with the Rust Foundation, at least for now, and the mark helps me do that.
> Your materials for the event must not imply that the event is officially endorsed or run by the Rust Project or Rust Foundation unless you have written permission.
You can't imply an event is official without permission. Very reasonable. Not a powergrab. This is the same sort of thing that Firefox does to prevent modified versions of Firefox from being called Firefox.
> For commercial events (including sponsored ones), please check in with us.
But then there's this. This implies that there are extra rules for an event that is "commercial" even if it does not try to pretend to be an official event; merely using the trademark and being a commercial event would compel you to adhere to some other set of rules, which they didn't even write in the policy.
On its face, that doesn't sound unreasonable, but I imagine the net cast over what counts as "commercial events" probably makes very few reasonable events possible that wouldn't fall under this umbrella.
It's an interesting choice in my opinion.
C++ is an entirely different thing. Even though it is backed by a standards body, it is far less centralized. Most people associate C++ with a language and I doubt that there are very many people who view it as a project backed by a particular organization.
It isn't. It's completely standard practice. Python uses it in the same way and you probably didn't even notice (and Go as you discovered).
It's not a new tactic. It's literally what trademark law is designed for.
Furthermore, I think there's a bit of nuance that people continue to miss: I'm not referring to having trademark rules. I am familiar with Linux and Mozilla, arguably the earliest "open source" organizations to deal with trademarks and have trademark policies.
What I'm referring to more specifically is what Go and Rust are doing for events: they seem to be applying additional rules for events that use the trademark in a way that does not imply affiliation. I think this is something that has not generally been the case for open source trademarks.
> Using the Rust trademarks (even in modified form) for social events like meetups, tutorials, and the like is allowed for events that are free to attend.
[1]: https://foundation.rust-lang.org/policies/logo-policy-and-me...
> Publicly distributing a modified version of the Rust programming language, compiler, or the Cargo package manager, provided that the modifications are limited to:
> - code adjustments for the purpose of porting to a different platform, architecture, or system, or integrating the software with the packaging system of that platform
It looks like distributing a modified version with any change that isn't related to compatibility with a different platform/architecture/system is not allowed. This would probably make almost all GitHub forks of Rust non-compliant.
- In GitHub, forks of public repositories are themselves public repositories.
- GitHub repositories can be cloned, which is a form of distribution.
- Therefore any fork that implements, for example, a change to the programming language itself, but still uses the name "Rust", is distributing a modified version of the programming language in a manner that is not allowed.
I sincerely hope that this is not the interpretation taken by the Rust Foundation, but I cannot know for sure. It seems very open to selective enforcement.
Arguing that it's covered because it's distribution requires chaining through a few overly literal definitions to achieve that result, and that isn't likely to be winning argument against a gut instinct of "no, it's just not."
But legalities have its costs as well. is it worth it to go after some random student project with no stars on it? Absolutely not. I imagine that's the bulk of those github forks.
Maybe the exact wording needs some refinement. Allowing repositories that are marked as forks for example.
basically that
Through it's very annoying that it needs refinement _again_ and _again_ every f* time they update the trademark policy.
Like why
- is there no exception for research (i.e. science) use, as long as explicitly labeled at such
- public development forks which are used to prototype directions rust could go into, again if clearly labeled as such and not maintained as forks (through to be fair the line between a public experimental rust development fork and an early rust "full" fork are thin)
- wrt. software compatibility allowance why is it limited to the "packaging system of that platform" can't I fork to idk. create compatibility with a code analysis tool, changes I then later want to upstream but first need to test so need to distribute to various people?
and sure you will normally get written permission for all the cases above, just the chance that someone could abuse this preventing you from doing very reasonable thing is IMHO an issue. I really don't want to see a headline like "rust forbids <company> from creating a compatible code analysis tool because <some stupid issue>".
exactly
but if you distribute something containing a trademark and the trade mark policies don't allow distribution it is pretty much automatically a gray area of trade mark infringement
i.e. you do a clone of the rust repo and a some changes is with the current form of the draft trade mark infringement as long as you don't also at least 1. rename the repo, 2. update the readme
but even if you do it might still not be enough
trademark law as it currently is can easily be ab-used as an additional form of copy right protection and as long as you don't replace any occurrences of rust/cargo you are always trading in a potential gray area of law which can be abused
and who wants to contribute under such circumstances?
also who wants to contribute if they have to change the readme/repo name just to make a bug branch but then also not have it in the PR you submit, but also needing to have this changes in any branch including the PR ...
The whole world is shades of gray, but this is more like a wispy cirrus cloud than a dark cumulonimbus. If it's clear that there's no intent to cause confusion (and I suspect that if you're not creating releases in that repo that would be a pretty easy case) then there's not really much of a trademark infringement case to be made.
In the absence of such a trademark policy you'd have the exact same concerns. Them trying to go after people who fork on github would be a waste of time for everyone concerned: there would be no damages unless they went through the trouble of finding someone who had somehow actually been confused, and a C&D would accomplish nothing positive for the Rust Foundation anyway.
It's fine, researchers won't be harmed by having to find a cheesy name for their rust-based project. Actuality they probably don't even need a trademark policy for doing this.
You need a name for your project when writing papers anyway.
it's quite easy to accidentally commit trade mark infringement if there is a restrictive policy about it and you "just fork on github"
while in many situations law cases probably would be shut down legal instability helps no one
(Except the current policy says "Distributing" rather than "Publicly distributing".)