La conformité des licences de GitHub est disponible pour tous

GitHub a rendu la conformité des licences open source disponible pour tous le 16 octobre 2026, pour les dépôts GitHub Enterprise Cloud où GitHub Code Security est activé. La fonction vérifie la licence de chaque dépendance qu'une pull request ajoute et peut bloquer le merge quand cette licence enfreint la politique de l'entreprise. C'est important, car la revue des licences se fait en général tard, à la main, une fois le code déjà écrit.

Ce que fait la conformité des licences

Chaque paquet open source est livré avec une licence, c'est-à-dire les conditions juridiques de son utilisation. Certaines licences, comme MIT ou Apache 2.0, exigent peu de l'utilisateur. D'autres ajoutent des conditions que les juristes d'une entreprise peuvent refuser. « Presque tous les logiciels sont soumis à une forme de contrat de licence », ont écrit Jeff Luszcz et Eric Sorenson, chefs de produit chez GitHub, cités par Help Net Security.

Le changelog de GitHub indique que la fonction étend l'action dependency review avec une seule politique de licences pour toute l'entreprise. L'entreprise (enterprise) est le compte de plus haut niveau de GitHub, qui regroupe de nombreuses organisations. Les vérifications se lancent automatiquement sur toute pull request qui ajoute ou modifie une dépendance. Chaque dépendance dont la licence n'est pas autorisée reçoit une annotation, une note attachée à la pull request.

Le développeur a alors trois options, selon le changelog. Il peut retirer ou remplacer le paquet, modifier la politique de licences, ou demander une exception pour ce seul paquet.

Ce qui a changé depuis la préversion de juin

GitHub a ouvert la fonction en préversion publique le 30 juin 2026. La version disponible pour tous ajoute quatre éléments, selon le changelog.

Ajouté à la disponibilité générale	Ce que cela fait
Prise en charge de la résidence des données	Les données de licence alimentent désormais le graphe de dépendances et les exports SBOM pour Enterprise Cloud avec résidence des données
Événements du journal d'audit	Les modifications de la politique de licences sont journalisées, pour que des systèmes externes puissent les suivre
API REST de la politique	De nouveaux endpoints téléchargent, mettent à jour et remplacent la politique de licences de l'entreprise
Endpoint de vérification des paquets	Indique à un outil si des paquets sont conformes, pour que les agents de code puissent éviter ceux qui ne le sont pas

Un SBOM, ou nomenclature logicielle, est la liste de tous les composants d'un logiciel. La dernière ligne compte le plus pour les outils de code IA. Un agent peut désormais demander à GitHub si un paquet est autorisé avant de l'ajouter.

Comment fonctionne l'application des règles

La politique liste les licences autorisées. La documentation de GitHub indique que les admins choisissent dans une liste intégrée ou en ajoutent d'autres par identifiant SPDX, le code court standard d'une licence. La vérification couvre aussi les dépendances transitives, c'est-à-dire les paquets que vos paquets importent à leur tour.

Les rulesets appliquent la politique au niveau de l'entreprise, de l'organisation ou du dépôt. Un ruleset est le moyen qu'utilise GitHub pour fixer des règles sur de nombreux dépôts à la fois. La documentation décrit deux modes :

• Active : un ruleset avec la condition « Requires license compliance results before merging » bloque le merge jusqu'à ce que le problème soit corrigé.
• Evaluate : la même vérification tourne et annote la pull request, mais ne la bloque pas.

Les demandes d'exception sont envoyées à un nouveau rôle d'entreprise prédéfini. Le changelog l'appelle Enterprise Open-Source License Manager. Ces relecteurs reçoivent des notifications par e-mail et approuvent les demandes depuis la console de l'entreprise.

La documentation de GitHub suggère une politique centrale large, plus des exceptions par dépôt. Les équipes peuvent ajouter une propriété de dépôt personnalisée avec les valeurs inactive, evaluate et active. Les rulesets ciblent ensuite ces valeurs pour régler l'application dépôt par dépôt.

Comment GitHub l'utilise en interne

Le propre bureau des programmes open source de GitHub utilise l'outil, a rapporté Help Net Security en juillet. Ce bureau a abandonné ses outils internes environ deux mois avant l'article. Il a fait tourner des dépôts en mode Evaluate pendant environ un mois avant d'activer l'application des règles. La plupart des demandes de licence étaient examinées « en quelques heures », selon l'article. La liste d'autorisation de départ comprenait MIT, Apache 2.0 et BSD-3-Clause.

Le même article signale une soupape de sécurité. Une équipe peut repasser un dépôt du mode Active au mode Evaluate pour un correctif critique, puis le remettre en mode Active.

GitHub renforce la pull request ce mois-ci. L'entreprise a rendu AI Scan pour les pull requests disponible pour tous le 15 octobre. Un jour plus tard, les lockfiles de workflow pour GitHub Actions sont entrés en préversion publique.

Ce que cela signifie pour les développeurs

Si votre entreprise utilise GitHub Enterprise Cloud avec Code Security, vous pouvez activer la fonction dès aujourd'hui. Aucune des sources n'indique de prix séparé. Vérifiez ce que couvre votre contrat Code Security actuel avant de planifier un déploiement.

Commencez en mode Evaluate, comme l'a fait l'équipe de GitHub. Un mois d'annotations montre de quelles licences votre base de code dépend déjà, avant que quoi que ce soit ne bloque un merge. Passez ensuite les dépôts en mode Active, un groupe à la fois, grâce à la propriété personnalisée.

Mettez-vous d'abord d'accord sur la liste d'autorisation. MIT, Apache 2.0 et BSD-3-Clause sont un point de départ courant. Décidez qui détient le rôle de gestionnaire des licences, car les demandes d'exception restent en suspens sans relecteur désigné.

Si vous créez des outils internes ou des agents de code, regardez le nouvel endpoint de vérification des paquets. Un agent qui vérifie un paquet avant de l'installer vous évite plus tard une pull request bloquée.

Aucune des sources n'indique quels écosystèmes de paquets sont couverts. Testez un dépôt de chaque langage utilisé par votre entreprise avant de compter sur une couverture complète.