Libretro – Page 65

We have an open-source project called RetroArch. It has a development interface called libretro that allows for the easy creation of emulators and games that can plug straight into this program called RetroArch. This development interface is open to others so that they can run these pluggable emulator and game cores also in their own programs or devices. You can find this project on Github. (github.com/libretro). We also have a website – http://www.libretro.com. We started this project in late 2010 and we have been steadily increasing in popularity. We are on over 15 different hardware platforms right now that you can run RetroArch on, including Android (which this Retron5 device is based on).

These open-source programs are covered under certain licenses. Several of the emulators are covered under non-commercial licenses, which means they cannot be sold or profited from.

We have discovered that Retron5 is in violation of the licenses of several projects:

Genesis Plus GX
1. It uses the open-source emulator ‘Genesis Plus GX’ by author Eke-Eke for its Sega Genesis/Mega Drive module (https://github.com/ekeeke/Genesis-Plus-GX). This core has been licensed under a non-commercial license. It can therefore not be sold as, or part of, a commercial product.

Proof is in the accompanied screenshots at the bottom of this post. None of the authors were contacted about their code’s use in the Retron5 hardware.

More evidence: (1, 2, 3, 4, 5, 6)

SNES9x Next

2. It uses the open-source emulator ‘SNES9x Next’, which is itself a derivative of SNES9x (https://github.com/libretro/snes9x-next). I (Squarepusher) personally made this version of SNES9x. It has a few differences compared to normal SNES9x. It has SuperFX overclocking code and it has certain game speed hacks that make games run faster on slower hardware. This comes at the expense of some graphics inaccuracies though.

We could tell it was the SNES9x Next core because the exact same strings for variables to do with the speed hacks and the SuperFX overclock code popped up in their SNES core.

SNES9x is licensed under a non-commercial license. Like Genesis Plus GX, it can therefore not be a part of a commercial product.

What also bears pointing out is that SNES9x Next has never been released in any other version than the libretro version. Libretro is the development interface of RetroArch if you remember. We will return to this later on.

Proof is in the accompanied screenshots (see below). None of the authors were contacted.

More evidence (1, 2, 3, 4, 5, 6).

FCEUmm

3. It uses the open-source emulator ‘FCEUmm’ for its NES module, which is itself a derivative of FCE Ultra. FCEUmm is licensed under the GPLv2. Technically they would have been allowed to sell this IF they had made sure their frontend was compatible with GPLv2. Unfortunately, this turns out not to be the case as we’ll find later on – since they are using GPLv3 code inside their frontend as well which is technically incompatible with this license.

Proof of it being FCEUmm is in the accompanied screenshots (see below).

More evidence (1, 2, 3, 4, 5, 6)

VBA Next

4. It uses the open-source emulator ‘VBA Next’ for its GBA module. VBA Next is a derivative of another emulator called VBA-M. I (Squarepusher) made this version specifically and I could recognize it was this version because of the fact that I have built-in a game database into this emulator. The game ID strings that are used to identify the ROMs appeared in Retron’s GBA module as well. As for the rest of the code, it is undoubtedly VBA. The screenshots showing the code flow of operation will illustrate this clearest.

VBA Next is licensed under the GPLv2. None of the authors were contacted. Proof is in the accompanied screenshots (see below).

More evidence (1, 2, 3, 4, 5, 6)

RetroArch

5. We found obvious bits of RetroArch’s sourcecode inside their frontend. Now the reason we could identify these snippets is because it is inlined Assembly code that is hard to obfuscate. The relevant parts are the ARM NEON-optimized sinc resampler code and the audio integer to float conversion routines. If you want photographic evidence, I refer you to the second link I posted below.

All of the other C code of RetroArch seems to have been obfuscated so it will take us some more time to identify these parts. What is evidently clear though is that they are already in violation of the GPL license that we covered this RetroArch code under. GPL version 3 specifically forbids TIVO-ization. Let me explain later what TIVO-ization is. It basically means that you use opensource software to make a locked-down hardware device that doesn’t allow you the freedoms that the GPL generally provides to users and developers alike.

Since they have used our libretro cores evidently and since the only way to actually use these cores is through a libretro frontend implementation, and since actual RetroArch code has already been identified in their frontend, this raises serious questions as to how much of their frontend constitutes ‘original work’ and how much of it is just RetroArch. Either way, they are in the wrong for several reasons here:

– They should have also made these publicly available for every user to download since that is part of the rules and stipulations of using GPL code.
– They made a locked-down crippled hardware device based on open-source software. You void your warranty if you attempt to modify the copyleft-licensed software on this product and furthermore it doesn’t even allow you to do this. It is not possible to run the original, non-crippled RetroArch frontend on this device, only the crippled one provided by HyperKin. It also uses encryption as a means to obfuscate and hide the originating source of this software. This is TIVO-ization and the GPL version 3 was specifically made to prevent this.

What is TIVO-ization?

http://en.wikipedia.org/wiki/Tivoization

Tivoization /ˈtiːvoʊɨˌzeɪʃən/ is the creation of a system that incorporates software under the terms of a copyleft software license (like the GPL), but uses hardware restrictions to prevent users from running modified versions of the software on that hardware. Richard Stallman coined the term in reference to TiVo’s use of GNU GPL licensed software on the TiVo brand digital video recorders (DVR), which actively blocks users from running modified software on its hardware by design.[1][2] Stallman believes this practice denies users some of the freedom that the GNU General Public License (GNU GPL) was designed to protect.[3]

The GPL version 3 was specifically made because GPL version 2 did not provide enough safeguards against abuse like in the case of the TIVo digital video recorders. They would take from open source, not credit anybody and not give anything back either – and even create a closed platform around it where they would set themselves up as owners of the software (and in effect the hardware).

GPLv3 forbids you from building a gated community around open-source software like this and giving nothing back in return. The fact that they have used RetroArch’s GPL version 3-licensed audio resampler code in a product that is running a locked-down, encryption-crippled version of Android is already bad enough. That they don’t even provide to users the ability to run content on this device without any restrictions is another serious concern.

Anyway, as it stands right now in its current state the product is using parts of our software illegally. There were also some other things found that were legally questionable like a Microsoft-licensed Verdana font which is covered by a End-User License Agreement, so there are multiple license violations here at play.

More evidence of RetroArch appropriation (1, 2, 3, 4, 5, 6, 7).

Multiple license violations, multiple conflicting licenses, bad faith

The problems with this are many-fold, but for us it comes down to mixing non-commercial cores on this device with more permissively licensed cores, the infringement of the emulator authors’ rights, the lack of credit paid where credit is due, the lack of freedom in the hardware device (which restricts the user in what he/she can do and makes him/her reliant on Hyperkin to serve as the gateway keeper since he/she can’t uncripple this version of Android on their device without voiding their warranty and they can’t run the uncrippled RetroArch frontend on it either), and the multiple conflicting licenses. Also, the fact that changes / patches to the sourcecode have not been provided to customers of this device. These should have been made available on a public place free of charge.

Open-source is not a matter of doing with it as you please. The license is there for a reason and it needs to be followed, and it dictates how you should go about your business when deciding to make a commercial product out of such software. GPL is known as a ‘viral license’ which means that the community behind this uses the viral nature of the GPL as an effective strategy to ensure more and more software gets licensed under the GPL, since every bit of GPL code that gets incorporated into another project needs to be made GPL or GPL-compatible as well otherwise it’s a violation of the license. As it stands right now, the software for the Retron5 is very likely illegal to distribute.

Links:

1. http://imgur.com/a/T6W4e – This image gallery shows comparisons of the infringing derivative Retron code vs. the originals

2. https://www.anonimg.com/img/5d807718b069e5dae8a4e4320fdda1ab.png – This shows the RetroArch audio resampling and audio conversion routines in the Retron frontend

3. http://i.imgur.com/81bnckH.png – Another image of the audio resampling code. Originally from this tweet: https://twitter.com/FioraAeterna/status/512790355591196673

4. Regarding the MS Verdana font: http://www.microsoft.com/typography/fonts/font.aspx?FMID=1817 – “Verdana is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.”

(EDIT: A section here about the ARM Mali drivers was removed since it appears to not be related to these issues)

(EDIT2 [9/20/2014]: Updated with more pics of evidence)

A key quality aspect of any API such as libretro is that there are multiple, independent, actors on both sides of the imaginary fence that the API represents; Multiple applications using an API (what we typically mean with “client” or “frontend”), and multiple implementations (what we mean when we say “core”). In a perfect world, you can mix and match clients and cores to your hearts desire and adapt things to fit your own specific needs.

In the emulation world, this is one aspect that sets the libretro project apart from many others in that it is not, as some critics may cry “a bunch of emulators bundled together like some weird game of katamari damacy” but rather an attempt to retrofit emulators (and nostalgic game engines) with an API so that they may be used on more hardware and software platforms and for additional purposes (validation, automated test suites, …).

Those of you reading this already know about RetroArch, the reference client with the primary goal of being clean, fast and extremely portable. There are others, and this post is to tell you of one of those, namely Arcan (http://arcan-fe.com).

One of the primary goals for Arcan is balancing versatility (being used for fun, weird and odd things), security, speed and portability. In the software world, it sits there quietly in a corner somewhere (and rather alone) between being a windowing system (like X or Weston), a game and graphics programming framework (like Love2D, Cocos2D, VisualTK, …), a hacking and reverse engineering framework and, indeed, a libretro client. The rest of the post will be dedicated to the libretro- related parts.

The first thing to cover is that Arcan is entirely script driven. You select some scripts to run (‘theme’) and that defines what Arcan will actually do. There are two major such themes, Gridle (that tries to mix and match styles from arcade frontends like Hyperspin, Wah!Cade and AdvanceMenu) and AWB that behaves more like a desktop environment but with some unexpected features that can be used to rather extreme ends. The screenshot below, for instance, shows one instance of Arcan with AWB running two instances of Arcan, one of them also running a libretro core. The display is simultaneously mapped to a 3D model.

The sets of pictures here (Gridle Examples) and here (AWB Examples) try to show a little more in-depth of what these two themes are up to. For those that prefer videos, this slightly dated youtube playlist shows a bit more on how things work. To work properly, the initial configuration in Arcan is slightly more difficult in the sense that you don’t just pick a game and a core and off you go, there’s an additional step involved in order to prevent nasty written scripts to do bad things to your computer.

Arcan expects all file operations to happen inside two folders, “resources” and “themes”. Resources are for save-states, additional artwork, data files (roms) and cores. An additional tool (“arcan_romman.rb” on Linux/BSD and arcan launcher on Windows) performs the job of scanning through the resource folder and to download extra artwork, metadata (like title, genre) and so on. This is done by scanning two subfolders, resources\targets and resources\games. You stuff your cores (like snes9x.dll) in the targets folder, create a corresponding subfolder like (resources\games\snes9x) where you put your roms and tell the tool to start building a database. Enough with the boring stuff, look on the Arcan wiki for more details.

To round this brief introduction off, lets demo a short script that launches two random games side by side, forwarding some input to both of them. To use / run, create a folder in your themes subdirectory called retrodemo and a file named retrodemo.lua inside the new folder. Type in the codeblocks below (or use the pastebin link).

function retrodemo() -- load a translation table to get decent names for keypresses symtable = system_load("scripts/symtable.lua")();

— query the database and return a table of all entries for a target called ‘snes’
games = list_games({target = “snes”});

— give up if nothing was found
if (#games == 0) then
shutdown(“empty database, can’t proceed.”);
return;
end

— launch two randomly selected games and save the handles for later
— game_callback is a function reference that will be called every time
— something happens in the core that we want to be alerted about
game_1 = launch_target(
games[math.random(#games)].gameid,
LAUNCH_INTERNAL,
game_callback
);

game_2 = launch_target(
games[math.random(#games)].gameid,
LAUNCH_INTERNAL,
game_callback
);

— place the two games side by side
move_image(game_2, VRESW * 0.5, 0);
show_image({game_1, game_2});
end

This function will be called when the engine is ready to run, all subsystems have been created and are up and running. We immediately launch two cores, but this still misses a callback and an function to handle input.

function game_callback(source, status) if (status.kind == "resized") then resize_image(source, VRESW * 0.5, VRESH); end end

This function will be called a lot, when the core has a frame ready, information about save state and other capabilities, if the emulation dies for any reason and so on. The first event is almost always “resize”, so we use that to force it to take up half the display.

Lastly, some input handling:
-- create a global input table that translates wasd,1 and ctrl/alt to special inputs -- the libretro frameserver can handle. keymap = {}; keymap["w"] = "PLAYER1_UP"; keymap["s"] = "PLAYER1_DOWN"; keymap["d"] = "PLAYER1_LEFT"; keymap["a"] = "PLAYER1_LEFT"; keymap["d"] = "PLAYER1_RIGHT"; keymap["1"] = "PLAYER1_START"; keymap["LCTRL"] = "PLAYER1_BUTTON1"; keymap["LALT"] = "PLAYER1_BUTTON2";

— this function will be called on any input received (including mouse, gamepads, etc.)
— for now, just check if its a translated device (aka keyboard)
function retrodemo_input(input)
if (not input.translated) then
return;
end

— translate the input using the table above
local key = keymap[ symtable[input.keysym] ];

— if it was a valid key, forward it to the two running cores.
if (key ~= nil) then
input.label = key;
target_input(game_1, input);
target_input(game_2, input);
end
end

In closing, there is a ton of stuff to explore and play around with in Arcan (humorously called ‘the emacs of frontends’ by some, though it should of course be vim..) — both for power users and for those of you with an interest for the lighter sides of programming.

Category: Libretro

RetroArch, Libretro core license violations by Hyperkin’s Retron5

Libretro Client Introduction, Arcan