Les écosystèmes Android et iOS imposent des restrictions techniques et juridiques qui rendent l’utilisation de la GPLv3 problématique pour les applications mobiles. Sur Android, bien que le système soit open source, les applications distribuées via le Google Play Store doivent respecter des conditions strictes. Google exige que les applications soient statiques (sans dépendances dynamiques externes non approuvées) et impose des restrictions sur les modifications du système. La GPLv3, avec son copyleft fort et son obligation de fournir le code source complet (y compris les modifications), peut entrer en conflit avec ces règles, notamment si l’application utilise des bibliothèques propriétaires ou des services Google (comme les Google Mobile Services, GMS).
Sur iOS, la situation est encore plus restrictive. Apple impose un sandboxing strict et interdit toute modification du système d’exploitation. La GPLv3, qui exige que les utilisateurs puissent modifier et redistribuer le logiciel, est incompatible avec l’App Store, car Apple interdit la redistribution d’applications modifiées. De plus, les applications iOS doivent être signées avec un certificat Apple, ce qui limite la liberté de modification garantie par la GPLv3. Ainsi, pour ces plateformes, des licences plus permissives comme la LGPL, MIT, ou Apache 2.0 sont souvent privilégiées, car elles permettent une intégration plus flexible avec les écosystèmes fermés tout en respectant les principes du logiciel libre.
Cependant, ces contraintes ne doivent pas décourager le développement d’applications libres. Elles soulignent plutôt la nécessité de choisir des architectures modulaires et des licences adaptées pour contourner ces limitations tout en promouvant les valeurs du logiciel libre.
La Free Software Foundation (FSF) affirme que lorsque deux processus communiquent via IPC (Inter-Process Communication), comme des appels réseau locaux ou des sockets, ils ne sont pas considérés comme un travail dérivé au sens de la GPLv3. Cela signifie qu’une application sous licence propriétaire (ou permissive) pourrait théoriquement communiquer avec un composant GPLv3 via IPC sans être contrainte de publier son propre code source sous GPLv3. Cet argument repose sur l’idée que les processus sont indépendants et communiquent via des interfaces standardisées, sans lien direct entre les binaires.
Cependant, cette interprétation n’est pas universelle et pourrait être contestée, notamment si les géants technologiques comme Google, Apple ou Microsoft y voient une menace pour leurs écosystèmes fermés. Par exemple, si une application mobile utilise un serveur local GPLv3 pour contourner les restrictions des stores, ces entreprises pourraient bloquer ou restreindre une telle application, arguant qu’elle viole leurs conditions d’utilisation. Ainsi, bien que la FSF fournisse une base légale pour cette approche, son application pratique reste risquée et dépendante des politiques des plateformes.
Pour une association comme Éthiciel, qui promeut le logiciel libre, cette stratégie pourrait être explorée dans le cadre de proofs of concept (POC) lors de hackathons du Libre, afin d’évaluer sa faisabilité technique et juridique avant une implémentation à grande échelle.
Pour développer une application multiplateforme (mobile et PC) respectant les principes du logiciel libre tout en contournant les restrictions des stores, une architecture modulaire combinant Flutter, Rust et Codon pourrait être envisagée. Flutter, sous licence Apache 2.0, servirait de front-end pour une interface utilisateur unifiée. Les bindings Rust (FFI) permettraient d’appeler un serveur local écrit en Rust (sous licence permissive ou GPLv3), qui exposerait une API via IPC (par exemple, des sockets Unix ou un protocole binaire léger). Enfin, les routes de ce serveur pourraient être implémentées soit directement en Rust pour les processus lourds optimisés, soit en Python compilé avec Codon pour des performances proches du natif tout en conservant la flexibilité du Python.
Cette approche présente plusieurs avantages :
Cependant, cette solution nécessite une analyse juridique approfondie et des tests techniques pour valider sa conformité avec les politiques des stores et les principes du logiciel libre. Un POC réalisé lors de hackathons du Libre permettrait d’évaluer les risques et les opportunités de cette architecture, tout en sensibilisant la communauté aux enjeux des licences dans les écosystèmes fermés.
Article rédigé à l’aide de Mistral AI.