Développement Open Source : les dépendances indirectes, un point noir dans la conformité

Attention, utiliser des logiciels Open Source dans un projet de développement logiciel provoque un risque en termes de conformité ! C’est la conclusion qu’il faudrait retenir de cette étude publiée par l’éditeur White Source, spécialisé dans les outils Open Source de gestion du cycle de vie. Selon lui, les développeurs, en intégrant des composants Open Source à leurs projets en oublient les dépendances associées, ces autres composants ou bibliothèques Open Source qui peuvent parfois être encadrés par une licence différente. De quoi alors remettre en cause la conformité du projet... sans même le savoir. Et selon les résultats de l’étude, réalisée sur quelque 473 projets, le phénomène serait même courant. Ainsi, selon les répondants à ce rapport, 91% des projets comportent bien des dépendances indirectes importées automatiquement par les développeurs - ce qui est un processus normal dans le développement Open Source. Mais sur ces 91%, 65% des dépendances ainsi importées indirectement sont liées à des licences différentes. De quoi en effet provoquer un trouble dans le portefeuille de l’entreprise. «Les développeurs ne tracent et comptent que les composants qu’ils utilisent directement et du coup, ratent les bibliothèques desquelles dépendent ces composants», explique White Source. Une façon de passer outre, à l’insu de leur plein gré ou par manque de vigilance, les risques et les contraintes liées à la conformité.

Un pistage trop rudimentaire Manque de formation au mécanisme du développement Open Source, pression de la hiérarchie pendant les phases de développement, processus internes inadaptés au développement Open Source ? White Source, de son côté, semble avoir une explication : il s’agirait plutôt d’une combinaison de l’ensemble de ces facteurs, associée à un manque d’outillage évident pour tracer les dépendances. «En l’absence d’outils adéquats qui détaillent toutes les dépendances, les développeurs sont presque sûrs de rater la longue chaîne de bibliothèques Open Source qui sont automatiquement importées avec les composants Open Source. Résultat, les décideurs n’ont souvent pas accès à l’information dans son ensemble, la conformité devient instable et les risques ne sont ni évalués ni gérés», résume White Source. D’autant que cette opération de pistage de dépendances et de licences «n’est pas ce qu’aiment le plus les développeurs», ajoute-t-il plus loin. Selon la société, ces mêmes sociétés s’adosseraient, si le tracking est assuré, à de simples outils manuels ou semi-automatisés. Les documents soumis alors seraient pour la plupart statiques. Difficile alors de pister les mises à jour ou les améliorations qui font souvent entrer en scène d’autres dépendances... et parfois encore d’autres licences... Sur la totalité des réponses obtenues, en moyenne, un projet est formé de 64 dépendances Open Source, avec 8 licences différentes. Le nombre de licences différentes le plus élevé dans un unique projet est de 26.