[bug#52109] How to resolve? (Re: [bug#52109] [PATCH] gnu: Add unrar-free.)

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Freitag, dem 13.01.2023 um 16:20 +0100 schrieb Simon Tournier:
> Hi Liliana,
> 
> On jeu., 12 janv. 2023 at 21:29, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
> 
> > > could this be a reason not to include a FSDG compliant software
> > > in Guix?
> > 
> > A free system distribution must not steer users towards obtaining
> > any nonfree information for practical use, or encourage them to do
> > so. [4]
> 
> Liliana, it is *your* interpretation that unrar-free is–quoting
> FSDG–“steering users toward obtaining any non-free information for
> practical use, or encourage them to do so”.  It is not the
> interpretation of Trisquel folks.  It is not my interpretation and
> probably also not the interpretation of many other peers here.
I am aware of that and I pointed that out myself several times already.

> For instance, a previous version of unrar had been added by commit,
> 
>         0da8313c679f101c3f99970c50d6f0fef995f633
>         Author:     John Darrington <jmd@gnu.org>
>         AuthorDate: Wed Mar 1 07:00:05 2017 +0100
>         Commit:     John Darrington <jmd@gnu.org>
>         CommitDate: Wed Mar 1 18:57:00 2017 +0100
> 
> and then removed by 2560aa7adbfcb46306e8b19180bd48d39c2da6dc:
> 
>         gnu: Remove unrar.
> 
>         This package is abandoned upstream and contains serious bugs:
> 
>         http://seclists.org/oss-sec/2017/q3/329
>         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14120
>         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14121
>         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14122
> 
>         * gnu/packages/compression.scm (unrar): Remove variable.
> 
> Therefore, I am still missing what is blocking. ;-)
I mean, I am not the only person, who can sign off commits here.  I am
merely raising my own concerns w.r.t. this package and refusing to sign
off the commit myself – I am not hindering anyone else from picking it
up.  Now, I can't exactly give you my written permission to do so, but
I will at least promise not to exercise my commit rights to revert it
without some more pressing issue (like the CVEs noted above).

> The fact that FSDG is poorly worded is one thing, indeed.  This
> sentence “steering users toward obtaining any non-free information
> for practical use, or encourage them to do so” from these FSDG could
> also be interpreted to many other features – another story. :-)
Sure.

> From my point of view, all the packages allowing interoperability
> across various operating system (including non-free ones) fits my
> understanding of the Liliana’s interpretation of “steer users toward
> obtaining any non-free information for practical use, or encourage
> them to do so”; interpretation mainly based – again, if I understand
> correctly – on speculations about the user’s intention.  Therefore,
> we should also remove the packages: mednafen, docx2txt, antiword,
> bochs, cabextract, cl-mssql, emacs-powershell, etc.
I fear your interpretation is made up of speculations of my intentions,
or in other words straw.  I do argue however, that for most people when
they go seek out unrar-free, then it'd be because the archiver of their
choice failed them, in which case unrar-free won't be able to do
anything.  Of the examples you list here, only cabextract is close in
spirit to unrar-free, with the difference that cabextract relies on the
CLI-less libmspack.  If libmspack shipped with a CLI of its own that
handles cabs, I would argue that cabextract is pretty pointless, but
nonetheless it ironically doesn't even feature name confusion.

> Any free reimplementation potentially offers a degraded experience
> compared to the proprietary product.  It does not appear to me an
> argument to raise that this potentially degraded experience leads to
> “steering users toward obtaining any non-free information for
> practical use, or encourage them to do so”.  Even, from my point of
> view, it is the contrary: a free reimplementation even with weakness
> is liberating.
The thing is, you don't need unrar-free to get a degraded experience of
unpacking rar archives.  Any libarchive-based archive manager will do,
most of which offer a more complete package.

> Last, I do not understand your Liliana argument about «Obviously,
> unrar-free has a different CLI – that's is whole shtick, after all –
> but I'd argue that this doesn't matter, because the people who prefer
> CLI over GUI know how to read manpages.».  Well, we could apply it
> many flavor of similar tools.  For instance, you would be in favor to
> remove/drop the CLI dulwich provided by the package python-dulwich
> since CLI Dulwich user could just read the Git man pages.  Or
> similarly bmake vs make, coreutils vs busybox vs toybox, etc.
If any of these packages were only offering alternative CLIs for
another tool while also inviting name confusion, yes, I would be in
favour of removing them.  But that is not the case in any of the
examples you list here.

For the dulwich example, yes, it provides an alternative frontend to
git, but the value of that package is that it's a pure python
implementation of the git protocol, i.e. it doesn't use libgit. 
(Interestingly, git is used as native input, presumably for testing
purposes.)

For bmake vs. GNU Make, I think that those are two different tools that
do the same job similar to clang and gcc both being C compilers.  Now
removing clang because we have gcc would admittedly be pretty based,
but sadly not an option, because some programs depend on certain
implementation-defined behaviour of clang (and other parts of its
infrastructure).

For coreutils, busybox and toybox, these are again different
implementations of the same thing with slight variations.  Now, based
on the controversial move of being GPL2 only, one could decide to
remove busybox in favour of the rollover-licensed toybox, but as it
stands I believe neither project steers users towards nonfree software
either by name or otherwise.

For contrast, the case we have with unrar-free is that we have a CLI in
libarchive (bsdtar) and a different CLI in unrar-free, both of which
use libarchive.  This would be roughly equivalent to me making a new 
CLI frontend for wine and calling it pro^H^H^Hwin10.

> Without saying that I do not even know which Guix package provides
> this bsdtar tool, from this FreeBSD tar manpage [1], it is not clear
> if RAR is supported or not.  To know it, one needs to open this other
> man page [2].  Bah, yes an easy CLI matters!
I hazard a guess that you didn't have to unpack many RAR archives via
CLI then.  Which fair enough, because there are other libarchive
frontends to further prove my point that unrar-free is not needed.

> All in all, it appears that we disagree. :-)
That it does :)


Cheers