bug#38360: Retroarch might violate FSDG

bug#38360: Retroarch might violate FSDG

[Nicolò Balzarotti]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

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 #2: Type: text/html, Size: 1296 bytes --]

bug#38360: Retroarch might violate FSDG

[Ludovic Courtès]

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’.

bug#38360: Retroarch might violate FSDG

[Nicolò Balzarotti]

[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]

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:

> 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 #2: Type: text/html, Size: 2710 bytes --]

bug#38360: Retroarch might violate FSDG

[Jesse Gibbons]

On Wed, 2019-11-27 at 00:26 +0100, Nicolò Balzarotti wrote:
> 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.
> 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?
> 
> 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.
> Thanks again,
> Nicolò
> 
> 
> [1] https://docs.libretro.com/guides/download-cores/
> [2] https://packages.debian.org/stretch/games/
> 
> 

bug#38360: Retroarch might violate FSDG

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]


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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

bug#38360: Retroarch does violate FSDG

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 3429 bytes --]

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 写道：
> 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.

> 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.

> 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!

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#38360: Retroarch might violate FSDG

[Nicolò Balzarotti]

[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]

Hi,

Il giorno mer 27 nov 2019 alle ore 21:48 Arne Babenhauserheide <
arne_bab@web.de> ha scritto:

>
> 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.


> 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


> 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ò

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

[-- Attachment #2: Type: text/html, Size: 3890 bytes --]

bug#38360: Retroarch might violate FSDG

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 3365 bytes --]


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

>> 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.

>> 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

>> 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.

> 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.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

bug#38360: Retroarch does violate FSDG

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 5157 bytes --]


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.

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

> 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)

> 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).

> 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.

>> 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.

>> 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.

> 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.

>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

bug#38360: Retroarch might violate FSDG

[Ludovic Courtès]

Hi Nicolò,

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

> 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.

> 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’.

bug#38360: Retroarch might violate FSDG

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

Ludovic Courtès 写道：
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#38360: Retroarch might violate FSDG

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

Tobias Geerinckx-Rice 写道：
> 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/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#38360: Retroarch might violate FSDG

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道：
>  $ echo 'menu_show_core_updater = "false"'
                                     ^^^^^
"true", of course…

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#38360: Retroarch might violate FSDG

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]


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

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

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

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

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

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

bug#38360: Retroarch does violate FSDG

[Mark H Weaver]

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?

> 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>

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

Agreed.

    Thanks,
      Mark

bug#38360: Retroarch does violate FSDG

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 3863 bytes --]


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

> 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.

>> 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.

> 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.

> 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).

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

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

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

Nicolò, Guix,

Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道：
> * 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#38360: Retroarch might violate FSDG

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

Arne,

Arne Babenhauserheide 写道：
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]