Votre équipe veut intégrer une bibliothèque trouvée sur GitHub dans un produit commercial. Le code est gratuit, téléchargeable en un clic. Est-ce pour autant sans contrainte ?
Pas du tout. Un logiciel open source reste une œuvre protégée, et sa licence fixe des règles que vous devez suivre. Les ignorer peut coûter cher, surtout quand le logiciel est redistribué.
Ce qu’est un logiciel open source
Un logiciel open source est un programme dont le code source est mis à disposition de tous, avec le droit de l’étudier, de le modifier et de le redistribuer, sous les conditions fixées par une licence. Pour la définition courte et l’origine du terme, consultez notre fiche open source : définition.
On parle aussi de logiciel libre. Le mouvement du logiciel libre, lancé dans les années 1980, insiste sur quatre libertés de l’utilisateur : exécuter, étudier, modifier et redistribuer le programme. L’open source, apparu à la fin des années 1990, met plutôt en avant les vertus du développement ouvert.
Et non, open source ne veut pas dire gratuit. Rien n’empêche de vendre un logiciel libre, ou de facturer les services qui l’accompagnent.
Un logiciel protégé par le droit d’auteur
C’est l’idée reçue la plus tenace. Beaucoup pensent que le logiciel libre échappe au droit d’auteur. C’est l’inverse.
En France, l’article L112-2 du Code de la propriété intellectuelle range les logiciels parmi les œuvres de l’esprit. Au niveau européen, la directive 2009/24/CE organise leur protection. L’auteur dispose donc de droits exclusifs, et c’est grâce à eux qu’il peut imposer les conditions de sa licence. Les bases de cette protection sont détaillées dans notre article sur le droit du logiciel.
Deux précisions comptent en pratique. Un programme dérivé d’un logiciel existant est lui-même protégé, sans préjudice des droits de l’auteur d’origine (article L112-3). Et lorsqu’un salarié développe un logiciel dans l’exercice de ses fonctions, les droits patrimoniaux reviennent à l’employeur (article L113-9).
Les grandes familles de licences
Toutes les licences libres ne se valent pas. La différence se joue surtout sur un point : ce que vous devez faire quand vous redistribuez le logiciel, modifié ou non.
| Type | Exemples | Ce que cela implique |
|---|---|---|
| Copyleft fort | GPL, AGPL | Les versions modifiées redistribuées doivent rester sous la même licence, code source compris |
| Copyleft faible | LGPL, MPL | Seuls les fichiers ou composants modifiés restent soumis à la licence |
| Permissives | MIT, BSD, Apache | Réutilisation très libre, y compris dans un logiciel propriétaire, avec mention de l’auteur et de la licence |
| Licences de droit français et européen | CeCILL, EUPL | Rédigées pour s’accorder avec le droit français ou européen, avec des variantes plus ou moins contraignantes |
Les licences CeCILL ont été créées par le CEA, le CNRS et Inria pour offrir un équivalent conforme au droit français. Les administrations françaises disposent d’une liste de licences qu’elles peuvent utiliser pour publier leurs codes sources.
Les obligations à respecter
Une licence libre est un contrat. Selon la licence choisie, vous devrez notamment :
- conserver les mentions de droit d’auteur et le texte de la licence
- fournir le code source, ou indiquer comment l’obtenir, lorsque vous redistribuez le logiciel sous copyleft
- signaler les modifications apportées
- vérifier la compatibilité entre les licences des différents composants que vous assemblez
Mon conseil : tenez un inventaire des composants open source de vos produits, avec leur licence. C’est souvent la première chose qu’un acquéreur ou un client grand compte demande lors d’un audit.
Les juridictions françaises ont déjà sanctionné des entreprises qui avaient redistribué un logiciel sous GPL sans en respecter les conditions. Le risque n’a rien de théorique, comme pour toute atteinte aux droits d’auteur sur internet.
Open source, brevet et autres protections
Le droit d’auteur n’est pas la seule protection possible. Certaines inventions mises en œuvre par ordinateur peuvent être brevetées, sous des conditions strictes expliquées dans notre article sur les logiciels brevetables.
Plusieurs licences récentes, comme Apache 2.0 ou la GPL version 3, contiennent d’ailleurs des clauses sur les brevets, pour éviter qu’un contributeur ne poursuive ensuite les utilisateurs.
Si vous publiez vous-même un logiciel, pensez aussi à établir la date de création et l’identité des auteurs. Les moyens d’y parvenir sont présentés dans notre page sur la façon de protéger un logiciel.
Enfin, côté secteur public, la loi pour une République numérique de 2016 demande aux administrations d’encourager l’usage des logiciels libres et des formats ouverts. Pour un litige complexe sur une licence, l’avis d’un avocat en propriété intellectuelle reste le bon réflexe.
Cas pratique : une bibliothèque GPL dans un produit vendu
Prenons l’exemple d’une jeune entreprise qui développe un logiciel de gestion et le vend sous forme de licence installée chez ses clients. Un développeur y a intégré une bibliothèque sous GPL, sans en parler à personne.
Le jour où le logiciel est distribué aux clients, la GPL s’applique pleinement. Si le programme forme un tout avec la bibliothèque, l’éditeur doit en principe fournir le code source de l’ensemble sous la même licence. Pour une société qui comptait garder son code fermé, le problème est sérieux.
Plusieurs sorties existent :
- remplacer la bibliothèque par un composant sous licence permissive
- négocier une licence commerciale avec les titulaires des droits, quand ils en proposent une
- accepter de publier le code sous GPL
Le bon choix dépend de la valeur du code et du temps dont vous disposez avant la prochaine livraison.
Mais si le même logiciel était seulement proposé en ligne, sans remise de copie aux clients, la GPL classique n’imposerait pas la publication du code. L’AGPL a justement été écrite pour couvrir cet usage par le réseau.
Les erreurs qui reviennent le plus souvent
- Croire qu’un code publié sur GitHub sans licence est libre. Sans licence, le droit d’auteur s’applique en entier et vous n’avez en principe aucun droit de réutilisation.
- Supprimer les mentions de copyright d’un fichier repris, même sous licence MIT.
- Oublier les dépendances des dépendances. Une bibliothèque permissive peut en embarquer une autre sous copyleft.
- Copier un extrait trouvé sur un forum sans vérifier sous quelle licence il a été publié.
- Changer la licence d’un projet sans l’accord des contributeurs qui détiennent des droits sur leur code.
Franchement, la plupart de ces erreurs se règlent avant de coûter quoi que ce soit. Un outil d’analyse des dépendances, lancé à chaque nouvelle version, repère les licences incompatibles bien plus vite qu’une relecture à la main.
Et quand un composant pose question, mieux vaut trancher avant la mise sur le marché qu’après la réclamation d’un auteur.
Questions fréquentes sur les logiciels open source
Un logiciel open source est-il libre de droits ?
Non. Il reste protégé par le droit d’auteur, et c’est justement ce droit qui permet à son auteur d’imposer les conditions de la licence. Vous pouvez l’utiliser librement, mais en respectant ces conditions.
Peut-on vendre un logiciel open source ?
Oui. Les licences libres n’interdisent pas la vente. Beaucoup d’entreprises font payer la distribution, l’intégration, le support ou la maintenance, tout en laissant le code source accessible.
Que se passe-t-il si une entreprise ne respecte pas la licence GPL ?
Elle s’expose à une action de l’auteur ou du titulaire des droits, sur le terrain contractuel ou de la contrefaçon selon les cas. Les juridictions françaises ont déjà condamné des sociétés pour avoir redistribué un logiciel sous GPL sans respecter ses obligations.
Quelle différence entre logiciel libre et open source ?
Les deux notions se recoupent très largement dans les faits. Le logiciel libre met l’accent sur les libertés de l’utilisateur, l’open source sur l’ouverture du code et le modèle de développement. La plupart des licences sont reconnues par les deux mouvements.
