Les développeurs de logiciels propriétaires se méfient parfois des plates-formes Linux embarquées, en raison des implications des licences open source telles que la GPL (GNU Public License) pour leurs applications. Ils craignent que l'utilisation de Linux ne les expose à des obligations découlant des licences open source d'autres composants logiciels du système, de telle sorte qu'ils pourraient être contraints (par le biais de litiges) de partager leur code source avec leurs concurrents, leurs clients ou le grand public.
Sans prétendre offrir des conseils juridiques, cet article présente quelques conseils et suggestions pratiques pour ceux qui envisagent de déployer une application propriétaire sur une plateforme open source, sur la base de l'expérience typique de nombre de nos clients qui utilisent des plateformes courantes comme Digi Embedded Yocto, Linaro, Android et autres.
Android, une alternative open source
Il est vrai que le moyen le plus sûr et le plus fiable d'éviter l'exposition à la GPL est de ne pas utiliser GNU/Linux du tout : Le système d'exploitation Android de Google offre une alternative open source pour les appareils embarqués. Il a été délibérément conçu dès le départ pour éliminer les logiciels sous licence GPL de son environnement utilisateur, au profit de composants sous des licences plus permissives (comme les licences Apache ou BSD) qui n'obligent pas les développeurs de travaux dérivés à partager leurs sources.
Les versions modernes d'Android ne contiennent essentiellement aucun composant sous licence GPL (à l'exception du noyau Linux lui-même, qui n'impose aucune restriction aux applications). Des distributions sont disponibles pour le matériel courant (y compris les SOM ConnectCore® de Digi), et Android a été porté avec succès sur de nombreuses cartes embarquées personnalisées.
D'un autre côté, Android a traditionnellement été moins bien adapté aux systèmes sans tête, et dans une certaine mesure, c'est un système d'exploitation maintenu par et pour les vendeurs de téléphones mobiles et les opérateurs cellulaires. Bien que de nombreux talents soient disponibles pour créer des applications sur les téléphones de nos jours, les développeurs expérimentés en matière de BSP (board-support packages) utilisant Android embarqué sont un peu moins nombreux dans la communauté.
Considérations relatives à la GPL sur GNU/Linux embarqué
Linux embarqué continue de bénéficier d'une grande diversité de support matériel et d'une large communauté de développeurs travaillant à tous les niveaux de la pile logicielle. Pour ceux qui ne sont pas opposés aux systèmes utilisant des logiciels sous licence GPL, il peut s'agir d'un excellent choix de plate-forme fiable. Au moins selon notre expérience, l'écrasante majorité des développeurs de logiciels d'application ne rencontrent pas de problèmes juridiques avec leurs clients, leurs concurrents ou le grand public.
Les développeurs d'applications sur Linux embarqué doivent néanmoins garder à l'esprit quelques concepts et règles de base. Nous aborderons les points suivants :
- Les bases de la GPL
- Applications et pilotes
- Bibliothèques à code source ouvert
- Liaison statique ou dynamique
- Communication interprocessus
- Bibliothèque C standard
- Python et autres langages de programmation
Les bases de la GPL
Les logiciels sous licence GPL sont open source : le code source doit être partagé avec toute personne à qui le logiciel est distribué. Mais le concept fondamental et le plus distinctif de la GPL (tant la GPLv2 que la GPLv3) est l'auto-propagation: la licence GPL s'applique à toute œuvre dérivée, c'est-à-dire à d'autres logiciels tels que des applications qui incorporent le logiciel GPL, par exemple en établissant des liens avec des bibliothèques GPL. Pour résumer, si votre application est liée à un logiciel sous GPL ou l'incorpore de toute autre manière, vous pouvez être obligé de partager vos sources.
Applications et pilotes
Sur un système Linux, les pilotes en général sont des composants qui se compilent avec le noyau Linux, et ils sont nécessairement soumis à la GPL. Si vous écrivez un pilote pour Linux, vous devrez peut-être partager vos sources, comme le font tous les grands fournisseurs de silicium (NXP, TI, Intel, etc.). Certains vendeurs distribuent des modules de noyau sous forme binaire (principalement pour les dispositifs cryptographiques et autres matériels très sensibles), mais le statut juridique de ces pilotes non libres n'est pas établi.
Quoi qu'il en soit, la majorité des périphériques n'ont pas de problèmes sérieux de propriété intellectuelle au niveau de l'interface du bus où opère le logiciel pilote. Lorsque les dispositifs matériels contiennent de la propriété intellectuelle de valeur, celle-ci est souvent gérée dans un micrologiciel à l'intérieur du dispositif et n'est pas exposée aux pilotes par le biais d'une interface de bus. Une application, d'autre part, fonctionne au niveau de l'espace utilisateur : elle peut communiquer avec le noyau Linux (via des appels système par le biais de bibliothèques), mais il est largement admis que les applications n'ont aucune dépendance de licence avec le noyau Linux.
Bibliothèques à code source ouvert
Les applications C/C++ doivent généralement être liées à des bibliothèques disponibles publiquement pour accéder aux fonctionnalités du système et éviter de réinventer la roue. (Par exemple, un programme C qui utilise Bluetooth peut avoir besoin de lier libbluetooth, qui fait partie de la pile BlueZ et est sous licence GPL). Puisque de nombreuses bibliothèques système sur GNU/Linux sont sous licence GPL, l'application peut prendre des obligations GPL en se liant avec elles.
Liaison statique ou dynamique
Il est communément admis que la liaison dynamique (au lieu de la liaison statique) protège l'application de l'héritage de la GPL, mais il s'agit en fait d'une question controversée qui n'a pas été entièrement résolue par les tribunaux. La FSF (Free Software Foundation, associée à GNU) maintient que la GPL s 'étend au code lié dynamiquement : https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic.
Communication interprocessus
D'un autre côté, les applications C/C++ n'ont pas besoin d'être liées à toutes les bibliothèques du système. De nombreuses applications se débrouilleront très bien sans libbluetooth ou d'autres bibliothèques sous licence GPL. Aucune obligation GPL n'est conférée à l'application si elle n'incorpore pas de logiciel sous licence GPL, même si elle fonctionne dans un environnement GNU. Si une application effectue une communication interprocessus avec des composants sous GPL (comme l'utilisation de DBus pour communiquer avec systemd ou d'autres processus démons), il est généralement admis que cela ne confère aucune obligation GPL à l'application.
Bibliothèque C standard
La seule bibliothèque avec laquelle pratiquement toutes les applications C doivent être liées est la bibliothèque C standard : l'implémentation la plus courante sous Linux est la glibc de GNU. Même s'il existe des options alternatives de bibliothèque C pour les systèmes Linux embarqués qui ont des licences permissives (comme uclibc ou musl), il n'y a pas de réel besoin pour les développeurs d'applications propriétaires d'éviter la bibliothèque C de GNU à cause de la licence : parce qu'elle n'est pas GPL.
La bibliothèque GNU C est en fait sous licence LGPL: la principale distinction pratique entre les deux est que la LGPL ("Limited GPL") autorise explicitement la liaison dynamique : si votre application lie glibc dynamiquement (et non statiquement), vous n'êtes pas obligé de partager vos sources.
Python et autres langages de programmation
Qu'en est-il des autres langages ? Si votre code n'est pas écrit en C, pouvez-vous échapper à la GPL parce que vous ne faites pas de liens vers des bibliothèques sous GPL ? Par exemple, l'interpréteur Python a sa propre licence de source ouverte permissive. Elle n'impose aucune obligation de partager les sources. Mais la licence Python est également compatible avec la GPL. Si vous écrivez et distribuez un script Python et n'importez que des bibliothèques Python non GPL, vous pouvez éviter les obligations de la GPL. D'un autre côté, certaines bibliothèques Python sont sous licence GPL. (Par exemple, si elles dépendent de bibliothèques GNU C sous-jacentes, de sorte que la GPL se propage à la bibliothèque Python). Il s'avère que le cas d'une application Python est très similaire à celui du C/C++.
À emporter
Les applications propriétaires, à source fermée, peuvent coexister avec des composants logiciels sous GPL sur un système GNU/Linux. Étant donné que le statut juridique de la liaison dynamique sous GPL est toujours contesté, un moyen sûr d'éviter de contracter accidentellement des obligations liées à la GPL est de s'assurer que votre application n'est pas liée à un logiciel sous GPL ni ne l'"incorpore" directement. Cela peut signifier chercher des alternatives pour certaines bibliothèques C ou Python. Mais la bibliothèque C standard GNU elle-même n'en fait pas partie, puisqu'elle n'a qu'une licence LGPL. Il existe de nombreux autres composants sous licence GPL fonctionnant sur un système Linux, mais il est généralement admis que ceux-ci ne propagent pas leur licence à une application dont le code n'en est pas dérivé.
Notre équipe peut fournir des conseils de conception, une conception matérielle complète et des services de développement d'applications, un support de certification et plus encore. Contactez-nous pour entamer la conversation.