Juridique : A qui appartient mon code source ?

Merci pour le partage...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0

Vous êtes-vous déjà posé la question ? Etes-vous propriétaire du code que vous écrivez ? Si vous récupérez des morceaux de code ici et là dans des exemples, sur le web, etc., quelles conséquences cela peut-il avoir pour vous ou l’entreprise qui va utiliser ces codes ?

Plusieurs affaires ont secoué le monde informatique et Internet : Oracle qui attaque Google sur la licence Java et le code source de ce dernier, Free et des problèmes liés à la licence GNU/GPL. Utiliser un code source d’origine indéterminée peut avoir des conséquences désastreuses.

Dura lex sed lex

 

La problématique

 

Par définition, tous les logiciels, tous les codes sources sont soumis à un statut juridique qui varie selon le pays : propriété intellectuelle, copyright, droit moral, droit patrimonial, brevet logiciel, etc. Nous n’avons que l’embarras du choix.

Bref, tout n’est pas permis. Vous ne pouvez pas réutiliser un code source dans un logiciel commercial/ payant si ce morceau de code est soumis à une licence d’utilisation précise. Dans certains cas, vous pouvez librement récupérer, modifier et redistribuer un code. Il existe de très nombreuses licences open source et propriétaires, avec des permissions et des contraintes très différentes.

Déterminer l’origine d’un code récupéré sur Internet ou auprès d’un collègue n’est pas à prendre à la légère surtout pour des entreprises sensibles à la propriété intellectuelle. La moindre  « faille » peut coûter très cher. Si un code à l’origine indéterminée est utilisé, mieux vaut parfois le redévelopper entièrement pour éviter toute ambiguïté.

Autre question qui revient souvent, « qu’est-ce que je fais quand il y a des codes soumis à différentes licences ? » Quelle licence prime sur l’autre ? Faut-il se référer à la licence la plus permissive ou la plus contraignante ?

 

Les outils de recensement et d’audit open source : pour quoi faire ?

 

Pour pouvoir recenser les licences utilisées dans les codes sources, un outil de recensement d’audit est indispensable quand un package applicatif représente plusieurs centaines ou milliers de fichiers.

Ces outils analysent l’ensemble des fichiers indiqués. Le moteur d’analyse utilise des bases spécifiques pour les licences et les codes référencés (base de connaissance incluant les forges). C’est en quelque sorte une empreinte avec les caractéristiques de la référence. Ces outils supportent les codes sources, les codes objets, les exécutables. L’objectif est de générer un rapport, le Bill of Material (BOM).

Ce rapport recense tous les éléments utilisés dans le projet : l’application. Pour faciliter le travail de ces outils et mieux identifier les codes et licences, un standard a été défini par la Linux Foundation, le SPDX.

Même si l’initiative est assez récente, ce format se répand. Le fichier SPDX comprend de nombreux éléments (nom du package, nom du fichier, description, identifiant, licence déclarée, etc.). Il est au niveau du package et de chaque fichier.

> Quelques outils

Blackduck : référence et leader du marché ! Il est utilisé par les grandes entreprises pour scanner les projets et logiciels.

Code Janitor : initié par la fondation Linux. Analyse les sources et les licences des fichiers de vos projets.

Antepedia Tool Suit : outil payant mais gratuit pour les projets non commerciaux. Est constitué de deux composants : Reporter (analyseur) et Notifier qui se connecte à un outil de gestion de code pour détecter les codes open source en temps réel. Site : http://www.antelink.com

Fossology : outil d’analyse statique, projet open source initié par HP. Reconnu par la communauté et qui évolue régulièrement. Site : http://www.fossology.org

Politique open source

Les bonnes pratiques de la politique open source, encore appelée gouvernance open source, mettent toujours en avant une première étape, qui est d’identifier l’existant en matière d’open source dans l’entreprise. Et effectivement, une majorité d’entreprises n’ont pas une vision complète des logiciels déployés au sein du système d’information.

L’open source entre souvent par la petite porte, simplement parce qu’un administrateur système, un chef de projet, un développeur, a jugé qu’il pouvait gagner du temps et de l’argent, en intégrant tel composant qui répond à ses besoins. Pas de bon de commande, pas d’autorisation requise.

Or méconnaître son utilisation de l’open source est dommageable, pas uniquement sous l’angle juridique. Peut-être que parmi ces composants, certains seront obsolètes, ou présenteront des failles, ou n’auront pas le niveau de support souhaité. Bref, identifier son patrimoine est toujours une bonne chose, le point de départ de sa politique open source. C’est aussi, comme on l’a dit, l’occasion de mesurer ce qui a été gagné déjà par ces composants, le plus souvent gratuits. Le recensement porte sur des référentiels de code déjà clairement identifiés.

Avoir une vision claire

Le besoin de voir clair dans son patrimoine de code est très réel. Le développement moderne repose largement sur un assemblage de composants. Un programme peut en compter des milliers. Il n’est pas aisé de garder précisément la trace de l’origine de chacun d’entre eux et de ses conditions de licences.

Les programmeurs ne sont pas tous bien formés sur le sujet, et une partie du logiciel peut être sous-traitée à différents fournisseurs dont le niveau de maîtrise de la propriété et des licences peuvent être insuffisantes.

Lors de fusion et acquisitions : auditer le parc logiciel

Ces questions surviennent souvent à l’occasion des acquisitions d’entreprises dont une grande partie du patrimoine est fait de logiciels. L’acquéreur se demande naturellement d’une part à qui appartient – de manière détaillée – ce logiciel, et d’autre part ce qu’il est autorisé à en faire. Cela peut concerner un éditeur de logiciel, bien sûr, mais aussi un fabricant de produits physiques incluant du logiciel embarqué, ou bien encore une startup du web. Quelle part du logiciel appartient à l’entreprise, et pour ce qui ne lui appartient pas, dispose-t-elle des droits d’utilisation requis ? L’acquéreur sera t-il libre de faire un autre usage de ces logiciels ? L’acquéreur court -il le risque d’être attaqué par le détenteur des droits de l’un des composants logiciels ?

Sans oublier la prévention du risque juridique, les exigences lors de la commercialisation de logiciels, de services (pour lever tout doute sur la conformité).

Source :

(Extrait du livre blanc « Les outils de recensement et d’audit open source source », Smile)

 

Christian Kas

Spécialiste de la réussite et du bien-être.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *