Generally, the way app stores work is that the developer uploads a copy of the app to the app store, and then the app store makes and distributes copies of that for people that request the app.
Note that since it is the app store making those copies for end users, the app store needs permission of the copyright owner to do so. There will be something in the agreement between the app developer and the app store that says that the developer grants such permission when the developer submits the app.
For app code whose copyright is actually owned by the developer, that's all that is necessary. The developer is able to grant all the necessary permissions to the app store.
If the app contains code that the developer does not own, then the app store also needs permission from the owner of that code in order to make and distribute copies of the app.
Consider a developer who includes someone else's GPL code in their app. To be able to make and distribute copies of it, the app store is going to have to obey GPL.
Most app stores require downloaders to agree to a license agreement with the app store, which typically includes things like prohibiting reverse engineering and prohibiting reselling or making and distributing copies.
GPL, however, prohibits such restrictions. If you impose such restrictions, GPL does not give you copyright permission to make and distribute copies. This makes the app store license and GPL incompatible, and so the software cannot be distributed on the store.
IMO this is pure laziness on the part of the app store. Any store could just say “this app is licensed to you under the GPL — download source here.”
Even ignoring licensing, I think app stores could add considerable value by offering reproducible builds. Let developers upload source, verify the has (git tree hash or plain sha256sum), and rebuild in a sandbox server-side. Reject the submission unless the binary’s hash matches the developer’s.
Now stick a badge on it: “verified open-source build”. And give it a small bonus in ranking relative to other apps.
Adding that license information doesn't help the end user to run modified code. You need an apple developer license to run changes that you have made. Thus, the code is not free.
On the other hand, apple offering to compile and run any modification that users made will never happen. Then, people could start with one program and run whatever they want. The app store would collapse.
That doesn’t contradict my point. Apple could achieve two goals here:
1. Allowing GPL code in a lightweight and compliant manner at a essentially no cost to Apple.
2. Adding a class of free (or paid) open-source apps that are more trustworthy. If Apple could effectively replace a decent fraction of the free shitware apps on the App Store with better free, open-source apps, the value to end-users and hence the value of the platform would increase.
There is no requirement in the GPL that recipients of source code be able to run modified versions of the code on the target device.
> Most app stores require downloaders to agree to a license agreement with the app store, which typically includes things like prohibiting reverse engineering and prohibiting reselling or making and distributing copies.
Apple’s (https://www.apple.com/legal/internet-services/itunes/dev/std...) actually has a very interesting clause that seems like you can discard their EULA and substitute your own (with some minimal restrictions pertaining to making sure that you don’t bring Apple into it and comply with warranty laws and such):
> Your license to each App is subject to your prior acceptance of either this Licensed Application End User License Agreement (“Standard EULA”), or a custom end user license agreement between you and the Application Provider (“Custom EULA”), if one is provided.
So can you just substitute one that grants your users the GPL freedoms?
In this case however, the code is under the GPLv3, which is far more problematic. It contains a "anti-tivoization" clause, which says you cannot require any "methods, procedures, authorization keys, or other information required to install and execute modified versions"
> In this case however, the code is under the GPLv3, which is far more problematic. It contains a "anti-tivoization" clause, which says you cannot require any "methods, procedures, authorization keys, or other information required to install and execute modified versions".
That doesn't actually apply to the Apple app store. The "anti-tivoization" clause is narrowly written to only cover what Tivo did. Namely, providing hardware with locked down firmware.
This is the trigger for the "anti-tivoization" clause:
> If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information.
A "User Product" is:
> either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.
When someone downloads an app from the Apple app store for their iPhone, the iPhone is the "User Product", and the transaction is not one in which "the right of possession and use of the User Product is transferred to the recipient", and so the "anti-tivoization" does not apply.
>anything designed or sold for incorporation into a dwelling.
I'd be willing to make the argument that a program integrated into a previously owned computing device is a totally valid case for this clause to trigger under. Your computer is part of, and is increasingly integrated into your dwelling. The program being pulled down is just another module for it.
It wouldn't matter. Two things are required to trigger the clause.
1. The GPLv3 object code has to be conveyed "in, or with, or specifically for use in, a User Product", and
2. This must occur "as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient".
The "User Product" in your argument is still the computer, and so unless you are buying the computer itself from the App Store at the same time as the app you are buying, the second condition is not met.
The definition of "User Product" in GPLv3 might seem a little puzzling at first. There are two kinds of things that count:
1. "any tangible personal property which is normally used for personal, family, or household purposes", or
2. "anything designed or sold for incorporation into a dwelling".
There is no definition of "dwelling" in GPLv3, so it is going to be given its ordinary meaning which according to Oxford is "a house, apartment, or other place of residence".
#1 already covers any tangible personal property used for personal, family, or household purposes, and since dwellings are places of residence it might seem that anything incorporated into a dwelling would also be covered by #1.
So what is #2 actually getting at?
The answer, I'm sure, is fixtures. A fixture is physical property that is permanently attached to real property. Crucially, if something is a fixture then it is not considered to be personal property and so does not fall under #1 of the "User Product" definition.
Unless the sales contract specifically says otherwise, fixtures go with the house, and personal property goes with the seller.
Nowadays a lot of things that include software might be fixtures. Some things that might be considered fixtures and might also have software in them:
1. Thermostats.
2. Smoke alarms.
3. Security cameras.
4. Appliances.
5. Lighting fixtures.
(I'm not saying that they are fixtures. In some houses they might be fixtures and in others they might not be, depending on how they were installed).
Without #2 in the "User Product" definition, manufactures of those things might be able to include locked down GPLv3 firmware without trigger the "anti-tivoization" clause.
I say "might be able to" because those things aren't fixtures until they get attached to the house. A thermostat sitting in a box on the shelf at Home Depot is not a fixture at that point. It only becomes a fixture when someone installs it.
This would probably cover it under #1, closing the loophole.
But what if the thermostat is not sold through stores like Home Depot? What if instead you have to buy it through the manufacturer, which sends an installer to install it, and only conveys ownership to you after it has become a fixture? This could probably be done in a way that evades #1.
#2 shuts down such shenanigans.
What I'm puzzled by is what about things that are neither personal property used "for personal, family, or household purposes" nor for incorporation into dwelling?
Would it be OK for Boeing or Airbus to Tivoize the software in their planes and still use GPLv3 code in it? Can John Deere use GPLv3 code in its combines and Tivoize it?
> What I'm puzzled by is what about things that are neither personal property used "for personal, family, or household purposes" nor for incorporation into dwelling?
AppleScript is nice tool for special jobs, but you do not like to write complete apps with it. It is too annoying to write, slow and hard to debug. Use it to script other apps.
The same list entry can be moved between several lists using the same type.
If the struct need to be in multiple lists in the same time you can keep multiple list entries in the same struct: https://github.com/freebsd/freebsd-src/blob/69413598d2660054...