Retroarch might violate FSDG

Done

Details

7 participants

Nicolò Balzarotti
Arne Babenhauserheide
Jesse Gibbons
Ludovic Courtès
Tobias Geerinckx-Rice
Mark H Weaver
Andrew Wong

Owner: unassigned

Submitted by: Nicolò Balzarotti

Severity: normal

Nicolò Balzarotti wrote on 24 Nov 2019 15:15

Recipients:(address . bug-guix@gnu.org)

Message-ID:CAO7Ox=bkYoJXyGPNL_W5MqKd8=ULPojGTUSzkZ9Dy4zLuyn3vA@mail.gmail.com

Hello guix!

How I reported today on the IRC #guix channel:

We might have a problem on how retroarch is packaged. I've never used it,

tried just now. There's the "core download" section where it downloads

"$core.so.zip". Those are .so files:

.config/retroarch/cores/atari800_libretro.so: file format elf64-x86-64.

I think we should either compile them and ship them or remove the download

section or something.

Also, when downloading cores there are no license info

nckx provided this [1] as a useful link. It seems that some of the plugins

are available for non-commercial projects only (so not compatible with the

GPLv3, used by retroarch).

It is something we should investigate and address, both for licensing

issues and for safety (and because we do not want to ship precompiled

binaries).

Thanks, Nicolò

[1] https://www.libretro.com/index.php/retroarch-license-violations

Attachment: file

Ludovic Courtès wrote on 26 Nov 2019 11:34

Recipients:(name . Nicolò Balzarotti)(address . anothersms@gmail.com)(address . 38360@debbugs.gnu.org)

Message-ID:87d0df7wpv.fsf@gnu.org

Hello,

Nicolò Balzarotti <anothersms@gmail.com> skribis:

Toggle quote (7 lines)

> We might have a problem on how retroarch is packaged. I've never used it,

> tried just now. There's the "core download" section where it downloads

> "$core.so.zip". Those are .so files:

> .config/retroarch/cores/atari800_libretro.so: file format elf64-x86-64.

> I think we should either compile them and ship them or remove the download

> section or something.

We should definitely remove all binary files from the “source” tarballs.

Toggle quote (2 lines)

> Also, when downloading cores there are no license info

That should be investigated, indeed, possibly looking at what Debian is

doing.

Toggle quote (4 lines)

> nckx provided this [1] as a useful link. It seems that some of the plugins

> are available for non-commercial projects only (so not compatible with the

> GPLv3, used by retroarch).

We don’t provide those plugins though, do we?

Thanks,

Ludo’.

Nicolò Balzarotti wrote on 27 Nov 2019 00:26

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 38360@debbugs.gnu.org)

Message-ID:CAO7Ox=aNu5AcxHVTm5puORCLf5aeJQ+MNdoRtbi7fnfG4g7aoA@mail.gmail.com

Hi Ludo, thanks for your response.

We don't provide them _directly_, but when loading the program the first

option is "Load core". Then, first option again, is "Download core". Here

you have a list of "proprietary" .so.zip downloads. Retroarch, as far as I

understand, is encouraging the download of those programs, with no

licensing information (see [1]). I don't know if this is ok or if we can

patch it (hiding the "Download core" menu maybe?).

Debian _does_ provide (from their package manager) some o the cores [2],

two of them with the non-free tag.

If we patch retroarch to hide the download menu, to make it functional we

should also package some free cores.

Thoughts?

Thanks again,

Nicolò

[1] https://docs.libretro.com/guides/download-cores/

[2] https://packages.debian.org/stretch/games/

Il giorno mar 26 nov 2019 alle ore 11:34 Ludovic Courtès <ludo@gnu.org> ha

scritto:

Toggle quote (31 lines)> Hello,
>
> Nicolò Balzarotti <anothersms@gmail.com> skribis:
>
> > We might have a problem on how retroarch is packaged. I've never used it,
> > tried just now. There's the "core download" section where it downloads
> > "$core.so.zip". Those are .so files:
> > .config/retroarch/cores/atari800_libretro.so:     file format
> elf64-x86-64.
> > I think we should either compile them and ship them or remove the
> download
> > section or something.
>
> We should definitely remove all binary files from the “source” tarballs.
>
> > Also, when downloading cores there are no license info
>
> That should be investigated, indeed, possibly looking at what Debian is
> doing.
>
> > nckx provided this [1] as a useful link. It seems that some of the
> plugins
> > are available for non-commercial projects only (so not compatible with
> the
> > GPLv3, used by retroarch).
>
> We don’t provide those plugins though, do we?
>
> Thanks,
> Ludo’.
>

Attachment: file

Jesse Gibbons wrote on 27 Nov 2019 03:09

Recipients:(address . 38360@debbugs.gnu.org)

Message-ID:b4c98b48fa52276ceb63708c5b7aff19f9c0a2f4.camel@gmail.com

On Wed, 2019-11-27 at 00:26 +0100, Nicolò Balzarotti wrote:

Toggle quote (11 lines)> Hi Ludo, thanks for your response.
> 
> We don't provide them _directly_, but when loading the program the first
> option is "Load core". Then, first option again, is "Download core". Here
> you have a list of "proprietary" .so.zip downloads. Retroarch, as far as I
> understand, is encouraging the download of those programs, with no
> licensing information (see [1]).  I don't know if this is ok or if we can
> patch it (hiding the "Download core" menu maybe?).
> 
> Debian _does_ provide (from their package manager) some o the cores [2],
> two of them with the non-free tag.

I can confirm that snes9x is nonfree because it is only for non-commercial
use. We should at least patch that out before the cores are available. I
don't know about the other one.
Since retroarch offers a third-party repository to download nonfree shared
libraries, we should blacklist it in order for GuixSD to remain FSDG
compliant.

Toggle quote (2 lines)

> If we patch retroarch to hide the download menu, to make it functional we

> should also package some free cores.

I don't know how retroarch works. What else would we need to patch out of or

into it so it recognizes the packaged cores?

Toggle quote (2 lines)

> Thoughts?

1. I think I can (eventually) compile an alist of cores, source locations,
licenses, and descriptions, but I won't be able to do that until December.
Anyone want to beat me to it?
2. After we have an alist for each of these cores, we can quickly generate
some code to start packaging them, hopefully all at once. It will probably
be faster than adding them on demand. I'm guessing we would want them in
emulators.scm correct?
3. When we have some cores packaged, we can work on making retroarch
recognize them and not try to download its own binaries.
I propose this order because I don't think I'm alone in wanting to keep
retroarch usable during this process, and it will be easier to adapt
retroarch after we have some cores packaged.

Toggle quote (8 lines)> Thanks again,
> Nicolò
> 
> 
> [1] https://docs.libretro.com/guides/download-cores/
> [2] https://packages.debian.org/stretch/games/
> 
>

Arne Babenhauserheide wrote on 27 Nov 2019 21:48

Recipients:(address . bug-guix@gnu.org)

Message-ID:877e3lkpv9.fsf@web.de

Jesse Gibbons <jgibbons2357@gmail.com> writes:

Toggle quote (5 lines)

> On Wed, 2019-11-27 at 00:26 +0100, Nicolò Balzarotti wrote:

> I can confirm that snes9x is nonfree because it is only for non-commercial

> use. We should at least patch that out before the cores are available. I

> don't know about the other one.

Aren’t we overblocking here? This is not a case of a program restricted

to push someone into proprietary software, but a case of a program

restricted to not-for-profit for everybody.

It is a similar case as allowing to ship GPLv3 software in a ROM without

the option to modify it, as long as no one is able to modify it on that

medium, including the propagator.

In the case of snes9x no one is able to monetize the software, including

the creators, because many people have a stake in the non-commercial

clause, but the software is freely modifiable and you can share it

non-commercially.

It is also not advertised (I just tried) but simply one in a long list

of possible cores. A very long list. And you have to actively do the

online-lookup.

We’re not restricting software which displays non-free online comics

either.

Installing the fastest and most compatible free software cores by

default (pre-installed) would minimize the effect of cores bound to

non-commercial use being available online without restricting the users

in using RetroArch — and it would make retroarch more convenient to use.

Best wishes,

Arne

Unpolitisch sein

heißt politisch sein

ohne es zu merken

Tobias Geerinckx-Rice wrote on 28 Nov 2019 01:02

Re: bug#38360: Retroarch does violate FSDG

Recipients:(address . 38360@debbugs.gnu.org)

Message-ID:874kyoamwd.fsf@nckx

Guix,

This is not about Schrödinger's proprietary-until-proven-innocent

binary. The Updater includes at least two cores explicitly marked

as non-free in Debian:

libretro-genesisplusgx

libretro-snes9x

Disabling the Updater seems like an open & shut case to me.

This is a shame, because I think these non-commercial clauses are

silly and legally void. Core authors can't place arbitrary

restrictions on derivative works of a GPL3 project.

Unfortunately, that obvious fact is for a court to point out, and

until then we must act as if it makes any sense.

Arne, to address your last point first:

Arne Babenhauserheide ???

Toggle quote (6 lines)

> It is also not advertised (I just tried) but simply one in a

> long list

> of possible cores. A very long list. And you have to actively do

> the

> online-lookup.

For the purpose of this (FSDG) discussion, that's exactly what

‘advertised’ means.

I install Retroarch with Guix. When I run Retroarch, it prods me

to (literally) ‘use the Updater if available’. When I do that, I

can select from many cores, at least two of them non-free.

There is no way for me to know this important fact; I have to type

the name of the core into a search engine and dig, possibly deep

(not everyone knows the awesome power of a Debian copyright file

:-).

You're not required to agree with any of the above, but Guix must.

Toggle quote (4 lines)

> We’re not restricting software which displays non-free online

> comics

> either.

Indeed, that would be against our stated goal of user freedom.

Comics aren't software so don't count, but take Linux-Libre: the

fact that it refuses to load non-free firmware supplied by the

user is a *bug*, and even upstream acknowleges this. IceCat is

another obvious example.

Same with Retroarch: if the user has a non-free core Guix's

Retroarch must, IMPO, run it.

The difference is that at no point do Linux-Libre or IceCat ask me

to ‘visit our cool firmware shoppe!’. Indeed, the FF ‘Get New

Add-ons’ button that directly advertises non-free software is

disabled for that reason.

Toggle quote (6 lines)

> Aren’t we overblocking here? This is not a case of a program

> restricted

> to push someone into proprietary software, but a case of a

> program

> restricted to not-for-profit for everybody.

It's just as bad for the same reason. Like proprietary licences,

this one restricts redistribution *and* use of the software:

“Permission to use, copy, modify and/or distribute Snes9x in

both binary

and source form, for non-commercial purposes, is hereby granted

without

fee […] Snes9x is freeware for PERSONAL USE only.”

That violates a fundamental software freedom (#0: the freedom to

run the software as you wish, for any purpose).

Contrast this with the GPL, which places zero restrictions on use

— I don't even have to share the software or my improvements with

anyone!

Toggle quote (6 lines)

> It is a similar case as allowing to ship GPLv3 software in a ROM

> without

> the option to modify it, as long as no one is able to modify it

> on that

> medium, including the propagator.

I don't see any similarities. With any GPL3 software, I am always

allowed to copy the software and do with it what I want, no matter

the underlying storage at some point in time.

Kind regards,

T (not a lawyer but talks to them at parties when no one else

will) G-R

Nicolò Balzarotti wrote on 28 Nov 2019 01:35

Re: bug#38360: Retroarch might violate FSDG

Recipients:(name . Arne Babenhauserheide)(address . arne_bab@web.de)

Message-ID:CAO7Ox=aBoDWbuo7T8syPw2R2-f-OAvyBhAC59Pom4jipvd3ULA@mail.gmail.com

Hi,

Il giorno mer 27 nov 2019 alle ore 21:48 Arne Babenhauserheide <

arne_bab@web.de> ha scritto:

Toggle quote (12 lines)>
> Jesse Gibbons <jgibbons2357@gmail.com> writes:
> > On Wed, 2019-11-27 at 00:26 +0100, Nicolò Balzarotti wrote:
> > I can confirm that snes9x is nonfree because it is only for
> non-commercial
> > use. We should at least patch that out before the cores are available. I
> > don't know about the other one.
>
> Aren’t we overblocking here? This is not a case of a program restricted
> to push someone into proprietary software, but a case of a program
> restricted to not-for-profit for everybody.
>

This is, by (some) definition, non free.

Toggle quote (17 lines)> It is a similar case as allowing to ship GPLv3 software in a ROM without
> the option to modify it, as long as no one is able to modify it on that
> medium, including the propagator.
>

> In the case of snes9x no one is able to monetize the software, including
> the creators, because many people have a stake in the non-commercial
> clause, but the software is freely modifiable and you can share it
> non-commercially.
>
> It is also not advertised (I just tried) but simply one in a long list
> of possible cores. A very long list. And you have to actively do the
> online-lookup.
>
> We’re not restricting software which displays non-free online comics
> either.
>

Comics aren't software. Free as in Freedom can apply only to software, AFAIK

Toggle quote (6 lines)

> Installing the fastest and most compatible free software cores by

> default (pre-installed) would minimize the effect of cores bound to

> non-commercial use being available online without restricting the users

> in using RetroArch — and it would make retroarch more convenient to use.

If I understand correctly (i.e. shipping free cores with our retroarch
distribution, while still allowing non-free software download from the
software), I half-way agree with you. However, IMO, we should not encourage
the use of non free software, at all. Those non-free cores available in one
click, and a user might not even know that 1. s/he is downloading some kind
of software and 2. that this software is non-free (no license details). I
was upset in discovering that I downloaded a non-free core, and I realized
just because of the ".so.zip" name. If upstream they change the name to
"core.zip", future users might not even understand what they are doing.
Also, it might even happen that they will share non-opensource plugins in
the future. I don't know and I don't think it is fair.
Finally, in a purely reproducible interest, having random software
downloaded is just bad.

Let me know what do you think,
Nicolò

Toggle quote (8 lines)>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>

Attachment: file

Arne Babenhauserheide wrote on 28 Nov 2019 09:05

Recipients:(name . Nicolò Balzarotti)(address . anothersms@gmail.com)

Message-ID:87eexs2zog.fsf@web.de

Nicolò Balzarotti <anothersms@gmail.com> writes:

Toggle quote (6 lines)

>> Aren’t we overblocking here? This is not a case of a program restricted

>> to push someone into proprietary software, but a case of a program

>> restricted to not-for-profit for everybody.

> This is, by (some) definition, non free.

Yes.

Toggle quote (19 lines)>> It is a similar case as allowing to ship GPLv3 software in a ROM without
>> the option to modify it, as long as no one is able to modify it on that
>> medium, including the propagator.
>>
>
>> In the case of snes9x no one is able to monetize the software, including
>> the creators, because many people have a stake in the non-commercial
>> clause, but the software is freely modifiable and you can share it
>> non-commercially.
>>
>> It is also not advertised (I just tried) but simply one in a long list
>> of possible cores. A very long list. And you have to actively do the
>> online-lookup.
>>
>> We’re not restricting software which displays non-free online comics
>> either.
>>
> Comics aren't software. Free as in Freedom can apply only to software, AFAIK

It can apply to non-software, see for example the Wikipedia and
Stackoverflow. I experience that regularly since I’m writing a
GPL-licensed roleplaying book: it uses graphics from Battle For Wesnoth,
under GPL, and getting cc by-sa GPL-compatible was a major pain point
for many years -> https://www.draketo.de/english/free-software/by-sa-gpl

Toggle quote (12 lines)>> Installing the fastest and most compatible free software cores by
>> default (pre-installed) would minimize the effect of cores bound to
>> non-commercial use being available online without restricting the users
>> in using RetroArch — and it would make retroarch more convenient to use.
>
> If I understand correctly (i.e. shipping free cores with our retroarch
> distribution, while still allowing non-free software download from the
> software), I half-way agree with you. However, IMO, we should not encourage
> the use of non free software, at all. Those non-free cores available in one
> click, and a user might not even know that 1. s/he is downloading some kind
> of software and 2. that this software is non-free (no license details).

Looking at the interface *if you have some cores installed* it first

presents those cores and only afterwards says "download core".

And for available cores there’s actually a license entry (but that

currently says N/A — which looks like a bug to me).

So while there is no license in the listing, you are presented with the

license before running a core.

Toggle quote (5 lines)

> I was upset in discovering that I downloaded a non-free core, and I

> realized just because of the ".so.zip" name. If upstream they change

> the name to "core.zip", future users might not even understand what

> they are doing.

The .so file ending is already something that takes domain knowledge to

recognize. But not from the domain of the program: The domain of the

program are emulators and roms. For these "this uses a core for the

specified hardware" is pretty clear.

Toggle quote (3 lines)

> Finally, in a purely reproducible interest, having random software

> downloaded is just bad.

I agree in principle but not in practice, because we also ship npm, pip,
gem, package.el, cargo, maven, …

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Arne Babenhauserheide wrote on 28 Nov 2019 11:06

Re: bug#38360: Retroarch does violate FSDG

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 38360@debbugs.gnu.org)

Message-ID:87d0dc2u2z.fsf@web.de

Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Toggle quote (9 lines)

> Guix,

> This is not about Schrödinger's proprietary-until-proven-innocent

> binary. The Updater includes at least two cores explicitly marked as

> non-free in Debian:

> libretro-genesisplusgx

> libretro-snes9x

In non-free because they are non-commercial, not because they

treacherous to users.

This is a distinction the FSF used to make until 2010 but dropped since then:

https://web.archive.org/web/20100126044451/http://www.gnu.org/philosophy/categories.html#semi-freeSoftware

Toggle quote (8 lines)

> Disabling the Updater seems like an open & shut case to me.

> This is a shame, because I think these non-commercial clauses are

> silly and legally void. Core authors can't place arbitrary

> restrictions on derivative works of a GPL3 project. Unfortunately,

> that obvious fact is for a court to point out, and until then we must

> act as if it makes any sense.

Retroarch is not a derivative work of the cores. There is an API-layer

between both.

This is similar to a PDF which can place restrictions on what I can do

with a PDF-viewer *while viewing that PDF*. For example I’m not allowed

to charge money for displaying a PDF for which I don’t have commercial

use rights.

(since PDFs can have Javascript embedded, this even applies when we have

a strict discussion about programs)

Toggle quote (17 lines)> Arne, to address your last point first:
>
> Arne Babenhauserheide ???
>> It is also not advertised (I just tried) but simply one in a long
>> list of possible cores. A very long list. And you have to actively do
>> the online-lookup.
>
> For the purpose of this (FSDG) discussion, that's exactly what
> ‘advertised’ means.
>
> I install Retroarch with Guix.  When I run Retroarch, it prods me to
> (literally) ‘use the Updater if available’.  When I do that, I can
> select from many cores, at least two of them non-free.
> There is no way for me to know this important fact; I have to type the
> name of the core into a search engine and dig, possibly deep (not
> everyone knows the awesome power of a Debian copyright file :-).

Look at what happens when you have at least one core installed: It shows

you the core with a line for the license (but that says N/A for snes9x,

which is likely a bug).

If we pre-install free cores, then these are what will be shown first.

And different from browser-add-ons, they are not run until you start

them — before which you see the license (barring the N/A bug).

Toggle quote (2 lines)

> You're not required to agree with any of the above, but Guix must.

If the license-info line is fixed, then not: You are then clearly

informed of the license *before* you run the core.

Toggle quote (7 lines)

>> We’re not restricting software which displays non-free online comics

>> either.

> Indeed, that would be against our stated goal of user freedom.

> Comics aren't software so don't count

I disagree, but that’s a personal opinion which is not mainstream in GNU.

Toggle quote (7 lines)

>> Aren’t we overblocking here? This is not a case of a program

>> restricted

>> to push someone into proprietary software, but a case of a program

>> restricted to not-for-profit for everybody.

> It's just as bad for the same reason.

It is not *just as* bad. If I can choose between a

closed-source-likely-spies-on-you-and-you-cannot-do-anything-about-it

tool and a

you-can-see-and-fix-everything-but-noone-can-earn-money-with-it tool,

the latter is clearly better.

Not sufficiently good for inclusion in a free distribution, but in my

opinion also not bad enough to censor from lists.

Toggle quote (6 lines)

> That violates a fundamental software freedom (#0: the freedom to run

> the software as you wish, for any purpose).

> Contrast this with the GPL, which places zero restrictions on use — I

> don't even have to share the software or my improvements with anyone!

This is not true for the AGPL, because that places the restriction that

you have to provide the source you’re running.

That’s a restriction I like, because it prevents circumvention of the

GPL, but it is a restriction.

The non-commercial clause for emulators was added because otherwise

they would have been struck down.

Toggle quote (10 lines)>> It is a similar case as allowing to ship GPLv3 software in a ROM
>> without
>> the option to modify it, as long as no one is able to modify it on
>> that
>> medium, including the propagator.
>
> I don't see any similarities.  With any GPL3 software, I am always
> allowed to copy the software and do with it what I want, no matter the
> underlying storage at some point in time.

In that case you cannot in practice do with it what you want, because

you cannot run a modified version on your device.

The important distinction is, that the creator cannot do so either.

And this is the symmetry which is also preserved with the non-commercial

cores.

I’m not arguing to include snes9x in Guix, just that this isn’t a case

where redaction of information is needed — if we package the free cores.

Best wishes,

Arne

Unpolitisch sein

heißt politisch sein

ohne es zu merken

Ludovic Courtès wrote on 28 Nov 2019 17:27

Re: bug#38360: Retroarch might violate FSDG

Recipients:(name . Nicolò Balzarotti)(address . anothersms@gmail.com)(address . 38360@debbugs.gnu.org)

Message-ID:87zhggt186.fsf@gnu.org

Hi Nicolò,

Nicolò Balzarotti <anothersms@gmail.com> skribis:

Toggle quote (7 lines)

> We don't provide them _directly_, but when loading the program the first

> option is "Load core". Then, first option again, is "Download core". Here

> you have a list of "proprietary" .so.zip downloads. Retroarch, as far as I

> understand, is encouraging the download of those programs, with no

> licensing information (see [1]). I don't know if this is ok or if we can

> patch it (hiding the "Download core" menu maybe?).

Oh, that sounds pretty bad. In my view, it’s a problem:

1. from a user freedom viewpoint, because the user might unwillingly

find themselves downloading non-free code, and thus Guix is not

fulfilling its mission;

2. from a security and engineering viewpoint, because we certainly

don’t want users to run code from arbitrary binaries downloaded

from the net.

I think it definitely needs to be fixed.

Toggle quote (5 lines)

> Debian _does_ provide (from their package manager) some o the cores [2],

> two of them with the non-free tag.

> If we patch retroarch to hide the download menu, to make it functional we

> should also package some free cores.

That sounds like a plan.

Would you be able to help with that? Hopefully there are patches we can

take from Debian, no?

If nobody can work on it in a timely fashion, I would propose to remove

retroarch until someone can do this work.

WDYT?

Thanks,

Ludo’.

Tobias Geerinckx-Rice wrote on 28 Nov 2019 20:24

Recipients:

Message-ID:87wobj953k.fsf@nckx

Ludovic Courtès ???

Toggle quote (8 lines)

> Would you be able to help with that? Hopefully there are

> patches we can

> take from Debian, no?

> If nobody can work on it in a timely fashion, I would propose to

> remove

> retroarch until someone can do this work.

I'm looking into this now.

Kind regards,

T G-R

Tobias Geerinckx-Rice wrote on 29 Nov 2019 16:21

Recipients:(address . 38360@debbugs.gnu.org)

Message-ID:87h82m908a.fsf@nckx

Tobias Geerinckx-Rice ???

Toggle quote (2 lines)

> I'm looking into this now.

So I've installed Retroarch on Debian.

They patch[0] it to hide the Updater by default but it's trivial

to reënable (tested):

$ echo 'menu_show_core_updater = "false"' >> \

~/.config/retroarch/retroarch.cfg

This does not appease me. I'm implementing more incisive

measures.

Thoughts? Am I an anti-choice extremist?

Kind regards,

T G-R

[0]:

https://sources.debian.org/patches/retroarch/1.7.3+dfsg1-1/01_config.patch/

Tobias Geerinckx-Rice wrote on 29 Nov 2019 16:24

Recipients:(address . 38360@debbugs.gnu.org)

Message-ID:87fti6903l.fsf@nckx

Tobias Geerinckx-Rice via Bug reports for GNU Guix ???

Toggle quote (1 lines)

> $ echo 'menu_show_core_updater = "false"'

^^^^^

"true", of course…

Kind regards,

T G-R

Arne Babenhauserheide wrote on 29 Nov 2019 17:05

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 38360@debbugs.gnu.org)

Message-ID:87tv6mzn06.fsf@web.de

Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Toggle quote (10 lines)> They patch[0] it to hide the Updater by default but it's trivial to
> reënable (tested):
>
>  $ echo 'menu_show_core_updater = "false"' >> \
>      ~/.config/retroarch/retroarch.cfg
>
> This does not appease me.  I'm implementing more incisive measures.
>
> Thoughts?  Am I an anti-choice extremist?

I do not like to put people into boxes. I can judge actions, not people.

Implementing more extreme measures than changing the default uses

practical power against users. It limits user freedom.

As committer to Guix you are in a position of power over users. You can

use that position to liberate them from shackles, or you can use it to

limit their freedom.

When I look into ethical decisions, I need a basic goal. The mission of

GNU is "to promote computer user freedom". This is too vague to use on

its own to check an action, therefore I’m using the more actionabe

mission of the Hurd:

“Our mission is to create a general-purpose kernel suitable for the GNU

operating system, which is viable for everyday use, and gives users and

programs as much control over their computing environment as possible.“

Giving programs as much control over their environment is not relevant

to the discussion (it is only relevant for a kernel with the assumption

that the program acts on behalf of the user). For this ethical check

I’ll therefore simplify the mission to:

“Our mission is to give users as much control over their computing

environment as possible.“

Does it give users as much control over their computing environment as

possible if you make it harder for them to re-enable the updater?

By making it harder, you limit the number of people who can take the

decision to re-activate the updater, therefore fewer people have the

practical freedom to do so, though they can still do so in theory.

But using a license like the GPL is all about practical Freedom. If we

were only talking about theoretical freedom, then any binary blob

(without DRM) would give as much freedom as an AGPL program. Game

modders have been demonstrating that for decades. Therefore theoretical

freedom does not suffice: The goal must be practical freedom. The

freedom to hack as easily as possible. Giving as many people as possible

the freedom to change the operation of as many parts of the system as

possible.

Implementing measures to limit user freedom beyond choosing defaults

that ensure that they do not accidentally fall into a trap they do not

see goes against that. It limits the practical freedom of users.

As committer to Guix you have practical power over every Guix user.

When you use that power, it is your responsibility to further their

freedom, not to create new chains.

That would be consistent with the mission to give users as much control

over their computing environment as possible.

Best wishes,

Arne

Unpolitisch sein

heißt politisch sein

ohne es zu merken

Tobias Geerinckx-Rice wrote on 29 Nov 2019 21:14

[PATCH] gnu: retroarch: Disable Online Updater [FSDG fix].

Recipients:(address . 38360@debbugs.gnu.org)

Message-ID:20191129201439.3668-1-me@tobias.gr

Addresses http://issues.guix.gnu.org/issue/38360.

* gnu/packages/emulators.scm (retroarch)[source]: Add patch and snippet.
* packages/patches/retroarch-disable-online-updater.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
---
 gnu/local.mk                                  |  1 +
 gnu/packages/emulators.scm                    | 17 +++++++++++++++--
 .../retroarch-disable-online-updater.patch    | 19 +++++++++++++++++++
 3 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100644 gnu/packages/patches/retroarch-disable-online-updater.patch

Toggle diff (85 lines)diff --git a/gnu/local.mk b/gnu/local.mk
index 88b0f98aa0..b0036a52a0 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1330,6 +1330,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/rpcbind-CVE-2017-8779.patch		\
   %D%/packages/patches/rtags-separate-rct.patch			\
   %D%/packages/patches/racket-store-checksum-override.patch	\
+  %D%/packages/patches/retroarch-disable-online-updater.patch	\
   %D%/packages/patches/ruby-rubygems-276-for-ruby24.patch	\
   %D%/packages/patches/ruby-rack-ignore-failing-test.patch      \
   %D%/packages/patches/ruby-safe-yaml-add-require-time.patch	\
diff --git a/gnu/packages/emulators.scm b/gnu/packages/emulators.scm
index 7d3f7f019c..e622d2df4d 100644
--- a/gnu/packages/emulators.scm
+++ b/gnu/packages/emulators.scm
@@ -1062,7 +1062,18 @@ emulation community.  It provides highly accurate emulation.")
              (commit (string-append "v" version))))
        (file-name (git-file-name name version))
        (sha256
-        (base32 "0y7rcpz7psf8k3agsrq277jdm651vbnn9xpqvmj2in1a786idya7"))))
+        (base32 "0y7rcpz7psf8k3agsrq277jdm651vbnn9xpqvmj2in1a786idya7"))
+       (patches
+        (search-patches "retroarch-disable-online-updater.patch"))
+       (modules '((guix build utils)))
+       (snippet
+        '(begin
+           ;; Don't suggest using the Online Updater if available: it never
+           ;; is.  This disables translation of this particular message.
+           (substitute* (find-files "menu/drivers" "\\.c$")
+             (("msg_hash_to_str\\(MSG_MISSING_ASSETS\\)")
+              "\"Warning: Missing assets, go get some\""))
+           #t))))
     (build-system gnu-build-system)
     (arguments
      `(#:tests? #f                      ; no tests
@@ -1074,7 +1085,7 @@ emulation community.  It provides highly accurate emulation.")
                     (etc (string-append out "/etc"))
                     (vulkan (assoc-ref inputs "vulkan-loader"))
                     (wayland-protocols (assoc-ref inputs "wayland-protocols")))
-               ;; Hard-code the path to libvulkan.so.
+               ;; Hard-code some store file names.
                (substitute* "gfx/common/vulkan_common.c"
                  (("libvulkan.so") (string-append vulkan "/lib/libvulkan.so")))
                (substitute* "gfx/common/wayland/generate_wayland_protos.sh"
@@ -1082,10 +1093,12 @@ emulation community.  It provides highly accurate emulation.")
                  (string-append wayland-protocols "/share/wayland-protocols")))
                (substitute* "qb/qb.libs.sh"
                  (("/bin/true") (which "true")))
+
                ;; Use shared zlib.
                (substitute* '("libretro-common/file/archive_file_zlib.c"
                               "libretro-common/streams/trans_stream_zlib.c")
                  (("<compat/zlib.h>") "<zlib.h>"))
+
                ;; The configure script does not yet accept the extra arguments
                ;; (like ‘CONFIG_SHELL=’) passed by the default configure phase.
                (invoke
diff --git a/gnu/packages/patches/retroarch-disable-online-updater.patch b/gnu/packages/patches/retroarch-disable-online-updater.patch
new file mode 100644
index 0000000000..99af848f6a
--- /dev/null
+++ b/gnu/packages/patches/retroarch-disable-online-updater.patch
@@ -0,0 +1,19 @@
+diff -Naur retroarch.a/menu/menu_setting.c retroarch.c/menu/menu_setting.c
+--- retroarch.a/menu/menu_setting.c	1970-01-01 01:00:01.000000000 +0100
++++ retroarch.c/menu/menu_setting.c	2019-11-29 18:13:05.999578841 +0100
+@@ -7292,6 +7292,7 @@
+                &subgroup_info,
+                parent_group);
+ 
++	 /*
+          CONFIG_ACTION(
+                list, list_info,
+                MENU_ENUM_LABEL_ONLINE_UPDATER,
+@@ -7299,6 +7300,7 @@
+                &group_info,
+                &subgroup_info,
+                parent_group);
++	 */
+ #endif
+ 
+          CONFIG_ACTION(
-- 
2.23.0

Mark H Weaver wrote on 30 Nov 2019 05:24

Re: bug#38360: Retroarch does violate FSDG

Recipients:(name . Arne Babenhauserheide)(address . arne_bab@web.de)

Message-ID:87wobi3s9f.fsf@netris.org

Hi Arne,

Arne Babenhauserheide <arne_bab@web.de> writes:

Toggle quote (14 lines)> Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
>
>> Guix,
>>
>> This is not about Schrödinger's proprietary-until-proven-innocent
>> binary.  The Updater includes at least two cores explicitly marked as
>> non-free in Debian:
>>
>>  libretro-genesisplusgx
>>  libretro-snes9x
>
> In non-free because they are non-commercial, not because they
> treacherous to users.

Your words "In non-free because they are non-commercial" are unclear.

I guess you meant to say "They are in non-free because they prohibit

commercial use". Is that right?

Toggle quote (3 lines)

> This is a distinction the FSF used to make until 2010 but dropped since then:

> https://web.archive.org/web/20100126044451/http://www.gnu.org/philosophy/categories.html#semi-freeSoftware

What distinction do you think was dropped by the FSF since 2010?

If you're suggesting that the Free Software Definition was changed in

2010 to allow programs that prohibit commercial use, you are certainly

mistaken.

The current Free Software Definition states:

“Free software” does not mean “noncommercial”. A free program must

be available for commercial use, commercial development, and

commercial distribution. Commercial development of free software is

no longer unusual; such free commercial software is very important.

You may have paid money to get copies of free software, or you may

have obtained copies at no charge. But regardless of how you got

your copies, you always have the freedom to copy and change the

software, even to sell copies.

https://www.gnu.org/philosophy/free-sw.html

Moreover, the GNU FSDG states:

A free system distribution must not steer users towards obtaining any

nonfree information for practical use, or encourage them to do so.

where "information for practical use" is defined as:

“Information for practical use” includes software, documentation,

fonts, and other data that has direct functional applications. It

does not include artistic works that have an aesthetic (rather than

functional) purpose, or statements of opinion or judgment.

https://www.gnu.org/distros/free-system-distribution-guidelines.html

Toggle quote (2 lines)

>> Disabling the Updater seems like an open & shut case to me.

Agreed.

Thanks,

Mark

Arne Babenhauserheide wrote on 30 Nov 2019 13:10

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:87zhgdr2d5.fsf@web.de

Mark H Weaver <mhw@netris.org> writes:

Toggle quote (22 lines)> Hi Arne,
>
> Arne Babenhauserheide <arne_bab@web.de> writes:
>
>> Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
>>
>>> Guix,
>>>
>>> This is not about Schrödinger's proprietary-until-proven-innocent
>>> binary.  The Updater includes at least two cores explicitly marked as
>>> non-free in Debian:
>>>
>>>  libretro-genesisplusgx
>>>  libretro-snes9x
>>
>> In non-free because they are non-commercial, not because they
>> treacherous to users.
>
> Your words "In non-free because they are non-commercial" are unclear.
> I guess you meant to say "They are in non-free because they prohibit
> commercial use".  Is that right?

Yes.

More exactly:

They are in non-free, because they prohibit commercial use, not because

they are treacherous to users.

Most proprietary programs are treacherous because they give their

creators power over their users. This is not the case for these cores.

Toggle quote (5 lines)

>> This is a distinction the FSF used to make until 2010 but dropped since then:

>> https://web.archive.org/web/20100126044451/http://www.gnu.org/philosophy/categories.html#semi-freeSoftware

> What distinction do you think was dropped by the FSF since 2010?

The distinction that was dropped is that non-commercial software which

provides the source and allows non-commercial use, changing and sharing

is less problematic that closed-source software.

The distinction to call that software semi-free.

Toggle quote (4 lines)

> If you're suggesting that the Free Software Definition was changed in

> 2010 to allow programs that prohibit commercial use, you are certainly

> mistaken.

I’m not suggesting that. I’m saying that before 2010 it had a friendlier

stance towards this non-commercial software.

I don’t know why that was changed, but I would assume that people abused

non-commercial licensing to trick people into using software for which

they would have to pay to use commercially.

But this is not the case here: The non-commercial cores do not offer

an option to pay for commercial rights. They are non-commercial because

this used to be the only way how you could release them without being

sued by Nintento, Sega, Sony & co.

Toggle quote (5 lines)

> Moreover, the GNU FSDG states:

> A free system distribution must not steer users towards obtaining any

> nonfree information for practical use, or encourage them to do so.

Now the question is whether allowing them to obtain such information is

encouragement or steering towards.

I agree that if there are no cores packaged, so users are forced to use

the online list to run retroarch at all is steering.

However when this is not the easiest way to use retroarch, it is no

longer steering them towards that.

And if there are cores available, retroarch presents the cores first,

along with license information (or at least it should display license

information, since there’s already a license-line shown).

Toggle quote (9 lines)

> where "information for practical use" is defined as:

> “Information for practical use” includes software, documentation,

> fonts, and other data that has direct functional applications. It

> does not include artistic works that have an aesthetic (rather than

> functional) purpose, or statements of opinion or judgment.

> <https://www.gnu.org/distros/free-system-distribution-guidelines.html>

I disagree with this, because I consider aestetics and and statements of

opinion or judgement as functional, too. They function on the mind

instead of computers, but they do function.

This is why what I write is copyleft licensed where I have that option.

But that’s another discussion.

For what I’m saying in practice, see my other longer email.

Best wishes,

Arne

Unpolitisch sein

heißt politisch sein

ohne es zu merken

Tobias Geerinckx-Rice wrote on 30 Nov 2019 22:20

Re: bug#38360: [PATCH] gnu: retroarch: Disable Online Updater [FSDG fix].

Recipients:(address . 38360-done@debbugs.gnu.org)

Message-ID:87a78dnjsj.fsf@nckx

Nicolò, Guix,

Tobias Geerinckx-Rice via Bug reports for GNU Guix ???

Toggle quote (6 lines)

> * gnu/packages/emulators.scm (retroarch)[source]: Add patch and

> snippet.

> * packages/patches/retroarch-disable-online-updater.patch: New

> file.

> * gnu/local.mk (dist_patch_DATA): Add it.

That patch was incomplete, but I've pushed a similar fix as

775497549c6114ebdce57e787c94d5fedc368e49.

I'm marking this as done. Let me know if there's anything I

missed.

Kind regards,

T G-R

Closed

Tobias Geerinckx-Rice wrote on 30 Nov 2019 22:58

Re: bug#38360: Retroarch might violate FSDG

Recipients:(address . 38360@debbugs.gnu.org)

Message-ID:877e3hni12.fsf@nckx

Arne,

Arne Babenhauserheide ???

Toggle quote (2 lines)

> Aren’t we overblocking here?

As of current master: very likely :-(

Regardless of (y)our opinions on commerce and freedom, downloading

executables that violate GNU's own Free Software Distribution

Guidelines is simply not an option.

However, it's very likely that I've now disabled more than

strictly necessary.

Kind regards,

T G-R

Andrew Wong wrote on 7 Nov 17:31 +0100

Reopen

Recipients:(address . control@debbugs.gnu.org)

Message-ID:D6D35B5E-58F1-418A-88A6-3A74BE834C07@icloud.com

reopen 38360 !

Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it

mumi current 38360

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

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date