Mobile app
An application distributed through an app store — App Store, Google Play, alternative stores, enterprise distribution.
What actually happens
| Question | Answer |
|---|---|
| Does a third party receive the software in executable form? | Yes |
| Is the product a consumer good? | Yes |
| Can the user install a modified version? | No on iOS, with difficulty on Android |
| Does an intermediary impose its own terms? | Yes — and that is what makes this scenario special |
It is the only scenario where the difficulty comes not only from the licence, but from the conflict between the licence and the distribution channel’s terms.
The verdict per family
| Family | Verdict | Reason |
|---|---|---|
| Permissive | ● | Attribution owed, to be reachable from inside the app |
| Weak copyleft, file (MPL, EPL) | ● | Workable: reciprocity limited to modified files |
| Weak copyleft, library (LGPL) | ○ | The replacement condition is unreachable through a store |
| Strong copyleft (GPL) | ✕ | Conflict with store terms — see below |
| Network copyleft (AGPL) | ✕ | Same, aggravated |
| Source-available | ✕ | Restrictions incompatible with public distribution |
The GPL / app store conflict
The mechanism is as follows.
The GPL prohibits imposing further restrictions on recipients beyond those of the licence — GPL-2.0 section 6, GPL-3.0 section 10.
Store terms of service impose exactly such restrictions: limits on the number of devices the application may be installed on, prohibitions on redistribution, digital rights management.
Distributing an application containing GPL code through a store that imposes those restrictions therefore places the distributor in breach of the licence.
The precedent is well known: VLC was pulled from the App Store in 2011 after a contributor gave notice, and returned once part of the code had been relicensed to LGPL and then MPL. No judge ruled on it — it is a precedent of practice, not of law — but it has shaped the sector ever since.
GPL-3.0 aggravates the conflict twice over:
- the anti-lock-down clause of section 6 requires supplying what is needed to install a modified version on the product — impossible against iOS’s mandatory code signing;
- the anti-DRM clause of section 3 runs directly against the stores’ distribution model.
The LGPL on mobile
Theoretically possible, practically very hard. The LGPL requires the user to be able to replace the library with their own build and have the application run with it.
| Platform | Obstacle |
|---|---|
| iOS | The bundle is signed; any modification invalidates the signature and blocks execution |
| Android | Technically more open, but the published package is signed, and replacement means recompiling |
The route sometimes taken — supplying object files for relinking and documenting the procedure — is heavy and rarely done properly. It needs legal advice and a deliberate decision.
What remains workable
| Family | How |
|---|---|
| Permissive | Without reservation. It is the bedrock of the mobile ecosystem |
| MPL-2.0 | Per-file reciprocity with no linking constraint: VLC’s move to MPL is exactly this |
| Apache-2.0 | Recommended: permissive and patent protection, which matters in a market with active patent litigation |
Pitfalls in this scenario
Third-party SDKs. Advertising, analytics, payment, notifications, mapping: they arrive under proprietary licences, often with display obligations, personal data clauses and usage restrictions. They are rarely in the SBOM and never in the licence review.
The unreachable attribution. The attribution duty under permissive licences requires a screen reachable from inside the application. Both platforms provide a standard location for it; it needs to be populated, automatically, from the SBOM.
Native libraries. A compiled native module carries its C or C++ dependencies’ licences, invisible to the mobile package manager.
Code shared with the web. A frontend and a mobile app sharing a codebase share its components too — but not the same constraints. The strictest regime applies to the shared code.
Enterprise distribution. Distributing an app internally to your own employees is not distribution to third parties, and store terms do not apply either. The regime moves closer to the internal tool.
What the CRA adds
A mobile app is a product with digital elements. Two points deserve attention:
- classification: a health monitoring app, a home assistant, a password manager fall under Annex III, Part I — class I, with the assessment constraint that follows. See Criticality classes;
- the support period must hold despite platform-imposed cycles that force regular recompilation to stay publishable. A product still supported but no longer publishable is a situation to anticipate contractually.