bug-guix
[Top][All Lists]
Advanced

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

bug#38360: Retroarch might violate FSDG


From: Jesse Gibbons
Subject: bug#38360: Retroarch might violate FSDG
Date: Tue, 26 Nov 2019 19:09:23 -0700
User-agent: Evolution 3.30.5

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






reply via email to

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