Rust freedom issue claim

Rust freedom issue claim

[Bone Baboon]

This is an article from Hyperbola about the Rust trademark. It claims
that Rust has a freedom issue.
<https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws>

I searched for this in the Guix bug and devel mailing list archive but
did not see it.

I would like to know how others interpret this claim of Rust having a
freedom issue.

# Linux-libre

If Rust does have a freedom issue then there is potential that it could
have an impact on Linux-libre.  Recently there was a RFC for adding
support for Rust to the Linux kernel
<https://lkml.org/lkml/2021/4/14/1023>.  Linus Torvalds's response is
here <https://lkml.org/lkml/2021/4/14/1099>.

# Responses on Freenode

I asked about Hyperbola's claim of a Rust freedom issue on
##rust@ire.freenode.net and these were some of the responses I
received.  However it appears that the core of Hyperbola's claim
remains unaddressed by these responses.

"<SpaceManiac> the trademarks are now owned by the Rust Foundation
rather than Mozilla, but the Rust Media Guide has not been updated to
reflect this"

"<lifeless> bone-baboon: https://github.com/rust-lang/rust/issues/53287
is closed by https://github.com/rust-lang/rust/pull/59748"

"<lifeless> bone-baboon: whether you consider is a freedom issue or not
is a matter of viewpoint - debian doesn't seem to care at this point,
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=cargo
shows no bugs open related to trademarks"

Re: Rust freedom issue claim

[Bone Baboon]

Bone Baboon writes:

> This is an article from Hyperbola about the Rust trademark. It claims
> that Rust has a freedom issue.
> <https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws>
>
> I searched for this in the Guix bug and devel mailing list archive but
> did not see it.
>
> I would like to know how others interpret this claim of Rust having a
> freedom issue.
>
> # Linux-libre
>
> If Rust does have a freedom issue then there is potential that it could
> have an impact on Linux-libre.  Recently there was a RFC for adding
> support for Rust to the Linux kernel
> <https://lkml.org/lkml/2021/4/14/1023>.  Linus Torvalds's response is
> here <https://lkml.org/lkml/2021/4/14/1099>.
>
> # Responses on Freenode
>
> I asked about Hyperbola's claim of a Rust freedom issue on
> ##rust@ire.freenode.net and these were some of the responses I
> received.  However it appears that the core of Hyperbola's claim
> remains unaddressed by these responses.
>
> "<SpaceManiac> the trademarks are now owned by the Rust Foundation
> rather than Mozilla, but the Rust Media Guide has not been updated to
> reflect this"
>
> "<lifeless> bone-baboon: https://github.com/rust-lang/rust/issues/53287
> is closed by https://github.com/rust-lang/rust/pull/59748"
>
> "<lifeless> bone-baboon: whether you consider is a freedom issue or not
> is a matter of viewpoint - debian doesn't seem to care at this point,
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=cargo
> shows no bugs open related to trademarks"

I asked about this on #hyperbola@Freenode.  I was told that it is still
an issue and this link was shared:
<https://github.com/rust-lang/foundation-faq-2020/issues/35>.

Re: Rust freedom issue claim

[Ludovic Courtès]

Hi,

Bone Baboon <bone.baboon@disroot.org> skribis:

> This is an article from Hyperbola about the Rust trademark. It claims
> that Rust has a freedom issue.
> <https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws>

(Side note: “freedom issue” is not a helpful term as it could mean all
sorts of things.)

The trademark discussion refers to
<https://issues.hyperbola.info/index.php?do=details&task_id=736>, which
dates back to 2018.

In recent years, Mozilla’s trademark policy changed, to the point that
distributions can use the name “Firefox” for packages they provide:

  https://lwn.net/Articles/676799/

Before triggering an alarm, I would check what major distros, and Debian
in particular, are doing about Rust; I have not heard of any concerns so
far.  If the Rust trademark turns out to be a concern, distros should
try hard, collectively, to resolve it through dialog with Rust
Foundation people.

> If Rust does have a freedom issue then there is potential that it could
> have an impact on Linux-libre.  Recently there was a RFC for adding
> support for Rust to the Linux kernel
> <https://lkml.org/lkml/2021/4/14/1023>.  Linus Torvalds's response is
> here <https://lkml.org/lkml/2021/4/14/1099>.

That’s a somewhat different topic.  FWIW, I’m both excited at the idea
of having a memory-safe replacement for C gaining momentum, and
frightened by the prospects of Rust being this replacement, for many
reasons including: Rust does not have a good bootstrapping story, as we
know all too well, Cargo encourages sloppy package distribution à la
npm, Rust in the kernel would give a false sense of safety (it’s still
that big monolithic blob!), and the Rust community is very much
anti-copyleft.

Guix, related projects such as Mes, Gash, and the Shepherd, together
with the Hurd, offer a very different and (to me) more appealing vision
for a user-empowering, safer, more robust, and yet POSIX-compliant OS.

Ludo’.

Re: Rust freedom issue claim

[Pjotr Prins]

On Wed, May 26, 2021 at 04:32:03PM +0200, Ludovic Courtès wrote:
> That’s a somewhat different topic.  FWIW, I’m both excited at the idea
> of having a memory-safe replacement for C gaining momentum, and
> frightened by the prospects of Rust being this replacement, for many
> reasons including: Rust does not have a good bootstrapping story, as we
> know all too well, Cargo encourages sloppy package distribution à la
> npm, Rust in the kernel would give a false sense of safety (it’s still
> that big monolithic blob!), and the Rust community is very much
> anti-copyleft.

Having adopted Rust for some of our bioinformatics work, I can fully
agree. It is actually hard to use Rust without Cargo and it is an
implosion npm-style waiting to happen if the most trivial program
already imports 100+ external packages - some of doubtful quality.

Another thing I have against Rust is its syntax - but that is
(arguably) taste. I can't believe references are written with an
ampersand - and they are so common it is in your face all the time.
That is just noise. And sometimes the borrow checker really gets in
the way (and I pine for GC). We are sticking with Rust though because
the compiler works hard and is a sucker for detail, so it helps both
less and more experienced programmers to avoid C/C++ traps. Also Rust
has no OOP that people can use - I am very happy about that. In short
it is a fairly pragmatic FP language with some nice compile time
features. I don't love it but it is an OK compromise.

For kernels I completely agree with you. Memory safety is a red
herring because we face much deeper problems. Open hardware and
message passing is the way forward.

Oh, did you know Rust expands all sources into one 'blob' for
compilation? At the crate level. It led to the meme: "The Rust
programming language compiles fast software slowly."

I have not hit real issues yet with compilation speed, but it feels
like we regressed to huge C++ template expansion...

> Guix, related projects such as Mes, Gash, and the Shepherd, together
> with the Hurd, offer a very different and (to me) more appealing vision
> for a user-empowering, safer, more robust, and yet POSIX-compliant OS.

Good architecture is far more important than a borrow checker.

Pj.

Re: Rust freedom issue claim

[Joshua Branson]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Wed, May 26, 2021 at 04:32:03PM +0200, Ludovic Courtès wrote:
>> That’s a somewhat different topic.  FWIW, I’m both excited at the idea
>> of having a memory-safe replacement for C gaining momentum, and
>> frightened by the prospects of Rust being this replacement, for many
>> reasons including: Rust does not have a good bootstrapping story, as we
>> know all too well, Cargo encourages sloppy package distribution à la
>> npm, Rust in the kernel would give a false sense of safety (it’s still
>> that big monolithic blob!), and the Rust community is very much
>> anti-copyleft.
>
> Having adopted Rust for some of our bioinformatics work, I can fully
> agree. It is actually hard to use Rust without Cargo and it is an
> implosion npm-style waiting to happen if the most trivial program
> already imports 100+ external packages - some of doubtful quality.
>
> Another thing I have against Rust is its syntax - but that is
> (arguably) taste. I can't believe references are written with an
> ampersand - and they are so common it is in your face all the time.
> That is just noise. And sometimes the borrow checker really gets in
> the way (and I pine for GC). We are sticking with Rust though because
> the compiler works hard and is a sucker for detail, so it helps both
> less and more experienced programmers to avoid C/C++ traps. Also Rust
> has no OOP that people can use - I am very happy about that. In short
> it is a fairly pragmatic FP language with some nice compile time
> features. I don't love it but it is an OK compromise.

In terms of languages trying to be replacements for C:

- Zig is one of the most famous ones, and will probably be the first C
  alternatives to reach 1.0.  https://ziglang.org/

- Odin https://odin-lang.org/

- scopes which using S-expressions  https://sr.ht/~duangle/scopes/

- Drew Devault's (creator or sway) secret programming language.  It may
  be the second language on this list to reach 1.0

>
> For kernels I completely agree with you. Memory safety is a red
> herring because we face much deeper problems. Open hardware and
> message passing is the way forward.
>
> Oh, did you know Rust expands all sources into one 'blob' for
> compilation? At the crate level. It led to the meme: "The Rust
> programming language compiles fast software slowly."
>
> I have not hit real issues yet with compilation speed, but it feels
> like we regressed to huge C++ template expansion...
>
>> Guix, related projects such as Mes, Gash, and the Shepherd, together
>> with the Hurd, offer a very different and (to me) more appealing vision
>> for a user-empowering, safer, more robust, and yet POSIX-compliant OS.
>
> Good architecture is far more important than a borrow checker.
>
> Pj.
>

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: Rust freedom issue claim

[Pjotr Prins]

Scopes sure looks cool!

Pj.

Re: Rust freedom issue claim

[Jack Hill]

On Thu, 27 May 2021, Joshua Branson wrote:

> In terms of languages trying to be replacements for C:
>
> - Zig is one of the most famous ones, and will probably be the first C
>  alternatives to reach 1.0.  https://ziglang.org/
>
> - Odin https://odin-lang.org/
>
> - scopes which using S-expressions  https://sr.ht/~duangle/scopes/
>
> - Drew Devault's (creator or sway) secret programming language.  It may
>  be the second language on this list to reach 1.0

Thanks for this list. Clearly we are living in a world of riches. I am 
also aware of:

- Carp https://github.com/carp-lang/Carp (s-expressions, research project)

- Pony https://www.ponylang.io/ (actors)

Best,
Jack

Re: Rust freedom issue claim

[Bone Baboon]

Ludovic Courtès writes:
> Before triggering an alarm, I would check what major distros, and Debian
> in particular, are doing about Rust; I have not heard of any concerns so
> far.  If the Rust trademark turns out to be a concern, distros should
> try hard, collectively, to resolve it through dialog with Rust
> Foundation people.

I started a thread about the Rust trademark policy on the debian-legal
mailing list.
<https://lists.debian.org/debian-legal/2021/06/msg00003.html>

I participated in the Free Software Foundation's most recent Free
Software Directory meeting.  Several participants in the meeting where
interested in the Rust trademark policy.  I started a thread on the
directory-discuss mailing list as was suggested in the meeting.
<https://lists.gnu.org/archive/html/directory-discuss/2021-06/msg00000.html>

The Free Software Foundation's licensing team will be taking a serious
look at the Rust trademark policy issue (no time frame was given).
<https://lists.gnu.org/archive/html/directory-discuss/2021-06/msg00001.html>

After reading further on the topic and receiving feedback I have written
an update to my understanding of the Rust trademark policy.
<https://lists.gnu.org/archive/html/directory-discuss/2021-06/msg00000.html>

Re: Rust freedom issue claim

[Ludovic Courtès]

Hi,

Bone Baboon <bone.baboon@disroot.org> skribis:

> After reading further on the topic and receiving feedback I have written
> an update to my understanding of the Rust trademark policy.
> <https://lists.gnu.org/archive/html/directory-discuss/2021-06/msg00000.html>

Thanks for the detailed study and summary!

Guix did not ask the Rust Foundation for permission.  Did any of the
other distros you mention did?

We could ask for permission.  Though I would have hoped Mozilla had
learned from the past.  :-/

Thanks,
Ludo’.

Re: Rust freedom issue claim

[Bone Baboon]

Ludovic Courtès writes:
> Bone Baboon <bone.baboon@disroot.org> skribis:
>
>> After reading further on the topic and receiving feedback I have written
>> an update to my understanding of the Rust trademark policy.
>> <https://lists.gnu.org/archive/html/directory-discuss/2021-06/msg00000.html>
>
> Thanks for the detailed study and summary!
>
> Guix did not ask the Rust Foundation for permission.  Did any of the
> other distros you mention did?

I do not know if any other distrobutions have asked the Mozilla or Rust
Foundations for permission.

> We could ask for permission.  Though I would have hoped Mozilla had
> learned from the past.  :-/

Contents:
* Passive Approaches
* Active Approaches
* Summary

There are several options for how to move forward with the issue of the
Rust Foundation trademark policy.

# Passive Approaches

* Wait for the FSF licensing team to complete their review of the Rust
  trademark policy.
** Advantages
*** No action needed by Guix while waiting for the FSF licensing team.
** Disadvantages
*** FSF licensing team has set no time frame and may never complete
    review. 
*** While waiting the Rust Foundation could try to enforce it's
    trademark policy.

* Do nothing
** Advantages
*** No action needed by Guix.
*** The trademark policy may not be enforceable see notes below.
** Disadvantages
*** The Rust Foundation could try to enforce it's trademark policy.
** Notes on trademark enforcement
*** "A trademark that is popularly used to describe a product or service
    (rather than to distinguish the product or services from those of
    third parties) is sometimes known as a genericized trademark. If
    such a mark becomes synonymous with that product or service to the
    extent that the trademark owner can no longer enforce its
    proprietary rights, the mark becomes generic."
    <https://en.wikipedia.org/wiki/Trademark>
    <https://en.wikipedia.org/wiki/Genericized_trademark>
*** "Once trademark rights are established in a particular jurisdiction,
    these rights are generally only enforceable in that jurisdiction, a
    quality which is sometimes known as "territoriality". However, there
    is a range of international trademark laws and systems which
    facilitate the protection of trademarks in more than one
    jurisdiction." 
    <https://en.wikipedia.org/wiki/Trademark>
*** "Trademarks rights must be maintained through actual lawful use of
    the trademark. These rights will cease if a mark is not actively
    used for a period of time, normally five years in most
    jurisdictions. In the case of trademark registration, failure to
    actively use the mark in the lawful course of trade, or to enforce
    the registration in the event of infringement, may also expose the
    registration itself to become liable for an application for the
    removal from the register after a certain period of time on the
    grounds of "non-use".
    <https://en.wikipedia.org/wiki/Trademark>

# Active Approaches

* Guix alone asks Rust Foundation for permission to use trademarks
** Advantages
*** No need to coordinate with other operating systems.
** Disadvantages
*** The problem remains for all other operating systems.
*** The Rust Foundation may not give Guix permission.

* Guix alone asks the Rust Foundation to change it's trademark policy
** Advantages
*** No need to coordinate with other operating systems.
** Disadvantages
*** The Rust Foundation may not change it's trademark policy.

* A group of operating system together ask the Rust Foundation to change
  it's trademark policy
** Advantages
*** More likely that the Rust Foundation will consider the request of a
    group of operating systems instead of request by just Guix.
** Disadvantages
*** The Rust Foundation may not change it's trademark policy.
** Notes
*** Ludovic Courtès proposed this approach previously in this
    thread. "If the Rust trademark turns out to be a concern, distros
    should try hard, collectively, to resolve it through dialog with
    Rust Foundation people."
*** If this is the desired approach I can begin work on an initial draft
    letter that could be shared with other operating systems for review
    and comment.  The intent of this letter would be for Guix and other
    operating systems to sign off on and present to the Rust Foundation
    to start a dialog about the trademark policy.

* Guix rebrands Rust and Cargo to conform with the current Rust
  Foundation trademark policy
** Advantages
*** Resolves the Rust trademark policy issue for Guix.
*** No coordination with any other groups is required as Guix can do
    this independently.
*** Other operating systems can take advantage of Guix's efforts to
    rebrand Rust and Cargo.
** Disadvantages
*** Guix would need to do work to evaluate the feasibility of rebranding
    Rust and Cargo.
*** If rebranding is feasible then Guix would need to do the work of
    rebranding Rust and Cargo.  (Hopefully other individuals and groups
    would volunteer to help.)
** Note on rebranding
*** In the FSDG's Trademark section it says "In extreme cases, these
    restrictions may effectively render the program nonfree. It is
    unfair for someone to ask you to remove a trademark from modified
    code if that trademark is scattered all throughout the original
    source.".
    <http://www.gnu.org/distros/free-system-distribution-guidelines.html>

# Summary

Comment and feedback are appreciated.  I may have missed other
interesting ways of moving forward with the Rust Foundation trademark
policy issue.

I seems like the ideal approach is for a group of operating system
together to ask the Rust Foundation to change it's trademark policy.
This approach was brought up by Ludovic Courtès previously in this
tread.

Another interesting option is for Guix to rebrand the versions of Rust
and Cargo that it is distributing.  Guix can do this independently of
any other group.  However the feasibility of rebranding Rust and Cargo
needs to be assessed.

Re: Rust freedom issue claim

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 7834 bytes --]

On 2021-06-12, Bone Baboon wrote:
> Ludovic Courtès writes:
>> Bone Baboon <bone.baboon@disroot.org> skribis:

...

> There are several options for how to move forward with the issue of the
> Rust Foundation trademark policy.
>
> # Passive Approaches

...

> * Do nothing
> ** Advantages
> *** No action needed by Guix.
> *** The trademark policy may not be enforceable see notes below.
> ** Disadvantages
> *** The Rust Foundation could try to enforce it's trademark policy.
> ** Notes on trademark enforcement
> *** "A trademark that is popularly used to describe a product or service
>     (rather than to distinguish the product or services from those of
>     third parties) is sometimes known as a genericized trademark. If
>     such a mark becomes synonymous with that product or service to the
>     extent that the trademark owner can no longer enforce its
>     proprietary rights, the mark becomes generic."
>     <https://en.wikipedia.org/wiki/Trademark>
>     <https://en.wikipedia.org/wiki/Genericized_trademark>
> *** "Once trademark rights are established in a particular jurisdiction,
>     these rights are generally only enforceable in that jurisdiction, a
>     quality which is sometimes known as "territoriality". However, there
>     is a range of international trademark laws and systems which
>     facilitate the protection of trademarks in more than one
>     jurisdiction." 
>     <https://en.wikipedia.org/wiki/Trademark>
> *** "Trademarks rights must be maintained through actual lawful use of
>     the trademark. These rights will cease if a mark is not actively
>     used for a period of time, normally five years in most
>     jurisdictions. In the case of trademark registration, failure to
>     actively use the mark in the lawful course of trade, or to enforce
>     the registration in the event of infringement, may also expose the
>     registration itself to become liable for an application for the
>     removal from the register after a certain period of time on the
>     grounds of "non-use".
>     <https://en.wikipedia.org/wiki/Trademark>

This really seems plausible; there are so many distributions
distributing rust; I'm not sure how enforceable or even desireable such
an outcome would be for the rust community to start taking legal action
against other free software projects... it would certainly look poorly
in the community at large.

The issue around firefox/icecat/iceweasel/icedove/etc. definitely
triggered a lot of WTF response from the community at large...


> # Active Approaches
>
> * Guix alone asks Rust Foundation for permission to use trademarks
> ** Advantages
> *** No need to coordinate with other operating systems.
> ** Disadvantages
> *** The problem remains for all other operating systems.
> *** The Rust Foundation may not give Guix permission.

A bigger disadvantage to having to ask for permission is that the
permission is not transitive; anyone producing a product using rust on
guix would also then have to ask for permission individually...

In Debian, there are clauses in the free software guidelines about this;
is there a correlary with GNU or FSF?

  https://www.debian.org/social_contract#guidelines

  7. Distribution of License

  The rights attached to the program must apply to all to whom the program
  is redistributed without the need for execution of an additional license
  by those parties.

  8. License Must Not Be Specific to Debian

  The rights attached to the program must not depend on the program's
  being part of a Debian system. If the program is extracted from Debian
  and used or distributed without Debian but otherwise within the terms
  of the program's license, all parties to whom the program is
  redistributed should have the same rights as those that are granted in
  conjunction with the Debian system.

Although it's tricky due to the intersection of "licenses", "rights" and
"trademarks"... the ability to use a trademark does typically require
some form of license, as i understand it... layman opinion, not a
lawyer, etc.


> * Guix alone asks the Rust Foundation to change it's trademark policy
> ** Advantages
> *** No need to coordinate with other operating systems.
> ** Disadvantages
> *** The Rust Foundation may not change it's trademark policy.

> * A group of operating system together ask the Rust Foundation to change
>   it's trademark policy
> ** Advantages
> *** More likely that the Rust Foundation will consider the request of a
>     group of operating systems instead of request by just Guix.
> ** Disadvantages
> *** The Rust Foundation may not change it's trademark policy.
> ** Notes
> *** Ludovic Courtès proposed this approach previously in this
>     thread. "If the Rust trademark turns out to be a concern, distros
>     should try hard, collectively, to resolve it through dialog with
>     Rust Foundation people."
> *** If this is the desired approach I can begin work on an initial draft
>     letter that could be shared with other operating systems for review
>     and comment.  The intent of this letter would be for Guix and other
>     operating systems to sign off on and present to the Rust Foundation
>     to start a dialog about the trademark policy.

There is a tension between distro package managers and language-specific
package managers; I'm not so sure the advocates for language-specific
package managers would mind forcing to use their tooling...
unfortuantely.

That said, we're stronger as a larger (hopefully mostly united) front!


> * Guix rebrands Rust and Cargo to conform with the current Rust
>   Foundation trademark policy
> ** Advantages
> *** Resolves the Rust trademark policy issue for Guix.
> *** No coordination with any other groups is required as Guix can do
>     this independently.
> *** Other operating systems can take advantage of Guix's efforts to
>     rebrand Rust and Cargo.
> ** Disadvantages
> *** Guix would need to do work to evaluate the feasibility of rebranding
>     Rust and Cargo.
> *** If rebranding is feasible then Guix would need to do the work of
>     rebranding Rust and Cargo.  (Hopefully other individuals and groups
>     would volunteer to help.)
> ** Note on rebranding
> *** In the FSDG's Trademark section it says "In extreme cases, these
>     restrictions may effectively render the program nonfree. It is
>     unfair for someone to ask you to remove a trademark from modified
>     code if that trademark is scattered all throughout the original
>     source.".
>     <http://www.gnu.org/distros/free-system-distribution-guidelines.html>

So... switch to calling everything unoxidized? :)


> # Summary
>
> Comment and feedback are appreciated.  I may have missed other
> interesting ways of moving forward with the Rust Foundation trademark
> policy issue.
>
> I seems like the ideal approach is for a group of operating system
> together to ask the Rust Foundation to change it's trademark policy.
> This approach was brought up by Ludovic Courtès previously in this
> tread.

I can probably help get in touch with folks on Debian's rust packaging
team(s) if that would be helpful.


> Another interesting option is for Guix to rebrand the versions of Rust
> and Cargo that it is distributing.  Guix can do this independently of
> any other group.  However the feasibility of rebranding Rust and Cargo
> needs to be assessed.

I'm somewhat curious (and partly terrified) how this might all pan out;
not a direct user of rust but it seems to be working it's bits into all
sorts of places and not something that can reasonably be ignored...

Rust, more than just a bootstrapping challenge!


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Rust freedom issue claim

[Leo Famulari]

On Sat, Jun 12, 2021 at 02:49:21PM -0400, Bone Baboon wrote:
> Contents:
> * Passive Approaches

I definitely think a passive approach is best, unless the owners of the
Rust trademark are taking actions that preclude it. Have they given us
any reason to think that we need to do something about this issue? Many
times, the best course of action is to do nothing.

Re: Rust freedom issue claim

[Bone Baboon]

Leo Famulari writes:

> On Sat, Jun 12, 2021 at 02:49:21PM -0400, Bone Baboon wrote:
>> Contents:
>> * Passive Approaches
>
> I definitely think a passive approach is best, unless the owners of the
> Rust trademark are taking actions that preclude it. Have they given us
> any reason to think that we need to do something about this issue? Many
> times, the best course of action is to do nothing.

What makes it timely to be talking about the Rust trademark policy is
that the Rust Foundation was recently created.

<https://blog.mozilla.org/en/mozilla/mozilla-welcomes-the-rust-foundation/>
says "The Rust Foundation will be the home of the popular Rust
programming language that began within Mozilla.".

<https://foundation.rust-lang.org/posts/2021-02-08-hello-world/> says
"Mozilla, the original home of the Rust project, has transferred all
trademark ... to the Rust Foundation.".

As the Rust Foundation is new there is the potential that they will be
open to changing the trademark policy.  This would make them look good
in free libre open source software communities.  It would also allow
them to demonstrate their independence from the Mozilla Foundation.

I am not currently aware of any actions being taken by the Rust
Foundation to enforce it's trademarks.

Re: Rust freedom issue claim

[Bone Baboon]

Ludovic Courtès writes:
> Thanks for the detailed study and summary!

The conversation about the Rust Trademark policy issue has been
happening on several mailing lists and in different IRC channels.  I
decided to write a new summary that bringing it all together, adds new
information and cleans it up.

The summary is located at
<https://bonebaboon.tilde.site/rust-trademark-policy-issue/>.

The Git repository for the summary that can be cloned is at
<https://bonebaboon.tilde.site/git/rust-trademark-policy-issue.git>.

There is also a website for browsing the source code at
<https://bonebaboon.tilde.site/git/rust-trademark-policy-issue/>.