Apple further explains why Game Boy emulator iGBA was removed from app store | Hacker News Reader

Apple further explains why Game Boy emulator iGBA was removed from app store

macrumors.com

38 pointstosh65 comments

Not surprising at all; the App's screenshots bared more than a passing resemblance to GBA4iOS: https://github.com/CocoaBob/GBA4iOS

Really just makes you think how much easier things would be if you could simply distribute Open Source apps safely on iOS. This one-two step of ad-ridden forks and who-knows-what isn't making things any easier for users. Nobody wants good software to be polluted with anti-features and redistributed by someone that isn't the maintainer.

Open source software wouldn't solve this problem if you could "simply" distribute open source apps on iOS because you could indeed just clone an app like this, make it open source on Github or something, and then distribute it without anyone in the way. Unless of course you want to start adding various validation technologies, in which case it's just Apple all over again except there's nobody to point the finger at anymore.

Depends on who does the validation. I've never had a problem downloading downstream forks on F-Droid, because more often than not the authoritative source is ranked right above it. The big problem for iOS users that want iGBA/Delta is that they can't download it to their device, despite the fact that the code is already written and freely available. Now third-parties are taking advantage of that demand.

This would be circumvented if the legitimate version was easy to get. Deceptive forks should still be removed at the store/repository's discretion, but the same goes for proprietary knock-offs like the Lastpass trojans and fake banking apps. It's less of an "Open Source" issue and more of an "App Store" one.

So not being able to get the actual version at this point is better somehow?

Agreed with all your points, but the clear issue here is wrongly believing that any apps on iOS / android can be: free from tracking, stable UI over time, trustworthy, privacy-preserving, non-addictive, etc.

There are some rare exceptions to this rule, but for the most point smart phone apps are bad for the user, and built to favor the company who's provided them.

I don't think it's wrong to believe that. It's hopeful and perhaps overly idealistic, but the sentiment of "good software" still exists. People still develop it, albeit slowly and to a smaller audience.

Enabling installation routes that aren't solely money-extraction machines will go a long ways towards changing things. It won't inherently stop people from abusing social media or screen time, but it might stop people from watching ads or paying money to use a PDF reader. That's a win in my book.

I’m actually okay with this I can see why apple don’t want to open the floodgates of cloned open source apps and games floating through. However I’m surprised they’re willing To say they will allow rom loading on “retro” consoles considering Nintendos extremely strict history on the matter..

Nintendo doesn't stop people from writing retro emulators, nor do they have a way to do that.

Case in point, emulators have been available on the Android store pretty much forever and as long as they keep it clean by not distributing copyrighted ROMs or BIOS files directly in the app it's never really been an issue. Nintendo probably doesn't like it but they have no cause to have them taken down.

The tl;dr seems to be that Apple pulled it because it's just a white-labeled build of Riley's (of AltStore fame) Delta/GBA4iOS, not because it's an emulator. The README on Riley's repo says:

> Due to the licensing of emulator cores used by Delta, I have no choice but to distribute Delta under the AGPLv3 license. That being said, I explicitly give permission for anyone to use, modify, and distribute all my original code for this project in any form, with or without attribution, without fear of legal consequences — unless you plan to submit your app to Apple’s App Store, in which case written permission from me is explicitly required.

So it sounds like Apple is going out of their way to enforce the non-standard licensing clause of some third-party developer (who until this weekend would have been considered a somewhat hostile party from Apple's perspective)? Is there any precedent for this, or is it just a convenient excuse?

I see this in the bitbucket readme:

> The GBA4iOS codebase is distributed under the GNU GPLv2 license. That being said, I explicitly give permission for anyone to use, modify, and distribute my original code for this project without fear of legal consequences — unless you plan to submit your app to Apple’s App Store, in which case written permission from me is explicitly required. Dependencies remain under their original licenses.

It says it is GPL then adds additional terms—is that even allowed by the license?

I’m very doubtful that it is, since an important goal of the GPL is to prevent such restrictions in derived works.

That argument would have to be made by the actual owner of the copyright though

Apple shouldn’t act as a judge here in either case.

The text of the GPL automatically grants a license to all derivative works without the original author having to do anything explicitly, if I understand it corretly:

> Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein [...]

So while the original author(s) could file license infringement terms against the author of the derivative software, they don't have to in order for third parties to be able to use the derivative under the terms of the GPLv2.

At least that's my read on the GPL, and it matches the expected outcome – I'm not a lawyer and I'm not aware of any court cases focusing on this particular clause.

That has nothing to do with who has standing to actually enforce the underlying copyright for the part that would be infringed under a violation of the relevant portion of the license.

GPL doesn't let you restrict it further via added clauses, but it does let you be more general under other licenses.

So that "I explicitly give" is a separate license you can use the code under, the GBA4iOS license, if you will, which is for anything but the App Store.

GBA4iOS includes GPL-ed code though, so the author can't just be granting additional licenses like that (without the permission of all of the authors of the GPL-ed code he's including).

If you own the covered work, then in some jurisdictions, you have the right to license it under the GPL plus additional restrictions (that cannot be removed under the 'Additional Terms' clause of the GPL). This was previously discussed at https://news.ycombinator.com/item?id=30712215

It is more complicated in this scenario where GPL-licensed code written by other people is involved.

Or where it's mixed; where some may be GPL-only but yours can't be used unless you agree to another clause, etc.

However, it's pretty obvious the intent whatever the wording and machinations may be.

Where it is mixed, the derivative work would usually be expected to be made available under the terms of the GPL, because the copyright held by the creators of the original work includes the right to create and distribute derivative works.

The licensor of the derivative work can refuse to give you a licence unless you agree to some other terms (e.g., money, and/or the right to terminate the business relationship if you exercise your GPL rights), but those terms cannot directly prevent you from exercising your GPL rights, or the licensor would be in violation of the GPL.

> If you own the covered work, then in some jurisdictions, you have the right to license it under the GPL plus additional restrictions

Then that license is not GPL. As a rights holder you may license or not license your work however you want. Is there a jurisdiction where this is not the case?

In the specific case of using the GPL as a part of your licence, a court could potentially rule that the additional restrictions are removable under the 'Additional Terms' clause. The licensor could have created a derivative licence with that clause removed (as well as renaming the licence and removing the preamble, as required by the FSF when creating derivative licences based on the GPL). If they did not, the licensee might have grounds to believe that additional terms are removable. In the case cited in the earlier link, the court disagreed, but another court might conceivably have a different opinion.

Ah, I see. I replied under the assumption that by "GPL plus additional terms" you meant "GPL plus additional terms minus the clause that expressly forbids additional terms", but I can see how paradoxical licensing terms would create this ambiguity.

It's allowed since it strictly grants additional permissions.

If Apple allowed GPL code then the restriction wouldn't be valid, but as it is it is only a restriction to the additional permission.

> It's allowed since it strictly grants additional permissions.

From the repo:

> written permission from me is explicitly required

That does not sound like an additional permission to me.

It's only a restriction to the "that being said" clause; it does not affect the GPL possibility.

It's at least very ambiguously worded, and a lot of confusion could be avoided by just explicitly stating it as "License: AGPLv2 (everything); additional/optional license for parts written by me: do-what-you-want-but-email-me-for-app-store license v0.1".

He's basically offering a dual license: GPL, and also his custom "do whatever, except Apple Apps store (unless explicit permission from me)". The dual license only applies to the code he personally wrote though, not the dependencies.

That's not how the GPL works, though.

He's including GPL-ed code, which means he must make his own code available under the GPL (without additional restrictions) as well.

Of course he can make his code (and only his code) alone also available under a more or less restrictive license, but anybody would be free to ignore all additional restrictions and just follow the GPL.

If by going out of their way, you mean not wanting to get in a copyright dispute where they hold liability with a likely copyright holder outside of more complicated legal claims on a project they don’t particularly want in the store anyway, sure

Yes, Apple will take down apps that are blatant redistribution without license of open-source software. Years ago I made a simple utility app and put the code on GitHub, someone took the code, changed the name, and uploaded it on the App Store with a 8$ price. It was taken down after I contacted Apple.

of course they have to enforce other peoples licenses, otherwise they're distributing stolen code. It's AGPL, which is probably not compatible with the app store license, and the code by Delta is also distributed under a custom license forbidding uploading to the app store. I don't think it's a non-standard AGPL clause, it's just multi-licensing in a very informal way

You can't multi-license other people's GPL-ed code (without them explicitly re-licensing it to you allowing that, in any case).

The wording:

>That being said, I explicitly give permission for anyone to use, modify, and distribute all _my original code_ for this project in any form, with or without attribution, without fear of legal consequences — unless you plan to submit your app to Apple’s App Store, in which case written permission from me is explicitly required.

so they're not doing that

That’s one read of the implicit brackets here, and maybe the intended one, but I think the ambiguity next to “fear of legal consequences” might make a lawyer a bit nervous.

I don’t understand what exactly Apple’s objection is, given that the original is GPL’d open source and not present on the app store. One person’s “knockoff” is another person’s fork.

Apple doesn’t want the App Store filled with 100,000 copies of the same thing. So they are very strict around how different forks must be because of how low effort these copies are.

The rules are simply a pragmatic response to their business goals.

But there was no alternative present on the app store. Apple also doesn’t define any clear rules here, they seem to decide in a very ad-hoc fashion.

it's not a fork unless source is available (even if it's a name replace copy-paste job) and other license terms are followed.

True, but that’s not the rationale Apple gave here. I would understand if they rejected the app on grounds that it is violating the GPL terms, which would be rather easily fixable by the submitter, and then the app could be reapproved.

I'm not positive the app store terms are compatible with the AGPL

The source has a GPL license next to it, but there are additional licensing conditions that make it proprietary:

> Licensing

> The GBA4iOS codebase is distributed under the GNU GPLv2 license. That being said, I explicitly give permission for anyone to use, modify, and distribute my original code for this project without fear of legal consequences — unless you plan to submit your app to Apple’s App Store, in which case written permission from me is explicitly required.

(emphasis mine)

https://bitbucket.org/rileytestut/gba4ios/src/master/

That clause is not compatible with the GPL, to which the author is bound in this case (since he does not own the copyright for all of the emulator cores he's including).

If the GBA4iOS author is infringing the GPL license by including 3rd-party GPLed code in a not-GPL-compatible codebase, does that make their 1st-party code any less proprietary?

My non-lawyerly interpretation is that both parties seem in the wrong.

> does that make their 1st-party code any less proprietary?

I believe that is the case, yes.

The GPL has a "sticky clause" that attempts to make all code deriving from/including GPL-ed code GPL-licensed itself, without requiring the original author to be the one that enforces this:

I have no idea if this practically works in court, though.

"That being said, I explicitly give permission for anyone to use, modify, and distribute my original code for this project without fear of legal consequences — unless you plan to submit your app to Apple’s App Store, in which case written permission from me is explicitly required."

Emphasis mine. The author is giving permission to use their original code but doesn't re-license anyone else's code. They're explicitly offering their own code under a dual license.

Perhaps it is in Apple's interest to allow additional restrictions on the GPL. They're certainly not required to distribute it.

How would Apple "allow additional restrictions on the GPL"? They're not the copyright holder of all GPL-licensed code!

I suppose they could try to establish something like a "first/original app wins" clause to prevent distribution of builds of paid-but-GPLed iOS apps, but that feels like it would at least clash heavily with the intent of the GPL.

By removing apps from it's store that don't comply with those restrictions. GPL only applies if Apples distributes.

Makes me wonder, if App Store distributes a GPL app which doesn't link to source, is Apple obligated to distribute the source? Seems like they'd have to.

Some of the dependencies/vendored code are GPL version 3 or later (see e.g. https://bitbucket.org/rileytestut/gba4ios/src/master/emu-ex-...). This license may require handing over signing keys in the iOS context (but I have not really analyzed the scope).

The project README says it's “distributed under the GNU GPLv2 license”, which isn't helpful, either. Under the usual reading, the GPLv2 is only compatible with the GPLv3 if the GPLv2 licensing declaration comes with the “or later” clause.

Of course I don't know if Apple even looked that far.

Buttons. You need buttons.

Analogue Pocket

Everything Game Boy and so much more.

https://www.analogue.co/pocket

Or any of the multitude of Chinese emulation handhelds, which are generally cheaper, can emulate systems like the PS1/N64 which can't feasibly fit onto the Pockets FPGA, and are available in more ergonomic horizontal form factors. The Pocket is a nice piece of hardware but it's far from the only option if you want real buttons.

Here's a primer on the current <$100 market: https://www.youtube.com/watch?v=6UGr42nOv54 . Above that price bracket there's options like the Retroid Pocket 4/Pro, which get into the territory of being fast enough to emulate the Gamecube/Wii/PS2.

Or any controller and android phone clip

Yeap. Analogue Pocket is neat, but pretty much anyone that can afford one probably already has hardware capable of playing Game Boy games in their pocket. Unless you're a stickler for FPGA gaming, I think most people would prefer to buy a cheap Bluetooth controller and play that way. It's not like most people still have their cartridge of Yoshi's Cookie to play on anyways.

It's very easy to screw up the controller when designing a device. And if the built-in controller sucks, then it's completely worthless no matter how powerful it is.

D-Pads especially are hard to get right. You can either be way too lenient on diagonals, or way too hard to hit diagonals. I had a Chinese handheld where you couldn't consistently hit Down while holding Right. Sonic runs into the enemy because his roll attack didn't start.

The major benefit of a Game Boy emulator on iOS is how much it would increase access to Game Boy games. While I love Analogue, their limited quantity stocks and high price tag make them a high barrier to entry. The iOS emulator would be an incredibly low barrier to entry.

There are many Game Boy emulator PWAs available on iOS today. I haven't tried it myself, but I believe some of them even support gamepads.

Alternatively, the Miyoo Mini+.

Costs less then the shipping of an Analogue Pocket to the UK /Europe (when you add the import tax+fees to the excessive shipping cost) and gives a decent pocket-sized gaming nostalgia hit.

Another alternative is to upgrade a real GBA or GBA, there's IPS screen kits, replacement shells, and modern rechargeable battery packs available now. Also for less than the shipping of an Analogue Pocket, if you've got a device to upgrade.

The Analogue Pocket was unobtanium for so many years that relatively inexpensive alternatives appeared. And while FPGA gaming is great to reduce input lag or to output to a CRT, the benefits are less obvious on a small handheld.

Cheaper FPGA systems are starting to appear too, the FPGBC is an FPGA-based drop-in motherboard replacement for the Gameboy Color. Every other component of the GBC has also been cloned already, so you can actually build a fully functional replica of the GBC using zero original Nintendo parts now, but with a better screen, USB-C charging, etc.

I'd guess Riley Testut (creator of GBA4iOS, which this app ripped off) is working on putting emulators on the App Store. (I don't know if he's announced this intention or not, but it seems likely)

His emulator collection "Delta" is the flagship app of AltStore, which uses Apple's Developer program to let you sideload apps without jailbreaking your iOS. It's all pretty above-board, and if Nintendo wasn't the one to take this app down, it would be a perfect fit.

Porting a bunch of GPL-ed emulators to iOS and then claiming exclusive distribution rights in the App Store (but not actually distributing it there!) seems at least dubious, in my view.

Is the issue just that the developer didn't give credit, or that even giving credit was enough to violate the guidelines?

> Notably, Apple confirmed to us that emulators on the App Store are permitted to load ROMs downloaded from the web, so long as the app is emulating retro console games only.

Speculation (and conclusions!) all over the internet, including this site, post-emulation announcement was that Apple wouldn't allow retro game emulators, so this confirmation is pretty exciting[0].

[0] For some reason, any time someone says something like this, someone has to jump in and point out Android has allowed emulators forever. To anyone tempted to do that: so what? We aren't talking about Android.

This is an odd requirement. It would make sense to require that no BIOS or decryption keys be distributed with the app, but the requirement for "retro" only is pretty arbitrary.

Reply on news.ycombinator.com