# Code GitHub dans un produit commercial : licences et points à vérifier > Les licences permissives MIT, Apache et BSD, les licences copyleft GPL/AGPL, l’absence de fichier LICENSE et la vérification de l’origine du code ajouté par l’IA. Source: https://ailoot.ai/blog/fr/github-code-commercial-licenses/ Canonical: https://ailoot.ai/blog/fr/github-code-commercial-licenses/ Language: fr Publisher: Ailoot (https://ailoot.ai/) Translation: guide-177 Revision: sha256-397280190d1d5ab04a8a8de2a5213c720057bd12858cb31ed0a49add389f088d Vous développez un produit et trouvez sur GitHub un élément prêt à l’emploi : une bibliothèque, un modèle, un projet entier qui fait exactement ce dont vous avez besoin. Claude suggère de l’intégrer à votre projet. Puis vous hésitez : le code semble accessible au public, mais pouvez-vous réellement l’utiliser, et même vendre un produit qui le contient ? Son auteur pourrait-il s’en prendre à vous plus tard ? Je vais examiner les choses dans l’ordre : pourquoi le code ouvert sur GitHub ne vaut pas autorisation, quelles licences vous permettent d’utiliser du code et de vendre un produit, quelles conditions copyleft peuvent exiger la source correspondante d’une œuvre couverte, et comment vérifier une licence en une minute avant d’utiliser le code. Pas de « cela dépend de la situation ». [Vous trouverez dans la documentation des informations pratiques sur l’utilisation d’Ailoot](https://ailoot.ai/docs/).
Attention Ce contenu est fourni à titre informatif ; je ne suis pas avocat. Je décris ci-dessous les conditions des licences et règles courantes, avec des liens vers les sources primaires, mais vérifiez votre situation précise à la lumière du texte de la licence et, si le produit est important et commercial, auprès d’un avocat. C’est à vous de prendre la décision.
## Est-il vrai que si un code est sur GitHub, on peut l’utiliser gratuitement ?
L’essentiel Non. Le fait qu’un code soit consultable ne signifie pas que vous êtes autorisé à l’utiliser dans votre propre travail. Par défaut, tout code est protégé par le droit d’auteur, et vous ne pouvez pas l’utiliser si son auteur ne vous en a pas accordé séparément l’autorisation. À lui seul, le fait de publier un code sur GitHub permet seulement aux autres de consulter le dépôt et d’en faire une copie au sein de GitHub. Le droit d’intégrer ce code à votre produit découle de la licence que l’auteur a jointe au dépôt. GitHub ne vous l’accorde pas.
Le principal piège, ici, tient au mot « ouvert ». Vous voyez le code source et vous pensez donc qu’il est utilisable puisqu’il n’est pas caché. Ce raisonnement est faux. « Ouvert à la lecture » et « autorisé sous licence pour être utilisé » sont deux choses différentes. Par défaut, toute œuvre de création, y compris un code, est protégée par le droit d’auteur dès sa création. Tant que l’auteur n’a pas explicitement donné son autorisation, vous ne pouvez pas l’utiliser. C’est ainsi que GitHub le décrit sur sa propre page de référence sur les licences.

Lorsque vous créez une œuvre (et le code est lui aussi une œuvre), celle-ci est protégée par défaut par un droit d’auteur exclusif. Si vous ne joignez pas une licence indiquant le contraire, personne d’autre ne peut copier, distribuer ou modifier votre œuvre sans risquer une réclamation ou une action en justice.

— choosealicense.com (projet de référence GitHub), https://choosealicense.com/no-permission/
La deuxième dimension, c’est GitHub lui-même. Certains pensent qu’en acceptant les règles de GitHub lorsqu’ils publient du code, ils peuvent également utiliser le code d’autres personnes qui s’y trouve. Les règles disent précisément le contraire. En rendant un dépôt public, l’auteur autorise seulement les autres à le consulter et à le forker, c’est-à-dire à en faire une copie au sein de GitHub. Cela ne vous autorise pas à utiliser le code dans votre propre travail.

En rendant un dépôt public, vous accordez aux autres utilisateurs une licence non exclusive et mondiale leur permettant d’utiliser, d’afficher et de reproduire vos éléments (en les forkant) par l’intermédiaire du service et dans le cadre des fonctionnalités de GitHub. Vous pouvez accorder des droits supplémentaires en joignant une licence.

— Conditions d’utilisation de GitHub, section D, https://docs.github.com/en/site-policy/github-terms/github-terms-of-service
Les mots clés se trouvent dans la dernière phrase : « dans le cadre des fonctionnalités de GitHub » et « une licence permet d’accorder des droits supplémentaires ». Un fork reste dans GitHub. Dès que vous voulez utiliser le code dans votre propre produit, et à plus forte raison le vendre, vous avez besoin d’une licence distincte accordée par l’auteur. Pas de licence, pas de droit — même si le code est là, en plein jour. ## De quoi dépend le droit d’utiliser le code de quelqu’un d’autre ?
L’essentiel Tout dépend du fichier de licence dans le dépôt, généralement nommé LICENSE ou LICENSE.md. Il contient l’autorisation de l’auteur et précise ce que vous pouvez et ne pouvez pas faire avec le code. La licence répond à trois questions : pouvez-vous utiliser le code dans un produit commercial ? Pouvez-vous le modifier ? Devez-vous ensuite ouvrir le code source de votre propre produit, ou pouvez-vous le garder fermé ? Les différentes licences répondent différemment à ces questions : le premier fichier à vérifier est donc celui-ci, avant même d’ouvrir le code.
Tout se joue autour d’un seul fichier. Un dépôt correctement maintenu contient un fichier de licence, généralement nommé LICENSE, parfois LICENSE.md, ou une mention directement dans le README. C’est l’autorisation de l’auteur, qui précise les conditions d’utilisation du code. GitHub affiche généralement le nom de la licence dans la barre latérale de la page du dépôt, avant même que vous ouvriez le fichier. Pour ne pas vous perdre dans le langage juridique, il est utile de lire la licence en vous posant trois questions concernant votre situation : 1. **Pouvez-vous utiliser ce code dans un produit commercial** que des personnes paient ? 2. **Pouvez-vous modifier le code** en fonction de vos besoins ? 3. **Devez-vous ensuite ouvrir le code source de votre produit**, ou pouvez-vous le garder fermé ? Presque toutes les différences entre les licences tiennent aux réponses distinctes à la troisième question. Pour les deux premières, les licences libres courantes répondent le plus souvent « oui » : utilisez-le, modifiez-le, vendez-le. C’est la question de savoir si la licence vous obligera à ouvrir votre propre code qui fait trébucher les gens. Voyons ensuite les principaux types à l’aide de ces trois questions. ## Quelles licences permettent d’utiliser du code et de vendre un produit ?
L’essentiel Les licences les plus pratiques pour un produit commercial sont les licences permissives : MIT, Apache 2.0 et BSD. Elles autorisent presque tout : utiliser le code, le modifier, vendre le produit et garder votre propre code source fermé. Il y a une obligation : conserver le texte de la licence et l’attribution. Apache 2.0 protège aussi contre les revendications liées aux brevets et exige que vous indiquiez les fichiers modifiés. Si le code de quelqu’un d’autre est publié sous l’une de ces licences, vous pouvez l’utiliser sans risque dans un produit commercial.
Commençons par une bonne nouvelle. Pour qui développe un produit destiné à la vente, le meilleur choix est un groupe de licences appelées « licences permissives ». Il en existe plusieurs, mais trois sont les plus courantes : MIT, Apache 2.0 et BSD. Toutes trois répondent « oui » aux deux premières questions et vous permettent de garder votre propre code source fermé. La plus courante et la plus simple est MIT. Son texte tient en un seul paragraphe.

La présente autorisation est accordée gratuitement à toute personne qui obtient une copie de ce logiciel, afin qu’elle puisse l’utiliser sans restriction, y compris les droits d’utiliser, de copier, de modifier, de fusionner, de publier, de distribuer, d’accorder des sous-licences et de vendre des copies, sous réserve que l’avis de droit d’auteur et le présent avis d’autorisation figurent sur toutes les copies.

— Licence MIT, opensource.org, https://opensource.org/license/mit
En termes plus simples, MIT vous permet de presque tout faire avec le code, notamment de vendre le produit et de garder votre propre code source fermé. La seule obligation consiste à inclure le texte de la licence et la ligne d’attribution. Babel, .NET et Rails, par exemple, sont publiés sous MIT : vous avez donc presque certainement déjà utilisé du code sous cette licence. Apache 2.0 fonctionne de façon similaire, mais ajoute deux points importants. Premièrement, elle offre une protection explicite contre les revendications liées aux brevets : les auteurs du code promettent de ne pas vous poursuivre au sujet des brevets portant sur ce code. Deuxièmement, elle impose quelques exigences formelles supplémentaires pour son utilisation.

Vous pouvez reproduire et distribuer des copies de l’œuvre ou de ses œuvres dérivées sur tout support, avec ou sans modifications, à condition de fournir aux destinataires une copie de cette licence, de marquer les fichiers modifiés, de conserver les avis de droit d’auteur et de brevet, et d’inclure une copie lisible du fichier NOTICE, s’il existe.

— Licence Apache 2.0, section 4, https://www.apache.org/licenses/LICENSE-2.0
BSD (dans ses versions à 2 et 3 clauses) est essentiellement comparable à MIT : utilisez le code, modifiez-le, vendez-le et conservez l’avis de droit d’auteur. J’ai mis les trois licences dans un tableau pour vous permettre de voir la différence d’un coup d’œil. | Licence | Vendre le produit | Garder le code source fermé | Obligations | Protection contre les brevets | |----|----|----|----|----| | MIT | oui | oui | conserver l’avis de droit d’auteur et le texte de la licence | aucune clause | | Apache 2.0 | oui | oui | avis de droit d’auteur, fichier NOTICE, signaler les modifications | oui | | BSD (2 et 3 clauses) | oui | oui | conserver l’avis de droit d’auteur | non | Comment lire ce tableau pour votre propre usage : si le code de quelqu’un d’autre est sous licence MIT, Apache 2.0 ou BSD, vous pouvez être tranquille : vous pouvez l’utiliser dans un produit commercial, le modifier et garder votre propre code source fermé. Veillez seulement à ne pas supprimer le fichier de licence et l’attribution de la partie que vous avez reprise. ## Comment s’appliquent les obligations de source GPL et AGPL ?
L’essentiel GPL et AGPL autorisent l’usage commercial. Les obligations GPL naissent de la transmission d’une œuvre couverte ; l’usage serveur sans copie transférée n’est pas ce déclencheur. AGPLv3 ajoute une offre de source aux utilisateurs interagissant à distance avec une version modifiée. Déterminez l’œuvre combinée couverte : les composants indépendants ne le sont pas automatiquement tous.
Le copyleft maintient l’œuvre couverte et ses dérivés sous la même licence lorsque les conditions applicables sont réunies. Distribuer des copies source ou binaires d’une œuvre couverte ou d’un ensemble dérivé sous GPLv3 exige respect de licence et fourniture de source correspondante. Cela ne s’étend pas automatiquement à tout programme indépendant du même produit ou serveur. Héberger une bibliothèque GPL sur votre serveur sans remettre de copies aux utilisateurs n’impose pas à lui seul de publier tout le service. Distribuer une application combinée couverte peut déclencher les obligations GPL : vérifiez intégration et licence pour déterminer les sources à fournir. Un client navigateur livré aux utilisateurs constitue une question de distribution distincte. AGPLv3 ajoute une condition réseau : si vous modifiez le programme et que des utilisateurs interagissent à distance avec cette version, il doit leur proposer clairement sa source correspondante. Cela ne signifie pas que tout composant AGPL hébergé ouvre chaque partie indépendante du service. Pour un produit propriétaire, examinez œuvre couverte, intégration, copies distribuées et interaction réseau AGPL. Choisissez une alternative permissive compatible ou obtenez une autorisation distincte si vous ne pouvez respecter ces obligations. L’usage commercial est autorisé ; c’est le respect de la licence et de l’intégration réelles qui compte. ## Que faire si le dépôt ne contient aucun fichier de licence ?
L’essentiel Sans fichier de licence, vous ne pouvez pas utiliser le code. Cela ne signifie pas qu’il est « gratuit » : au contraire, sans licence, le code reste entièrement protégé par le droit d’auteur de son auteur, et vous n’avez pas le droit de l’utiliser, de le copier ou de le modifier. L’autorisation de le consulter et de le forker dans GitHub n’y change rien : elle ne vous donne pas le droit d’intégrer le code à votre produit. Si vous avez vraiment besoin de ce code, la seule démarche correcte consiste à écrire à l’auteur pour lui demander son autorisation, ou à attendre qu’il ajoute une licence.
Une erreur fréquente consiste à supposer que l’absence de licence signifie qu’il n’y a pas de restrictions et que l’on peut utiliser librement le code. C’est l’inverse. Pas de licence ne signifie pas autorisation ; par défaut, cela signifie qu’il n’y a pas d’autorisation. Le code dépourvu de licence reste entièrement protégé par le droit d’auteur de son auteur, et vous ne pouvez pas y toucher. La règle énoncée au début s’applique de nouveau : par défaut, le code est protégé par le droit d’auteur, et sans autorisation explicite, vous ne pouvez pas le copier, le modifier ou le distribuer. Le fait de pouvoir le consulter et le forker dans GitHub ne franchit pas cette barrière : il ne vous donne pas le droit d’utiliser le code dans votre propre produit. Que faire en pratique si le code n’a pas de licence, mais que vous en avez vraiment besoin ? 1. **Écrivez à l’auteur.** Dans l’espace de discussion du dépôt ou par e-mail, demandez-lui directement si vous pouvez utiliser le code et sous quelles conditions. Parfois, l’auteur a simplement oublié d’ajouter une licence et l’ajoutera si vous le lui demandez. 2. **Cherchez un remplacement.** Pour presque toutes les tâches, il existe un deuxième, un troisième et un dixième dépôt similaire : vous en trouverez un qui possède une licence MIT ou Apache appropriée. 3. **Ne l’utilisez pas.** Si vous n’avez pas d’autorisation et qu’il n’existe aucun remplacement, le code ne vous appartient pas et vous ne pouvez pas l’intégrer à un produit que vous comptez vendre. La tentation de se dire « qui va s’en rendre compte ? » finit mal dès que le produit commence à rapporter de l’argent et à attirer l’attention. ## Et si Claude lui-même a ajouté au projet le code de quelqu’un d’autre ?
L’essentiel C’est un cas distinct, qu’il est important de ne pas confondre avec la copie directe d’un dépôt. Lorsque vous prenez vous-même du code dans un dépôt précis, vous devez respecter sa licence. Lorsque Claude ou une autre IA génère du code en réponse à votre demande, elle produit généralement son propre texte, composé pour la tâche, plutôt qu’une copie du fichier de quelqu’un d’autre ; la question porte alors sur les droits relatifs au code généré. Mais si l’IA a clairement reproduit une partie reconnaissable du code sous licence d’autrui, les conditions de cette licence s’appliquent toujours. Dans les deux cas, il vaut la peine de vérifier l’origine du code.
Il y a ici une deuxième dimension qu’il est facile de confondre avec la première. C’est une chose de consulter un dépôt et d’en copier un fichier : vous êtes alors directement soumis à tout ce qui précède au sujet de la licence. C’en est une autre lorsque Claude écrit du code pour vous en réponse à une demande. Dans les cas ordinaires, l’IA produit son propre texte, composé pour votre tâche, plutôt qu’une copie du fichier de quelqu’un d’autre. La question se déplace alors vers un autre sujet : à qui appartient le code généré, et pouvez-vous le vendre ? C’est un sujet important à part entière, que j’ai traité dans un article sur la propriété du code écrit par l’IA. Mais il faut garder à l’esprit une exception. Parfois, l’IA produit presque mot pour mot une partie reconnaissable du code d’une autre personne, par exemple une fonction entière d’une bibliothèque connue. Dans ce cas, la licence de la bibliothèque s’applique toujours, quelle que soit la personne qui a appuyé sur les touches. Il faut donc vérifier les grands blocs prêts à l’emploi que Claude a repris en entier comme si vous les aviez copiés vous-même. ## Comment vérifier une licence avant d’utiliser du code : les étapes à suivre
L’essentiel La procédure est la suivante : ouvrez la page du dépôt et vérifiez le nom de la licence dans la barre latérale, ouvrez le fichier LICENSE lui-même, déterminez le type de licence — permissive (MIT, Apache, BSD) ou copyleft (GPL, AGPL) —, comparez-la à votre situation, puis décidez d’utiliser le code ou de chercher un remplacement. S’il n’y a aucune licence, ne l’utilisez pas. La vérification prend quelques minutes et doit être faite avant que le code n’entre dans votre projet, pas après.
Rassemblons tout cela dans une courte liste de vérification pour examiner tout code tiers avant de l’intégrer à votre projet. Suivez les étapes de haut en bas. 1. ### Trouvez le nom de la licence sur la page du dépôt Ouvrez le dépôt sur GitHub. Le nom de la licence apparaît généralement dans la colonne de droite ou sous la liste des fichiers, par exemple « MIT License », « Apache-2.0 » ou « GPL-3.0 ». Si le champ est vide et qu’il n’y a pas de fichier de licence, c’est déjà un signal d’alerte ; revenez-y à la dernière étape. 2. ### Ouvrez le fichier de licence lui-même Cherchez LICENSE, LICENSE.md ou COPYING dans la liste des fichiers et ouvrez-le. Vérifiez que son nom correspond à celui affiché dans la barre latérale et que la licence s’applique au code que vous utilisez, et pas seulement à une partie distincte du dépôt. 3. ### Déterminez le type : permissif ou copyleft MIT, Apache 2.0 et BSD sont des licences permissives ; vous pouvez utiliser le code dans un produit commercial fermé. GPL et AGPL sont copyleft ; vérifiez œuvre couverte, distribution et condition réseau AGPL avant de déterminer les obligations. Le nom seul ne détermine pas les composants indépendants couverts. 4. ### Comparez la licence à votre situation Répondez à trois questions : vendez-vous le produit, modifiez-vous le code et souhaitez-vous garder le code source fermé ? MIT, Apache et BSD conviennent à un produit fermé destiné à la vente. Pour GPL et AGPL, déterminez quelle œuvre couverte ou combinée exige sa source correspondante et quand l’obligation se déclenche, puis évaluez votre capacité à la respecter. 5. ### Pas de licence, donc pas d’utilisation S’il n’y a pas de fichier de licence et que le README ne dit rien au sujet de l’autorisation, vous ne pouvez pas utiliser le code. Écrivez à l’auteur pour lui demander l’autorisation ou cherchez un équivalent sous une licence appropriée. « Il est accessible au public » ne signifie pas que vous en avez l’autorisation. Cette vérification semble fastidieuse jusqu’au jour où votre produit se développe, commence à rapporter de l’argent et où quelqu’un s’interroge sur le code tiers qu’il contient. Deux minutes au début coûtent moins cher qu’un litige plus tard. Je traite séparément de ce qu’il faut faire ensuite avec votre produit pour éviter qu’il ne stagne après son lancement : [J’ai créé un produit avec l’IA ; quelle est la suite ?](https://ailoot.ai/blog/fr/ai-product-maintenance-after-launch/).
### Questions fréquentes Peut-on vendre un produit qui contient le code d’une autre personne provenant de GitHub ? Oui, si le code est sous une licence permissive — MIT, Apache 2.0 ou BSD. Ces licences vous permettent d’utiliser le code dans un produit commercial, de le vendre et de garder votre propre code source fermé, à condition de conserver le texte de la licence et l’attribution. GPL et AGPL autorisent aussi le commerce ; les obligations de source dépendent de l’œuvre couverte et de la distribution ou du déclencheur réseau AGPL applicable. Sans fichier de licence, vous ne pouvez pas utiliser le code. Que signifie l’absence de licence dans un dépôt GitHub ? Cela signifie que vous ne pouvez pas utiliser le code. Par défaut, pas de licence signifie pas d’autorisation ; cela ne veut pas dire « gratuit ». Le code reste entièrement protégé par le droit d’auteur de son auteur. Le fait de pouvoir consulter et forker le dépôt dans GitHub ne vous donne pas le droit d’utiliser le code dans votre produit. Si vous en avez besoin, écrivez à l’auteur pour lui demander son autorisation ou trouvez un équivalent sous une licence libre. Quelle est la différence entre MIT et GPL pour mon produit ? MIT vous permet d’utiliser et de modifier le code, de vendre le produit et de garder votre propre code source fermé ; la seule obligation consiste à conserver le texte de la licence. GPL autorise aussi le commerce ; transmettre une œuvre combinée ou dérivée couverte exige le respect des obligations de source correspondante et de même licence. L’hébergement sans copie transférée est différent, et les composants indépendants ne sont pas automatiquement couverts. Dois-je faire quelque chose si j’utilise du code sous licence MIT ? Oui, une petite chose : conserver le texte de la licence MIT et la ligne d’attribution du code que vous avez utilisé dans votre projet. Il s’agit généralement du même fichier LICENSE que celui joint à l’original. MIT n’impose rien d’autre : vous pouvez modifier le code, vendre le produit et garder votre code source fermé. Et si Claude lui-même a ajouté le code de quelqu’un d’autre, et non moi ? Vous devez tout de même vérifier l’origine du code. L’IA produit généralement son propre texte pour votre tâche, et la question porte alors sur les droits relatifs au code généré, un sujet distinct. Mais si l’IA a reproduit presque mot pour mot une partie reconnaissable du code d’une autre personne provenant d’une bibliothèque connue, la licence de cette bibliothèque s’applique toujours. Vérifiez les grands blocs prêts à l’emploi repris en entier comme vous le feriez pour vos propres copier-coller.
### Sources - [choosealicense.com - Projet de référence GitHub pour choisir une licence](https://choosealicense.com/) - [choosealicense.com - Ce que signifie l’absence de licence](https://choosealicense.com/no-permission/) - [Conditions d’utilisation de GitHub, section D (octroi de licence aux autres utilisateurs)](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service) - [Licence MIT (opensource.org)](https://opensource.org/license/mit) - [Licence Apache 2.0 (apache.org)](https://www.apache.org/licenses/LICENSE-2.0) - [GNU General Public License v3.0 (gnu.org)](https://www.gnu.org/licenses/gpl-3.0.en.html) - [GNU Affero General Public License v3.0 (gnu.org)](https://www.gnu.org/licenses/agpl-3.0.en.html)
[Ouvrir Ailoot](https://ailoot.ai/). ## Questions fréquentes : Code GitHub dans un produit commercial : licences et points à vérifier ### Héberger une bibliothèque GPL impose-t-il de publier tout mon service web ? L’hébergement seul sans transfert de copies ne déclenche pas la distribution GPL. Si vous distribuez une application combinée ou dérivée couverte, des obligations de source peuvent viser cette œuvre ; les composants indépendants ne sont pas automatiquement couverts. ### Quelle condition AGPLv3 ajoute-t-elle pour un service web ? Un programme AGPL modifié permettant une interaction réseau doit proposer sa source correspondante à ces utilisateurs. Vérifiez programme couvert et intégration sans supposer ni absence d’obligation ni ouverture de tout service indépendant. ## Ailoot · L’entreprise et son portefeuille de projets Ailoot s’appuie sur une expérience opérationnelle éprouvée, une large clientèle, un service stable et un suivi continu des KPI. L’entreprise et son portefeuille de projets : des millions de clients ; des ventes qui se chiffrent en milliards chaque mois. Ailoot met cette expérience opérationnelle au service de l’accès API aux fonctions d’IA dans les produits des clients, leurs agents, applications et automatisations.