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.
> 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.
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.
1 reply →
> 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?
Some people argue that the GPL2's clause
"You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
is violated because you need to agree to additional terms from Apple to use the apps.
https://www.fsf.org/news/2010-05-app-store-compliance
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.
2 replies →
According to the FSF, the App Store is incompatible with the GPL because its Terms of Service restricts what people can do with the apps they download: https://www.fsf.org/blogs/licensing/more-about-the-app-store...
That verbiage no longer seems to appear in the EULA.
It doesn't. The Apple app store prohibits the GPL.
Apple does not prohibit the GPL. Some people such as the FSF say it is incompatible, but Apple isn't stopping people from publishing GPL apps.
That's why Signal added a rider which explicitly allows their app on the App Store - So it's not a factor here.
I think Apple bans strong copyleft licenses somehow, by having store requirements that aren't compatible with them. I'm not sure about details.