unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Vagrant Cascadian <vagrant@debian.org>
To: "Bone Baboon" <bone.baboon@disroot.org>,
	"Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Rust freedom issue claim
Date: Sat, 12 Jun 2021 14:31:06 -0700	[thread overview]
Message-ID: <87tum222jp.fsf@yucca> (raw)
In-Reply-To: <87im2i7wb2.fsf@disroot.org>

[-- 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 --]

  reply	other threads:[~2021-06-12 21:32 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
2021-06-12 21:31         ` Vagrant Cascadian [this message]
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=87tum222jp.fsf@yucca \
    --to=vagrant@debian.org \
    --cc=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).