From: Bone Baboon <bone.baboon@disroot.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Rust freedom issue claim
Date: Sat, 12 Jun 2021 14:49:21 -0400 [thread overview]
Message-ID: <87im2i7wb2.fsf@disroot.org> (raw)
In-Reply-To: <87fsxsh5p9.fsf@gnu.org>
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.
next prev parent reply other threads:[~2021-06-12 18:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-24 3:24 Rust freedom issue claim Bone Baboon
2021-05-25 2:01 ` Bone Baboon
2021-05-26 14:32 ` Ludovic Courtès
2021-05-26 15:14 ` Pjotr Prins
2021-05-27 14:47 ` Joshua Branson
2021-05-27 16:28 ` Pjotr Prins
2021-05-27 20:23 ` Jack Hill
2021-06-03 18:38 ` Bone Baboon
2021-06-08 13:00 ` Ludovic Courtès
2021-06-12 18:49 ` Bone Baboon [this message]
2021-06-12 21:31 ` Vagrant Cascadian
2021-06-13 18:20 ` Leo Famulari
2021-06-15 12:38 ` Bone Baboon
2021-06-19 3:21 ` Bone Baboon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87im2i7wb2.fsf@disroot.org \
--to=bone.baboon@disroot.org \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).