# Comment évaluer un logiciel de sécurité à code accessible

Pouvoir lire un dépôt ne donne pas à votre équipe les droits ni l'indépendance opérationnelle qu'offre l'open source. Avant d'adopter un logiciel de sécurité à code accessible, traitez sa licence, son processus de publication et sa frontière commerciale comme des éléments de l'architecture de sécurité. Une restriction qui paraît anodine pendant une preuve de concept peut ensuite vous empêcher de déployer un correctif urgent, de servir un client ou de poursuivre l'exploitation si l'éditeur change de direction.

J'ai vu des équipes consacrer des semaines à la conception cryptographique et une demi-heure à la licence du code qui conserve leurs secrets. Cet ordre est mauvais. Votre examen doit répondre à une question concrète : si l'éditeur, le dépôt et la relation commerciale changent tous en même temps, que votre organisation peut-elle légalement et techniquement continuer à faire ?

Il s'agit d'un examen d'ingénierie mené avec un avis juridique, pas d'une invitation faite aux ingénieurs de pratiquer le droit. Les ingénieurs doivent décrire comment le logiciel fonctionne réellement, qui y touche et ce qu'exige la reprise après une panne. Les juristes peuvent alors évaluer un déploiement réel plutôt qu'une affirmation vague selon laquelle le code est visible.

## Comment la licence classe-t-elle le logiciel ?

Commencez par nommer correctement la catégorie de licence, car « code accessible » et « open source » accordent des droits différents. La publication du code est un fait de distribution. L'open source est une qualification juridique qui comprend le droit d'utiliser, de modifier et de redistribuer le logiciel sans discrimination envers des personnes, des groupes ou des domaines d'activité.

L'Open Source Definition de l'Open Source Initiative rend cette distinction exploitable. Ses critères exigent l'accès au code, mais aussi les œuvres dérivées, la libre redistribution et l'absence de restriction visant un domaine d'activité. Une licence qui interdit l'usage en production, les services concurrents ou une catégorie d'entreprise peut publier chaque ligne du programme. Elle ne répond toujours pas à cette définition.

N'employez pas « open source » comme un synonyme commode de « nous pouvons lire le dépôt ». Consignez le nom exact, la version et l'identifiant de la licence. Indiquez ensuite si l'Open Source Initiative l'a approuvée. La SPDX License List aide à identifier les textes de licence de façon cohérente, mais la présence dans cette liste ne vaut pas approbation. La liste possède un champ distinct pour l'approbation OSI et inclut des licences telles que BUSL-1.1 et Elastic-2.0 sans les marquer comme approuvées par l'OSI.

Cette distinction a des effets qui dépassent le vocabulaire. Votre analyseur de dépendances peut autoriser automatiquement Apache-2.0 tout en envoyant une licence personnalisée à code accessible en examen manuel. Votre politique d'achat peut n'autoriser les modifications que si les droits de redistribution sont clairs. Une personne chargée d'un incident peut supposer que l'équipe a le droit de corriger et de déployer un dépôt visible, alors que la licence interdit cet usage en production.

Inscrivez le résultat dans une phrase que personne ne pourra atténuer par la suite : « Le code est disponible sous [licence exacte], qui [est/n'est pas] approuvée par l'OSI, et notre usage prévu dépend de [autorisation ou restriction précise]. » Si l'équipe ne peut pas remplir cette phrase, elle n'a pas terminé le premier examen.

## Que permet la licence dans notre déploiement réel ?

Lisez le texte opposable de la licence avec un schéma de déploiement, pas avec la page de résumé de l'éditeur. Des termes comme « production », « service géré », « offre concurrente », « usage professionnel interne » et « utilisateur autorisé » ne prennent sens qu'une fois reliés à des processus, des comptes, des clients et des flux de données.

Tracez la frontière autour de chaque personne morale et de chaque personne qui utilisera la fonction du logiciel ou en recevra le résultat. Une société mère, une filiale, un prestataire, un fournisseur de services gérés et un client peuvent occuper des positions différentes au regard de la même clause. Si un agent effectue un appel API pour un client, demandez si ce client reçoit le produit à code accessible sous forme de service ou seulement le résultat de votre propre produit. Ne tranchez pas avec un message envoyé par un commercial.

La Business Source License 1.1 montre pourquoi les paramètres renseignés comptent. Son texte standard accorde les droits de copier, modifier, créer des œuvres dérivées, redistribuer et utiliser hors production. Le concédant peut ajouter une autorisation limitée d'usage en production, et chaque version passe ensuite sous une licence open source donnée à une Change Date précisée ou à l'échéance maximale prévue par la licence. L'autorisation pratique figure donc en partie dans l'en-tête de licence propre au produit et à la version. Lire une présentation générale de BSL sans consulter Additional Use Grant et Change License laisse les conditions importantes sans réponse.

Elastic License 2.0 suit une autre logique. La FAQ d'Elastic indique que la licence permet l'usage, la modification, les œuvres dérivées et la redistribution, mais interdit de proposer les produits comme service géré, de contourner les fonctions liées aux clés de licence et de supprimer les mentions. Cela ne dit pas si votre architecture hébergée précise est autorisée. Cela vous indique quelle frontière doit recevoir une réponse écrite.

Testez au moins ces situations concrètes par écrit : évaluation interne, production pour votre personnel, production au service d'un client payant, accès d'un prestataire, redistribution dans un appareil, reprise après sinistre par une autre entité et fork comportant des changements locaux. Pour chacune, notez autorisé, interdit ou non résolu, puis la clause qui fonde la réponse. « Gratuit pour la plupart des usages » n'est pas une conclusion.

Un libellé ambigu est un risque de déploiement. Demandez à l'éditeur une interprétation écrite liée à votre schéma, puis laissez les juristes décider si elle suffit. Si l'éditeur accorde une exception, inscrivez-la dans un accord signé et précisez les versions couvertes. Une réponse sur un forum peut disparaître, pas vos obligations.

Séparez les autorisations liées au droit d'auteur du reste de l'accord. Une licence de dépôt peut permettre un usage alors qu'un contrat d'abonnement, des conditions de service, une politique de marque, une clause de brevet, une condition d'exportation ou un contrat de support impose d'autres règles. Rassemblez tous les documents intégrés par référence et déterminez lequel prévaut en cas de conflit. L'accord accepté en ligne par le titulaire du compte doit être examiné avec le fichier LICENSE.

Les clauses de brevet méritent de l'attention dans une infrastructure de sécurité, car l'implémentation touche souvent à l'authentification, au chiffrement, au réseau et à la gestion des appareils. Demandez si la licence accorde une autorisation expresse sur les brevets, si cette autorisation prend fin en cas de revendication et si les contributeurs ont qualité pour l'accorder. La visibilité du code ne confère aucun droit de brevet. Les juristes doivent examiner ce point lorsque le produit s'insère dans une offre distribuée ou que votre fork prévu change son fonctionnement.

Examinez les dépendances séparément de la licence du dépôt principal. Une licence permissive au niveau supérieur ne corrige pas une bibliothèque incompatible, un modèle ou un ensemble de règles non redistribuable, une police assortie de limites d'empaquetage ou un auxiliaire binaire indispensable en production. Produisez l'inventaire des licences à partir de la version que vous livrerez, puis examinez les entrées marquées unknown, custom ou NOASSERTION. La mention « facultatif » ne sert à rien si votre déploiement exige le composant.

Ne placez pas les promesses contractuelles dans la colonne réservée à la licence. Les objectifs de réponse du support, les obligations de notification de sécurité, les dates de livraison du code et les protections tarifaires peuvent rendre l'adoption acceptable, mais ils lient généralement des parties précises pendant une durée donnée. Les droits de licence peuvent suivre chaque copie plus longtemps. Votre dossier doit indiquer le document qui apporte chaque protection et ce qui se produit à l'expiration du contrat.

Cette séparation révèle une mauvaise recommandation fréquente : accepter la licence maintenant parce que les achats négocieront une exception plus tard. Elle est populaire parce qu'elle accélère la preuve de concept. Elle devient fausse dès que des données réelles, des clients ou des automatisations dépendent du logiciel, car l'éditeur connaît alors le coût du changement. Réglez les droits nécessaires avant que l'intégration technique crée cette pression.

## Pouvons-nous inspecter, compiler, corriger et livrer la même chose ?

La visibilité du code facilite l'inspection, mais assumer la sécurité exige une chaîne plus longue de droits et de capacités. Votre équipe doit savoir si elle peut obtenir le code complet, reproduire l'artefact concerné, le modifier, le tester, déployer la version modifiée et la distribuer partout où la reprise l'exige.

Les éditeurs publient souvent un noyau utile tout en omettant l'infrastructure de compilation, les étapes de signature, les fichiers générés, les modules payants ou l'empaquetage des versions officielles. Ce dépôt peut encore aider un chercheur à comprendre un analyseur ou à vérifier un appel cryptographique. Il ne peut pas soutenir un fork d'urgence si le binaire distribué dépend d'éléments indisponibles.

Lancez une compilation propre sur une machine dépourvue de cache privé de développeur. Épinglez le commit ou le tag, conservez les commandes et comparez le paquet produit à la version de l'éditeur. Une reproduction exacte octet par octet est excellente lorsque le projet la permet, mais une différence documentée et explicable peut convenir. Un binaire inexpliqué contenant des fichiers absents du code correspondant est inacceptable pour un composant auquel sont confiés des identifiants ou des preuves d'audit.

Conservez un petit dossier de preuve plutôt qu'une capture d'écran d'une compilation réussie :

```text
release: 4.2.1
source_ref: refs/tags/v4.2.1
source_commit: 8f2c...91a
build_command: ./scripts/build-release
artifact: dist/tool-4.2.1.pkg
artifact_sha256: 1c71...0be
vendor_sha256: 93a4...82d
comparison: differs
explained_differences: signing envelope, build timestamp
unexplained_files: none
patch_deploy_allowed_by: License section 2, counsel ticket LEG-184
```

Ce dossier impose deux conclusions distinctes. « Nous avons réussi à le compiler » est une conclusion technique. « Nous pouvons exécuter et redistribuer notre compilation » est une conclusion juridique. Les équipes les confondent souvent et découvrent la moitié manquante pendant un incident.

Vérifiez aussi le parcours des mises à jour de sécurité. Pouvez-vous appliquer une correction d'une ligne à la dernière version que votre organisation a le droit d'exécuter ? Pouvez-vous signer ou autoriser autrement l'artefact corrigé dans votre parc ? Les extensions, agents ou serveurs rejetteront-ils une compilation étrangère à l'éditeur ? Si le logiciel protège des secrets, un fork incapable de recevoir des identifiants des systèmes environnants n'est pas une sortie.

Enfin, examinez les conditions de contribution. Un Contributor License Agreement peut permettre à l'éditeur de changer la licence des contributions alors que les contributeurs externes ne peuvent pas utiliser le futur code commercial. Ce dispositif peut être légitime, mais il change l'identité de ceux qui pourront poursuivre le projet après une scission. Notez si les contributions reposent sur un Developer Certificate of Origin, une cession de droits, un CLA large ou aucune procédure déclarée.

## Les versions correspondent-elles au dépôt public ?

Un examen de sécurité s'applique à un artefact précis, pas à un dépôt abstrait. Exigez une correspondance fiable entre la version installée, le commit source, le texte de licence, l'ensemble des dépendances et les avis de sécurité associés à cette version.

Commencez par l'historique des versions. Cherchez des tags signés ou un autre mécanisme authentifié, des journaux qui identifient les changements de sécurité, des branches de version maintenues et un délai constant entre la publication du binaire et celle du code. Un retard ponctuel peut être une erreur. Un écart récurrent signifie que le dépôt public n'est pas la véritable source de production.

Demandez au mainteneur d'indiquer le calendrier et la durée de support dans une documentation durable. « Mises à jour fréquentes » ne dit rien. Vous devez savoir quelles branches reçoivent des correctifs, combien de temps les anciennes versions restent prises en charge, si les corrections apparaissent dans le code avant ou après les binaires clients et si un embargo peut exposer ceux qui compilent eux-mêmes. Ne déduisez pas une promesse de service à partir de l'activité passée.

Comparez trois versions récentes au lieu d'examiner uniquement le dernier tag. Pour chacune, répondez à quatre questions :

1. Le tag pointe-t-il vers le code utilisé pour produire l'artefact livré ?
2. Les instructions de compilation et les verrous de dépendances sont-ils présents à ce tag ?
3. La licence ou la frontière des fonctions commerciales a-t-elle changé ?
4. Un environnement neuf peut-il produire un paquet exécutable ?

Conservez les résultats dans votre dossier de décision d'ingénierie. Refaites la comparaison lors du renouvellement et avant une mise à niveau majeure. L'accès au code peut régresser discrètement lorsqu'un éditeur déplace l'empaquetage vers un système privé ou transfère une fonction dans un dépôt commercial.

Une nomenclature logicielle aide, mais ne l'acceptez pas comme preuve de parité avec le code. Un SBOM décrit les composants présents dans un artefact. Il ne prouve pas que le dépôt public contient le code, la logique de compilation ou les droits nécessaires pour recréer cet artefact. Utilisez les deux : le SBOM pour les dépendances et les vulnérabilités, la correspondance entre code et artefact pour l'indépendance.

Le rythme des versions indique aussi la charge de maintenance que votre équipe peut hériter. Un projet qui publie des fonctions chaque mois et ne corrige que sa branche la plus récente peut imposer des mises à niveau rapides. Un projet plus lent doté d'une politique documentée de rétroportage peut être plus facile à exploiter. Comptez le travail imposé à votre équipe, pas le nombre de versions annoncé par l'éditeur.

## Où se trouve la frontière commerciale actuelle et future ?

Les fonctions commerciales prévues comptent lorsqu'elles se trouvent sur votre chemin de sécurité, même si elles n'existent pas encore. Demandez à l'éditeur de répartir le produit entre code ouvert ou accessible actuel, code payant actuel et code payant prévu, puis reliez chaque partie à vos contrôles requis.

Évitez la question vague « Le noyau restera-t-il gratuit ? » La réponse peut être oui alors que les fonctions dont vous avez besoin pour un usage sûr en équipe partent ailleurs. Interrogez l'éditeur sur l'intégration des identités, la révocation centralisée, l'administration des politiques, l'export d'audit, la conservation, la haute disponibilité, la gestion du parc, l'assistance en cas d'incident et les outils de migration. L'ensemble dépend du produit, mais la méthode reste la même : reliez chaque exigence opérationnelle à un composant livré et à sa licence.

Les feuilles de route ne sont pas des contrats, et l'absence d'un élément n'est pas une promesse. Notez les fonctions prévues comme des signaux de planification avec un responsable, une fenêtre de livraison, une licence envisagée et une solution de repli. Si votre adoption dépend d'un futur contrôle Enterprise, chiffrez et approuvez la voie commerciale dès maintenant ou considérez le contrôle indisponible. Une équipe ne doit pas déployer une conception plus faible parce qu'une présentation annonce la protection manquante.

Repérez aussi les contrôles de clé de licence ou les droits à distance dans le code visible. Déterminez ce qui arrive lorsque le service de licence est inaccessible, que l'abonnement prend fin, que l'éditeur ferme ou que votre organisation exécute un fork corrigé. Le comportement voulu peut consister à conserver un accès en lecture, exporter et arrêter proprement, plutôt qu'à garder indéfiniment les fonctions payantes. Testez votre exigence, quelle qu'elle soit.

Demandez également qui contrôle le protocole et le format de données. Une console commerciale se remplace si les agents peuvent utiliser un protocole documenté et exporter des dossiers complets dans un format stable. Elle se remplace bien plus difficilement lorsque le noyau visible conserve un état opaque ou que le service payant émet les identifiants nécessaires au démarrage. Du code public autour d'un plan de contrôle privé peut offrir très peu d'indépendance opérationnelle.

Sallyport fournit une comparaison nette, car son application macOS actuelle est entièrement open source sous Apache-2.0, tandis que des composants commerciaux Enterprise sont prévus. Cette phrase ne dit ni ce que comprendront les futures fonctions d'équipe ni leur prix. Une équipe doit donc évaluer l'application livrée sous sa licence actuelle et considérer les composants prévus comme inconnus jusqu'à la publication de leurs frontières.

## Le projet peut-il changer les conditions après l'adoption ?

Un concédant peut généralement publier de futures versions sous d'autres conditions s'il contrôle les droits concernés. Il ne peut normalement pas effacer la licence déjà accordée sur une version que vous possédez, mais rester sur cette version peut vous priver de correctifs, de compatibilité ou de nouveaux protocoles.

Dans ces conditions, « ils ne peuvent pas reprendre le code » est peu rassurant. Votre choix réel peut consister à accepter de nouvelles conditions, rester bloqué sur une branche vulnérable ou financer un fork. Évaluez ces coûts avant l'adoption, quand renoncer au logiciel reste peu coûteux.

Examinez la gouvernance du dépôt et la concentration des droits. Qui peut fusionner ? Qui publie une version ? Des mainteneurs externes peuvent-ils distribuer une version compatible ? Une entreprise détient-elle presque tous les droits par les contrats de travail et les accords de contribution ? Un projet piloté par une entreprise peut être bien entretenu, mais un contrôle concentré facilite un changement de licence et complique la poursuite par la communauté.

Examinez l'historique du projet pour repérer les changements de licence, les modules déplacés, les tags supprimés, les retards de publication du code et les fonctions transférées entre dépôts. Ne traitez pas automatiquement chaque changement comme un abus. Demandez si la tendance correspond à votre tolérance et si les anciens utilisateurs ont reçu un préavis, une période de transition et une dernière version exploitable.

Mettez ensuite sous surveillance les éléments susceptibles de changer :

- Calculez le hash et conservez chaque texte de licence accepté et chaque fichier de paramètres propre au produit.
- Déclenchez une alerte lorsque les métadonnées indiquent une nouvelle expression de licence.
- Examinez les notes de version pour les changements de dépôt ou de droits.
- Faites réapprouver les versions majeures avant leur déploiement en production.
- Conservez le dernier code approuvé et ses instructions de compilation dans un stockage contrôlé par votre organisation.

Ces contrôles transforment une promesse de licence en élément observable par l'ingénierie. Ils empêchent aussi une mise à jour ordinaire de dépendances d'importer de nouvelles obligations sans examen.

Ne comptez pas sur la promesse publique de l'éditeur que la licence ne changera jamais, sauf si votre décision de risque accepte explicitement le caractère non contraignant de cette promesse. Si des droits stables sont indispensables, préférez une licence standard approuvée par l'OSI pour le code requis ou négociez des conditions qui survivent à la relation commerciale. Les bonnes intentions ne remplacent pas une autorisation durable.

## Existe-t-il une sortie crédible ?

Une sortie crédible permet de maintenir la fonction de sécurité assez longtemps pour migrer sans enfreindre la licence ni dépendre d'un service susceptible de disparaître. Un dépôt public n'est qu'un ingrédient.

Testez la sortie comme un exercice d'incident. Supposez que l'éditeur cesse de publier, désactive son service de licence et ne réponde plus au support le même jour. Votre équipe doit identifier la dernière version autorisée, restaurer le code et les dépendances, produire un artefact, charger la configuration existante, récupérer ou migrer les données protégées et l'exploiter avec son propre processus de signature et de déploiement.

Incluez les secrets et les journaux d'audit dans l'exercice. Pouvez-vous les exporter dans un format documenté ? L'export exige-t-il un service payant ou un droit encore valide ? Une compilation locale peut-elle déchiffrer l'état existant à l'aide de clés contrôlées par votre organisation ? Pouvez-vous vérifier d'anciens journaux sans l'éditeur ? Une conception qui protège les données contre l'éditeur peut tout de même les enfermer dans un format propriétaire.

Un fork exige aussi des personnes. Nommez l'équipe qui reprendrait le code, estimez les connaissances requises sur les langages et plateformes, et identifiez les dépendances qui ne pourraient pas être redistribuées. Si personne ne peut accepter ce travail, écrivez « migration uniquement » au lieu de prétendre que le dépôt constitue un recours.

Les marques méritent une ligne séparée dans le plan. Les licences logicielles accordent souvent des droits sur le code sans accorder de droits sur la marque. Votre fork peut nécessiter un autre nom, un identifiant de paquet, une identité de signature, un canal de mise à jour et une documentation propres. C'est gérable lorsque c'est planifié, et perturbant lorsque vous le découvrez en pleine publication urgente.

Un passage différé à l'open source peut améliorer la situation à long terme, mais examinez-le version par version. Sous BSL 1.1, chaque version possède sa propre Change Date et la licence s'applique séparément à chacune. L'ancienne version qui a basculé peut ne pas contenir les correctifs présents dans une version restreinte plus récente. « Open source plus tard » ne signifie pas que la version maintenue est ouverte quand vous en avez besoin.

Fixez un objectif de sortie vérifiable, par exemple : « En dix jours ouvrés, nous pouvons recompiler la dernière version approuvée, déployer un correctif local, exporter toutes les données de l'organisation et commencer la migration sans infrastructure de l'éditeur. » Choisissez une durée cohérente avec votre risque, puis faites l'exercice. S'il échoue, financez la capacité manquante ou inscrivez la dépendance à l'éditeur comme risque accepté.

## Qui assume la réponse de sécurité lorsque le code est visible ?

La visibilité du code n'attribue pas les responsabilités de tri, de divulgation, de correction ou de communication avec les clients. Demandez qui reçoit les rapports de vulnérabilité, quelles versions sont corrigées, comment les problèmes sous embargo parviennent aux utilisateurs autorisés et si votre équipe peut créer et distribuer un correctif d'urgence.

Lisez la politique de sécurité du dépôt et comparez-la à la pratique réelle. Une politique utile nomme les versions prises en charge, un canal privé, les accusés de réception attendus et le processus de divulgation. Si elle dit seulement « ouvrez un ticket », un rapport sensible peut devenir public avant qu'un correctif existe. Si elle promet des délais, vérifiez s'il s'agit d'objectifs ou d'engagements contractuels.

Clarifiez ce que l'éditeur attend de ceux qui compilent eux-mêmes. Certains éditeurs ne prennent en charge que leur distribution signée, même lorsque la licence autorise les modifications. Cela peut être raisonnable, mais votre procédure doit montrer où le support s'arrête après un correctif local et comment revenir à une version prise en charge. Sinon, un correctif d'urgence crée une branche privée durable dont personne n'est responsable.

Les affirmations de sécurité doivent pouvoir être reliées au code et aux tests. Pour une passerelle d'identifiants, examinez où le texte en clair existe, quel processus exécute l'action externe, comment l'état d'approbation est lié à l'appelant et ce que prouve le journal d'audit. L'accès au code permet de répondre à ces questions, mais ne garantit pas des réponses favorables. Testez le comportement aux frontières des processus, pas seulement la fonction qui chiffre une valeur.

Demandez les modèles de menace, les notes d'architecture, les pratiques de mise à jour des dépendances et les rapports d'évaluation externe s'ils existent. Ne rejetez pas un jeune projet uniquement parce qu'il n'a pas de rapport soigné et ne faites pas confiance à un badge sans en examiner la portée. Notez les affirmations que votre équipe a vérifiées, celles qui reposent sur l'éditeur et celles qui restent non testées.

Désignez un responsable interne avant la production. Cette personne surveille les avis de sécurité, les changements de licence, les écarts de publication et la frontière commerciale. Sans responsable, le code public donne l'impression que quelqu'un peut l'inspecter alors que chacun suppose qu'un autre le fera.

## Que doit contenir le dossier d'adoption ?

La décision finale doit tenir dans un dossier que l'ingénierie, la sécurité, les achats et les juristes peuvent chacun contester. Une longue conversation n'est pas un dossier d'adoption, car elle perd le périmètre des versions, les hypothèses et les questions non résolues.

Utilisez cette liste compacte pendant la réunion d'approbation :

- Identité : version exacte, commit source, empreinte de l'artefact, empreinte du texte de licence, expression SPDX et statut OSI.
- Droits : usages autorisés et interdits pour l'évaluation, la production interne, la production destinée aux clients, les modifications, la redistribution, les prestataires et les filiales.
- Exploitabilité : résultat de compilation propre, différences entre code et artefact, processus de signature, export des données, archive des dépendances et test de déploiement d'un correctif.
- Parcours éditeur : branches prises en charge, pratiques de publication et de divulgation, frontière payante actuelle, dépendances commerciales prévues et interprétations écrites.
- Sortie et responsabilité : objectif de migration, responsable du fork ou de la migration, risques résiduels acceptés, événement de réexamen et expiration de l'approbation.

Attribuez chaque point non résolu à un responsable avec une date. Marquez clairement les hypothèses. Si les juristes attendent une réponse concernant l'usage en service géré, la décision est conditionnelle, pas approuvée. Si une fonction commerciale prévue contrôle la conservation de l'audit, inscrivez son absence dans l'exception de sécurité au lieu de la cacher dans les notes de feuille de route.

Refusez l'adoption lorsque la licence interdit clairement l'usage prévu, quand l'artefact livré ne peut pas être relié au code disponible ou lorsque les données nécessaires ne peuvent pas quitter l'infrastructure de l'éditeur. Suspendez la décision lorsqu'une clause importante est ambiguë. N'acceptez la dépendance à l'éditeur que si l'organisation en comprend le coût et la choisit, pas parce que le dépôt paraît rassurant.

Rouvrez le dossier en cas de version majeure, de changement du texte de licence ou du propriétaire, de nouvelle dépendance commerciale, de modification importante de l'architecture ou d'échec du test de sortie. Fixez aussi une date même si aucun de ces événements ne se produit. Un logiciel de sécurité devient souvent une infrastructure sans bruit, et un remplacement facile pendant l'évaluation peut devenir difficile lorsque des agents, des identifiants et des processus d'audit se développent autour de lui.

Le meilleur résultat n'est pas toujours l'adoption du produit sous la licence la plus permissive. Un produit restreint aux conditions claires, avec une maintenance attentive et un plan de migration financé, peut mieux convenir qu'un projet open source abandonné. La décision est saine lorsque l'équipe peut énoncer précisément les droits qu'elle possède, les capacités dont elle dépend et ce qu'elle fera si l'un ou l'autre change.