Is there a technical reason why this couldn't be put on the app store? I've seen reference to Apple not allowing certain OSS code but never seen that confirmed so I'm curious!
So, "Subjective reasons" such as? Example?
Here is an example of a 3D game running on the Apple Watch, that was approved by Apple, on the App Store, which looks rather "Quake like". Mindkeeper: The lurking fear (Apple Watch)[https://apps.apple.com/us/app/mindkeeper-the-lurking-fear/id...]
EDIT: To clarify 'very much an edge case', I mean, you can see how a non-technical reviewer at Apple may view iSH as a program that executes remote code. While you or I may know better, and it is unfortunate that you had to go through that process in the first instance, you can see why it happened compared to a standard todo list, or a typical web-client based app.
The specific issue is that iSH did end up getting reviewed by non-technical reviewers. We went through at least four levels of appeals, and about half a dozen interactions with people doing review. Several of these people gave the obvious impression that they understood what our app did, and might even be personal familiar with Linux/the command line. The core issue was not a technical one, but a policy one: our app does execute remote code. The reviewers read this as being "any remote code". Our (correct) interpretation was that this rule was designed to prevent remote updates by the developer. A user downloading code in our app and executing it is fully within the guidelines, which we ended up confirming with the highest levels of the review team once the app had been re-approved.
The core problem is that the actual guidelines (which includes both the written guidelines, and a bunch of "case law" that supplements it) is only really known within Apple to a handful of very senior reviewers, and getting to them is very difficult and requires an exceptional appeals process. For iSH, you can see how the written guidelines were misinterpreted by technical people; for apps like these it is very possible that they get flagged by some sort of "game includes IP that's not yours" or "app is unplayable on Apple Watch" and the person who would review this Quake game could get flagged even while complying with the guidelines.
Mindkeeper: The lurking fear (Apple Watch)[https://apps.apple.com/us/app/mindkeeper-the-lurking-fear/id...]
I said "provided it used properly licensed assets". Apple has accepted compiled open source projects before, even from people other than the authors e.g. OpenTTD[0].
>Apple may reject it just based on "not matching app guidelines".
We all know Apple might reject an app for any reason it wishes. This is a poor answer to support a claim that it wouldn't want this specific app.
>Apple banned even console emulators even tho technically there's nothing legally wrong with emulator
Emulators where you add game images yourself were always forbidden.
"2.5.2 Apps […] may not download, install, or execute code which introduces or changes features or functionality of the app"[1]
>torrent downloaders, Kodi
This is an entirely different topic than Quake.
[0] - https://apps.apple.com/us/app/openttd/id1585549844
[1] - https://developer.apple.com/app-store/review/guidelines/#sof...
In the release notes for J901 iOS I saw the following:
"it is legally impossible to release a J IDE for iOS as an open source project due to restrictions imposed on app developers by both Apple Inc and the Open Source community".
https://code.jsoftware.com/wiki/User:Ian_Clark/iOS/Review_No...
Although there was no justification for this comment, but maybe it's just true due to enforcement.
It's not that Apple doesn't allow anything here, they just impose their own T&C which breaches some, but not all, OSS licenses. And the workaround for the former is usually to have the contributors accept a small affidavit, which effectively puts their software in compliance with App Store.
If you copy and distribute the GPLv2 code or a work based on it in object or executable form, you have to do one of:
a) Accompany it with the complete machine-readable source code; or
b) Accompany it with a written offer valid for at least three years to give any third party a complete machine-readable copy of the source code, for a charge of no more than your cost of physically distributing the source; or
c) Accompany it with the information you received to distribute such code, but only if your distribution is noncommercial and you received it in object or executable code.
See GPLv2 section 3.
A developer uploads a copy of their app to the App Store. Apple then makes copies and distributes it when people buy it (for free or for money) on the App Store.
Since Apple is copying and distributing that GPLv2 code, Apple should have an obligation under GPLv2 section 3 to distribute the source. They would not be able to punt this obligation back on the developer via option c because their distribution is not noncommercial.
This is a crucial difference between app stores (and other digital goods stores) and stores selling physical products that contain GPL code.
Best Buy for example does not run into this problem when they sell you a TV that contains a Linux kernel because although they are in fact distributing a copy of a Linux kernel to you they did not make that copy. They received that copy from the TV manufacturer or a distributor and are just passing it along.
Copyright law in most places contains an exception, often called the "first sale doctrine", which states that once the copyright owner releases a particular copy, those who legally obtain that copy can give it away or sell it or rent it without requiring permission of the copyright owner. That covers Best Buy's case.
Unless there is some way to argue that when I but an app on the Apple App Store it is the developer who uploaded the app that is making the copy I get, I'm having trouble thinking of a way to avoid Apple having to handle GPLv2 source distribution if they let third party GPLv2 code on the store.
First party GPLv2 code would be OK, because then the developer owns the copyright and so can grant Apple the rights to distribute it in binary form without source code. (It has been a long time since I've read Apple's developer agreement, but I think it requires the developer to give Apple such rights).
Judges are allowed to argue that the "equity of the license" prevails over the text in these sorts of cases. If, say, the database lawnmower company decided to sue over App Store distribution of GPL software, the judge is allowed to say "well, the developer is already complying with the offer, they're using Apple's platform to do it, and that gives you what you wanted when you put the software under GPL, which was to have modified source code remain public".
However, you could also sidestep the whole "is a link to a Git repository 'good enough'" question by bundling a source ZIP in the app itself and letting people export it to Files or whatever. That would unambiguously satisfy GPL.
Is there any write-up on that that explains how exactly they did that?
> For example, this is what iSH uses to legally ship an entire x86 Linux userland inside of an app.
An entire userland?! AFIR it only shipped the gnu toolkit, the rest is downloaded from the repositories?