Re: MAME emulator is giving incentive to use non-free software

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

these are the approaches i can think:
*extremely conservative (eliminating false positive errors)[1]
 removing all emulators
*conservative (eliminating false positive errors)[1]
 make packages/executables like game1-emulator1, game1-emulator2, ...
and not allowing direct emulator installation/execution
*liberal (avoiding false positive errors[1] and false negative errors[2])
 allowing all emulators with free games know
*extremely liberal (eliminating false negative errors)[2]
 allowing all emulators

extremely liberal is naive because it just looks down in the
dependency dag, there's no reason to not look up
extremely conservative is naive because it doesn't allow completely free uses
conservative would solve the issues that originate this thread
liberal is more convenient in some cases

i consider conservative better, liberal ok, and any of the extremes unreasonable

fsdg doesn't allow extremely liberal (according to other people
interpretation), in ndiswrapper, for example:
"with one exception, all ndis drivers are nonfree--and the one free
one is a windows port of a native linux driver. so right now, this
isn't useful for anything besides using nonfree software"[3]

parabola follows extremely conservative with your-freedom_emu[4]

assuming we choose conservative; for wine, we can make guile-wine,
emacs-wine[5] and gnutls-wine[6], but remove wine

it seems there's at least one free game needing an emulator[7]

i think this is a discussion about fsdg[8] and we should discuss it at
gnu-linux-libre@nongnu.org

[1]https://en.wikipedia.org/wiki/false_positives_and_false_negatives#False_positive_error
[2]https://en.wikipedia.org/wiki/false_positives_and_false_negatives#False_negative_error
[3]https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
[4]https://www.parabola.nu/packages/libre/any/your-freedom_emu/
[5]https://lists.gnu.org/archive/html/guix-devel/2016-03/msg01216.html
[6]https://lists.gnu.org/archive/html/guix-devel/2014-11/msg00333.html
[7]http://pineight.com/lu/
[8]http://www.gnu.org/distros/free-system-distribution-guidelines.html

Re: MAME emulator is giving incentive to use non-free software

[Isaac David]

Hi,

Parabola does ship fully free emulators for which no free games
exist. At this moment the user has to opt-in for installing
your-freedom_emu to block those packages, so it actually falls
down somewhere between your "liberal" and "extremely liberal"
categories.

My view was that while useless in a 100% free environment just
having them installed and inspecting their user interfaces wouldn't
violate your freedom in any way. A free emulator with free
dependencies wouldn't be unethical unless it recommended using
proprietary software with it. However in the last few days I have
seen many arguments showing there are yet more valid uses I hadn't
imagined, like learning from the source code and testing portability
without leaving your comfy libre OS.

In a distro without unprivileged package management like Parabola
an opt-in blacklist could satisfy Jean Louis' parenting concerns, but
only until the point the unprivileged users determined to run non-free
software learn to look for applications outside the package manager.

(I lied. Parabola has unprivileged package management thanks to
Guix)[1]

Meanwhile other emulators and wine are completely out of the
question because there's free applications for them, even though
using the non-free ones is more common. Parabola documents emulators
extensively in a wiki page.[2] The wiki also considers aspects such
as the possibility of writing free software for free emulator
platforms which currently have no free games/applications as far as
it's known (i,e. whether free toolchains targeting those platforms
exist). I also had a good laugh learning about free emulators that
will only run on wine.


[1]: https://www.parabola.nu/packages/?q=guix
[2]: https://wiki.parabola.nu/Emulator_licensing_issues

Le mar. 29 mars 2016 à 10:31, alírio eyng <alirioeyng@gmail.com> a 
écrit :
> these are the approaches i can think:
> *extremely conservative (eliminating false positive errors)[1]
>  removing all emulators
> *conservative (eliminating false positive errors)[1]
>  make packages/executables like game1-emulator1, game1-emulator2, ...
> and not allowing direct emulator installation/execution
> *liberal (avoiding false positive errors[1] and false negative 
> errors[2])
>  allowing all emulators with free games know
> *extremely liberal (eliminating false negative errors)[2]
>  allowing all emulators
> 
> extremely liberal is naive because it just looks down in the
> dependency dag, there's no reason to not look up
> extremely conservative is naive because it doesn't allow completely 
> free uses
> conservative would solve the issues that originate this thread
> liberal is more convenient in some cases
> 
> i consider conservative better, liberal ok, and any of the extremes 
> unreasonable
> 
> fsdg doesn't allow extremely liberal (according to other people
> interpretation), in ndiswrapper, for example:
> "with one exception, all ndis drivers are nonfree--and the one free
> one is a windows port of a native linux driver. so right now, this
> isn't useful for anything besides using nonfree software"[3]
> 
> parabola follows extremely conservative with your-freedom_emu[4]
> 
> assuming we choose conservative; for wine, we can make guile-wine,
> emacs-wine[5] and gnutls-wine[6], but remove wine
> 
> it seems there's at least one free game needing an emulator[7]
> 
> i think this is a discussion about fsdg[8] and we should discuss it at
> gnu-linux-libre@nongnu.org
> 
> [1]https://en.wikipedia.org/wiki/false_positives_and_false_negatives#False_positive_error
> [2]https://en.wikipedia.org/wiki/false_positives_and_false_negatives#False_negative_error
> [3]https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
> [4]https://www.parabola.nu/packages/libre/any/your-freedom_emu/
> [5]https://lists.gnu.org/archive/html/guix-devel/2016-03/msg01216.html
> [6]https://lists.gnu.org/archive/html/guix-devel/2014-11/msg00333.html
> [7]http://pineight.com/lu/
> [8]http://www.gnu.org/distros/free-system-distribution-guidelines.html
> 

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

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

Isaac David:
>Parabola does ship fully free emulators for which no free games
>exist. At this moment the user has to opt-in for installing
>your-freedom_emu to block those packages, so it actually falls
>down somewhere between your "liberal" and "extremely liberal"
>categories.
"parabola follows extremely liberal without your-freedom_emu"
i thought it was common knowledge/implicit, my mistake

>My view was that while useless in a 100% free environment just
>having them installed and inspecting their user interfaces wouldn't
>violate your freedom in any way. A free emulator with free
>dependencies wouldn't be unethical unless it recommended using
>proprietary software with it.
agreed, but we shouldn't package useless things

> However in the last few days I have
>seen many arguments showing there are yet more valid uses I hadn't
>imagined, like learning from the source code and testing portability
>without leaving your comfy libre OS.
source code is out of question for a distro, unless you want to
compile and execute it (or just have a package that copy the source
code); but developing without a game is like developing without a test
suite...
"testing portability without leaving your comfy libre os" would only
be impeded by extremely conservative, that i reject

>In a distro without unprivileged package management like Parabola
>an opt-in blacklist could satisfy Jean Louis' parenting concerns, but
>only until the point the unprivileged users determined to run non-free
>software learn to look for applications outside the package manager.
applying a policy to unwilling people is a security issue, out of question
i'm interested in lessening the effort to remain in freedom (for
people willing it)
but your-freedom_emu is extremely conservative, it deny free uses; that i reject

>Meanwhile other emulators and wine are completely out of the
>question because there's free applications for them
i translate it as "extremely conservative/conservative is completely
out of the question"

you missed the main argument
"extremely liberal is naive because it just looks down in the
dependency dag, there's no reason to not look up"
i think i should try to explain better, included is a image
(emulator-dependency-dag.svg)
to _execute_ an emulator _usefully_, and to test during development,
we need all dependencies and a game
every one agree that if one dependency is nonfree, we can't _execute_
an emulator _usefully_ in freedom
several people miss: if all games are nonfree, we also can't _execute_
an emulator _usefully_ in freedom

maybe an analogy:
*extremely conservative is like nonfree software
*conservative is like agpl
*liberal is like gpl
*extremely liberal is like public domain
nonfree software is unreasonable (unethical) because it denies freedom
public domain is unreasonable (not unethical) because it doesn't protect freedom
gpl restrict freedom _directly_; gpl2 can't be linked with gpl3, even
both being free software; but it gives more freedom _indirectly_; and
in most cases we can make an exception, just releasing the gpl2 as
gpl2+
agpl gives yet more freedom, although it is more inconvenient in some cases

so agpl is better, gpl ok and public domain unreasonable (not
unethical), if your aim is freedom
_not denying_ freedom and _actively protecting_ it are different
even if _actively protecting_ freedom is inconvenient and we need to
make some exceptions, i believe it is better

expecting the user to evaluate if some game is free is making it
unnecessarily difficult to remain in freedom
making game packages/executables and not emulator packages/executables
would allow all know good uses and still signal the user to be
cautious with other games

[-- Attachment #2: emulator-dependency-dag.svg --]
[-- Type: image/svg+xml, Size: 6891 bytes --]

Re: MAME emulator is giving incentive to use non-free software

[Ricardo Wurmus]

alírio eyng <alirioeyng@gmail.com> writes:

> Isaac David:
>> However in the last few days I have
>>seen many arguments showing there are yet more valid uses I hadn't
>>imagined, like learning from the source code and testing portability
>>without leaving your comfy libre OS.
> source code is out of question for a distro, unless you want to
> compile and execute it (or just have a package that copy the source
> code); but developing without a game is like developing without a test
> suite...

I don’t understand this.  I regularly look at the sources of programmes
I find interesting.  Guix makes this very easy with

    guix build -S name

You don’t have to compile and execute it to find source code useful.

I also disagree with the second part of the last sentence.  You don’t
have to hack on the emulator, but you can hack on an existing free game
or write your own.

> expecting the user to evaluate if some game is free is making it
> unnecessarily difficult to remain in freedom
> making game packages/executables and not emulator packages/executables
> would allow all know good uses and still signal the user to be
> cautious with other games

This limits the use of the emulator.  You seem to think that an emulator
is only useful as a runtime dependency for a game, but I and others in
this thread disagree.

~~ Ricardo

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

On 4/1/16, Ricardo Wurmus <rekado@elephly.net> wrote:
> alírio eyng <alirioeyng@gmail.com> writes:
>> Isaac David:
>>> However in the last few days I have
>>>seen many arguments showing there are yet more valid uses I hadn't
>>>imagined, like learning from the source code and testing portability
>>>without leaving your comfy libre OS.
>> source code is out of question for a distro, unless you want to
>> compile and execute it (or just have a package that copy the source
>> code); but developing without a game is like developing without a test
>> suite...
> I don’t understand this.  I regularly look at the sources of programmes
> I find interesting.
how do you find it interesting without executing it?

> You don’t have to compile and execute it to find source code useful.
agreed; but as i argued, if you never will execute, just have a
package that copy the source code or not include in the distro

> You don’t
> have to hack on the emulator, but you can hack on an existing free game
> or write your own.
agreed
a free game would be allowed by conservative approach as i described
a free game would only be disallowed by extremely conservative
approach as i described, that i reject

>> expecting the user to evaluate if some game is free is making it
>> unnecessarily difficult to remain in freedom
>> making game packages/executables and not emulator packages/executables
>> would allow all know good uses and still signal the user to be
>> cautious with other games
>
> This limits the use of the emulator.  You seem to think that an emulator
> is only useful as a runtime dependency for a game, but I and others in
> this thread disagree.
i want to allow all good uses, they all can have exceptions
i believe the best way to _actively protect_ freedom is with a policy
with some compromise, this don't mean the exceptions justify changing
the rule
you seem to think i'm defending extremely conservative, that i reject
most people in this thread seem only choosing between extremely
conservative or extremely liberal, i reject extremely conservative; so
i also would prefer extremely liberal, if that was a binary choice;
i'm arguing it isn't

i believe the _main_ use of a emulator is as a runtime dependency for
a game, and we should apply the same reasoning behind ndiswrapper
"with one exception, all ndis drivers are nonfree--and the one free
one is a windows port of a native linux driver. so right now, this
isn't useful for anything besides using nonfree software"[1]
obviously i can say i want to look at ndiswrapper source code, and
this should be allowed
but this don't justify including ndiswrapper executable in a free distro

[1]https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

Ivan Zaigralin:
> Yes, it emulates non-free software.
wait, this is missing the point
there are several categories of software that are itself free and can
be used to run (directly or indirectly) nonfree software:

nonfree down in dag: dosemu
_only_ nonfree up in dag: ndiswrapper
nonfree oriented community: wine
free oriented community: gcc

nonfree down is nonfree, you can't build it in freedom
nonfree up is nonfree, you can't execute it _usefully_ in freedom
nonfree community, example:
if i go to appdb in wine site, from the "top-10 platinum", nine have
"license: retail", one have "license: free to use"; they not just
promote nonfree software but also spread misleading information; this
should be "price: nongratis" and "price: gratis"

my approach was to remove nonfree down and nonfree up and hide the
package/executable of nonfree community

joshua proposed forking nonfree community[1]; this is still better,
and still more effort

> No, it's no longer relevant. I mean,
> it's no longer relevant as software, but only as the historical record
> of what entertainment software was like in the times of yore. New
> nonfree games are being written today in order to seduce people, so I
> can see why something like wine is dangerous, but no one, no one will
> get seduced by a museum piece.
wine-supported nonfree programs are increasing, mame-supported nonfree
programs don't.
so wine should get priority, if they are in the same category

> MAME does not give any incentive to use
> non-free software, because all of this old software is obsolete and
> useless. But it does give an ability to study it from the historical
> perspective, which is a good thing.
not sure what it means
maybe "mame source code should be allowed to be studied"?
 sure, but this don't justify including executables
maybe "using nonfree software with historical interest is ok"?
 i don't believe the motive to use it (fun, nostalgia, historical
interest) justify nonfree software

from [2], for _most_ hardware it emulates, mame is nonfree up, you
can't execute it _usefully_ in freedom (note _usefully_ means
something more than playing with menus or commandline switches)
so i think mame should be broke down, as there are parts in different categories

[1]http://lists.nongnu.org/archive/html/gnu-linux-libre/2016-04/msg00005.html
[2]http://docs.mamedev.org/basicuse/gettingstarted.html#system-requirements,
section "BIOS Dumps and Software"

Re: MAME emulator is giving incentive to use non-free software

[Denis 'GNUtoo' Carikli]

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

On Tue, 29 Mar 2016 16:31:40 +0000
alírio eyng <alirioeyng@gmail.com> wrote:

> these are the approaches i can think:
> *extremely conservative (eliminating false positive errors)[1]
>  removing all emulators
> *conservative (eliminating false positive errors)[1]
>  make packages/executables like game1-emulator1, game1-emulator2, ...
> and not allowing direct emulator installation/execution
> *liberal (avoiding false positive errors[1] and false negative
> errors[2]) allowing all emulators with free games know
> *extremely liberal (eliminating false negative errors)[2]
>  allowing all emulators
Why not just requiring some documentation along the emulator that
documents at least one fully free software that can run on it.

That software would have to be able to be built and run 100% free
software.

Making that documentation available and known to the user will steer
that user toward free software.

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: MAME emulator is giving incentive to use non-free software

[Denis 'GNUtoo' Carikli]

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

On Wed, 30 Mar 2016 16:30:17 -0600
Isaac David <isacdaavid@isacdaavid.info> wrote:

> Hi,
Hi,

> My view was that while useless in a 100% free environment just
> having them installed and inspecting their user interfaces wouldn't
> violate your freedom in any way. A free emulator with free
> dependencies wouldn't be unethical unless it recommended using
> proprietary software with it. However in the last few days I have
> seen many arguments showing there are yet more valid uses I hadn't
> imagined, like learning from the source code and testing portability
> without leaving your comfy libre OS.
Just requiring documentation that shows how at least one valid use case
(that works) while remaining 100% free would be great:
It would fix the issue for good, while improving users freedom by
limiting the steer towards non-free software that such virtual machines
create.

For instance:
- For qemu, libvirt and so on, we would ship or point to documentation
  explaining how to run a 100% free software distribution like Trisquel.
- For wine we would document compiling and running of a 100% free
  software.
- For emulators, unless 100% free distributions do exist for the
  machines they emulate, we'd document how to compile and run an
  application or game.
- For emulators that have no 100% free games but that have a toolchain,
  we could document how to do compile and run a hello world. That would
  count as 100% free software compiling and running.

> Meanwhile other emulators and wine are completely out of the
> question because there's free applications for them, even though
> using the non-free ones is more common.
I don't doubt that, however is it possible to compile and run such
applications 100% free? Since some GNU software is ported on wine, I
would guess that there is a way to do it, but I've no proof.
I fear that some free software applications would include some non-free
runtime libraries. Given how poorly I know non-free OS, I've no idea if
it's a legitimate concern.

> Parabola documents emulators extensively in a wiki page.
Should we document how to compile and run free software there, or
should we ship that documentation with the package?
In the former case, should we point the user to the wiki page at the
end of the package installation, in the case of Parabola.

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [GNU-linux-libre] MAME emulator is giving incentive to use non-free software

[alírio eyng]

On 4/2/16, Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> wrote:
> Why not just requiring some documentation along the emulator that
> documents at least one fully free software that can run on it.
this is missing some complexity:
we don't want something better done natively (we exclude ndiswrapper)[1]
but we still want to allow introducing free software on nonfree platforms[2]

i think packaging is better than documenting, shouldn't be much more effort

but this doesn't address the problem of discernment
example: i can go to [3] and see there are four games, i know they are
free because they are inside a free distro frontier
if users need to exit the free distro frontier, they probably will
find nonfree and free games and don't see much difference
the ideal would be to have a comprehensive set of games packaged
inside the free distro frontier

hiding the emulator executable/package would warn when they are
exiting the free distro frontier and poke them to add free games to
the distro (suggesting to developers or sending patches)
alternatively, forking all emulators and creating a free community
around them would also provide a freedom frontier

[1]https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
[2]https://lists.gnu.org/archive/html/guix-devel/2014-11/msg00333.html
[3]http://packages.trisquel.info/belenos-updates/scummvm

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

i think i got the root of the controversy:
some people started to think of emulators as hardware (replacements)
 hardware is useful to develop to
some people started to think of emulators as obsolete apis
 obsolete apis are not useful to develop to

i still see emulators (like ndiswrapper) as obsolete apis; without
free applications that can't run natively they are useless and should
be removed so the user doesn't run nonfree software by mistake
unless they emulate current hardware (like qemu), in this case they
are useful in themselves (don't need a free application that can't run
natively), just being hardware replacements helping development
wine is a exception to introduce free software in nonfree platforms

the compromise is define _current hardware_
"MAME now documents a wide variety of (mostly vintage) computers"[1]
_vintage_ seems undoubtly out _current hardware_

i also noticed i was conflating technical details i shouldn't
my approach was to make an opt-out whitelist of free uses (mostly
games) for packages with a nonfree community (mostly emulators like
mame or wine) implemented with the package manager/filesystem

[1]http://mamedev.org/

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

Tobias Platen:
> Emulators can be useful for reverse engineering
reverse engineering is the action of understanding undocumented
interfaces (mostly hardware).
emulators are the _result_ of reverse engineering, not tools to do it.
this result is useless if there's no other interface implementations
to develop things to or free software requiring it to run.

> In the case of MAME at least some files will be usable to build new works.
sure, but if they are to be used as source, this don't justify
inclusion of executables in a free distro.

> Some of those old FM-based sound synthesizer chips are emulated with MAME
sounds like obsolete api, is there any reason to use it instead of
using sound synthesizer software?

> Ndiswrapper is a different case, because it implements a proprietary interface of the Windows Kernel.
"proprietary interface" is misleading.
there are _undocumented_ interfaces and maybe _legally unusable_ interfaces [1].
ndiswrapper implements an undocumented interface originally meant as
software (api).
mame implements undocumented interfaces originally meant as hardware.
the only difference is the original intentions, and i think they are
not relevant.

> sometimes I use Wine, but only when I need to reverse engineer a proprietary format.
i think you meant you use nonfree software on top of wine with the
intention of reverse engineering it.
this is a compromise acceptable to use nonfree software, if "the use
of the nonfree software aims directly at putting an end to the use of
that very same nonfree software" [2].
but this isn't related to wine (or other emulators) at all and apply
to _all_ nonfree software.
free distros choose the compromise of making this a little harder by
not supporting nonfree software so people are not mislead in using it.
but it is still reasonably easy to opt-out of the free distro
whitelist and use nonfree software if wanted.

[1]https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.
[2]https://www.gnu.org/philosophy/is-ever-good-use-nonfree-program.en.html

Re: MAME emulator is giving incentive to use non-free software

[Felipe Sanches]

On Sun, Apr 3, 2016 at 3:36 PM, alírio eyng <alirioeyng@gmail.com> wrote:
> Tobias Platen:
>> Emulators can be useful for reverse engineering
> reverse engineering is the action of understanding undocumented
> interfaces (mostly hardware).
> emulators are the _result_ of reverse engineering, not tools to do it.
> this result is useless if there's no other interface implementations
> to develop things to or free software requiring it to run.

I completely disagree!
I have been actively using MAME to perform reverse engineering of
non-free firmware for a bit more than a couple years.
Since I do it myself, I know my sentence is true :-)

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

Felipe Sanches:
>On Sun, Apr 3, 2016 at 3:36 PM, alírio eyng <address@hidden> wrote:
>> Tobias Platen:
>>> Emulators can be useful for reverse engineering
...
>> emulators are the _result_ of reverse engineering, not tools to do it.
...
>I completely disagree!
>I have been actively using MAME to perform reverse engineering of
>non-free firmware for a bit more than a couple years.
this is missing the point.
you are using mame to _run_ non-free firmware and performing reverse
engineering on a running non-free firmware.
but if we support running non-free software (or firmware) on an
emulator there's no point in not supporting non-free software outside
it. e.g. skype
because i can say its useful to run skype to reverse engineer it, and
this is true.

free distros choose the compromise of making this a little harder by
not supporting nonfree software so people are not mislead in using it.
but it is still reasonably easy to opt-out of the free distro
whitelist and use nonfree software if wanted.

Re: MAME emulator is giving incentive to use non-free software

[Felipe Sanches]

I will attempt to stop posting to this thread because I think I
already presented all of my points here.

To summarize my conclusions:
I think MAME is likely not compatible with the free sw distro
guidelines. And I think shipping a prebuilt binary package of MAME is
not really useful for **most** of the things that MAME is useful other
than playing non-free games. Whether it should or shouldn't be
acceptable on such distros policies is still an ongoing debate,
though.

I still think that MAME is a very useful asset for education on
electronics, hardware design, reverse engineering techniques, and
similar topics as well as for the historical preservation of our
technological legacy (even if it's a legacy of mostly non-free
programs, we still must not "burn books", right?). But the way to
**truly appreciate** all of that is probably by really fetching MAME
from git and inspecting its source code. So, the whole packaging
debate is of not much value in that context (in my opinion), even
though it is nice as a sort of brainstorming or some sort of
intellectual exploration of ideas.

Having said it all, I will try not to talk here any more, unless I
have something really new to say.
Happy Hacking
Felipe Sanches

On Sun, Apr 3, 2016 at 6:02 PM, alírio eyng <alirioeyng@gmail.com> wrote:
> Felipe Sanches:
>>On Sun, Apr 3, 2016 at 3:36 PM, alírio eyng <address@hidden> wrote:
>>> Tobias Platen:
>>>> Emulators can be useful for reverse engineering
> ...
>>> emulators are the _result_ of reverse engineering, not tools to do it.
> ...
>>I completely disagree!
>>I have been actively using MAME to perform reverse engineering of
>>non-free firmware for a bit more than a couple years.
> this is missing the point.
> you are using mame to _run_ non-free firmware and performing reverse
> engineering on a running non-free firmware.
> but if we support running non-free software (or firmware) on an
> emulator there's no point in not supporting non-free software outside
> it. e.g. skype
> because i can say its useful to run skype to reverse engineer it, and
> this is true.
>
> free distros choose the compromise of making this a little harder by
> not supporting nonfree software so people are not mislead in using it.
> but it is still reasonably easy to opt-out of the free distro
> whitelist and use nonfree software if wanted.
>

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

Felipe Sanches:
>I think MAME is likely not compatible with the free sw distro
>guidelines.
ignoring the trademark; as a whole, mame is in the same category as
wine, which is allowed.
but most parts of it are in the same category as ndiswrapper; i don't
think this parts should be allowed just because they are bundled
together.

>I think shipping a prebuilt binary package of MAME is
>not really useful for **most** of the things that MAME is useful other
>than playing non-free games.
...
>I still think that MAME is a very useful asset for education on
>electronics, hardware design, reverse engineering techniques, and
>similar topics as well as for the historical preservation of our
>technological legacy (even if it's a legacy of mostly non-free
>programs, we still must not "burn books", right?).
i think the argument here is "obsolete interfaces are useful by themselves".
this imply reversing the decision on ndiswrapper.
this is a valid approach (eliminating false negative errors)[1] but
probably not the best way to protect freedom.

>I will try not to talk here any more, unless I
>have something really new to say.
i will probably continue replying while people are quoting me and
making proposals or confusing general-purpose runtime dependencies
with tools for reverse engineering without understanding the
consequences.

[1]https://en.wikipedia.org/wiki/false_positives_and_false_negatives#False_negative_error

Re: MAME emulator is giving incentive to use non-free software

[Felipe Sanches]

On Mon, Apr 4, 2016 at 12:26 AM, alírio eyng <alirioeyng@gmail.com> wrote:
> Felipe Sanches:
>>I will try not to talk here any more, unless I
>>have something really new to say.
> i will probably continue replying while people are quoting me and
> making proposals or confusing general-purpose runtime dependencies
> with tools for reverse engineering without understanding the
> consequences.

MAME provides an interactive debugger that enables reverse engineering
of the loaded ROMs.

http://letshackarcadegames.com/?p=338

http://letshackarcadegames.com/wp-content/uploads/2015/09/dkong_watchpoint_barrel.png

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

Felipe Sanches:
>MAME provides an interactive debugger
so mame is not just an emulator.
it is a emulator, disassembler and debugger.
this is relevant information i can't see in official documentation, thanks.

it seems even with a obsolete executable format, it can be a
interesting development environment.
a interesting development environment is useful in itself and don't
need free games.
is there a similar environment to a current architecture?
can this development environment be used in freedom to develop a game
from scratch?
this development environment works for all architectures mame supports?

Re: [GNU-linux-libre] MAME emulator is giving incentive to use non-free software

[Felipe Sanches]

On Mon, Apr 4, 2016 at 7:23 PM, alírio eyng <alirioeyng@gmail.com> wrote:
> Felipe Sanches:
>>MAME provides an interactive debugger
> so mame is not just an emulator.
> it is a emulator, disassembler and debugger.
> this is relevant information i can't see in official documentation, thanks.
>
> it seems even with a obsolete executable format, it can be a
> interesting development environment.
> a interesting development environment is useful in itself and don't
> need free games.
> is there a similar environment to a current architecture?
> can this development environment be used in freedom to develop a game
> from scratch?

Yes. I did it.
https://github.com/garoa/GunSmoke/tree/master/

> this development environment works for all architectures mame supports?
Yes. The debugger dialog is generic and you get it automatically as a
bonus if you implement a new CPU emulation module. This happened with
me a couple times already. I got access to the technical manuals of
the first computer designed and manufactured in Brazil, which was
called "Patinho Feio" (meaning something like "Ugly Duckling
Computer"). I got the printed documentation from the hands of one of
my university professors at the engineering school. He was involved in
the team that developed the pioneer computer back in 1972.

Based on the documentation (which I published it all on the Internet
Archive with authorization form the original author:
https://archive.org/details/Montador_do_Patinho_Feio__Julho1977) I
wrote a new CPU emulation driver in MAME to emulate the custom
instruction set of this Brazilian machine. Not only emulation works
when loading its sample software - a trivially simple hello-world
extracted from a punched data tape, trivial enough to not even be
copyrightable I guess... - It also allows me to run the code step by
step and to inspect the system memory because the whole debugging
framework was "magically" inherited by the way MAME codebase is
structured.

So this makes it sure that absolutely every CPU architecture supported
by MAME does also provide such nice interactive debugger. And the list
of supported CPUs is absurdly broad:

felipe@guarana:~/mame/src/devices/cpu$ ls
8x300      arm       drcbec.cpp    drccache.h  e0c6200   hd61700
i860     m6800     mcs51        pdp8       sc61860  sm8500   tms32010
ucom4    x86emit.h
adsp2100   arm7      drcbec.h      drcfe.cpp   e132xs    hmcs40
i960     m68000    mcs96        pic16c5x   scmp     spc700   tms32025
uml.cpp  x86log.cpp
alph8201   asap      drcbeut.cpp   drcfe.h     es5510    hphybrid
ie15     m6805     melps4       pic16c62x  score    ssem     tms32031
uml.h    x86log.h
alto2      avr8      drcbeut.h     drcuml.cpp  esrip     i386
jaguar   m6809     minx         powerpc    scudsp   ssp1601  tms32051
unsp     z180
am29000    ccpu      drcbex64.cpp  drcuml.h    f8        i4004
lc8670   mb86233   mips         pps4       se3208   superfx  tms32082
upd7725  z8
amis2000   cop400    drcbex64.h    drcumlsh.h  g65816    i8008
lh5801   mb86235   mn10200      psx        sh2      t11      tms34010
upd7810  z80
apexc      cosmac    drcbex86.cpp  dsp16       h6280     i8085
lr35902  mb88xx    nec          rsp        sh4      tlcs90   tms57002
v30mz    z8000
arc        cp1610    drcbex86.h    dsp32       h8        i8089
m37710   mc68hc11  patinhofeio  s2650      sharc    tlcs900  tms7000
v60
arcompact  cubeqcpu  drccache.cpp  dsp56k      hcd62121  i86
m6502    mcs48     pdp1         saturn     sm510    tms1000  tms9900
v810

Re: MAME emulator is giving incentive to use non-free software

[Felipe Sanches]

The other situation when I was able to benefit from the automatically
generated custom debugger UI was when working on emulating the
(non-free) game Another World from the 90's. It was originally
executed on Amiga computers, so the debugger would let me see the
opcodes of the Amiga CPU. But the game was actually originally
implemented in a custom virtual machine created by its author, Eric
Chahi. I decided to emulate this virtual machine in MAME as if it were
a real CPU. The end-result was that I got for the first time the
ability to inspect the game (non-free) bytecode at the virtual-machine
level by running it on the automatically generated debugger that MAME
provides.

This opens up a new level of insight on the internal workings of the
program that was never possible before with so much ease. A screenshot
of that can be seen here:
https://twitter.com/juca_gnu/status/686597622417719296

Happy Hacking,
Felipe Sanches

On Mon, Apr 4, 2016 at 7:47 PM, Felipe Sanches <juca@members.fsf.org> wrote:
> On Mon, Apr 4, 2016 at 7:23 PM, alírio eyng <alirioeyng@gmail.com> wrote:
>> Felipe Sanches:
>>>MAME provides an interactive debugger
>> so mame is not just an emulator.
>> it is a emulator, disassembler and debugger.
>> this is relevant information i can't see in official documentation, thanks.
>>
>> it seems even with a obsolete executable format, it can be a
>> interesting development environment.
>> a interesting development environment is useful in itself and don't
>> need free games.
>> is there a similar environment to a current architecture?
>> can this development environment be used in freedom to develop a game
>> from scratch?
>
> Yes. I did it.
> https://github.com/garoa/GunSmoke/tree/master/
>
>> this development environment works for all architectures mame supports?
> Yes. The debugger dialog is generic and you get it automatically as a
> bonus if you implement a new CPU emulation module. This happened with
> me a couple times already. I got access to the technical manuals of
> the first computer designed and manufactured in Brazil, which was
> called "Patinho Feio" (meaning something like "Ugly Duckling
> Computer"). I got the printed documentation from the hands of one of
> my university professors at the engineering school. He was involved in
> the team that developed the pioneer computer back in 1972.
>
> Based on the documentation (which I published it all on the Internet
> Archive with authorization form the original author:
> https://archive.org/details/Montador_do_Patinho_Feio__Julho1977) I
> wrote a new CPU emulation driver in MAME to emulate the custom
> instruction set of this Brazilian machine. Not only emulation works
> when loading its sample software - a trivially simple hello-world
> extracted from a punched data tape, trivial enough to not even be
> copyrightable I guess... - It also allows me to run the code step by
> step and to inspect the system memory because the whole debugging
> framework was "magically" inherited by the way MAME codebase is
> structured.
>
> So this makes it sure that absolutely every CPU architecture supported
> by MAME does also provide such nice interactive debugger. And the list
> of supported CPUs is absurdly broad:
>
> felipe@guarana:~/mame/src/devices/cpu$ ls
> 8x300      arm       drcbec.cpp    drccache.h  e0c6200   hd61700
> i860     m6800     mcs51        pdp8       sc61860  sm8500   tms32010
> ucom4    x86emit.h
> adsp2100   arm7      drcbec.h      drcfe.cpp   e132xs    hmcs40
> i960     m68000    mcs96        pic16c5x   scmp     spc700   tms32025
> uml.cpp  x86log.cpp
> alph8201   asap      drcbeut.cpp   drcfe.h     es5510    hphybrid
> ie15     m6805     melps4       pic16c62x  score    ssem     tms32031
> uml.h    x86log.h
> alto2      avr8      drcbeut.h     drcuml.cpp  esrip     i386
> jaguar   m6809     minx         powerpc    scudsp   ssp1601  tms32051
> unsp     z180
> am29000    ccpu      drcbex64.cpp  drcuml.h    f8        i4004
> lc8670   mb86233   mips         pps4       se3208   superfx  tms32082
> upd7725  z8
> amis2000   cop400    drcbex64.h    drcumlsh.h  g65816    i8008
> lh5801   mb86235   mn10200      psx        sh2      t11      tms34010
> upd7810  z80
> apexc      cosmac    drcbex86.cpp  dsp16       h6280     i8085
> lr35902  mb88xx    nec          rsp        sh4      tlcs90   tms57002
> v30mz    z8000
> arc        cp1610    drcbex86.h    dsp32       h8        i8089
> m37710   mc68hc11  patinhofeio  s2650      sharc    tlcs900  tms7000
> v60
> arcompact  cubeqcpu  drccache.cpp  dsp56k      hcd62121  i86
> m6502    mcs48     pdp1         saturn     sm510    tms1000  tms9900
> v810

Re: MAME emulator is giving incentive to use non-free software

[Felipe Sanches]

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

I am also sending the screenshot of the Another World virtual machine
debugger as an attachment to this message.

On Mon, Apr 4, 2016 at 7:58 PM, Felipe Sanches <juca@members.fsf.org> wrote:
> The other situation when I was able to benefit from the automatically
> generated custom debugger UI was when working on emulating the
> (non-free) game Another World from the 90's. It was originally
> executed on Amiga computers, so the debugger would let me see the
> opcodes of the Amiga CPU. But the game was actually originally
> implemented in a custom virtual machine created by its author, Eric
> Chahi. I decided to emulate this virtual machine in MAME as if it were
> a real CPU. The end-result was that I got for the first time the
> ability to inspect the game (non-free) bytecode at the virtual-machine
> level by running it on the automatically generated debugger that MAME
> provides.
>
> This opens up a new level of insight on the internal workings of the
> program that was never possible before with so much ease. A screenshot
> of that can be seen here:
> https://twitter.com/juca_gnu/status/686597622417719296
>
> Happy Hacking,
> Felipe Sanches
>
> On Mon, Apr 4, 2016 at 7:47 PM, Felipe Sanches <juca@members.fsf.org> wrote:
>> On Mon, Apr 4, 2016 at 7:23 PM, alírio eyng <alirioeyng@gmail.com> wrote:
>>> Felipe Sanches:
>>>>MAME provides an interactive debugger
>>> so mame is not just an emulator.
>>> it is a emulator, disassembler and debugger.
>>> this is relevant information i can't see in official documentation, thanks.
>>>
>>> it seems even with a obsolete executable format, it can be a
>>> interesting development environment.
>>> a interesting development environment is useful in itself and don't
>>> need free games.
>>> is there a similar environment to a current architecture?
>>> can this development environment be used in freedom to develop a game
>>> from scratch?
>>
>> Yes. I did it.
>> https://github.com/garoa/GunSmoke/tree/master/
>>
>>> this development environment works for all architectures mame supports?
>> Yes. The debugger dialog is generic and you get it automatically as a
>> bonus if you implement a new CPU emulation module. This happened with
>> me a couple times already. I got access to the technical manuals of
>> the first computer designed and manufactured in Brazil, which was
>> called "Patinho Feio" (meaning something like "Ugly Duckling
>> Computer"). I got the printed documentation from the hands of one of
>> my university professors at the engineering school. He was involved in
>> the team that developed the pioneer computer back in 1972.
>>
>> Based on the documentation (which I published it all on the Internet
>> Archive with authorization form the original author:
>> https://archive.org/details/Montador_do_Patinho_Feio__Julho1977) I
>> wrote a new CPU emulation driver in MAME to emulate the custom
>> instruction set of this Brazilian machine. Not only emulation works
>> when loading its sample software - a trivially simple hello-world
>> extracted from a punched data tape, trivial enough to not even be
>> copyrightable I guess... - It also allows me to run the code step by
>> step and to inspect the system memory because the whole debugging
>> framework was "magically" inherited by the way MAME codebase is
>> structured.
>>
>> So this makes it sure that absolutely every CPU architecture supported
>> by MAME does also provide such nice interactive debugger. And the list
>> of supported CPUs is absurdly broad:
>>
>> felipe@guarana:~/mame/src/devices/cpu$ ls
>> 8x300      arm       drcbec.cpp    drccache.h  e0c6200   hd61700
>> i860     m6800     mcs51        pdp8       sc61860  sm8500   tms32010
>> ucom4    x86emit.h
>> adsp2100   arm7      drcbec.h      drcfe.cpp   e132xs    hmcs40
>> i960     m68000    mcs96        pic16c5x   scmp     spc700   tms32025
>> uml.cpp  x86log.cpp
>> alph8201   asap      drcbeut.cpp   drcfe.h     es5510    hphybrid
>> ie15     m6805     melps4       pic16c62x  score    ssem     tms32031
>> uml.h    x86log.h
>> alto2      avr8      drcbeut.h     drcuml.cpp  esrip     i386
>> jaguar   m6809     minx         powerpc    scudsp   ssp1601  tms32051
>> unsp     z180
>> am29000    ccpu      drcbex64.cpp  drcuml.h    f8        i4004
>> lc8670   mb86233   mips         pps4       se3208   superfx  tms32082
>> upd7725  z8
>> amis2000   cop400    drcbex64.h    drcumlsh.h  g65816    i8008
>> lh5801   mb86235   mn10200      psx        sh2      t11      tms34010
>> upd7810  z80
>> apexc      cosmac    drcbex86.cpp  dsp16       h6280     i8085
>> lr35902  mb88xx    nec          rsp        sh4      tlcs90   tms57002
>> v30mz    z8000
>> arc        cp1610    drcbex86.h    dsp32       h8        i8089
>> m37710   mc68hc11  patinhofeio  s2650      sharc    tlcs900  tms7000
>> v60
>> arcompact  cubeqcpu  drccache.cpp  dsp56k      hcd62121  i86
>> m6502    mcs48     pdp1         saturn     sm510    tms1000  tms9900
>> v810

[-- Attachment #2: 2016_JAN_11_AnotherWolrd_interactive_debugger.png --]
[-- Type: image/png, Size: 203556 bytes --]

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

Felipe Sanches:
>On Mon, Apr 4, 2016 at 7:23 PM, alírio eyng <address@hidden> wrote:
>> this development environment works for all architectures mame supports?
>Yes. The debugger dialog is generic
...
>mame/src/devices/cpu$ ls
...
>i386
the debugger works on all architectures
i can use i386
i can use z80 and read your code as example
it still seem useless supporting obselete architectures with only
nonfree software depending on it

Re: MAME emulator is giving incentive to use non-free software

[Denis 'GNUtoo' Carikli]

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

On Sat, 2 Apr 2016 08:48:58 +0000
alírio eyng <alirioeyng@gmail.com> wrote:

> On 4/2/16, Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> wrote:
> > Why not just requiring some documentation along the emulator that
> > documents at least one fully free software that can run on it.  
> this is missing some complexity:
> we don't want something better done natively (we exclude
> ndiswrapper)[1] but we still want to allow introducing free software
> on nonfree platforms[2]
My point was that documentation (and packaging as you point it) can
steer users towards free software.

The goal of the software may even be altered this way, if it cannot
be used fully free with its regular uses cases.

The former case might be faster to do, but getting it right would be
difficult since the user would have to be aware of that documentation.

Which one to do would then depend on the context.
For instance with qemu and libvirt, the software was modified not to
steer users towards running non-free GNU/Linux distributions.

While unrelated, the case of debootstrap is also interesting, since, on
parabola, it by default debootstraps free software distributions.
References and configuration related to non-100%-free distributions
were removed.

> i think packaging is better than documenting, shouldn't be much more
> effort
Right, I assumed documenting was way faster. I was probably wrong.

> but this doesn't address the problem of discernment
> example: i can go to [3] and see there are four games, i know they are
> free because they are inside a free distro frontier
> if users need to exit the free distro frontier, they probably will
> find nonfree and free games and don't see much difference
> the ideal would be to have a comprehensive set of games packaged
> inside the free distro frontier
The documentation would have had to take that into account.
I was thinking of something along the lines of HOWTO that you find in
the documentation of the distributions. Such as list of commands that
would explain how to do it, while making sure that freedom is preserved.

But as you pointed out, packaging might be faster and easier.

> hiding the emulator executable/package
I don't understand what it means.

> would warn when they are exiting the free distro frontier and poke
> them to add free games to the distro (suggesting to developers or
> sending patches)
That is very similar to documentation for me.
We might also want to do that on the parabola wiki, trying to implicate
people who might want to use such emulators.
Example: Why is <foo emulator> not in Parabola
         |-> <Explanation suggesting to send patches>

> alternatively, forking all emulators and creating a
> free community around them would also provide a freedom frontier
That is nice too. Uzebox seem in the right direction with that.

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

On 4/5/16, Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> wrote:
>documentation (and packaging as you point it) can
> steer users towards free software.
...
> Which one to do would then depend on the context.
> For instance with qemu and libvirt, the software was modified not to
> steer users towards running non-free GNU/Linux distributions.
qemu images seems big to package.
in guix we can make non-substitutable packages.

> While unrelated, the case of debootstrap is also interesting
not unrelated at all.
the guix way for qemu images would be packaging trisquel from
debootstrap, parabola from pacstrap, ...

>> hiding the emulator executable/package
> I don't understand what it means.
it is an opt-out whitelist implementation, i sketched it at [1].
in guix we can make a package not directly installable, but use it as
a dependency for other packages; so it would go to the store but not
to the profile and remain out of $PATH.
in parabola we can make the executable install to
/usr/exitingfreedistrofrontier and remain out of $PATH, but it would
need to copy the executable to every game package or make a pacman
wrapper to make it not directly installable.

>> would warn when they are exiting the free distro frontier and poke
>> them to add free games to the distro (suggesting to developers or
>> sending patches)
> That is very similar to documentation for me.
i think skipping the documentation and using a general-purpose search
engine like duckduckgo is quite common.
making the user install some other packaged free software and execute
a command like "PATH=$PATH:/usr/exitingfreedistrofrontier/wine/" could
warn much better.

>> alternatively, forking all emulators and creating a
>> free community around them would also provide a freedom frontier
> That is nice too. Uzebox seem in the right direction with that.
not sure[2]

looking up in dag, there's three kinds of packages:
useless in freedom: ndiswrapper.
mostly useless in freedom: wine.
useful in freedom: qemu.

useless packages should be removed.
making a opt-out whitelist for mostly useless packages seems the better option.
useful packages should get a opt-in whitelist.

mame should be classified for each architecture:
i386 and z80[3] are useful as development tools replacing current hardware.
obsolete architectures are useless if only nonfree software depend on
it, mostly useless otherwise.

[1]http://lists.nongnu.org/archive/html/gnu-linux-libre/2016-03/msg00021.html
[2]http://uzebox.org/wiki/index.php?title=Category:Possible_copyright_violations
[3]z80's are still produced
https://en.wikipedia.org/wiki/Zilog_Z80

Re: MAME emulator is giving incentive to use non-free software

[Denis 'GNUtoo' Carikli]

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

On Mon, 4 Apr 2016 22:23:17 +0000
alírio eyng <alirioeyng@gmail.com> wrote:

> Felipe Sanches:
> >MAME provides an interactive debugger  
> so mame is not just an emulator.
> it is a emulator, disassembler and debugger.
> this is relevant information i can't see in official documentation,
> thanks.
> 
[...]
> a interesting development environment is useful in itself and don't
> need free games.
> is there a similar environment to a current architecture?
community/qtspim 9.1.17-2
    New user interface for spim, a MIPS simulator.

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: MAME emulator is giving incentive to use non-free software

[alírio eyng]

On 4/9/16, Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> wrote:
> alírio eyng <alirioeyng@gmail.com> wrote:
>> so mame is not just an emulator.
>> it is a emulator, disassembler and debugger.
...
>> is there a similar environment to a current architecture?
> community/qtspim 9.1.17-2
>     New user interface for spim, a MIPS simulator.
not really.
mame is a _machine code_ emulator, disassembler and debugger.
spim is an _assembly_ emulator and debugger.

assembly from disassembled _machine code_ can be used for reverse
engineering, detecting bugs on assemblers/compilers, ...
assembly _source code_ has meaningful labels, comments... like [0];
but you wont get it by reverse engineering itself, although you can
write it later.

spim isn't a tool for reverse engineering, although it can help after
using a disassembler.

but this question was already addressed by mame itself supporting
current architectures.
ignoring the trademark, for the purposes of this discussion:
a mame version with only support for current architectures (i386, z80,
...) would be like qemu.
a mame version with only support for obsolete architectures with some
free software depending on it would be like wine.
a mame version with only support for obsolete architectures without
free software depending on it would be like ndiswrapper.

[0]https://github.com/garoa/GunSmoke/blob/master/homebrew/maincpu.asm

Re: [GNU-linux-libre] MAME emulator is giving incentive to use non-free software

[alírio eyng]

Luke:
>https://wiki.parabola.nu/Emulator_licensing_issues
>
>This may prove useful in the event of further research/discussion.
this was mentioned, and it's missing crucial information.

let's add ndiswrapper to it.
it would be classified as "free + free use", but it is still rejected;
because [0] classifies it as "free + useless free use" or "useless in freedom".

proposed definition of "usefulness" for emulators:
 free software _needs_ it as a runtime dependency; or
 development tool acting as hardware replacement.

ndiswrapper fails both, so it's useless in freedom.
qemu emulates current hardware, so it succeeds the second.
wine is needed for notepad++[1], so it succeeds the first.

wine fails the second, so we could provide it just as a dependency not
directly installable.

hatari (atari st) and ppsspp (psp) fail the second.
psp was discontinued in december 2014[2], so it is possible to argue
it is not obsolete; but we probably should not support it for
development anyway[3]

these information and others already there is not really about an
emulator, but about the architecture/board ("driver" in mame[4]); we
could have separate tables describing architectures/boards and
emulators.

mame is so flexible [4] it's really tricky.
a current main processor architecture can have all boards failing the
above criteria, directly.
how much main processor emulation needs board emulation?
if a board is needed and there are no other similar
emulators/disassemblers/debuggers for that architecture with boards
succeeding the criteria, the most recently discontinued board should
get an exception.


answering [5], mac-on-linux was removed from debian/trisquel by being
unmaintained [6].
[0] and [6] should be refactored or merged.

[0]https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
[1]needs checking
https://en.wikipedia.org/wiki/Category:Windows-only_free_software
[2]https://en.wikipedia.org/wiki/PlayStation_Portable
[3]boycottsony.org
[4]18:34
https://media.libreplanet.org/u/libreplanet/m/hardware-reverse-engineering-insights-from-the-mame/
[5]http://lists.nongnu.org/archive/html/gnu-linux-libre/2016-04/msg00122.html
[6]https://trisquel.info/en/wiki/software-does-not-respect-free-system-distribution-guidelines