Chapitre 1311 minIntermédiaire
Licences logicielles : propriétaires, libres, GPL et MIT
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- distinguer licences propriétaires, permissives et copyleft ;
- vérifier qu'un projet respecte les licences de ses dépendances ;
- choisir une licence pour son propre code ;
- gérer les licences d'un parc face à un audit.
3 exercices corrigés1 schéma
Une licence logicielle est le contrat par lequel le titulaire des droits d'auteur sur un logiciel autorise d'autres personnes à l'utiliser, et parfois à le copier, le modifier ou le redistribuer, à certaines conditions. Une licence propriétaire accorde un droit d'usage limité ; une licence libre accorde les libertés d'utiliser, d'étudier, de modifier et de redistribuer, avec plus ou moins d'obligations selon qu'elle est permissive (MIT, Apache) ou copyleft (GPL, AGPL). Ce chapitre t'apprend à lire une licence, à vérifier qu'un projet la respecte et à gérer les licences d'un parc.
Le point de départ : le droit d'auteur
Le logiciel est protégé par le droit d'auteur dès sa création, sans dépôt : code source, code objet et matériel de conception préparatoire (article L112-2 du Code de la propriété intellectuelle). Les idées, les algorithmes et les fonctionnalités ne le sont pas. Les droits patrimoniaux d'un logiciel créé par un salarié dans ses fonctions appartiennent à l'employeur (article L113-9) ; ceux d'un logiciel développé par un freelance, une ESN ou un stagiaire restent au créateur, sauf cession écrite. Ces règles sont détaillées dans le cours CEJM : droit.
Conséquence : utiliser un logiciel, c'est le reproduire (l'installer, le charger en mémoire), ce qui suppose l'autorisation du titulaire. La licence est cette autorisation. Sans licence, ou hors de ses limites, l'usage est une contrefaçon (article L335-2 : 3 ans d'emprisonnement et 300 000 € d'amende, 1,5 million d'euros pour une personne morale).
Les licences propriétaires
Une licence propriétaire (on parle aussi de CLUF, contrat de licence utilisateur final, ou EULA) concède un droit d'utilisation sans transférer la propriété, et sans fournir le code source en général. Elle précise :
| Clause | Exemples |
|---|---|
| Métrique | Par utilisateur nommé, par appareil, par processeur ou cœur, par utilisateurs simultanés, par volume de données |
| Durée | Perpétuelle (avec ou sans maintenance) ou par abonnement |
| Périmètre | Usage interne, territoire, entités du groupe autorisées |
| Restrictions | Interdiction de céder, de sous-licencier, de modifier, de contourner les protections |
| Audit | Droit de l'éditeur de vérifier le nombre de licences utilisées, et pénalités en cas de dépassement |
| Garanties et responsabilité | Garantie de conformité limitée, clause limitative de responsabilité |
Les audits d'éditeurs sont une source de risque financier réel : une entreprise qui a installé un logiciel sur plus de postes que prévu, ou dans une configuration non couverte (virtualisation, cloud), doit régulariser au prix fort. D'où la gestion des licences dans l'outil de gestion de parc : inventaire des installations, rapprochement avec les licences achetées, alertes de dépassement et d'échéance (cours GLPI). C'est une activité typique de la compétence « Gérer le patrimoine informatique » de l'E5.
Avec le SaaS, le client n'installe rien : il obtient un droit d'accès à un service, défini par des conditions générales ou un contrat d'abonnement. La question n'est plus le nombre d'installations, mais le nombre de comptes, les données, la disponibilité et la réversibilité (chapitre 14).
Les licences libres et open source
Un logiciel libre garantit quatre libertés, selon la définition de la Free Software Foundation : exécuter le programme pour tous les usages ; étudier son fonctionnement et l'adapter, ce qui suppose l'accès au code source ; redistribuer des copies ; distribuer des versions modifiées. La définition de l'open source (Open Source Initiative) aboutit, en pratique, à la même liste de licences. « Libre » ne veut pas dire « libre de droits » ni « gratuit » : l'auteur garde ses droits d'auteur, et c'est précisément ce droit qui lui permet d'imposer les conditions de la licence.
| Famille | Licences | Obligation principale de qui redistribue | Peut-on l'intégrer dans un logiciel propriétaire ? |
|---|---|---|---|
| Permissive | MIT, BSD 2 ou 3 clauses | Conserver la mention de copyright et le texte de la licence | Oui |
| Permissive avec brevets | Apache 2.0 | Idem, plus indiquer les fichiers modifiés et reprendre le fichier NOTICE ; licence de brevet accordée par les contributeurs | Oui |
| Copyleft faible | LGPL, MPL 2.0, CeCILL-C | Les modifications du composant lui-même restent sous la même licence ; le logiciel qui l'utilise peut être sous une autre licence | Oui, sous conditions (liaison dynamique pour la LGPL, fichiers séparés pour la MPL) |
| Copyleft fort | GPL v2, GPL v3, CeCILL v2.1, EUPL 1.2 | Toute œuvre dérivée distribuée l'est sous la même licence, avec son code source | Non, si le logiciel propriétaire est distribué |
| Copyleft réseau | AGPL v3 | La même obligation s'applique quand le logiciel modifié est mis à disposition d'utilisateurs à travers un réseau (SaaS) | Non |
Points à bien comprendre :
- Le copyleft se déclenche à la distribution. Modifier un logiciel GPL pour un usage interne, sans le distribuer, n'oblige à rien publier. Le distribuer (le vendre, le fournir à un client, l'intégrer à un appareil) oblige à fournir le code source de l'ensemble sous GPL. C'est pourquoi l'AGPL existe : avec le SaaS, il n'y a plus de distribution, et la GPL ne s'appliquerait pas.
- La compatibilité entre licences décide si deux composants peuvent être combinés. Du code MIT peut être intégré dans un projet GPL ; l'inverse est impossible. Apache 2.0 est compatible avec la GPL v3 mais pas avec la GPL v2. Les licences françaises CeCILL (conçues pour le droit français par des organismes de recherche publics) et la licence européenne EUPL prévoient des clauses de compatibilité avec la GPL.
- Creative Commons est fait pour les contenus (textes, images, documentation), pas pour le code. CC0 et le domaine public renoncent à presque tous les droits.
Vérifier les licences d'un projet
Un projet moderne embarque des centaines de dépendances, chacune avec sa licence. Les vérifier une par une est impossible ; on outille :
- chaque fichier ou paquet déclare sa licence avec un identifiant SPDX normalisé (
MIT,Apache-2.0,GPL-3.0-only,AGPL-3.0-or-later) ; - un outil d'analyse de composition logicielle (SCA) liste les dépendances, leurs licences et leurs vulnérabilités connues ; une politique définit les licences acceptées, à examiner ou interdites ;
- une nomenclature logicielle (SBOM, Software Bill of Materials), au format SPDX ou CycloneDX, documente les composants livrés. Le Cyber Resilience Act l'impose aux fabricants de produits numériques (chapitre 15).
# Lister les licences des dépendances d'un projet Node.js (outil libre license-checker-rseidelsohn)
npx license-checker-rseidelsohn --summary
# Échouer si une dépendance est sous licence copyleft forte ou réseau (identifiants SPDX actuels et anciens)
npx license-checker-rseidelsohn --failOn "GPL-2.0;GPL-2.0-only;GPL-3.0;GPL-3.0-only;GPL-3.0-or-later;AGPL-3.0;AGPL-3.0-only;AGPL-3.0-or-later"
Choisir la licence de son propre code dépend de l'objectif : être réutilisé le plus largement possible, y compris dans des produits fermés (MIT, Apache 2.0), ou garantir que les améliorations restent libres (GPL, AGPL). Un fichier LICENSE à la racine du dépôt, et une mention SPDX dans chaque fichier source, suffisent. Sans licence, un code publié sur GitHub reste protégé par le droit d'auteur : personne n'a le droit de le réutiliser.
Exercices
Exercice 1 sur 3 Quelle licence choisir ? Réussi À revoir
Nadia a développé une bibliothèque de composants d'interface pour le portail. Cèdre Habitat veut la publier pour que d'autres bailleurs puissent l'utiliser, y compris dans leurs logiciels propriétaires, à condition que Cèdre Habitat soit citée. Quelle licence recommander ? Et si l'objectif était que toute amélioration revienne à la communauté, même quand la bibliothèque est utilisée dans un service en ligne ?
Voir la réponseMasquer la réponse de l'exercice 1
- Premier objectif : une licence permissive, MIT ou Apache 2.0. Toutes deux autorisent l'intégration dans un logiciel propriétaire et imposent de conserver la mention de copyright. Apache 2.0 ajoute une licence de brevet et l'obligation de signaler les modifications. Le code a été écrit par Nadia, salariée, dans ses fonctions : c'est bien Cèdre Habitat, titulaire des droits (article L113-9), qui choisit la licence.
- Second objectif : AGPL v3, qui étend le copyleft à la mise à disposition par le réseau. La GPL ne suffirait pas, puisqu'un service en ligne ne distribue pas le logiciel.
Tu avais trouvé ?
Exercice 2 sur 3 Ces usages sont-ils permis ? Réussi À revoir
Pour chaque cas, dis si la licence est respectée et ce qu'il faut faire.
- Une ESN intègre une bibliothèque MIT dans un logiciel qu'elle vend sous licence propriétaire, sans mentionner la bibliothèque.
- Cèdre Habitat modifie un logiciel GPL v3 pour son usage interne et ne publie pas ses modifications.
- Un éditeur intègre une bibliothèque GPL v3 dans un logiciel de bureau qu'il vend à ses clients, sans fournir le code source.
- Une start-up modifie un logiciel AGPL v3 et le propose en SaaS sans publier ses modifications.
- Un développeur utilise une bibliothèque LGPL, liée dynamiquement, dans une application propriétaire distribuée, sans la modifier.
Voir la réponseMasquer la réponse de l'exercice 2
- Non respectée : la licence MIT impose de conserver la notice de copyright et le texte de la licence dans les copies distribuées. Correction simple : ajouter les mentions (fichier de licences tierces, écran « À propos »).
- Respectée : sans distribution, le copyleft ne s'applique pas.
- Non respectée : en distribuant une œuvre dérivée d'un code GPL, l'éditeur doit la distribuer sous GPL avec son code source. C'est une contrefaçon. Il doit soit publier le logiciel sous GPL, soit remplacer la bibliothèque, soit obtenir une licence commerciale si l'auteur en propose une (double licence).
- Non respectée : l'AGPL oblige à proposer le code source modifié aux utilisateurs qui interagissent avec le logiciel à travers le réseau.
- Respectée, si la liaison permet de remplacer la bibliothèque par une autre version, si la licence LGPL et la notice sont fournies et si le code source de la bibliothèque est accessible.
Tu avais trouvé ?
Exercice 3 sur 3 Un audit de licences Réussi À revoir
Lors d'un audit, un éditeur constate que son logiciel de dessin, acheté en 20 licences par utilisateur nommé, est installé sur 34 postes de Cèdre Habitat et utilisé par 27 personnes.
- Quelle est la qualification juridique ?
- Quelles mesures la DSI aurait-elle dû prendre ?
Voir la réponseMasquer la réponse de l'exercice 3
- Les 7 utilisateurs nommés non couverts (27 − 20) utilisent le logiciel hors des limites de la licence : c'est une contrefaçon. L'éditeur peut exiger l'achat des licences manquantes, souvent au tarif public avec pénalités prévues au contrat, et pourrait agir en justice. Les 7 installations supplémentaires non utilisées ne posent pas de problème si la licence ne compte que les utilisateurs nommés, mais elles doivent être retirées si le contrat compte aussi les installations.
- Tenir l'inventaire des installations et le rapprocher des licences achetées dans l'outil de gestion de parc ; restreindre l'installation aux administrateurs ; désinstaller le logiciel des postes qui n'en ont plus besoin ; lire la métrique de chaque contrat (utilisateur, poste, cœur) ; anticiper les renouvellements.
Tu avais trouvé ?