10.3 Marchés publics, code source ouvert, et licences

Vue d’ensemble et motivation

Presque chaque système logiciel moderne est surtout assemblé à partir de composants que quelqu’un d’autre a écrits. Le logiciel à code source ouvert forme la fondation des systèmes d’exploitation, langages, cadriciels, bases de données, et infrastructure cloud. Il entre dans l’entreprise de deux façons : à travers des marchés publics délibérés, et à travers des instructions import occasionnelles par des développeurs individuels. Ce chapitre parle de faire cette consommation (et, là où cela convient, la contribution) délibérément. Cela signifie une stratégie, la conformité de licence, une compréhension des obligations et du risque de copyleft, et un plan pour la fin de vie inévitable des composants dont vous dépendez.

Pour les grandes équipes, les enjeux sont légaux, opérationnels, et stratégiques tous à la fois. Légalement, les licences de code source ouvert sont des contrats exécutoires avec de vraies obligations. Se tromper sur le copyleft (licence qui peut exiger que les œuvres dérivées soient partagées sous les mêmes termes) peut, dans le pire cas, forcer la divulgation de source propriétaire ou déclencher un litige. Les violations de licence peuvent même bloquer une acquisition ou une offre publique pendant la diligence raisonnable. Opérationnellement, les dépendances non gérées pourrissent : les composants deviennent non maintenus, accumulent des vulnérabilités, et atteignent la fin de vie tout en restant enfouis profondément en production. Stratégiquement, le code source ouvert est plus qu’une entrée d’économie de coût. C’est un moyen d’éviter la dépendance au fournisseur, attirer le talent, et façonner les écosystèmes dont vous dépendez, des avantages que vous ne capturez que si vous vous engagez délibérément.

Le gouvernement a une dimension supplémentaire. De nombreuses juridictions ont maintenant des politiques explicites favorisant le code source ouvert, les normes ouvertes, et le partage de code entre agences. Celles-ci sont souvent exprimées comme « argent public, code public » : le principe selon lequel le logiciel financé par les contribuables devrait, par défaut, être disponible au public. Donc les ingénieurs du secteur public doivent naviguer à la fois la conformité de licence et les mandats actifs de préférer, publier, et réutiliser le code source ouvert. Ce chapitre vise à rendre tout cela gérable à l’échelle.

Principes clés

Le code source ouvert est une chaîne d’approvisionnement, pas des trucs gratuits. Traitez les composants consommés avec la même rigueur que tout fournisseur critique.
Les licences sont des obligations, pas des permissions à ignorer. Chaque dépendance porte des termes ; connaissez-les avant de livrer.
Le copyleft est une contrainte de conception, pas un tabou. Les licences copyleft sont utilisables et précieuses ; elles exigent seulement que vous compreniez comment vous combinez et distribuez le logiciel.
Consommez délibérément, contribuez stratégiquement. Décidez quoi apporter et, là où cela vous sert, investissez dans la remontée en amont plutôt que la bifurcation.
Inventoriez tout. Vous ne pouvez pas vous conformer, sécuriser, ou mettre à jour ce que vous ne pouvez pas voir ; une SBOM (nomenclature logicielle, un inventaire complet des composants dans votre logiciel) est le minimum requis.
Planifiez la fin de vie dès le départ. Chaque dépendance sera un jour non maintenue ; connaissez votre sortie avant d’y être forcé.
Dans le gouvernement, préférez par défaut l’ouvert. Préférez les normes ouvertes et le code source ouvert, et publiez le code d’argent public sauf raison spécifique de ne pas le faire.

Recommandations

Fixer une stratégie de code source ouvert et une politique de consommation

Publiez une politique claire pour comment les développeurs peuvent apporter du code source ouvert dans l’organisation : quelles licences sont préapprouvées, lesquelles exigent une révision, et lesquelles sont prohibées pour vos cas d’usage. Fournissez un chemin d’approbation rapide et à faible friction. Une politique plus lente que copier du code sera simplement ignorée. Distinguez les contextes, parce que la même licence se comporte différemment quand un composant est utilisé en interne comme service, intégré dans un produit distribué, ou lié dans une application propriétaire. Faites du chemin facile le chemin conforme : un dépôt interne sélectionné de composants vérifiés, un scan automatisé dans le pipeline, et des directives claires que les développeurs peuvent suivre sans appeler un avocat pour les cas routiniers.

Gérer la conformité de licence, les obligations, et le risque de copyleft

Apprenez à connaître les familles de licences et leurs obligations. Les licences permissives (comme MIT, BSD, et Apache 2.0) exigent surtout l’attribution et la préservation d’avis ; Apache 2.0 ajoute une concession de brevet explicite. Le copyleft faible (comme LGPL et MPL) exige que vous partagiez les modifications aux fichiers couverts mais vous laisse généralement combiner avec du code propriétaire. Le copyleft fort (comme GPL) peut exiger que toute l’œuvre distribuée soit offerte sous les mêmes termes. Le copyleft réseau (AGPL) étend cette obligation au logiciel offert sur un réseau, pas seulement distribué comme binaires. Les obligations qui comptent le plus dépendent de deux choses : si vous distribuez le logiciel, et à quel point vous combinez étroitement les composants. Automatisez la conformité : scannez les dépendances pour les licences, générez et livrez les fichiers d’attribution et d’avis requis, et conditionnez la construction sur la politique pour qu’une licence prohibée ne puisse pas entrer silencieusement en production.

Établir un bureau de programme de code source ouvert (OSPO)

Si vous consommez du code source ouvert à l’échelle, créez un point focal, un OSPO, qui possède la stratégie de code source ouvert, la politique, l’outillage de conformité, la gouvernance de contribution, et les relations communautaires. L’OSPO freine le chaos de chaque équipe prenant ses propres décisions. Il fournit une expertise que les équipes individuelles ne peuvent pas maintenir. Et il capture la valeur stratégique : décider dans quels projets investir, quand contribuer en amont, et comment bien publier vos propres projets de code source ouvert. Même un petit OSPO (parfois une personne plus un groupe de travail transversal) améliore dramatiquement la cohérence et réduit le risque légal comparé à une anarchie.

Gouverner la contribution et, là où cela convient, la publication

Décidez délibérément quand contribuer en retour. Remonter des correctifs et fonctionnalités en amont vers les projets dont vous dépendez réduit votre fardeau de maintenance, parce que vous cessez de porter des correctifs privés. Cela construit aussi de la bonne volonté et de l’influence, et renforce les composants critiques pour vous. Donnez aux développeurs un processus clair et rapide pour les contributions approuvées, incluant comment la propriété intellectuelle et les accords de contributeur sont gérés. Quand vous publiez vos propres projets de code source ouvert, faites-le proprement : choisissez une licence appropriée, documentez la gouvernance, et engagez-vous à l’intendance. Un projet abandonné nuit à votre réputation plus qu’aucun projet.

Respecter les mandats gouvernementaux de code source ouvert et « argent public, code public »

Les équipes du secteur public devraient traiter l’ouverture comme le défaut. Préférez les normes ouvertes pour éviter la dépendance et travailler à travers agences et fournisseurs. Publiez ouvertement le code source développé avec des fonds publics, sauf si une exemption spécifique et documentée s’applique : pour des composants sensibles à la sécurité, des droits de tiers, ou des préoccupations de vie privée. Réutilisez avant de construire : vérifiez si une autre agence a déjà publié un code adapté. Intégrez ces attentes dans les marchés publics, pour que les fournisseurs livrent du code ouvert, réutilisable, et bien documenté avec le gouvernement gardant les droits appropriés, plutôt que des boîtes noires propriétaires que l’agence ne peut pas maintenir ou partager.

Gérer les dépendances et le logiciel en fin de vie

Maintenez un inventaire vivant (SBOM) de chaque composant et sa version, licence, et statut de maintenance. Gardez les dépendances raisonnablement à jour. Des mises à jour petites et fréquentes sont bien moins chères et plus sûres que des sauts géants et rares. Surveillez les projets en amont pour les annonces de fin de vie et les fenêtres de support de sécurité, et planifiez les migrations avant que le support ne se termine, pas après qu’une vulnérabilité force une ruée. Pour les composants critiques à risque d’abandon, décidez à l’avance si vous financerez le mainteneur, contribuerez la maintenance vous-même, bifurquerez, ou remplacerez. Suivez la fin de vie pour le logiciel commercial et de code source ouvert de la même façon, et tenez l’épuisement du support au même standard que tout autre risque opérationnel.

Compromis : avantages et inconvénients

Choix	Avantages	Inconvénients
Consommer le code source ouvert librement	Livraison rapide ; énorme levier ; pas de frais de licence	Obligations de licence, sécurité, et maintenance que vous possédez maintenant
Liste d’autorisation de licence stricte	Faible risque légal ; prévisible	Ralentit les équipes ; peut exclure des composants véritablement utiles
Licences permissives seulement	Obligations minimales ; facile à combiner	Renonce à de précieux projets copyleft ; moins de réciprocité
Accepter le copyleft là où approprié	Accès à de forts écosystèmes ; bénéfices de réciprocité	Exige du soin dans la combinaison et la distribution
Contribuer en amont	Moins de fardeau de correctif privé ; influence ; bonne volonté	Effort continu ; surcharge de PI et de processus
Construire propriétaire à la place	Contrôle total ; aucune obligation externe	Coût élevé ; réinvente une commodité ; vous le maintenez pour toujours
Publication gouvernementale par défaut	Transparence ; réutilisation ; évite la dépendance	Effort de publication ; revue de sécurité ; intendance soutenue

La tension centrale est entre la vélocité de développeur et le contrôle. Verrouillez tout derrière une lourde révision, et les développeurs contournent la politique. Cela crée des dépendances fantômes non gérées, qui sont pires qu’une approche permissive mais visible. Laissez-le entièrement non contrôlé, et vous accumulez une dette légale et de sécurité invisiblement. La résolution est l’automatisation et la curation : faites du chemin conforme le chemin le plus rapide, à travers des composants prévérifiés, un scan de pipeline, et des défauts clairs, pour obtenir le contrôle sans friction. Sur le copyleft, le compromis n’est pas « risqué contre sûr » mais « compris contre non compris ». Le copyleft est entièrement utilisable une fois que vous savez comment vous combinez et distribuez.

Questions à discuter avec votre équipe

Quelle est votre règle explicite pour le copyleft fort et réseau à travers les contextes interne, distribué, et servi par réseau ? Le copyleft est une contrainte de conception, pas un tabou, et les obligations dépendent de deux choses : si vous distribuez le logiciel et à quel point vous combinez étroitement les composants. GPL dans un outil interne se comporte très différemment de GPL lié dans un produit que vous livrez, et AGPL étend les devoirs de divulgation au logiciel que vous offrez simplement sur un réseau, ce qui change votre calcul construire contre adopter pour tout ce que vous exploitez comme service. Écrivez la règle par contexte, pour qu’un développeur sache sans appeler un avocat que (par exemple) le permissif est préapprouvé partout, le copyleft fort est bien en interne mais bloqué du produit livré, et l’AGPL a besoin de révision avant de toucher un service en réseau. Apportez des preuves : scannez votre arbre de dépendance actuel et trouvez où les composants copyleft se trouvent déjà par rapport à votre frontière de distribution. Puis conditionnez la construction sur cette politique, parce qu’une règle qu’aucun scanner n’applique est une règle que les développeurs casseront accidentellement.
Avez-vous besoin d’un bureau de programme de code source ouvert, et qui possède la politique de licence, le scan, et les décisions de contribution aujourd’hui ? Si la réponse honnête est « personne » ou « chaque équipe décide », vous exploitez une anarchie qui accumule une dette légale et de sécurité invisiblement. Un OSPO, même une personne plus un groupe de travail transversal, freine ce chaos et capture la valeur stratégique : dans quels projets en amont investir, quand contribuer, et comment bien publier vos propres projets. Apportez des preuves à la réunion : quelqu’un peut-il produire la liste de licences approuvées actuelle, la SBOM, et le nom de la personne qui répondrait à une question de copyleft pendant une diligence raisonnable d’acquisition ? La réponse devrait assigner une propriété claire et faire du chemin conforme le chemin le plus rapide, à travers des composants prévérifiés et un scan de pipeline, pour que les développeurs obtiennent le contrôle sans friction. Une politique plus lente que copier du code sera simplement ignorée.
Quelles dépendances feraient le plus mal si abandonnées demain, et quelle est votre réponse prédécidée pour chacune ? Chaque dépendance atteint éventuellement la fin de vie, et la version coûteuse de cet événement est de découvrir qu’un composant central a perdu le support il y a des mois, seulement quand une vulnérabilité force l’attention. Pour vos composants critiques à risque d’abandon, décidez à l’avance si vous financerez le mainteneur, contribuerez la maintenance vous-même, bifurquerez, ou remplacerez. Apportez des preuves : depuis votre SBOM, listez les composants dont l’échec arrêterait un service critique pour le revenu ou la mission, et notez le statut de maintenance et la fenêtre de support de sécurité de chacun. La réponse devrait transformer la fin de vie d’une surprise en un risque opérationnel suivi avec une migration planifiée, tenu au même standard que tout autre risque. Garder les dépendances à jour par petits pas fréquents est bien moins cher que le saut rare, géant, et forcé.
Pouvez-vous produire une SBOM complète et actuelle qui atteint jusqu’au fond de votre arbre de dépendance transitive, et à quelle vitesse ? Quand une vulnérabilité à la une atterrit dans une bibliothèque largement utilisée, la première question que la direction pose est « sommes-nous exposés, et où ? » Une équipe qui ne peut pas répondre en quelques heures est déjà en retard, parce que le vrai risque se cache habituellement plusieurs couches en profondeur dans des dépendances que personne n’a choisies délibérément. La considération concurrente est le coût et le bruit : l’inventaire transitif complet à travers de nombreux services génère une longue liste fluctuante, et sur-alerter forme les gens à l’ignorer, donc vous devez décider quelle profondeur et quelle sévérité déclenchent réellement une action. Apportez des preuves à la discussion : essayez de générer une SBOM fraîche pour un service de production en ce moment, comptez combien de composants sont directs contre transitifs, et chronométrez combien de temps cela a pris. Pour un organisme d’entreprise ou gouvernemental, liez cela à une cible de réponse d’incident concrète et à tout devoir réglementaire de divulguer les composants affectés, parce qu’un mandat de rapporter une exposition que vous ne pouvez pas énumérer est un mandat que vous violerez.
Quand une dépendance critique vaut-elle la peine d’être financée, contribuée, ou dont être l’intendant, plutôt que traitée comme gratuite ? La plupart des organisations consomment le code source ouvert comme si c’était un service public, puis sont choquées quand un composant soutenant un service de revenu s’avère être un bénévole non payé. Décider délibérément de financer un mainteneur, de remonter des correctifs en amont, ou de publier et gérer votre propre projet convertit une entrée gratuite fragile en une entrée durable et influencée, et cela empêche vos ingénieurs de porter des correctifs privés à travers chaque mise à niveau. La tension est que la contribution et l’intendance coûtent du vrai temps d’ingénierie continu et portent une surcharge de propriété intellectuelle et de processus, donc vous ne pouvez pas le faire pour tout. Apportez des preuves : depuis votre SBOM, marquez la poignée de composants dont l’échec arrêterait un service critique pour la mission, et notez le nombre de mainteneurs, le financement, et combien de correctifs privés vous portez déjà contre chacun. Pour une grande organisation ou publique, pesez le coût réputationnel d’une publication de code source ouvert abandonnée que vous avez publiée en fanfare, et, dans le gouvernement, traitez l’intendance soutenue du code d’argent public publié comme partie de la livraison, pas un extra optionnel.
Vos marchés publics livrent-ils réellement du code ouvert, réutilisable, et bien documenté avec les droits dont vous avez besoin, ou des boîtes noires propriétaires que vous ne pouvez ni maintenir ni quitter ? Les contrats écrits sans expertise de code source ouvert donnent routinièrement à un fournisseur un contrôle que vous regretterez : formats fermés, aucun droit de publier ou modifier, et des dépendances que l’agence ne peut pas corriger quand le fournisseur passe à autre chose. Bien faire cela tôt est bien moins cher que de découvrir au renouvellement que vous ne pouvez pas partir. Les considérations concurrentes sont la vitesse et le choix de fournisseur : exiger des livrables ouverts et la portabilité peut restreindre le champ et ralentir une attribution, et certains fournisseurs véritablement utiles résistent à cela. Apportez des preuves : sortez deux contrats récents et vérifiez s’ils spécifient les termes de licence, la livraison de code source, les normes de documentation, la fourniture de SBOM, et les droits que l’organisation retient. Pour les marchés publics d’entreprise, connectez cela à l’analyse de dépendance et de coût total ; pour le gouvernement, connectez-le aux mandats ouvert-par-défaut et « argent public, code public », et au processus d’exemption documenté qui vous permet de fermer seulement les parties sensibles à la sécurité plutôt que tout le système.

Regard sectoriel

Jeune pousse. Vous assemblez presque tout depuis le code source ouvert et n’avez pas d’avocat, donc gardez la règle sur une page : les licences permissives comme MIT et Apache 2.0 sont préapprouvées, le copyleft fort est bien pour l’outillage interne mais bloqué du produit livré, et tout ce qui est étrange obtient une revue rapide de fondateur. Ajoutez un scan de licence et de vulnérabilité au pipeline et gardez une SBOM dès le premier jour, parce que le moment le moins cher pour bien faire cela est avant que la diligence raisonnable d’un acquéreur ne peigne votre arbre de dépendance. Ne bannissez pas le copyleft par peur ; comprenez-le, et passez à autre chose.

Petite entreprise. Sans spécialiste de code source ouvert et avec un budget serré, appuyez-vous sur l’outillage plutôt que l’effectif : un scanner dans la construction et une courte liste de licences approuvées font la plupart du travail qu’une personne ferait. Cadrez la consommation comme acheter contre construire honnêtement, puisque réinventer un composant ouvert bien maintenu est habituellement le choix coûteux, mais dépendre d’un que vous n’inventoriez jamais l’est aussi. Gardez un enregistrement simple de ce que vous utilisez et sous quelle licence, pour qu’un questionnaire de sécurité client ou une alerte de vulnérabilité ne devienne pas une ruée.

Grande entreprise. À l’échelle, le problème est la cohérence à travers de nombreuses équipes, donc érigez un OSPO pour posséder la politique, le scan automatisé, la génération d’attribution, et la gouvernance de contribution, et faites du chemin conforme le chemin le plus rapide à travers des composants sélectionnés et prévérifiés. Appliquez les règles de copyleft par contexte dans le pipeline, maintenez des SBOM à travers les services, et gérez la fraîcheur de dépendance et la fin de vie comme un risque opérationnel suivi. Traitez le code source ouvert comme de la gestion de chaîne d’approvisionnement pour la majorité de votre base de code, avec des preuves prêtes pour l’audit pour la diligence raisonnable d’acquisition.

Gouvernement. L’ouverture est souvent mandatée, pas optionnelle, donc préférez par défaut les normes ouvertes et publiez le code d’argent public sauf si une exemption documentée s’applique pour la sécurité, les droits de tiers, ou la vie privée. Réutilisez avant de construire en vérifiant un catalogue inter-gouvernemental, et intégrez des livrables ouverts, réutilisables, bien documentés et des droits retenus dans les marchés publics pour que vous receviez du code maintenable plutôt que des boîtes noires propriétaires. Tenez le code publié à une vraie intendance, et gardez le processus d’exemption étroit et transparent pour qu’il ferme seulement ce qu’il doit.

Exemples

Jeune pousse. Une jeune pousse de quatre personnes construisant une application mobile assemble presque tout depuis le code source ouvert et n’a pas d’avocat en personnel. Au lieu de bannir le copyleft par peur, les fondateurs écrivent une politique d’une page : les licences permissives comme MIT et Apache 2.0 sont préapprouvées, le copyleft fort comme GPL est bien pour l’outillage interne mais bloqué de l’application livrée pour éviter les devoirs de divulgation, et tout ce qui est inhabituel obtient une revue rapide de fondateur. Ils ajoutent un scan de licence et de vulnérabilité au pipeline pour qu’une licence prohibée ne puisse pas se glisser dans une publication, gardent une SBOM dès le premier jour, et remontent un petit correctif à une bibliothèque critique en amont pour cesser de porter un correctif privé à travers chaque mise à niveau. Bien faire cela tôt leur épargne aussi une surprise douloureuse quand la diligence raisonnable d’un acquéreur peigne éventuellement l’arbre de dépendance.

Grande entreprise. Un fournisseur de logiciel qui livre un produit distribué exploite un OSPO. L’OSPO maintient une liste de licences approuvées, un dépôt de composants sélectionné interne, et un scan automatisé de licence et vulnérabilité dans chaque pipeline. Quand un développeur intègre une nouvelle dépendance, le pipeline vérifie sa licence contre la politique, génère les avis d’attribution qui accompagnent le produit, et signale tout ce qui exige une révision. Les composants à copyleft fort sont autorisés pour l’outillage interne mais bloqués du produit distribué, pour éviter les obligations de divulgation. L’entreprise remonte des correctifs vers quelques dépendances critiques en amont. Cela a éliminé un arriéré de correctifs privés que ses ingénieurs portaient auparavant à travers chaque mise à niveau.

Gouvernement. Un service numérique national opère sous une politique « argent public, code public ». Les nouveaux services sont construits sur des normes ouvertes, développés ouvertement sur un dépôt de code public par défaut, et réutilisés à travers les agences. Ses modèles de marchés publics exigent que les fournisseurs livrent du code ouvert, bien documenté, et réutilisable, avec le gouvernement gardant les droits de publier et modifier. Avant de commencer un nouveau composant, les équipes cherchent dans un catalogue inter-gouvernemental du code réutilisable existant. Les modules sensibles à la sécurité sont exemptés de publication à travers un processus documenté, plutôt qu’en rendant tout le système fermé.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

Bien gérer le code source ouvert est la différence entre capturer son énorme levier et payer ses coûts cachés. Le code source ouvert permet à une grande organisation de se tenir sur une fondation qu’elle ne pourrait jamais se permettre de construire. Mais le coût total de possession inclut la conformité, le correctif de sécurité, et la migration éventuelle, des coûts qui arrivent que vous les planifiiez ou non. Une gestion délibérée convertit des crises imprévisibles et coûteuses en petits coûts stables et planifiés. Ces crises incluent une violation de copyleft trouvée pendant la diligence raisonnable d’acquisition, une migration d’urgence hors d’un composant abandonné, ou une vulnérabilité dans une dépendance dont personne ne savait l’existence.

Le coût d’adoption est modeste en regard de l’exposition : un OSPO ou groupe de travail, un outillage de scan, et la discipline de garder un inventaire. Le coût de ne pas adopter apparaît comme une responsabilité légale, une diligence raisonnable échouée, des incidents de sécurité tracés à des dépendances non corrigées, et la dépense composée des mises à niveau différées qui forcent éventuellement des migrations douloureuses de type big bang. Quand vous faites valoir le dossier auprès de la direction, cadrez la gestion de code source ouvert comme de la gestion de chaîne d’approvisionnement pour la majorité de votre base de code. Notez aussi l’avantage stratégique : dépendance évitée, livraison plus rapide, attraction de talent, et influence sur les écosystèmes dont vous dépendez. Dans le gouvernement, ajoutez la dimension de mandat. L’ouverture est souvent requise, pas optionnelle, et bien la faire évite à la fois la non-conformité et la dépense publique dupliquée.

Anti-patterns et pièges

La licence copier-coller. Des développeurs intégrant des composants sans vérification de licence, découvrant les obligations seulement à l’audit ou à l’acquisition.
Aucun inventaire. Être incapable de répondre « qu’utilisons-nous et sous quelle licence ? » quand une vulnérabilité ou question de licence éclate.
La panique de copyleft. Bannir tout copyleft par peur plutôt que compréhension, renonçant à de précieux écosystèmes.
La publication de code source ouvert abandonnée. Publier un projet en fanfare puis ne jamais le maintenir, nuisant à la réputation.
Ignorer les dépendances transitives. Vérifier les dépendances directes tandis que le vrai risque se cache plusieurs couches en profondeur.
La surprise de fin de vie. Découvrir qu’un composant central a perdu le support il y a des mois, seulement quand une vulnérabilité force l’attention.
Une politique plus lente que copier. Un processus de conformité si lourd que les développeurs le contournent, créant des dépendances fantômes invisibles.
Les boîtes noires gouvernementales. Acquérir des systèmes propriétaires que l’agence ne peut ni maintenir, ni partager, ni quitter, en violation des principes ouvert-par-défaut.

Modèle de maturité

Niveau 1 : Initier. Les développeurs ajoutent du code source ouvert librement sans politique ou inventaire. Les licences ne sont pas examinées et les obligations de copyleft sont inconnues. La fin de vie est découverte par accident, habituellement quand une vulnérabilité force l’attention. Personne ne possède la stratégie de code source ouvert.

Niveau 2 : Développer. Une politique de base et une liste de licences approuvées existent, et certaines équipes les suivent. Le scan se produit, mais souvent manuellement, tardivement, ou seulement sur quelques projets. Un inventaire est gardé pour les systèmes majeurs tandis que les dépendances transitives restent non cartographiées. La gestion de contribution et de fin de vie est ad hoc et incohérente entre équipes.

Niveau 3 : Standardiser. Un OSPO ou équivalent possède la stratégie, la politique, et l’outillage à l’échelle de l’organisation. Le scan de licence et vulnérabilité est automatisé dans chaque pipeline, les fichiers d’attribution et d’avis sont générés automatiquement, et la construction est conditionnée pour qu’une licence prohibée ne puisse pas entrer. Les SBOM sont maintenues jusqu’au fond de l’arbre transitif, la contribution suit un processus documenté, la fin de vie est suivie avec des migrations planifiées, et les équipes gouvernementales publient par défaut.

Niveau 4 : Gérer. Le programme est mesuré et contrôlé contre des référentiels. Vous suivez la couverture de scan de politique à travers les services, le temps moyen pour corriger une vulnérabilité de dépendance divulguée, la part de composants à l’intérieur de leur fenêtre de support de sécurité, le taux d’échappement de violation de licence, le retard de fraîcheur de dépendance, et le compte de correctifs privés portés en amont. Le placement de copyleft par rapport à la frontière de distribution est surveillé, et les métriques contre des cibles pilotent chaque décision de lancement ou d’arrêt plutôt que l’opinion.

Niveau 5 : Orchestrer. Le code source ouvert est un actif stratégique continuellement amélioré et intégré à travers l’organisation. La conformité est entièrement automatisée et les composants non conformes ne peuvent pas atteindre la production. Vous investissez délibérément dans les projets en amont critiques, contribuez routinièrement, et gérez vos propres projets bien exploités. La fraîcheur de dépendance et la fin de vie sont gérées adaptativement à mesure que le risque et les métriques changent, et l’ouverture devient un véritable avantage concurrentiel et civique.

Pistes de réflexion

Où est la bonne ligne entre un défaut permissif rapide et le contrôle nécessaire pour éviter la dette légale et de sécurité ?
Quand une organisation devrait-elle financer ou maintenir une dépendance en amont critique plutôt que la traiter comme gratuite ?
Comment décidez-vous lesquels de vos propres composants valent la peine d’être publiés et gérés comme code source ouvert ?
Pour le gouvernement, quel est un processus défendable pour exempter des composants de la publication par défaut sans éroder le principe ?
À quelle profondeur dans les dépendances transitives la revue de licence et de sécurité doit-elle réalistement aller ?
Le copyleft réseau (AGPL) change-t-il votre calcul construire contre adopter pour le logiciel que vous offrez comme service ?

Points clés à retenir

Le code source ouvert est la majorité de la plupart des bases de code et doit être géré comme une chaîne d’approvisionnement, pas traité comme gratuit et sans conséquence.
Les licences portent de vraies obligations ; comprenez les familles permissive, copyleft faible, copyleft fort, et copyleft réseau et comment la distribution et la combinaison déclenchent des devoirs.
Faites du chemin conforme le chemin le plus rapide à travers la curation, le scan automatisé, et des défauts clairs, sinon les développeurs contourneront la politique.
Érigez un OSPO pour posséder la stratégie, la conformité, la contribution, et l’intendance à l’échelle.
Maintenez une SBOM, gardez les dépendances à jour par petits pas, et planifiez la fin de vie avant qu’elle ne force une crise.
Dans le gouvernement, préférez par défaut les normes ouvertes et publiez le code d’argent public, en réutilisant avant de construire.

Références et lectures complémentaires

Heather Meeker, Open (Source) for Business et Open Source for Business
Van Lindberg, Intellectual Property and Open Source
The Linux Foundation et TODO Group, OSPO guides et Open Source Program Office resources
OpenChain (ISO/IEC 5230), Open Source License Compliance
Spécification Software Package Data Exchange (SPDX, ISO/IEC 5962)
Spécification CycloneDX SBOM
Free Software Foundation, GNU General Public License et GPL FAQ
Open Source Initiative, The Open Source Definition et liste de licences approuvées
Free Software Foundation Europe, Public Money, Public Code
U.S. Federal Source Code Policy et orientation Code.gov
UK Government, Technology Code of Practice et principes de normes ouvertes