Licence open source : définition, types et points d'attention pour l'entreprise

Définition

Un logiciel open source a toujours une licence. Le code est publié, mais son auteur reste titulaire des droits et ne les accorde que sous les termes de cette licence. On parle de logiciel libre, ou de licence libre, dans la tradition de la Free Software Foundation, d'open source dans celle de l'Open Source Initiative ; les deux familles recouvrent en pratique à peu près les mêmes licences.

Une licence open source n'interdit pas de facturer un support, un hébergement ou une version packagée. Les types de licences commerciales (perpétuelle, abonnement, par utilisateur) sont traités dans la page licence logicielle.

Licences permissives et copyleft

La différence tient à ce que la licence exige quand vous redistribuez le logiciel, seul ou intégré dans un autre produit.

La licence MIT, selon le texte publié par l'Open Source Initiative, accorde gratuitement le droit d'utiliser, copier, modifier, publier, distribuer, sous-licencier et vendre le logiciel, à la seule condition que l'avis de droit d'auteur et de permission figure dans toutes les copies. La licence Apache 2.0 demande en plus de remettre un exemplaire de la licence aux destinataires et de signaler les fichiers modifiés (section 4). Elle accorde aussi une licence sur les brevets des contributeurs, qui prend fin pour celui qui engage une action en contrefaçon de brevet visant le logiciel (section 3 du texte de l'Apache Software Foundation).

Une licence copyleft sert à garder libre ce qui l'était. La GPL v3 définit la redistribution (« convey ») comme toute propagation qui permet à d'autres de faire ou recevoir des copies ; une simple interaction par le réseau, sans transfert de copie, n'en est pas une. Elle exige, pour une œuvre modifiée, de licencier l'ensemble sous la même licence, avec le code source correspondant (texte de la Free Software Foundation, sections 5 et 6). L'AGPL ajoute une règle pour les services en réseau : le logiciel modifié doit proposer à ses utilisateurs distants un accès à son code source (section 13). Un usage interne, sans redistribution, ne déclenche pas en principe les obligations de la GPL ; l'AGPL est donc la licence à regarder quand le logiciel devient un service. La LGPL, enfin, reprend la GPL v3 avec des permissions supplémentaires : un programme qui utilise la bibliothèque peut être distribué sous ses propres conditions, à certaines exigences près, dont celle de ne pas empêcher la modification de la bibliothèque (texte de la FSF, section 4).

En France existe la famille CeCILL, rédigée par le CEA, le CNRS et Inria. La CeCILL v2.1 est régie par la loi française (article 13) et, à son article 5.3.4, prévoit la compatibilité avec la GPL, l'AGPL et l'EUPL : on peut combiner du code CeCILL avec du code GPL et distribuer l'ensemble sous cette licence-là. La famille compte aussi la CeCILL-B, permissive, et la CeCILL-C, un copyleft faible pensé pour les composants.

Ce que cela engage pour l'entreprise

Une entreprise qui utilise un logiciel open source en interne a peu d'obligations. La question change dès qu'elle le redistribue (produit livré à un client, application embarquée, logiciel remis à une filiale ou à un partenaire) ou, sous AGPL, dès qu'elle ouvre une version modifiée à des utilisateurs par le réseau. Aucune règle simple n'établit où s'arrête l'obligation de publier : l'effet d'un copyleft sur du code lié à une bibliothèque se discute, selon la licence et la façon dont les deux se combinent. Faites valider chaque cas par un juriste, au lieu de vous fier à un raccourci.

• Tenir la liste des composants open source et de leurs licences dans les produits que vous livrez.
• Savoir qui décide, en interne, d'intégrer un composant sous GPL ou AGPL.
• Conserver les avis de droit d'auteur et les textes de licence exigés.
• Prévoir qui répond si un auteur conteste le respect de sa licence.

Les licences open source excluent en général toute garantie : le logiciel est livré tel quel. Si le composant est critique, prévoyez un contrat de support ou de maintenance : lui seul vous donne un interlocuteur.

Open source dans une offre fournisseur

Le produit d'un éditeur ou d'un intégrateur repose souvent sur des composants open source. L'acheteur n'en a la liste que si le contrat la prévoit. Ce que vous pouvez demander, comme bonne pratique de contrat :

• Un inventaire des composants open source livrés ou utilisés, avec leur licence, mis à jour à chaque version.
• Une garantie de conformité : le fournisseur respecte les licences de ces composants et vous livre ce qu'elles exigent (textes, avis, source quand c'est requis).
• Une clause de propriété intellectuelle : il garantit que son produit ne vous expose pas à une réclamation d'un tiers et vous défend si elle survient.
• L'engagement qu'aucun composant n'impose sa licence à votre propre code ou à vos développements sur mesure, sauf accord écrit.

La même demande vaut quand vous commandez un développement spécifique : sans inventaire, vous recevez peut-être un livrable que vous ne pouvez pas redistribuer comme vous le pensiez. Cette vérification s'ajoute à celle de l'EULA ou du contrat de licence qui accompagne le produit.

Dans Naigo, une même question (« le fournisseur garantit-il le respect des licences open source ? ») peut être posée à tout un lot de contrats, avec des réponses sourcées. Voir la gestion des contrats fournisseurs.

Publié le 10 octobre 2026