User awareness of Anti-Features

  • Open
  • quality assurance status badge
Details
5 participants
  • Leo Famulari
  • Ludovic Courtès
  • Maxim Cournoyer
  • Maxime Devos
  • soheil
Owner
unassigned
Submitted by
soheil
Severity
normal
S
S
soheil wrote on 8 Feb 2021 14:28
(address . bug-guix@gnu.org)
f9b336f64b53e808ebb86880f5014569@disroot.org
Users should be aware of anti-feature of packages.
It is best to have anti-feature tag in anti-feature packages so that user know which program has anti-features; Like F-Droid. Also, user should be aware of anti-feature during installation. And wherever this awareness is needed...

An example is Telegram, Telegram is a program that user connects to a proprietary server, and users who know less about computer softwares, are not aware of the anti-feature.
Attachment: file
M
M
Maxime Devos wrote on 10 Feb 2021 15:38
c3fcd7974b4493d931d6a1f3e2175d86426c536e.camel@telenet.be
Hi,

On Mon, 2021-02-08 at 13:28 +0000, soheil--- via Bug reports for GNU Guix wrote:
Toggle quote (9 lines)
> Users should be aware of anti-feature of packages.
> It is best to have anti-feature tag in anti-feature packages so that user know
> which program has anti-features; Like F-Droid. Also, user should be aware of
> anti-feature during installation. And wherever this awareness is needed...
>
> An example is Telegram, Telegram is a program that user connects to a
> proprietary server, and users who know less about computer softwares,
> are not aware of the anti-feature.

I'll have to think some more on whether this is something Guix needs, but I
do have a partial concrete implementation proposal:

Packages can have a ‘properties’ field, e.g. from gnu/packages/bioconductors.scm:

(define-public r-reactome-db
(package
(name "r-reactome-db")
(version "1.70.0")
[...]
(properties `((upstream-name . "reactome.db")))))

Maybe add a ‘anti-features’ entry field for some packages?
E.g.,

(define-public some-twitter-app
(package
(name "tweet")
[...]
(properties `((anti-features x y z)))))

x, y and z can be symbols, e.g. based upon from https://f-droid.org/en/docs/Anti-Features/

* ads (I don't think any application in Guix has these?)
* tracking (should be patched out if possible)
* non-free-network-services
* non-free-dependencies (probably not allowed in upstream Guix, but maybe in a channel)

The code behind ‘guix show’ and ‘guix search’ would need to
be adjusted to display anti-features, and the ‘guix install’ code
should warn if someone installs a package with anti-features.

Greetings,
Maxime
-----BEGIN PGP SIGNATURE-----

iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYCPv7BccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7pftAQD4KQHWo9z/TsfjwrcKQ+AottXW
ZzuGVVXDs4RUcDZpmgEAhn/66AgxZa8Cymj3ea6sZCpmK9FUASTtIgiR6l6ZxAI=
=eaOT
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 10 Feb 2021 17:53
(name . soheil--- via Bug reports for GNU Guix)(address . bug-guix@gnu.org)(address . 46385@debbugs.gnu.org)
YCQPdSVQhCYn5obK@jasmine.lan
On Mon, Feb 08, 2021 at 01:28:40PM +0000, soheil--- via Bug reports for GNU Guix wrote:
Toggle quote (3 lines)
> Users should be aware of anti-feature of packages.
> It is best to have anti-feature tag in anti-feature packages so that user know which program has anti-features; Like F-Droid. Also, user should be aware of anti-feature during installation. And wherever this awareness is needed...

I use F-Droid, but I dislike their "anti-feature" messaging. It's not
clear to me that it's an example we should follow.
L
L
Ludovic Courtès wrote on 19 Feb 2021 16:22
(name . Maxime Devos)(address . maximedevos@telenet.be)
87v9aokrph.fsf@gnu.org
Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

Toggle quote (32 lines)
> I'll have to think some more on whether this is something Guix needs, but I
> do have a partial concrete implementation proposal:
>
> Packages can have a ‘properties’ field, e.g. from gnu/packages/bioconductors.scm:
>
> (define-public r-reactome-db
> (package
> (name "r-reactome-db")
> (version "1.70.0")
> [...]
> (properties `((upstream-name . "reactome.db")))))
>
> Maybe add a ‘anti-features’ entry field for some packages?
> E.g.,
>
> (define-public some-twitter-app
> (package
> (name "tweet")
> [...]
> (properties `((anti-features x y z)))))
>
> x, y and z can be symbols, e.g. based upon from https://f-droid.org/en/docs/Anti-Features/
>
> * ads (I don't think any application in Guix has these?)
> * tracking (should be patched out if possible)
> * non-free-network-services
> * non-free-dependencies (probably not allowed in upstream Guix, but maybe in a channel)
>
> The code behind ‘guix show’ and ‘guix search’ would need to
> be adjusted to display anti-features, and the ‘guix install’ code
> should warn if someone installs a package with anti-features.

I’m sympathetic with the idea of raising awareness of those
anti-features. However, I don’t see a clear way we could “define” each
possible anti-feature; some are definitely ill-defined (for instance, a
service is neither “free” nor “non-free” in the same sense as software
can be free or non-free.) It’s also not entirely clear to me how the UI
could make good use of it.

That said, there are anti-features that we have always patched out in
the past, such as tracking/“phoning home” and auto-upgrades. Perhaps we
could formalize that in our packaging guidelines?

Ludo’.
M
M
Maxim Cournoyer wrote on 9 Jun 2022 23:12
(name . Ludovic Courtès)(address . ludo@gnu.org)
87wndph779.fsf@gmail.com
Hi,

Ludovic Courtès <ludo@gnu.org> writes:

[...]

Toggle quote (16 lines)
>> * ads (I don't think any application in Guix has these?)
>> * tracking (should be patched out if possible)
>> * non-free-network-services
>> * non-free-dependencies (probably not allowed in upstream Guix, but maybe in a channel)
>>
>> The code behind ‘guix show’ and ‘guix search’ would need to
>> be adjusted to display anti-features, and the ‘guix install’ code
>> should warn if someone installs a package with anti-features.
>
> I’m sympathetic with the idea of raising awareness of those
> anti-features. However, I don’t see a clear way we could “define” each
> possible anti-feature; some are definitely ill-defined (for instance, a
> service is neither “free” nor “non-free” in the same sense as software
> can be free or non-free.) It’s also not entirely clear to me how the UI
> could make good use of it.

I agree. It's not well defined, and to me following the FSDG seems an
already good warranty that you're getting only free software from a
project dedicated to fixing any freedom issues that may be discovered.

Toggle quote (4 lines)
> That said, there are anti-features that we have always patched out in
> the past, such as tracking/“phoning home” and auto-upgrades. Perhaps we
> could formalize that in our packaging guidelines?

It'd be good to have this documented, indeed.

Thanks,

Maxim
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 46385@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 46385
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch