L'ampleur du défi pour la gestion des licences open source

Temps de lecture : 8 minutes

De plus en plus d'entreprises utilisent de plus en plus l'open source. Les statistiques  indiquent que 70 à 75% de toutes les applications utilisent l'open source ou sont associées à un type d'open source. D'après Mend, ce nombre est en fait plus élevé. Toutes les entreprises et presque toutes les applications sont associées à un type d'open source. Et plus vous en utilisez, plus cela se multiplie car chaque morceau d'open source a des composants et ces composants ont des dépendances.

La prolifération s'accélère à mesure qu'elle progresse. Par exemple, vous pouvez prendre deux ou trois bibliothèques open source et les appliquer à votre application. Mais sous les couvertures, vous pouvez avoir plusieurs bibliothèques open source qui leur sont associées. Si vous faites quelque chose comme un simple téléchargement de fichier, vous n'aurez peut-être qu'une ou deux sous-dépendances, mais si vous faites quelque chose de plus complexe, comme avec des langages comme Angular, vous pourriez facilement en avoir trente ou quarante, et le La chose à laquelle vous devez faire face n'est pas seulement de savoir si vos dépendances directes utilisent des dépendances indirectes, mais s'il pourrait y avoir des dépendances indirectes dans d'autres outils. Ainsi, il pourrait atteindre des centaines dans certaines circonstances.

De plus, lorsque vous recherchez une bibliothèque open source à connecter à votre application, tous les modèles de licence qui y sont associés ne sont pas nécessairement clairs. Une bibliothèque peut suivre le modèle MIT, et vous pensez que vous êtes en sécurité, mais une dépendance transitive peut être cachée sous la surface qui est A GPL, qui a un ensemble différent de défis qui doivent être gérés. Cela peut donc être assez détaillé pour qu'un outil de gestion des licences couvre tout.

Dans cet article, Mend dresse un constat complet :

• Défis et opportunités des licences open source
• Certaines industries prennent-elles les licences plus au sérieux que d'autres ?
• Le défi le plus difficile pour la gestion des licences open source
• Comment relever le défi de l'Open Source ?
• Quels types de licences présentent les risques les plus sérieux ?
• Que devez-vous rechercher dans un outil de gestion de licences open source ?
• Les bonnes pratiques pour choisir un outil de gestion de licence open source ?
• Quelle est la prochaine étape pour la gestion des licences open source ?

Il existe une dynamique push-pull entre les développeurs et les besoins de leurs entreprises. Les développeurs utilisent le code open source et les fonctionnalités qu'il apporte pour créer de nouvelles applications. Naturellement, ils sont enthousiasmés par cela, et par le principe de l'open source de leurs propres applications.

Cependant, les entreprises se rendent compte qu'elles doivent protéger une partie de leur production. Ils ne veulent pas nécessairement une permissivité totale dans leur environnement car ils ne veulent pas avoir à ouvrir complètement leurs systèmes. Mais les restrictions de licence découragent le partage et l'adaptation des bibliothèques des développeurs, aussi étonnantes soient-elles, alors ils cherchent à utiliser des licences moins restrictives comme MIT, BSD ou Apache. C'est là qu'intervient le modèle multi-licences, pour essayer de concilier les différents termes et conditions des différentes licences . Par conséquent, de plus en plus d'entreprises ont pris conscience de la nécessité de suivre plusieurs licences et le modèle multi-licences.

La priorité des développeurs a toujours été la productivité plutôt que les licences et la conformité. Aujourd'hui, les équipes veulent savoir si elles créaient un risque en déployant des applications et s'il existait des vulnérabilités qui pourraient exposer l'entreprise à des menaces. L'octroi de licences était un problème pour le service juridique.

Les entreprises qui traitent des informations manifestement sensibles, telles que les systèmes de dossiers de santé électroniques ou les dossiers financiers des patients, prennent très au sérieux les problèmes de licence. En outre, toutes les organisations gouvernementales et celles qui fournissent des infrastructures essentielles, comme le réseau électrique. Mais il y a une prise de conscience croissante dans tous les secteurs dorénavant.

C'est parce que si vous ouvrez votre logiciel, vous donnez potentiellement à tout le monde les clés du royaume, votre code source. Les pirates se rendent compte qu'ils peuvent injecter du code malveillant, le recompiler, le faire ressembler à l'original et fonctionner comme l'original, et personne ne le saura. Et avec un accès au code source, ils peuvent manipuler votre environnement, l'administration, les privilèges et les accès que vous avez configurés, afin qu'ils puissent s'infiltrer et causer des ravages à la source. Les risques se manifestent principalement par des vulnérabilités qui permettent aux pirates de désactiver, de voler ou de manipuler des données, de l'argent, des actifs, etc.

Dans cet esprit, il est essentiel de savoir ce que vous avez dans vos bibliothèques open source et de vous assurer qu'elles ne sont pas exposées. Sachez ce que vous avez en production et comprenez quels sont vos risques. Techniquement, ce qui est en développement et pas encore en production n'a pas besoin d'une diligence raisonnable aussi stricte. 
Cependant, une fois que vous l'aurez mis à la disposition des utilisateurs, il deviendra évident que les bibliothèques sont utilisées et vous devrez pouvoir suivre les conditions d'utilisation. De plus, et peut-être encore plus difficile, il ne s'agit pas seulement de savoir quelles licences se trouvent dans votre environnement, mais également d'anticiper l'impact potentiel de ces licences.

Vous avez besoin d'un outil de gestion des licences qui vous donne une visibilité complète. Par exemple, un outil comme Mend vous dira que vous avez un composant GPLv3 dans votre base de code. Vous pouvez accéder à l'outil et voir les détails d'utilisation sous la forme du texte de licence réel. Un écran vous indique quel est le score de risque de droit d'auteur et les détails qui l'entourent, afin que vous ayez une idée de l'impact de votre redistribution de ce composant. Il vous indique s'il existe des risques de brevets ou de redevances attribués à certaines de vos bibliothèques open source, qui nécessitent des paiements et qui sont libres de droits, par exemple, et l'outil donne le détail du copyleft. Le risque est affiché dans un système de feux de signalisation facile à comprendre, de sorte que vous pouvez dire en un coup d'œil ce qui pourrait être problématique et ce qu'il faut éviter pour éviter les problèmes juridiques.

Les risques diffèrent en fonction du contexte dans lequel le logiciel est utilisé et de la manière dont il est destiné à être utilisé. Il est donc difficile de dire quelles sont généralement les pires licences. Mend aide en affichant les licences à éviter en rouge, directement sur le tableau de bord.

Si vous deviez éviter une licence en particulier, ce serait la GPL qui est du copyleft. Vous devez divulguer votre source à chaque fois, vous devez fournir vos avis de licence et de copyright, et dans certains modèles de licence, vous devez divulguer les bibliothèques que vous utilisez. Parfois, vous devez même reconnaître publiquement votre application dans un fichier, pour montrer que vous suivez précisément le modèle de licence.

C'est très transparent, mais cela peut aussi vous exposer.

Votre outil de gestion des licences open source doit être :

• Complet : Vous indique-t-il exactement quelles licences sont utilisées lorsque vous créez une application ? Il est important d'avoir un système qui indique quelles sont vos dépendances directes et transitives, car vous devez connaître l'étendue complète de vos licences et de vos vulnérabilités.
• Clair : Votre outil doit clairement indiquer tous les détails concernant votre base de code. Le rapport de risque de Mend vous montre précisément quelles licences sont attachées à un projet. Il vous indique en un coup d'œil quel est votre risque et vous indique exactement à quelles conditions de licence vous devez vous conformer.
• Rapide et transparent : Les développeurs doivent s'assurer que le FOSS (logiciel libre et open source) passe par le processus d'assurance qualité avant de le brancher à leur application. Si un outil vous donne tous les détails sur les bibliothèques que vous utilisez dans un rapport, vous pouvez simplement le donner à l'équipe d'approbation, afin qu'elle puisse prendre des décisions plus rapidement sur les licences que vous pouvez utiliser.
• Facile à utiliser et à comprendre : Cela semble évident, mais un outil de licence open source ne peut être efficace que si la plupart ou la totalité de ses utilisateurs potentiels au sein d'une organisation l'utilisent réellement. Il doit donc être facile à utiliser et son interface utilisateur et son UX doivent être faciles à comprendre. Un bon outil distille toutes les informations sur les licences dans des rapports de conformité très simples afin que vous puissiez facilement porter des jugements éclairés sur les risques tels que les droits d'auteur, les brevets et les redevances. L'outil de Mend fait cela. Il génère des tableaux de bord et des écrans visuellement percutants afin que ces informations complexes puissent être comprises en un coup d'œil.
• Mettre en évidence et mettre en œuvre des mises à jour : Un bon outil ne résout pas seulement le problème de licence, mais fournit également d'excellentes données de vulnérabilité. Cela vous permet d'identifier et de mettre à niveau vers de nouvelles versions de composants et de dépendances en un clic. Votre outil devrait vous montrer les versions que vous utilisez et les mises à niveau disponibles et vous recommander vers quoi passer. Cela signifie que vous continuez à respecter les critères de licence tout en renforçant simultanément la sécurité en mettant en œuvre les versions les plus récentes susceptibles d'être moins vulnérables.
• Mettre en place de politiques et d'alertes : Votre outil peut faciliter la gestion des licences en définissant des politiques et en cas de violation, en alertant les utilisateurs afin qu'ils puissent résoudre les problèmes rapidement. Idéalement, votre outil devrait même empêcher la construction avec des composants non conformes pour vous assurer de ne pas introduire de risque pour vos applications. L'outil de Mend peut définir des politiques au niveau du produit et de l'organisation et peut automatiquement rejeter les composants qui ne sont pas conformes à vos politiques.

Le plus important est peut-être de permettre à vos développeurs de trouver l'outil de gestion de licences qui leur convient le mieux. Ensuite, il s'agit de s'assurer qu'il est complet afin que les développeurs obtiennent toutes les informations dont ils ont besoin pour effectuer une diligence raisonnable approfondie.

Si vos développeurs souhaitent introduire une nouvelle licence, ils doivent fournir un rapport de risque à l'examen technique senior, car ceux sont eux qui doivent savoir si quelque chose de nouveau a été introduit dans votre base de code, afin qu'ils puissent le vérifier. Ceux seront eux qui confirmeront si la licence de ce qui a été introduit est conforme. Votre outil doit pouvoir faciliter ce processus.

La question suivante est de savoir si une licence est approuvée par l'entreprise. Cela signifie le transmettre à votre équipe juridique pour vérifier si une nouvelle bibliothèque figure sur sa liste approuvée. Vous devez vous assurer que votre outil vous permet de soumettre des bibliothèques pour examen, afin de pouvoir examiner les licences associées à chaque bibliothèque.

Vous devriez être en mesure d'afficher et d'évaluer toutes les dépendances - directes ou indirectes - afin que vous puissiez voir si vous risquez d'introduire des menaces pour votre application en prenant une bibliothèque particulière. Et vous devez voir quelles sont les vulnérabilités associées à chaque bibliothèque.

D'après Mend, la gestion des licences open source va devenir plus difficile. Vous verrez davantage l'effet push/pull entre la permissivité et la protection. Les entreprises sont plus disposées à utiliser des logiciels open source, et de nombreux nouveaux modèles de licences émergent qui apportent plus de liberté qu'une GPL. Mais les entreprises veulent toujours pouvoir se protéger et protéger leur propriété intellectuelle. Par conséquent, il existe une tension persistante entre tous ceux qui utilisent des licences open source et les utilisateurs qui souhaitent les rendre plus restrictives au fil du temps s'ils le préfèrent.

Java en est un bon exemple. Le moteur d'exécution de Java était gratuit, et ils ont décidé à un moment donné de le monétiser en facturant son utilisation. Mais lorsqu'ils ont commencé à faire payer les licences, presque personne n'a utilisé la nouvelle version. Tout le monde a téléchargé les anciennes versions. Java s'est rendu compte que cela pouvait tuer son produit, alors il a soudainement changé de tactique. Il a toujours donné son outil gratuitement, avec quelques conditions supplémentaires, mais toujours suffisamment permissif pour que tout le monde puisse utiliser d'autres versions à venir.

Aujourd'hui, de plus en plus d'entreprises publient de nouvelles fonctionnalités, bibliothèques et outils open source parce qu'elles savent que c'est bénéfique pour elles-mêmes et pour leur secteur. Néanmoins, ils veulent s'assurer qu'ils ont un certain contrôle, afin qu'ils puissent conserver leurs points de différence par rapport à leurs concurrents. C'est un exercice d'équilibre qui continuera d'exercer ceux d'entre nous concernés par la gestion des licences open source.