{"meta":{"title":"À propos de la conformité des licences open source","intro":"Définissez et appliquez une stratégie de licence pour les dépendances dans vos référentiels grâce à la conformité des licences open source.","product":"Sécurité et qualité du code","breadcrumbs":[{"href":"/fr/code-security","title":"Sécurité et qualité du code"},{"href":"/fr/code-security/concepts","title":"Concepts"},{"href":"/fr/code-security/concepts/supply-chain-security","title":"Sécurité de la chaîne d’approvisionnement"},{"href":"/fr/code-security/concepts/supply-chain-security/open-source-license-compliance","title":"Conformité des licences open source"}],"documentType":"article"},"body":"# À propos de la conformité des licences open source\n\nDéfinissez et appliquez une stratégie de licence pour les dépendances dans vos référentiels grâce à la conformité des licences open source.\n\n> \\[!NOTE]\n> La conformité des licences open source est en préversion publique cours et peut être modifiée.\n\n## Aperçu\n\nLa conformité aux licences open source vous aide à **suivre les licences des dépendances** et à **faire respecter la politique** pour les logiciels open source de votre chaîne d’approvisionnement. Vous pouvez utiliser la conformité des licences pour réduire les risques juridiques et opérationnels, intercepter les dépendances non conformes **avant** la fusion des modifications.\n\n## Fonctionnement de la stratégie de licence\n\nVous pouvez définir une stratégie d’entreprise qui contrôle les licences que vos dépendances sont autorisées à utiliser.\n\nVous pouvez spécifier des licences à partir d’une liste intégrée ou, si une licence n’est pas répertoriée, en ajoutant manuellement un identificateur de licence SPDX.\n\nVotre stratégie est appliquée par des ensembles de règles qui peuvent être définis au niveau de l’étendue de l’entreprise, de l’organisation et du référentiel. Vous pouvez également ajouter des exceptions de package ou de licence lorsqu’un **Gestionnaire de licences Open Source d’entreprise** approuve les demandes.\n\nL’évaluation des licences utilise des données de dépendance à partir de vos référentiels, y compris les dépendances transitives détectées dans le graphique des dépendances.\n\n## Comment l’application des pull requests fonctionne\n\nLa conformité des licences open source est appliquée via des ensembles de règles de branche. Lorsqu’une pull request modifie des fichiers manifestes de package, GitHub compare les modifications des dépendances entre les branches de base et de la pull request, évalue les licences détectées au regard de la politique et signale les violations.\n\nS’il existe un ensemble de règles en mode **Actif** qui utilise la condition « Nécessite des résultats de conformité des licences avant la fusion », les demandes de tirage qui introduisent des dépendances non conformes sont bloquées jusqu’à ce que les violations soient résolues. Un jeu de règles en mode **Évaluer** avec cette condition exécutera des vérifications de licence et annotera la pull request, sans toutefois bloquer la fusion.\n\nEn outre, une [règle de protection de branche](/fr/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule) qui nécessite la résolution de commentaires avant la fusion effectue le suivi des annotations des vérifications de licence, de sorte que même les alertes générées par les ensembles de règles **Évaluer** seront soumises à la protection.\n\n## Où les résultats s’affichent\n\nSi la licence d’une dépendance ne figure pas dans votre politique, les résultats apparaîtront dans les annotations de la pull request. Les annotations ne génèrent pas automatiquement une demande d’exception, car le développeur peut décider de modifier son code pour éviter la dépendance non conforme. S’ils souhaitent utiliser la dépendance, GitHub invitez le développeur à obtenir plus d’informations, puis envoyez la demande de fermeture aux gestionnaires de licences Open Source Enterprise, qui ont l’autorisation de modifier la stratégie.\n\nPour les gestionnaires de licences open source d’entreprise, les demandes d’exception en attente sont disponibles dans les vues de sécurité d’entreprise et envoyées en tant que notifications par e-mail.\n\n## Modèle d’étendue et de gouvernance\n\nVous pouvez créer une stratégie au niveau de l’étendue d’entreprise pour une base de référence commune, puis des exceptions spécifiques au référentiel de couches si nécessaire.\n\nPour les grandes entreprises, un modèle courant est le suivant :\n\n* Définir une stratégie étendue de manière centralisée\n* Attribuer le rôle Enterprise Open Source License Manager aux réviseurs de stratégie\n* Utiliser une propriété personnalisée de référentiel pour classer les référentiels comme inactifs, évalués ou actifs\n* Utiliser des ensembles de règles qui ciblent les valeurs de propriété personnalisée pour contrôler le mode d’application pour chaque dépôt\n\nLes développeurs disposant d’un accès en écriture peuvent afficher la stratégie et les exceptions effectives d’un référentiel à partir de la page des paramètres de stratégie de licence du référentiel.\n\n## Étapes suivantes\n\nPour bien démarrer, consultez [Configuration des stratégies de licence open source](/fr/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-license-policies).\n\nPour plus d’informations sur les ensembles de règles, consultez [À propos des ensembles de règles](/fr/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."}