bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45450: Guix, third-party repositories and GNU FSDG


From: Adonay Felipe Nogueira
Subject: bug#45450: Guix, third-party repositories and GNU FSDG
Date: Sat, 26 Dec 2020 16:13:51 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Icedove/68.10.0

Severity: critical

According to the GNU FSDG ([1], emphasis are mine):

> A free system distribution must not steer users towards obtaining any nonfree 
> information for practical use, or encourage them to do so. The system should 
> have no repositories for nonfree software and no specific recipes for 
> installation of particular nonfree programs. *Nor should the distribution 
> refer to third-party repositories that are not committed to only including 
> free software; even if they only have free software today, that may not be 
> true tomorrow.* Programs in the system should not suggest installing nonfree 
> plugins, documentation, and so on.

However, at least on the case of the rust package, in the following example one 
can see that cargo is also included:

$ guix package --show=rust

> name: rust
> version: 1.46.0
> outputs: out doc cargo
> systems: x86_64-linux i686-linux
> dependencies: bison@3.5.3 cmake-minimal@3.16.5 curl@7.69.1 flex@2.6.4
> + gdb@8.2.1 jemalloc@5.2.1 libssh2@1.9.0 llvm@10.0.0 make@4.2.1 openssl@1.1.1f
> + pkg-config@0.29.2 procps@3.3.16 python2@2.7.17 rust@1.45.2 which@2.21
> location: gnu/packages/rust.scm:105:2
> homepage: https://www.rust-lang.org
> license: ASL 2.0, Expat
> synopsis: Compiler for the Rust programming language  
> description: Rust is a systems programming language that provides memory
> + safety and thread safety guarantees.

In continuation, as can be seen on [2], the installed cargo has it's default 
repository enabled.

Furthermore, neither [3] nor [4] have expressed commitment to the GNU FSDG.

Here are some suggestions, probably not tested nor researched for viability:

a) make the importer activate a flag of its own in order to use that package. 
This would render a plain install of the package a version with cargo absent 
while still having the possibility to do the imports;

b) coordinate with the head of the cargo community (and possibily other 
free/libre system distributions or free/libre software activism groups) an 
agreement so that they express commitment to the GNU FSDG on [3] and [4], and 
of course make them setup a bug/issue/task tag/section for GNU FSDG issues. 
This must be done together with either (a), (d) or (e);

c) coordinate with other free/libre system distributions or free/libre software 
activism groups a project to provide a common repository that such groups could 
refer to by default by patching their copy of cargo. This must be done together 
with either (a), (d) or (e);

d) find a way to provide cargo but without any repository. This would require a 
way for the importer to specify the repositories at run-time;

e) despite not being desirable by some people, there is also the possibility of 
removing cargo.

As a side-note, as the original subject stated, I think we should address this 
issue in other packages too, if any, and also document the decision on the 
manual or on guideline.


# References


[1]: 
https://www.gnu.org/distros/free-system-distribution-guidelines.en.html#license-rules
 .

[2]: https://lists.gnu.org/archive/html/help-guix/2020-12/msg00231.html .

[3]: https://crates.io/policies .

[4]: https://www.rust-lang.org/policies/code-of-conduct .


-- 
* Ativista do software livre
        * https://libreplanet.org/wiki/User:Adfeno
        * Membro dos grupos avaliadores de
                * Software (Free Software Directory)
                * Distribuições de sistemas (FreedSoftware)
                * Sites (Free JavaScript Action Team)
        * Não sou advogado e não fomento os não livres
* Sempre veja o spam/lixo eletrônico do teu e-mail
        * Ou coloque todos os recebidos na caixa de entrada
* Sempre assino e-mails com OpenPGP
        * Chave pública: vide endereço anterior
        * Qualquer outro pode ser fraude
        * Se não tens OpenPGP, ignore o anexo "signature.asc"
* Ao enviar anexos
        * Docs., planilhas e apresentações: use OpenDocument
        * Outros tipos: vide endereço anterior
* Use protocolos de comunicação federadas
        * Vide endereço anterior
* Mensagens secretas somente via
        * XMPP com OMEMO
        * E-mail criptografado e assinado com OpenPGP

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]