Retron 5 source code discussion

Does it save the ROMs permanently - can you then use them without the cart? If so, why wouldn't the likes of Nintendo go after them for making a copying device?

 

I suspect they either dump them to /tmp or part of their loading process includes deleting it afterward. I would assume that's more to avoid having it run out of memory eventually, though, since Nintendo never went after the retrode guys.

 

So IIUC, if they had shipped their device with only a simple android-based OS, with no RetroArch-"inspired" gui or libretro cores, but with instructions on how to obtain those from the internet it'd have been ok? On the condition that each of their cores and front-end comply with their respective license?

I'm just wondering, as any android mini-computer, like those chinese sticks or r-pi or openpandora, can run retroarch and picodrive and whatnot without anybody ever complaining. Surely it'd be possible to sell a device that runs android, can dumps roms, and on which you can install emulators/frontend?

I'm just asking out of curiosity as I'm a big fan of free software, contributing to some projects myself, and I find this topic pretty interesting. What they've done is a disgrace IMHO.

Please keep us updated if you or other parties take legal actions on this matter.

 

It's them not abiding by the anti-TIVOization laws imposed by GPLv3 which is the most damning problem. Having users void their warranty in order to use the original software in a non-crippled state or even to be able to modify the software and run it on the same box. This is what GPLv3 was specifically set out to prevent in light of the TIVO fiasco, and by not honoring that, this is the most fundamental of GPLv3 violations there possibly could be. If they had used strictly GPLv2-but-not-later code and if there had not been any noncommercial cores they could have gotten away with this kind of abusive and bad behavior, but they made the crucial mistake of using GPLv3 code instead (and even mixing it in with several conflicting licensed code).

Using any GPLv3 code means the software on your product now has to conform to these anti-TIVOization laws. If it doesn't, you're in the wrong.

The noncommercial cores and the fact that they haven't show any good faith or paid any credit to the authors are all equally damning, but merely icing on the cake compared to an issue (TIVOIzation) that could actually get an entity like the FSF (and its lawyers) interested in the case. For noncommercial cores there's no entity to run to when a violation occurs and it's up to the individual authors to do the strongarming. In this case, there's an entity that could deal with this.

 

It certainly seems that they included the emulation cores in the required update out of the box specifically to try and legally worm their way around it.(IE One can argue that since they aren't included with the product. They are still "Non-commercial) That could end up being a problem as well.

 

It's on Reddit now:

http://www.reddit.com/r/gamecollecting/comments/2gyz79/retron_5_steals_opensource_emulator_code/

 

has libretro lawyered up yet

 

seeing as how this is the retron 5 source code discussion(hope this is not off-topic), any ideas why the r5 apks can see start and select on controllers but retro arch(and other emulators) cannot? only the dpad and b+a seem to register in retro arch

seems like the key handling should basically be the same? maybe with proper configuration retroArch could be used instead/in addition to the stock emulators

edit: start and select don't even seem to register events when I do adb shell getevent (dpad and a+b do)

 

They've come out and admitted it.

http://retron5.in/node/9

This is a really weak half-way measure of complying though. Doesn't even cover 1/3rd of what is still legally wrong about this thing.

I'm still not seeing RetroArch on this list (since we've found the exact same resampler/audio util conversion code used in RetroArch inside their libretron.so - and those were the only parts that could have not been symbol stripped or code obfuscated). Methinks RetroArch being GPLv3 is the real reason why they're purposefully avoiding mentioning that. Not to mention SNES9x Next goes through the libretro API exclusively, there is no standalone port at all.

Also, I see no explanation here how they possibly can think it's in the spirit of noncommercial licenses to be using noncommercial cores on a commercial device.

 

So normal gameboy also uses VBA-M?

And the frontend is using code from RetroArch for certain, but they didn't release its source code?

 

Yep, they didn't.

Also, them using GPLv3 code in the frontend means that their ENTIRE frontend must be covered under the same license, hence they need to release all the sourcecode to it.

Anyway, that e-mail address they left at the bottom there seems to indicate to me they intend to bribe their way out of it with 'license exceptions' for money. Well, screw that. I'm not bribe-able, and I hope everybody involved will stand their ground and follow suit. I'm going to be filing a GPL violation very soon along with the other teammembers for the RetroArch code at least that we've conclusively proven has appeared in their frontend.

If we don't do anything about this this time, there will be a million copycat LLCs all pulling the same shit and just hiding behind concealment and encryption of stolen goods to hide their wrongdoing, and we can't let that happen. I invested too much in the libretro/RetroArch ecosystem to just see it being hijacked like this for shekels.

 

Send Pat the NES Punk a message, he's covered the Retron 5 a few times and has a fairly big audience on his Youtube channel.

 

not gunna lie, was kinda hoping the issue would come up on their CU podcast

 

Sure, can you forward me his details through PM?

 

I don't have any contact details apart from the ones he makes public, but you could try:
pat@thepunkeffect.com

Or maybe leaving a comment on one of his recent videos on youtube, he does seem to read them:
https://www.youtube.com/watch?v=pzedjS2BGYI

 

What a fucking Joke. Hyperkin never ceases to amaze me. Not only did they just basically prove EVERYTHING, but they are only making themselves look worse!

 

incase you didn't see it there is a response from retron tech: https://www.retro5.net/viewtopic.php?f=11&t=57&sid=638613d1c1de4fc414c15cc2654597e1&start=10

 

I'm pretty sure that shipping and selling a device with firmware that has GPLv3 code in it and then making sure the box is TIVOized, only to then send out a firmware update once you're caught that removes the GPLv3 code so as to make it 'legal' to have the box be a TIVOized box, is not alllowed at all and at the very least it would call for a full recall of all boxes that are currently being shipped without the v2.0 firmware. And they would still have to release all of the sourcecode from the pre-v2.0 frontend code. If anything they are digging an even deeper hole for themselves and adding even more malice, forethought and illegality to their already considerable license offenses.

Anyway, seems that these guys are trying to play damage control now and that I have already stalled bringing this to the FSF's attention for too long. That now seems to be inevitable since they are now being selective in what bits and pieces of the GPL they respect and which they don't and even going as far as being GPL-covered code one day and then taking it out the next, and same with the noncommercial cores that are STILL on their device.

 

At this point the infringement has all ready occurred and it is a question of what to do about it. (at least for the GPL code). The non-commercial cores are still an issue but it looks like they are taking a "wait and see" approach on those.

 

has anybody else tried to compile these? im getting an error on the nes one:

make.exe: *** No rule to make target `/./cart.c', needed by '[path to file]cart.o'. Stop.

after these compile seemingly ok:
libcore-gameboy.so
libcore-gba.so
libcore-genesis.so

edit: btw this looks suspicious considering they have claimed they aren't using libretro(although I don't know the source well enough to confirm what this means)

in the nes Android.mk: 'LOCAL_CFLAGS := -O3 -fno-inline -Wno-write-strings -Wno-sign-compare -DLOCAL_LE=1 -DLSB_FIRST=1 -D__LIBRETRO__ -DSOUND_QUALITY=0 \'