Application mobile
Application distribuée par un magasin d’applications — App Store, Google Play, magasins alternatifs, distribution d’entreprise.
Ce qui se passe réellement
| Question | Réponse |
|---|---|
| Un tiers reçoit-il le logiciel sous forme exécutable ? | Oui |
| Le produit est-il un bien de consommation ? | Oui |
| L’utilisateur peut-il installer une version modifiée ? | Non sur iOS, difficilement sur Android |
| Un intermédiaire impose-t-il ses propres conditions ? | Oui — et c’est la particularité du scénario |
C’est le seul scénario où la difficulté ne vient pas seulement de la licence, mais du conflit entre la licence et les conditions du canal de distribution.
Le verdict par famille
| Famille | Verdict | Raison |
|---|---|---|
| Permissive | ● | Attribution due, à rendre accessible depuis l’application |
| Copyleft faible fichier (MPL, EPL) | ● | Praticable : réciprocité limitée aux fichiers modifiés |
| Copyleft faible bibliothèque (LGPL) | ○ | La condition de remplacement est inatteignable sur un magasin |
| Copyleft fort (GPL) | ✕ | Conflit avec les conditions de magasin — voir ci-dessous |
| Copyleft réseau (AGPL) | ✕ | Idem, aggravé |
| Source-available | ✕ | Restrictions incompatibles avec une distribution publique |
Le conflit GPL / magasin d’applications
Le mécanisme est le suivant.
La GPL interdit d’imposer aux destinataires des restrictions supplémentaires au-delà de celles de la licence — GPL-2.0 article 6, GPL-3.0 article 10.
Or les conditions d’utilisation des magasins imposent précisément de telles restrictions : limitation du nombre d’appareils sur lesquels l’application peut être installée, interdiction de redistribution, gestion des droits numériques.
Distribuer une application contenant du code GPL via un magasin qui impose ces restrictions place donc le distributeur en violation de la licence.
Le précédent est connu : VLC a été retiré de l’App Store en 2011 à la suite d’une notification d’un contributeur, puis republié après relicenciement d’une partie du code en LGPL puis MPL. L’affaire n’a pas été tranchée par un juge — c’est un précédent de fait, pas de droit, mais il structure la pratique du secteur depuis.
GPL-3.0 aggrave le conflit de deux façons :
- l’anti-verrouillage de l’article 6 exige de fournir de quoi installer une version modifiée sur le produit — impossible face à la signature de code obligatoire d’iOS ;
- la clause anti-DRM de l’article 3 s’oppose frontalement au modèle de distribution des magasins.
La LGPL sur mobile
Théoriquement possible, pratiquement très difficile. La LGPL exige que l’utilisateur puisse remplacer la bibliothèque par sa propre version et faire fonctionner l’application avec.
| Plateforme | Obstacle |
|---|---|
| iOS | Le paquet est signé ; toute modification invalide la signature et empêche l’exécution |
| Android | Techniquement plus ouvert, mais le paquet publié sur le magasin est signé, et le remplacement suppose de recompiler |
La voie parfois retenue — fournir les fichiers objets permettant de relier, et documenter la procédure — est lourde et rarement mise en œuvre correctement. Elle suppose un avis juridique et une décision assumée.
Ce qui reste praticable
| Famille | Comment |
|---|---|
| Permissive | Sans réserve. C’est le socle de l’écosystème mobile |
| MPL-2.0 | Réciprocité par fichier, sans contrainte de liaison : la relicence de VLC vers MPL est exactement ce mouvement |
| Apache-2.0 | Recommandée : permissive et protection brevets, ce qui compte sur un marché où le contentieux brevets est actif |
Les pièges de ce scénario
Les SDK tiers. Publicité, analytique, paiement, notifications, cartographie : ils arrivent avec des licences propriétaires, souvent assorties d’obligations d’affichage, de clauses de données personnelles et de restrictions d’usage. Ils sont rarement dans le SBOM, et jamais dans la revue de licences.
L’attribution introuvable. L’obligation d’attribution des licences permissives suppose un écran accessible depuis l’application. Les deux plateformes fournissent un emplacement standard pour cela ; il faut l’alimenter, automatiquement, depuis le SBOM.
Les bibliothèques natives. Un module natif compilé emporte les licences de ses dépendances C ou C++, invisibles dans le gestionnaire de paquets mobile.
Le partage de code avec le web. Un frontend et une application mobile qui partagent une base de code partagent aussi ses composants — mais pas les mêmes contraintes. C’est le régime le plus strict qui s’applique au code partagé.
La distribution d’entreprise. Diffuser une application en interne à ses propres salariés n’est pas une distribution à des tiers ; les conditions du magasin ne s’appliquent pas non plus. Le régime se rapproche de l’outil interne.
Ce que le CRA ajoute
Une application mobile est un produit comportant des éléments numériques. Deux points méritent attention :
- la classification : une application de suivi de santé, un assistant domotique, un gestionnaire de mots de passe relèvent de l’annexe III, partie I — classe I, avec la contrainte d’évaluation qui s’y attache. Voir Les classes de criticité ;
- la période de support doit tenir malgré les cycles imposés par les plateformes, qui obligent à recompiler régulièrement pour rester publiable. Un produit encore supporté mais devenu impubliable est une situation à anticiper contractuellement.