Re: newbe question

[Bone Baboon]

Adam Kandur via Development of GNU Guix and the GNU System distribution. writes:

> hi everyoone! is there any example of packed racket code?

The Guix repository has a file for racket packages
`/gnu/packages/racket.scm`.  You can look at this file here
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/racket.scm
or by cloning the git repository `git clone
https://git.savannah.gnu.org/git/guix.git` and inspecting the files it
contains locally.

The way I found the location of this file was by running `guix search
racket` and in the output I saw a package for racket and
racket-minimal.  Then looking at the information on these packages there
is a field labeled location.  Using racket minimal as an example it says
"location:  gnu/packages/racket.scm:67:2".  The
"gnu/packages/racket.scm" corresponds with the path of the file in the
Guix repository.  There is even line and column information provided with 
"67:2".

Free software telemetry and the Guix System

[Bone Baboon]

What types of telemetry in free software programs are compatible with
the Guix System?

This is a general question but Audacity is a current example of a free
software program that is in the process of introducing telemetry to some
degree.  It does not look like Audacity has implemented telemetry yet.
Here are two links that provide further information.

https://github.com/audacity/audacity/pull/835

https://github.com/audacity/audacity/discussions/889

GPU compatibility with Linux-libre

[Bone Baboon]

This message has two parts about GPU compatibility with Linux-libre.
1) Manual Warning
2) Summary

# Manual Warning

I originally posted the message below on the help mailing list.  It is
reposted here for two reasons.

* It was suggested that the help mailing list may not be the correct
  mailing list. 
  https://lists.gnu.org/archive/html/help-guix/2021-04/msg00229.html

* Someone else recently had the same issue with GPU compatibility.
  https://issues.guix.gnu.org/issue/48343

>From the original message:

```
I found the Hardware Considerations section of the Guix manual very
helpful.  I was prepared for the issue of WiFi device compatibility.
However I was surprised by GPU compatibility.

I think it would be helpful to have a warning about GPU compatibility.
This would help someone who is looking at buying a computer by bringing
GPU compatibility to their attention.

I found the WiFi device warning with specific hardware that is known to
work very helpful.  Maybe an equivalent could be done for GPUs

...

I appreciate that this extra warning may discourage some people from
trying Guix.  I think it would still be good to warn people about
potential problems so that they are not surprised.
```

# Summary

I have been sharing a link to "GPU compatibility with Linux-libre"
https://lists.gnu.org/archive/html/help-guix/2021-04/msg00220.html on
the Guix mailing lists and in #guix when people were asking for help
about getting a graphical environment setup in Guix. The feedback I have
received is that it was helpful.  I would appreciate any correction or
additions as I do not want to misinform people.

Re: What’s next?

[Bone Baboon]

Ludovic Courtès writes:
> So, now that 1.3.0 is out the door, what’s next?!

> What’s your wish list?  What do you feel an urge to hack on?  :-)

There are two improvements on my Guix wish list.

1) Make the core parts of Guix reproducible
** I do not know if this fits into the 4-6 month time frame mentioned.

2) Alternative kernel
** Motivated by 1.
** Longer term beyond 6 months.

1) Make the core parts of Guix reproducible

Many core parts of Guix are not reproducible.  If more core parts of
Guix were reproducible it would benefit all Guix users.

There are several core parts of Guix that are not reproducible
including:

* Linux-libre
  https://issues.guix.gnu.org/24028#2
  Note: I like what the Linux-libre project is doing.
This is likely a result of Linux not being reproducible.

* Many guix-*
  https://issues.guix.gnu.org/48487#0

* Guile
  https://issues.guix.gnu.org/48490#0

* nss 3.59 on the master branch
  https://issues.guix.gnu.org/40316#5

* Emacs
  https://issues.guix.gnu.org/35085#7
  Note: A good text editor is important.
nvi, vim and neovim are reproducible for me.
Emacs is more than a text editor and that is a part of why it is
not reproducible. 

2) Alternative kernel

It is important to have a reproducible kernel.  Linux-libre is not
reproducible (see 1 above).  Linux-libre has not been reproducible for
an extended period of time.  Linux-libre not being reproducible was
reported in 2016 .

 provides an interesting
thought exercise.  What free libre kernel would Guix use if Linux was
no longer a viable option?  I do not agree with all their points. The
point on Linux complexity increasing rapidly (13:29-17:56) is the one I
would be most concerned about.

Both Linux-libre not being reproducible and the idea that Linux might
not be viable in the future highlight the importance (and potential
urgency) of having an alternative free libre kernel that Guix can run
on.

It is great that work is already underway to get Guix to run on the Gnu
Hurd microkernel.

I think the design concept of a microkernel make them  more resistant to
the problem of increasing complexity at the kernel level when compared
to monolithic kernels.  With microkernels the increased complexity is
pushes out to user processes.  This allows the user (or their operating
system) to choose the level of complexity.

 is a listing of microkernel projects.

Re: What’s next?

[Bone Baboon]

Bone Baboon writes:
> 1) Make the core parts of Guix reproducible
>
> Many core parts of Guix are not reproducible.  If more core parts of
> Guix were reproducible it would benefit all Guix users.
>
> There are several core parts of Guix that are not reproducible
> including:
>
> * Linux-libre
>   https://issues.guix.gnu.org/24028#2
>   Note: I like what the Linux-libre project is doing.
>   This is likely a result of Linux not being reproducible.
>
> * Many guix-*
>   https://issues.guix.gnu.org/48487#0
>
> * Guile
>   https://issues.guix.gnu.org/48490#0
>
> * nss 3.59 on the master branch
>   https://issues.guix.gnu.org/40316#5
>
> * Emacs
>   https://issues.guix.gnu.org/35085#7
>   Note: A good text editor is important.
> nvi, vim and neovim are reproducible for me.
>   Emacs is more than a text editor and that is a part of why it is
> not reproducible. 

I have one addition to this.  mariadb is failing to build from source
because of a failing test suite.  As mariadb is a dependency of
diffoscope this is causing diffoscope's build from source to also fail.
diffoscope is a useful tool for gathering information about why a
package is not reproducible.

`guix graph --path diffoscope mariadb` outputs:

```
diffoscope@174
ffmpeg@4.3.2
sdl2@2.0.12
fcitx@4.2.9.8
extra-cmake-modules@5.70.0
qtbase@5.15.2
mariadb@10.5.8
```

More details on how mariadb is failing to build can be seen here
<https://issues.guix.gnu.org/48151#3>.

Re: Freenode Administration

[Bone Baboon]

Bone Baboon writes:
> # IRC alternatives / compliments
>
> Some criteria that I have come up with are:
> * Free software
> * Can be used without a graphical user interface as many GPUs are not
>   compatible with Linux-libre and can not run Xorg or Wayland window
>   managers / desktops.
> * Peer to peer as a way to avoid the issue of a centralized
>   administrator changing their administration in undesirable ways. 

One more criteria.  Is an Emacs client available.  Inspired by
<https://logs.guix.gnu.org/guix/2021-05-19.log#183825>.

> Some alternatives that come to mind that would need further
> investigation include the following.  I do not know if any of these meet
> all the criteria I mention above.
>
> * Scuttlebutt
> ** https://scuttlebutt.nz/
> ** Is there a client that works without a graphical environment?
>
> * DAT
> ** Are there messaging application for DAT?
> ** https://www.datprotocol.com/
>
> * IPFS
> ** Are there messaging application for IPFS?
> ** https://ipfs.io/
>
> * Jami
> ** https://jami.net/
> ** Swarms specifically
> *** 
> https://jami.net/swarm-introducing-a-new-generation-of-group-conversations/
> *** Swarms are fully distributed and peer-to-peer text conversations,
> with a potentially unlimited number of participants.
> **  on Freenode #jami said:
>"https://github.com/AmarOk1412/jami-cli/ no video/audio support but
>support swarm"
>
> * RetroShare
> ** http://retroshare.cc/
> ** Is there a client that works without a graphical environment?

Here is what I have discovered after some further preliminary
exploration.  I have added XMPP and Tox.

## Scuttlebutt

<https://scuttlebutt.nz/>

* Free libre - yes
* Peer to peer - yes
* Non graphical client - yes
** scat <https://github.com/stripedpajamas/scat>
** scatzero <https://github.com/stripedpajamas/scatzero>
** scuttle-chat <https://github.com/clevinson/scuttle-chat>
* IRC capabilities - ?
* Emacs client - no

## DAT

<https://www.datprotocol.com/>

* Free libre - yes
* Peer to peer - yes
* Non graphical client - yes
** cabal-cli <https://github.com/cabal-club/cabal-cli>
* IRC capabilities - yes
** <https://cabal.chat/>
* Emacs client - no

## IPFS

<https://ipfs.io/>

* Free libre - yes
* Peer to peer - yes
* Non graphical client - prototype
** orbit-textui <https://github.com/orbitdb/orbit-textui>
*** prototype
* IRC capabilities - ?
* Emacs client - no

## Jami

<https://jami.net/>

* Free libre - yes
* Peer to peer - yes
* Non graphical client - yes
** jami-cli <https://github.com/AmarOk1412/jami-cli>
* IRC capabilities - not yet
** Swarm requires more optimizations before pubic channels are added.
** Currently jami-cli has been tested for group of 5 (jami-cli's
   developer devices). 
** A group is invite only currently.
* Emacs client - no

## RetroShare

<https://retroshare.cc/>

* Free libre - yes
* Peer to peer - yes
* Non graphical client - no
* IRC capabilities - yes
* Emacs client - no

## XMPP

<https://xmpp.org/>

* Free libre - yes
* Peer to peer - no
** federated servers
* Non graphical client - yes
** Mcabber <https://mcabber.com/>
** Poezio <https://poez.io/en/>
** Profanity <https://profanity-im.github.io/>
** Aparte <https://github.com/paulfariello/aparte>
* IRC capabilities - yes
* Emacs client - yes
** jabber.el <https://github.com/legoscia/emacs-jabber>

## Tox

<https://tox.chat/>

* Free libre - yes
* Peer to peer - yes
* Non graphical client - yes
** Toxic <https://github.com/JFreegman/toxic>
* IRC capabilities - not currently
** Would get IRC capabilities if this gets added
   <https://github.com/TokTok/c-toxcore/blob/ngc/docs/DHT-Group-Chats.md> 
* Emacs client - no

Re: Freenode Administration

[Bone Baboon]

François writes:
>> # IRC alternatives / compliments
>
> On alternatives you missed Matrix[1] which is federated (like email)
> and have several clients includig weechat for text-based interface.
>
> Several people (and I am one of them) already uses Matrix clients to
> access IRC networks with bridges (which libera.chat does not already
> have but work is in progress).
>
> There is even some ongoing work ([2], [3]) on making Matrix more
> peer-to-peer but it is still completely experimental.
>
>
> [1]: https://matrix.org
> [2]: 
> https://matrix.org/blog/2021/05/06/introducing-the-pinecone-overlay-network
> [3]: https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix

## Matrix



* Free libre - yes
* Peer to peer - no yet, currently federated servers
** 
** 
* Non graphical client - yes
** 
** 
** 
** 
* IRC capabilities - yes
* Emacs client - yes
** 

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
##r...@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.

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

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

" 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: Freenode Administration

[Bone Baboon]

raingloom writes:
> I don't think we can package NPM stuff.
>
> Both the Dat and SSB cores have non-JavaScript implementations AFAIK,
> but Cabal itself is JavaScript-only and so are all the SSB clients that
> I've seen, but admittedly I haven't looked at the state of the SSB
> ecosystem in a few months, so maybe that has changed.
> The various sbot implementations do not count as proper clients.

I have added information on the implementation languages for clients to
this tread.

Here is information on servers for XMPP and Matrix.

# XMPP Servers

* https://github.com/ortuman/jackal
** Implemented in Go

* https://github.com/maranda/metronome
** Implemented in Lua

* https://github.com/bjc/prosody
** Implemented in Lua

* https://github.com/igniterealtime/Openfire
** Implemented in Java

# Matrix Servers

* https://github.com/matrix-org/synapse
** Implemented in Python 3

* https://github.com/matrix-org/dendrite
** Implemented in Go

** https://gitlab.com/famedly/conduit
** Implemented in Rust

* https://github.com/matrix-construct/construct
** Implemented in C++

* https://gitlab.com/plasmahs/plasma
** Implemented in Elixir

* https://gitlab.com/mascarene/mascarene
** Implemented in Scala

* https://gitlab.com/ma1uta/jeon
** Implemented in Java

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
> ##r...@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.
>
> " the trademarks are now owned by the Rust Foundation
> rather than Mozilla, but the Rust Media Guide has not been updated to
> reflect this"
>
> " bone-baboon: https://github.com/rust-lang/rust/issues/53287
> is closed by https://github.com/rust-lang/rust/pull/59748";
>
> " 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: Freenode Administration

[Bone Baboon]

Bone Baboon writes:
> ## Matrix

This is supplemental information in regards to raingloom's comment on
implementation languages.

>
> <https://matrix.org>
>
> * Free libre - yes
> * Peer to peer - no yet, currently federated servers
> ** 
> <https://matrix.org/blog/2021/05/06/introducing-the-pinecone-overlay-network>
> ** <https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix>
> * Non graphical client - yes
> ** <https://github.com/8go/matrix-commander>

matrix-commander is implemented in Python 3.

> ** <https://github.com/saadrushd/matrixcli>

matrixcli is implemented in Python 3.

> ** <https://github.com/tulir/gomuks>

gomuks is implemented in Go.  The Readme says "Basic usage is possible,
but expect bugs and missing features".

> ** <https://github.com/poljar/weechat-matrix>

weechat-matrix is support Python 2 and 3.  The Readme says
"weechat-matrix is in maintenance mode". 

<https://github.com/poljar/weechat-matrix-rs> is implemented in Rust.
The Readme says "This project is a work in progress".


> * IRC capabilities - yes
> * Emacs client - yes
> ** <https://github.com/alphapapa/matrix-client.el>

matrix-client.el is implemented in Emacs Lisp.

Re: Freenode Administration

[Bone Baboon]

Bone Baboon writes:
> Here is what I have discovered after some further preliminary
> exploration.  I have added XMPP and Tox.

This is supplemental information in regards to raingloom's comment on
implementation languages.

> ## Scuttlebutt
>
> <https://scuttlebutt.nz/>
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** scat <https://github.com/stripedpajamas/scat>

scat is implemented in JavaScript.

> ** scatzero <https://github.com/stripedpajamas/scatzero>

scatzero is implemented in JavaScript.

> ** scuttle-chat <https://github.com/clevinson/scuttle-chat>

scuttle-chat is implemented in Rust.  The Readme says "Work in
Progress!!".

> * IRC capabilities - ?
> * Emacs client - no
>
> ## DAT
>
> <https://www.datprotocol.com/>
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** cabal-cli <https://github.com/cabal-club/cabal-cli>

cabal-cli is implemented in JavaScript.

> * IRC capabilities - yes
> ** <https://cabal.chat/>
> * Emacs client - no
>
> ## IPFS
>
> <https://ipfs.io/>
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - prototype
> ** orbit-textui <https://github.com/orbitdb/orbit-textui>

orbit-textui is implemented in JavaScript.

> *** prototype
> * IRC capabilities - ?
> * Emacs client - no
>
> ## Jami
>
> <https://jami.net/>
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** jami-cli <https://github.com/AmarOk1412/jami-cli>

jami-cli is implemented in Rust.

> * IRC capabilities - not yet
> ** Swarm requires more optimizations before pubic channels are added.
> ** Currently jami-cli has been tested for group of 5 (jami-cli's
>developer devices). 
> ** A group is invite only currently.
> * Emacs client - no
>
> ## RetroShare
>
> <https://retroshare.cc/>
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - no

RetroShare is implemented in C++.

> * IRC capabilities - yes
> * Emacs client - no
>
> ## XMPP
>
> <https://xmpp.org/>
>
> * Free libre - yes
> * Peer to peer - no
> ** federated servers
> * Non graphical client - yes
> ** Mcabber <https://mcabber.com/>

Mcabber is implemented in C.

> ** Poezio <https://poez.io/en/>

Poezio is implemented in Python 3.

> ** Profanity <https://profanity-im.github.io/>

Profanity is implemented in C.

> ** Aparte <https://github.com/paulfariello/aparte>

Aparte is implemented in Rust.

> * IRC capabilities - yes
> * Emacs client - yes
> ** jabber.el <https://github.com/legoscia/emacs-jabber>

jabber.el is implemented in Emacs Lisp.

>
> ## Tox
>
> <https://tox.chat/>
>
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** Toxic <https://github.com/JFreegman/toxic>

Toxic is implemented in C.

> * IRC capabilities - not currently
> ** Would get IRC capabilities if this gets added
><https://github.com/TokTok/c-toxcore/blob/ngc/docs/DHT-Group-Chats.md> 
> * Emacs client - no

Re: Freenode Administration

[Bone Baboon]

Bone Baboon writes:
> # IRC alternatives / compliments
>
> Some criteria that I have come up with are:
> * Free software
> * Can be used without a graphical user interface as many GPUs are not
>   compatible with Linux-libre and can not run Xorg or Wayland window
>   managers / desktops.
> * Peer to peer as a way to avoid the issue of a centralized
>   administrator changing their administration in undesirable ways. 

Here is one more criteria.  This would be important if being inclusive
of a diverse group of people is desirable.

* Works with slow and low bandwidth internet connections.

Some examples are dial up modems, mesh networks and satellite.

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.


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.


The Free Software Foundation's licensing team will be taking a serious
look at the Rust trademark policy issue (no time frame was given).


After reading further on the topic and receiving feedback I have written
an update to my understanding of the Rust trademark policy.

Re: Rust freedom issue claim

[Bone Baboon]

Ludovic Courtès writes:
> Bone Baboon  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/msg0.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.
***

Telemetry on by default kitty

[Bone Baboon]

Guix provides kitty a terminal emulator as a package.

Kitty has telemetry on by default.  See this issue on the kitty
repository for further information:


The issue was closed by the lead developer of the project without
addressing the concern raised.  It does not look like this is something
that is going to be fixed upstream.

The kitty telemetry is not a core part of kitty's functionality.  The
kitty lead developer said in that issue thread that the telemetry is to
notify users of available updates.  Further source code review would be
required to verify that is the only thing the telemetry is doing.  As
the lead developer did not provide much in the way of details when asked
about the telemetry in the issue thread.  It seems that the methods Guix
provides would be better suited for letting users know about updates. 

What do other people think about this in the context of the Free System
Distribution Guidelines?

```
No Malware
The distro must contain no DRM, no back doors, and no spyware.
```


How should the issue of kitty's telemetry on be default be addressed?

Re: Telemetry on by default kitty

[Bone Baboon]

Tobias Geerinckx-Rice writes:

> Bone Baboon 写道：
>> What do other people think about this in the context of the Free
>> System
>> Distribution Guidelines?
>
> This is not a point of discussion.  Telemetry or ‘phoning home’ for
> updates must be opt-in if possible or disabled entirely otherwise.

The telemetry is not opt-in or disabled upstream.

> Would you care to submit a patch?

Should the patch be to remove the kitty package?

Re: Telemetry on by default kitty

[Bone Baboon]

Leo Prikler writes:
> Am Samstag, den 12.06.2021, 23:44 +0200 schrieb Tobias Geerinckx-Rice:
>> Bone Baboon 写道：
>> > Should the patch be to remove the kitty package?
>> 
>> No.  The telemetry.

While I appreciate the invitation to write a patch for kitty's telemetry
I am not going to write that patch.  My rational is explained below.

> If I read terminals.scm, we already disable the telemetry in kitty:
>
>> (invoke "python3" "setup.py" "linux-package"
>> ;; Do not phone home.
>> "--update-check-interval=0"
>
> @Bone: Did you notice any other telemetry during your further code
> review (or are you still in the process of reviewing the code)?  If
> not, please try to cross-check Guix sources to see whether we already
> disable telemetry, so as to not cause unwarranted panic :)

It appears problematic to patch kitty's telemetry for several reasons.

kitt's lead developer did not explaining kitty's telemetry when asked
for further information.  It is not clear if kitty performs other kinds
of telemetry as well.  It would seem that the only way to make sure that
all undesirable telemetry is removed would be a full review of kitty's
source code.

kitty's lead developer thinks that the telemetry in kitty is
acceptable.  So there would need to be an ongoing review of commits to
the kitty source code to ensure that undesirable telemetry is not added
in the future.

I have never been a kitty user and seeing the position kitty's lead
developer holds on telemetry I will not be a kitty user in the future.
I will not be reviewing the kitty source code or future commits to the
kitty source code.

FIGlet licensing information

[Bone Baboon]

The TOIlet website says: "The TOIlet project attempts to create a free
replacement for the FIGlet utility.".


Guix has a package for FIGlet.  Guix does not have a package for TOIlet.

I looked into this and contacted FIGlet with the suggestion to improve
the copyright and licensing information in the comment headers of the
FIGlet source code files.

I have attached the content of the message I sent to FIGlet as it
includes further information.

Contents
* Summary
* Background
* Spot Check
* Conclusion

# Summary

It would be helpful for packagers and users of FIGlet if all FIGlet
source code files had a header comment providing information on
copyright as well as licensing information.  With the licensing
information hopefully being free libre licenses.

# Background

I saw that the TOIlet website says: "The TOIlet project attempts to
create a free replacement for the FIGlet utility.".


The TOIlet website listed this IRC channel #libcaca@Freenode.  I asked
for further information about FIGlet being nonfree software in that
channel and this link was shared. 


# Spot Check

I used the files mentioned in
 to
do an informed spot check of files in the FIGlet version 2.2.5
repository.
 

 says to "Add copyright and licensing
information to each file".  

There were many files in the spot check that could be improved:

* Makefile
** Copyright information but no license information.
* chkfont.c
** Authors mentioned but no license information.
* figlist
** Authors mentioned but no license information.
* showfigfonts
** Authors mentioned but no license information.
* figfont.txt
** Copyright information but license information appears more
   restrictive than LICENSE.
* figlet.6
** Copyright information but license information appears more
   restrictive than LICENSE.
* All the files with .flf extension in the fonts directory
** Missing license information or the license information appears more
   restrictive than LICENSE.

# Conclusion

Given that many of the files in the spot check could be improved it
make sense for a review of all of the source code files in the FIGlet
source code.  This would identify any other source code files that would
benefit from having their copyright and licensing information improved.

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
.

The Git repository for the summary that can be cloned is at
.

There is also a website for browsing the source code at
.

Re: Telemetry on by default kitty

[Bone Baboon]

Leo Prikler writes:
> If I read terminals.scm, we already disable the telemetry in kitty:
>
>> (invoke "python3" "setup.py" "linux-package"
>> ;; Do not phone home.
>> "--update-check-interval=0"

> @Bone: Did you notice any other telemetry during your further code
> review (or are you still in the process of reviewing the code)?  If
> not, please try to cross-check Guix sources to see whether we already
> disable telemetry, so as to not cause unwarranted panic :)

I have followed up with kitty's use of telemetry by opening an issue on
the kitty repository.

https://github.com/kovidgoyal/kitty/issues/3802

I suggested that all the uses of telemetry be documented and that there
be a configuration to disable all telemetry.

My interpretation of the response is that the update checking telemetry
is the only telemetry and that the way to disable it is how it is being
done in terminals.scm.

Audacity has new administration

[Bone Baboon]

# Contents

* Audacity's new administration
* Controversial Changes to Audacity
* Audacity Forks
* Guix and Audacity

# Audacity's new administration

Audacity has new administration.  Based on these announcements Audacity
is now part of Muse Group.

May 3 2021 this announcement was made on Audacity's website


April 30 2021 this announcement was made by the new lead of audacity:

Invidious link

YouTube link


# Controversial Changes to Audacity

Muse Group has made several controversial changes to Audacity.

Three controversial changes were:

* The introduction of telemetry
  
  

* The introduction of a contributor license agreement
  

* A new privacy policy
  
  
  
  

The introduction of telemetry has been discussed here
.

# Audacity Forks

The controversial changes to Audacity by Muse Group has motivated
several Audacity forks.

One example of a fork is .
That fork gives this rational for it's existence
.
Which includes some of the links in the to the Controversial Changes to
Audacity section above.

It is probably to early to tell which if any of the Audacity forks are
going to be maintained over an extended period of time.

# Guix and Audacity

Guix packages the 2.4.2 version of Audacity.

Looking at /gnu/packages/audio.scm the source code repository Guix uses
for audacity is  which is now
controlled by Muse Group.

Based on Audacity release information
 version
2.4.2 was released on 26 June 2020.  This is before Muse Group acquired
administrative control of Audacity some time between April 30 2021 and
May 3 2021.  So no action is currently required by Guix in regards to
it's Audacity package.

The most current version of Audacity before Muse Group acquired
administrative control of Audacity was version 3.0.2 which released on
19 April 2021.

Before the next update of the version of Audacity that Guix packages it
would probably be a good idea to reassess the situation with Muse
Group's Audacity and the Audacity forks.

cowsay could attract copyright and trademark enforcement action

[Bone Baboon]

cowsay has many questionable files that could attract copyright and
trademark enforcement action.  For further details see the pull
requested linked below.

Guix packages cowsay.  /gnu/packages/games.scm says that the source code
repository used is .
In that repository's CONTRIBUTING.md it says "Issues and pull requests
on that repository will be ignored.".  I submitted a pull request
.  I expect that
it will be ignored.

I have also found a fork of cowsay
 that claims to be maintained.
I have submitted a pull request to it as well.
 

It would be good to have this issue addressed upstream.  I have just
submitted these pull requests.  I will provide an update if either pull
request is merged (modified or unmodified).  If neither repository makes
any changes to address these questionable files then it may make sense
for Guix to patch the cowsay package.

Re: Audacity has new administration

[Bone Baboon]

Bone Baboon writes:
> * A new privacy policy
>   <https://github.com/audacity/audacity/issues/1213>
>   <https://github.com/audacity/audacity/issues/1236>
>   <https://github.com/audacity/audacity/issues/1232>
>   <https://github.com/audacity/audacity/discussions/1225>

My initial message in this email tread did not clearly communicate what
the issues with Muse Group's new privacy policy for Audacity are.

The two main issues are the on by default telemetry and that Audacity
can no longer be used for any purpose contradicting freedom 0.

# On by default telemetry

On by default telemetry is being introduced to Audacity.  This does not
comply with the No Malware section of the FSDG.
<https://www.gnu.org/distros/free-system-distribution-guidelines.html>

The on by default telemetry collects IP address information, system
information and Audacity version information.
<https://github.com/audacity/audacity/discussions/1225#discussioncomment-967178>
<https://github.com/audacity/audacity/discussions/1225#discussioncomment-966782>
<https://www.audacityteam.org/about/desktop-privacy-notice/>

# Freedom 0

Audacity can no longer be used for any purpose.  Section 3 of the Muse
Group's new privacy policy for Audacity
<https://www.audacityteam.org/about/desktop-privacy-notice/> says:

> 3 Minors
>
> 1 The App we provide is not intended for individuals below the age
> of 13. If you are under 13 years old, please do not use the App.

This age restriction contradicts freedom 0.
<http://www.gnu.org/philosophy/free-sw.en.html>

> The freedom to run the program as you wish, for any purpose
> (freedom 0).

This age restriction also contradicts Audacity's license which is the
GPL version 2
<https://github.com/audacity/audacity/blob/master/LICENSE.txt> 
says:

> The act of running the Program is not restricted

Re: Audacity has new administration

[Bone Baboon]

Giovanni Biscuolo writes:
>> * A new privacy policy
>
> That's relevant only for people using telemetry (off by default); AFAIU
> privacy policies are not covered by FSDG: am I wrong?

Muse Group's new privacy policy for Audacity has added telemetry on by
default.  For more details see:


> I'm not following discussions on GitHub on telemetry but AFAIU the
> situation has not changed since we had the above mentioned discussions:
> am I wrong?

When telemetry in Audacity was discussed previously here

Muse Group's telemetry policy for Audacity was that the telemetry be off
by default.  However Muse Group's new privacy policy introduces on by
default telemetry.

For more details see:


> In general, we can take as granted that if we find a package in Guix
> with telemetry enabled by default we can consider it a bug a file a
> proper bug report so it can be fixed if possible or the package removed
> if not.

Guix's current package of Audacity does not have telemetry on by
default.

Muse Group is aware of the issue of telemetry on by default and it
appears that they are going to proceed with telemetry on by default in
future versions of Audacity.

>> # Guix and Audacity
>>
>> Before the next update of the version of Audacity that Guix packages
>> it would probably be a good idea to reassess the situation with Muse
>> Group's Audacity and the Audacity forks.
>
> I think the situation it's already clear enough to agree there is no
> issue with the introduction of optional telemetry in Aucacity in
> particular

Muse Group's new privacy policy for Audacity has added telemetry on by
default and an age restriction that contradicts freedom 0 and Audacity's
GPL version 2 license.  For more details see:

Re: cowsay could attract copyright and trademark enforcement action

[Bone Baboon]

Bone Baboon writes:

> cowsay has many questionable files that could attract copyright and
> trademark enforcement action.  For further details see the pull
> requested linked below.
>
> Guix packages cowsay.  /gnu/packages/games.scm says that the source code
> repository used is <https://github.com/tnalpgge/rank-amateur-cowsay>.
> In that repository's CONTRIBUTING.md it says "Issues and pull requests
> on that repository will be ignored.".  I submitted a pull request
> <https://github.com/tnalpgge/rank-amateur-cowsay/pull/4>.  I expect that
> it will be ignored.
>
> I have also found a fork of cowsay
> <https://github.com/cowsay-org/cowsay> that claims to be maintained.
> I have submitted a pull request to it as well.
> <https://github.com/cowsay-org/cowsay/pull/16> 
>
> It would be good to have this issue addressed upstream.  I have just
> submitted these pull requests.  I will provide an update if either pull
> request is merged (modified or unmodified).  If neither repository makes
> any changes to address these questionable files then it may make sense
> for Guix to patch the cowsay package.

In this response to the pull request I submitted about the
questionable files in the cowsay repository
<https://github.com/tnalpgge/rank-amateur-cowsay/pull/4#issuecomment-878092487>
apjanke is requesting feedback.

> If there are any actual IP lawyers, relevant IP owners, or
> distributions who redistribute cowsay who would like to weigh in on
> this, I'd definitely like to hear what you have to say.

For those who want to respond to apjanke but do not have or do not
want to use a GitHub account I can link this email thread in the
discussion about the pull request.

Re: cowsay could attract copyright and trademark enforcement action

[Bone Baboon]

Leo Famulari writes:

> On Sun, Jul 11, 2021 at 10:56:33PM -0400, Bone Baboon wrote:
>> cowsay has many questionable files that could attract copyright and
>> trademark enforcement action.
>
> I doubt it. Many of these files have been in the cowsay source code
> since 1999 (apparently), and at least since 2004, according to
> archive.org:
>
> https://web.archive.org/web/20040404080800/http://www.nog.net/~tony/warez/cowsay.shtml

Thanks for sharing that.

I would like to point out that the situation is not static as the
ownership of trademark and copyright can change over time and the new
owners may choose to behave differently.

A directly relevant example is the Star Wars cowsay
files. <https://en.wikipedia.org/wiki/Star_Wars> says that Lucasfilm
Ltd. the owners of the Star Wars franchise was acquired by Disney.

Re: cowsay could attract copyright and trademark enforcement action

[Bone Baboon]

Bone Baboon writes:

> cowsay has many questionable files that could attract copyright and
> trademark enforcement action.  For further details see the pull
> requested linked below.
>
> Guix packages cowsay.  /gnu/packages/games.scm says that the source code
> repository used is <https://github.com/tnalpgge/rank-amateur-cowsay>.
> In that repository's CONTRIBUTING.md it says "Issues and pull requests
> on that repository will be ignored.".  I submitted a pull request
> <https://github.com/tnalpgge/rank-amateur-cowsay/pull/4>.  I expect that
> it will be ignored.
>
> I have also found a fork of cowsay
> <https://github.com/cowsay-org/cowsay> that claims to be maintained.
> I have submitted a pull request to it as well.
> <https://github.com/cowsay-org/cowsay/pull/16> 
>
> It would be good to have this issue addressed upstream.  I have just
> submitted these pull requests.  I will provide an update if either pull
> request is merged (modified or unmodified).  If neither repository makes
> any changes to address these questionable files then it may make sense
> for Guix to patch the cowsay package.

The pull request I opened that removed the questionable files on the
cowsay repository Guix uses was closed without being merged.
<https://github.com/tnalpgge/rank-amateur-cowsay/pull/4>

This pull request on a cowsay fork is still open.
<https://github.com/cowsay-org/cowsay/pull/16>