Les logiciels open source (OSS) ont changé les modes de programmation : désormais, la communauté des développeurs partage du code, fournit des recommandations quant à son utilisation, et y apporte constamment des améliorations. Presque toutes les nouvelles applications et tous les build systems modernes intègrent automatiquement des centaines de composants ou de bibliothèques open source (ainsi que d'autres composants et fichiers tiers).

Le problème ? Certains membres de la communauté des développeurs sont parfois très désinvoltes dans leur façon de copier des fichiers, des extraits de code, des images, des binaires, voire des modules open source entiers sans en respecter les licences. Et même s'ils se montrent extrêmement rigoureux quant au fait de mentionner les licences présentes dans leurs principaux composants, il y a de fortes chances que le code qu'ils utilisent soit en réalité du code copié et amélioré. 

Comment résoudre ce problème ? Analyser le code source à l'aide de techniques de recherche de similarités est la seule solution pour découvrir les composants tiers qu'il contient avec fiabilité. Dans le cas contraire, les risques sont considérables, que ce soit au niveau des licences ou des vulnérabilités. « D'où vient le code ? », « Quels sont nos droits d'utilisation ? », et « Y a-t-il eu des changements sur le plan de la sécurité depuis que nous l'avons copié ? » sont autant de questions nécessitant l'attention des équipes de développement.

La recherche de similarités (ou « source code fingerprinting ») permettra donc de comparer le code source d'une application avec une base de données de projets open source pour voir s'il contient des éléments copiés et collés ou importés autrement.

Pourquoi et à quel moment les développeurs copient-ils du code ?

Un certain nombre de scénarios peuvent pousser un développer à copier du code dans son code base. Imaginons qu'il ait besoin de code de construction (« build up ») et de libération (« tear down ») pour utiliser un composant logiciel. Ce code est souvent issu du projet original, et montre comment effectuer un appel dans le composant global. Généralement, les droits d'auteur et de licence ne sont pas clairement renseignés au sein de ce squelette de code, et ce dernier se retrouve dans le code du projet principal de l'utilisateur. Les projets open source peuvent aider dans ce type de scénario en étiquetant plus clairement le squelette et l'exemple de code, et en tenant compte des différences potentielles en matière de licences entre le code du composant principal et le code nécessaire pour effectuer un appel dans ce composant principal.

Autre cas fréquent : lorsqu'une routine principale est nécessaire, mais que le reste du composant ne l'est pas. Les algorithmes, les helpers et les données statiques en sont des exemples fréquents.

Quels sont les considérations et les potentiels problèmes vis-à-vis des licences ?

Comment distinguer le convenable de l'excès ? Cette question a été au cœur de nombreuses discussions sur la copie de code ces dernières années, cristallisant les tensions entre ceux qui estiment n'avoir pas d'autre moyen de procéder et les fervents défenseurs des droits d'auteur et licences. Il semble clair que les informations relatives aux droits et autorisations d'une page entière de code source doivent être préservées ; mais comment procéder lorsque quelques lignes ou une méthode ont été récupérées dans un fichier qui ne contenait pas ces renseignements ? Dans de tels cas de figure, votre avocat en propriété intellectuelle sera votre meilleur allié pour obtenir des conseils quant aux mesures appropriées. Si vous n'en avez pas, ou si le vôtre n'a pas d'opinion en matière de politiques vis-à-vis des licences open source, de nombreux conseillers externes spécialisés dans ce domaine pourront vous aider.

En tout état de cause, l'absence d'informations de licence doit être un avertissement clair signalant au développeur qu'il s'apprête potentiellement à provoquer des problèmes plus en aval dans le cadre du projet. À ce stade, il suffit parfois d'un peu de vigilance et d'un minimum d'investissement pour s'éviter des maux de tête par la suite.

Quels sont les problèmes avec le mode de fonctionnement actuel des développeurs ?

Les développeurs ont tendance à vouloir mentionner leurs sources. Le problème est que souvent, les droits d'auteurs et d'informations de licence ne sont pas juxtaposés au fragment copié, et le programmeur peut faire preuve d'une certaine désinvolture en se contentant d'un simple « code piqué à xyz » ou « pompé sans vergogne sur le projet Foo ».  Bien que les formulations de ce genre ne soient guère appréciées par les équipes juridiques, elles attestent néanmoins de la volonté du développeur de reconnaître la propriété du code copié. Il est donc important de fournir des conseils clairs sur la bonne façon d'importer des morceaux de code à des fins de respect des licences et pour les analyses de sécurité. La conformité passe par le maintien ou l'inclusion des informations adéquates. Surtout, ces renseignements sont indispensables pour permettre aux individus qui consulteront le code source d'en distinguer les auteurs.

Quelles sont les politiques généralement adoptées en matière de copie de code source ?

Bien que chaque entreprise ait ses propres considérations ou scénarios à gérer, les politiques dédiées proposent souvent des procédures appropriées pour enregistrer l'auteur, ses coordonnées, ainsi que la licence liée à l'extrait en question.

En l'absence de telles informations, l'entreprise formule parfois une requête auprès de l'auteur original en lui indiquant le code concerné et le cas d'utilisation, et sollicite une licence spécifique le cas échéant. Si ces questions restent sans réponse ou si la licence sélectionnée par l'auteur est contraire à la politique du développeur, ce dernier choisit généralement de partir à la recherche d'une nouvelle source de code pour résoudre son problème.

En les formant, en créant des politiques faciles à suivre et en analysant le code source pour identifier les problèmes potentiels, il devient possible de créer un produit conformer et sûr, et surtout d'éviter les problèmes de maintenance de code source au moment de la mise en production ou dans le contexte d'une fusion-acquisition.