Add app store exception to license

[12people]

In the license for Feeel, I use the AGPL with an app store exception. This allows me to potentially release the app on the iOS AppStore in the future, which has terms incompatible with the GPL and AGPL.

If you would also potentially like to release on iOS in the future, adding this exception might be helpful.

I use these two sentences to my LICENSE file:

Code is licensed under the GNU AGPL v3 or any later version with an app store exception, unless specified otherwise. See COPYING for its content.

As an additional permission under section 7, you are allowed to distribute the software through an app store, even if that store has restrictive terms and conditions that are incompatible with the AGPL, provided that the source is also available under the AGPL with or without this permission through a channel without those restrictive terms and conditions.

[12people]

I thought to mention this now, as there was a suggestion in another issue to relicense the project to AGPL anyway. If you're going to be relicensing, then it'd be good to add the exception alongside the new license.

[rolandgeider]

While we're not planning on releasing it on the app store any time soon (due to a lack of Macs 😄), this is a good point and it's definitely better to do it now

[comradekingu]

You also need a 99$ developer license to release on the iOS app store. Least that is how it used to be.
Why give any of that the time of day.

Got an e-mail saying the dev dislikes CC licensing for the same reasons I do, so why bother with it?

https://www.gnu.org/licenses/license-list.en.html#ccbysa
CC BY-SA 4.0 is one-way compatible with the GNU GPL version 3: this means you may license your modified versions of CC BY-SA 4.0 materials under GNU GPL version 3, but you may not relicense GPL 3 licensed works under CC BY-SA 4.0.

https://www.gnu.org/licenses/gpl-faq.en.html#AllCompatibility Each place that the matrix states GPLv3, the same statement about compatibility is true for AGPLv3 as well.

[rolandgeider]

It seems it's still like that 🙄 I'm also not a fan of apple's ultra closed ecosystem (and would obvioulsy prefer to avoid adding exceptions like this) but would like to keep the option open of releasing it there in the future. And that's better done now than later when more people might have contributed and all will need to accept it.

[comradekingu]

@rolandgeider You are also granting it to everyone else. This might make it difficult to establish the original as such.
There is an endless amount of NewPipe forks on the Play store, when the project itself doesn't meet the guidelines.

Working the angle of nice-app-store-exclusivity I reckon means more donations.

[12people]

@comradekingu There are three things to note here:

1. The exception itself is relevant only for app stores whose terms of use conflict with the GPL. The Google Play Store and F-Droid, where wger will ship first, are unaffected.
2. Not having this exception in the license wouldn't mean app store exclusivity, but rather not being able to be in the AppStore at all. That is, unless all contributors to wger sign a CLA, assigning all copyrights to Roland and allowing him to relicense the app as he sees fit. (In that case, the AppStore version would be strictly proprietary.)
3. One way of preventing copycat apps under the same name would be to trademark the wger name and logo. IANAL and not well-versed in trademark law, so I'm not sure what steps that would take. But, if I understand correctly, a trademark would prevent copycats from using the wger name for their copies. (E.g. Firefox does this, which is why unofficial Linux builds use the Iceweasel moniker.)

[comradekingu]

@12people Heia.

1. Learnt something there.
   https://www.zdnet.com/article/no-gpl-apps-for-apples-app-store/

2. I meant exclusivity in the sense of opting to not distribute on the likes of the play or iOS store. I understand that might only mean in name.

3. I am obviously not a lawyer either, but repeating the PR fiascos of Mozilla/FF seems like something to avoid.
   (I am a bit confused with "may" and "required")

https://www.gnu.org/licenses/agpl-3.0.en.html
Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:

b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or authors of the material; or

[12people]

@comradekingu Hi :)

If I understand correctly, you're proposing that wger is released in neither the AppStore nor the Play Store? But the Play Store allows GPL apps, so that would lead to only copycats being in the Play Store. Perhaps I'm not understanding correctly.

Thanks for posting the AGPL sections on differentiation — it's the first time I noticed them and they may come in handy for me. :)

[12people]

@rolandgeider You added the app store exception, but the README still says "GNU General Public License 3 or later (GPL 3+)" rather than "GNU Affero General Public License 3 or later (AGPL 3+)".

[comradekingu]

@12people
I am hypothesizing that since there may or may not be copycats anyway, people are more inclined to donate if there are no exceptions, and for some level of exclusivity with values aligned with donating.
Protecting the name in the non-FF way doesn't seem to have the same connotation.

It could entirely be the case that NewPipe not being allowed on the Play store is different, and that its users are more inclined to use F-Droid.

[12people]

@comradekingu NewPipe is not allowed in the Play Store because it breaks YouTube's Terms of Service, not because of GPL.

[comradekingu]

Yes, but psychologically the effect is the same, or could be.

[rolandgeider]

@rolandgeider You added the app store exception, but the README still says "GNU General Public License 3 or later (GPL 3+)" rather than "GNU Affero General Public License 3 or later (AGPL 3+)".

You're right, it's fixed now

Also, that article on zdnet was pretty interesting (and a bit depressing)

[12people]

@rolandgeider You'll also need to add a contributor license agreement in Weblate, at least for the strings for the mobile app.

I use this for Feeel:

The project uses GNU AGPL v 3.0 with the following exception for publishing on app stores:

"As an additional permission under section 7, you are allowed to distribute the software through an app store, even if that store has restrictive terms and conditions that are incompatible with the AGPL, provided that the source is also available under the AGPL with or without this permission through a channel without those restrictive terms and conditions."

By contributing to the project, you agree to release your contributions under AGPL v3 with this app store exception.

[rolandgeider]

That's more an explicit mention of the exception than a real license agreement, but it's probably better to have it in an obvious place before people start contributing. I'll add it later today.

[12people]

The problem is, Weblate only shows standard licenses by default and I believe translators have to explicitly agree to the extended license. (I might be wrong here, though.)

Oh, and if you have ideas on how to improve the wording, definitely let me know. :)

[rolandgeider]

Perhaps explaining a bit why this is necessary?

Since Apple's App Store is incompatible with AGPL licensenced software, it is necessary to add an exception for it. As such this project uses GNU AGPL v 3.0 with the following exception for publishing on app stores:

"As an additional permission..."

[comradekingu]

You can't add inroads on licenses anywhere. This means acquiring permission from everyone to erode a license down to a more permissive one.

@12people Weblate only shows standard licenses by default, but you can configure that in your own installation.
Hosted Weblate otoh, (and in turn Weblate) derives it reputation from supporting and being libre software.

If I understand it correctly, both of you run projects under the libre software plan https://hosted.weblate.org/hosting
How is it fair to Weblate or its volunteer translators to add invariant sections to licenses?
I don't see any reason why Hosted Weblate should allow that on the Libre plan.

Why erode copyleft to placate to Apple? It is losing marketshare, why should libre software help it along by allowing itself to be used at their whim?

[12people]

@comradekingu
If I'm understanding you correctly, you see the added permission as a dangerous precedent that could inspire other developers to add other permissions that whittle down the AGPL into a permissive or week copyleft license — is that correct?

And you also don't like the idea of AGPL and GPL apps being part of Apple's app ecosystem, and thereby being more of a selling point for their platform — is that right?

I would personally also hate to see strong copyleft licenses discarded in favor of more permissive licenses. And I also have qualms about supporting closed ecosystems (e.g. that's why I never plan to support Canonical's snap packages, as their back-end is proprietary).

With regards to the AppStore, these are the options I see:

• Never ship on the AppStore
• Dual-license under a proprietary and AGPL license
• License under a more permissive license
• Add a license exception for AGPL

Let's go through them one by one:

Never ship on the AppStore.

By doing this, we wouldn't be contributing to Apple's app ecosystem. However, we'd be doing so at the cost of diminishing the presence and relevance of strong copyleft apps on Apple's platforms.

To Apple, the harm is negligible (and if it wasn't, they could easily just copy these apps — they have more than enough funds to do so). To the open-source movement, I'd say the harm is more pronounced. With primarily only proprietary and more permissively licensed apps being on Apple's platforms, large swaths of computer users will only get to know these projects, volunteers who are Apple users will be more likely to hack on just these projects and developers on Macs will be inspired to also choose permissive licenses for their projects.

Dual-license under a proprietary and AGPL license.

This would allow spreading AGPL apps on the AppStore without adding extra permissions to AGPL. However, it would also give the maintainer of the project a unique proprietary license to all contributed code. The danger here is that the maintainer could just sell the work contributed by volunteers to the highest bidder or extend the proprietary version with unique features, making the FOSS app inferior.

License under a more permissive license.

This is the path that projects like VLC and SyncThing chose. Both went form GPL to the more permissive MPL license.

In my eyes, this is more harmful to strong copyleft than using an exception, with all of the same problems.

Add a license exception.

Here, we're talking about this exception specifically:

As an additional permission under section 7, you are allowed to distribute the software through an app store, even if that store has restrictive terms and conditions that are incompatible with the AGPL, provided that the source is also available under the AGPL with or without this permission through a channel without those restrictive terms and conditions.

This exception still requires everyone to share the code under the AGPL. As such, this license is still a strong copyleft free and open-source license. It's also in the spirit of the AGPL, which has section 7 for situations just like these.

While it does allow companies like Apple to benefit from AGPL and GPL apps in their ecosystem, it also allows AGPL and GPL to have a foothold in this major ecosystem.

I would hope that by showing that you can have strong copyleft licenses even on Apple platforms, we would inspire others developing for these platforms to also use these licenses (rather than opting for more permissive ones like VLC or Syncthing did).

[comradekingu]

There is enough garbage to deal with already. CoCs, CLAs, DCOs, terms and agreements, and then various licenses that do the same thing.

All the "license differently" options come at a loss. Some parts translations, some parts PR, and potential issues with Hosted Weblate, and time down the drain.

"Never ship on App Store" is a great option, and one that can bring extra donations. It is the right thing to doTM, and makes it exclusive for other platforms.
The other options complicates matters, proliferate the number of effective licenses, and is a pain.

I haven't re-licensed anything for SyncThing or VLC. Pretty sure the VLC app is a entirely a different codebase.
If you think MPL is worse, don't do it. Agree there.
For the same reason, AGPLv3+ without the exception is good, and will for sure be compatible with AGPLv4+.
It is a similar pain to remove the granted permission again should that be needed.

Every time Apple just copies some app, they take a huge PR loss. Like Google, the idea that they would touch AGPLv3+ at all is dubious. Doesn't mean handing anything to them is better. They are not special. They probably have some nefarious reason other than what is stated.
Strong and full copylefted libre software on the app store is like christian black metal.
How much money do you think you will make, and I'll see if I can't match it.

[12people]

If you'd like, I'd be more than open to having a call about this — I think that would be much more efficient than writing out our beliefs in detail here.

As I explained above, I don't see not shipping on the AppStore as the right thing to do. On the contrary, it would reduce access to GPL and AGPL apps for a huge number of people (apparently, there are more than 1 billion active iPhones out there), and thereby progressively reduce the use and impact of the AGPL and GPL licenses.

And as for any complications that might arise from having this exception — the AGPL license expressly defines how to add exceptions and how they're dealt with, so there really shouldn't be complications. If there are, the license allows removing exceptions like the one above in derived works.