Devez-vous mettre en place une convention d’entiercement concernant le logiciel et/ou le code source que vous utilisez sous licence?

convention d'entiercement

Dans le monde des affaires numériques et technologiques, avoir un plan B au cas où la licence de logiciel ou de programme d’ordinateur tourne mal, est une obligation. Est-ce qu’un client peut renforcer sa position avec succés, en concluant une convention d’entiercement avec le concédant de la licence? Comment l’entiercement de code source fonctionne, dans tous les cas? Comment le séquestre du code source peut-il être divulgué au licencié?

1. Qu’est-ce que l’entiercement de logiciel ou de code source?

1.1. Qu’est-ce que le code source?

Le code source est une version de logiciel tel qu’il a été écrit à l’origine (c’est à dire écrit sur un ordinateur) par un être humain en texte en clair (c’est à dire des caractères alphanumériques lisibles humains), selon le Projet d’Information Linux.

La notion de code source peut aussi être comprise de manière plus large, pour inclure le code et les notations de machine en langages graphiques, dont aucun ne sont textuels par nature.

Par exemple, durant une présentation à des pairs ou à un client potentiel, le créateur de logiciel peut clarifier dès le début que, ‟par souci de clarté, le ‟code source” est pris dans sa signification de toute description pleinement exécutable d’un système de logiciel. Il est par conséquent interprété comme incluant le code machine, des langages de très haut niveau et des représentations graphiques exécutables, de systèmes”.

Souvent, il y a plusieurs étapes de traduction ou minification (c’est à dire le processus consistant à retirer tous les caractères non nécessaires du code source, provenant de langages de programmation et de langages de balisage, interprétés, sans changer sa fonctionnalité) de programme, entre le code source original écrit par un être humain, et un programme exécutable.

Le code source est majoritairement utilisé comme contribution au processus qui produit un programme informatique exécutable (c’est à dire qu’il est compilé ou interprété). Par conséquent, les programmeurs informatiques trouvent souvent utile de revoir le code source existant afin d’apprendre des techniques de programmation. Ceci est si vrai, que partager le code source entre développeurs est fréquemment cité comme un facteur contribuant à la maturation de leurs compétences en programmation.

En outre, le portage de logiciel à d’autres plateformes informatiques est normalement trop difficile – si ce n’est impossible – sans le code source.

1.2. Statut juridique du logiciel, des programmes informatiques et du code source

Au Royaume-Uni, la section 3 (Oeuvres littéraires, dramatiques et musicales) du Copyright, Designs and Patents Act 1988 (‟CDPA 1988”) dispose que, parmi les oeuvres qui sont protégées par le droit d’auteur, il y a les ‟programmes informatiques”, ‟les matériaux de dessin préparatoires pour un logiciel informatique” et les ‟bases de données” (c’est à dire les collections d’oeuvres indépendantes, données ou autres matériaux qui sont organisés de manière systématique ou méthodique et sont accessibles individuellement par des moyens électroniques ou autre).

La section 3A du CDPA 1988 dispose que le standard pour la protection du droit d’auteur est plus élevé, pour les bases de données, que pour les autres ‟oeuvres littéraires”, étant donné qu’elles doivent être originales (c’est à dire que, du fait de la sélection ou de l’arrangement des contenus de la base de données, la base de données constitue la création intellectuelle propre, de l’auteur). Etant donné que le CDPA 1988 n’a aucune disposition similaire, pour les programmes informatiques, il est de notoriété publique que les dispositions de la section 3A du CDPA 1988, relative à l’originalité, s’applique tant aux bases de données qu’aux programmes informatiques.

En outre, la Directive européenne sur la protection juridique des bases de données (Directive 96/9/CE) et la Directive sur la protection juridique des programmes d’ordinateur (Directive 91/250/CEE) confirment ces standards d’originalité supérieurs pour les logiciels informatiques et bases de données, au sens qu’ils sont la création intellectuelle propre de l’auteur. Ceci est un standard d’originalité plus élevé que ‟la compétence, le travail et le jugement”.

L’article L112-2 du Code de la propriété intellectuelle français (‟CPI”) dispose que les logiciels, y compris le travail de conception préliminaire, sont réputés être des ‟oeuvres de l’esprit” protégées par le droit d’auteur. Cette protection de droit d’auteur comprend le code source.

Tant en France qu’au Royaume Uni, la durée du droit d’auteur pour les logiciels et les programmes informatiques est de 70 ans après la mort de l’auteur ou, si l’auteur est une personne morale, de la date à laquelle le logiciel a été rendu public.

Le droit d’auteur est acquis automatiquement en France et au Royaume Uni, dès la création du logiciel ou du programme informatique, sans besoin d’enregistrement de ce droit de propriété intellectuelle.

Tant en droit anglais qu’en droit français, les logiciels informatiques sont considérés comme non protégeables via d’autres droits de propriété intellectuelle enregistrés, tels que les brevets. En effet, la section 1(2) (c) du Patents Act 1977 (‟PA 1977”) énumère les programmes informatiques parmi les choses qui ne sont pas considérées comme des inventions ‟en tant que telles”. L’article L611-10 du CPI fait la même chose en France.

1.3. L’entiercement de logiciel / l’entiercement de code source

Étant donné que les auteurs de logiciels et programmes informatiques – ce qui comprend le code source – possèdent le droit d’auteur sur leurs oeuvres, ils peuvent octroyer une licence sur ces oeuvres. En effet, l’auteur a le droit d’accorder aux clients et utilisateurs de son logiciel certains de ses droits exclusifs, sous la forme de licence de logiciel.

Alors que certains logiciels sont ‟open source”, c’est à dire gratuit à l’utilisation, la distribution, la modification et l’étude; la plupart des logiciels sont ‟propriétaires”, c’est à dire détenus de manière privée, restreinte et, parfois, tenus secrets.

Pour le logiciel propriétaire, la seule manière pour un utilisateur d’y avoir un accès légal est en obtenant une licence d’utilisation de la part de son auteur.

Lorsque de très larges sommes d’argent sont échangées, entre le concédant de la licence (c’est à dire l’auteur du logiciel et du code source) et ses licenciés (c’est à dire les utilisateurs de ce logiciel et code source), une mesure de précaution peut être requise par ces derniers: l’entiercement du logiciel.

C’est le dépôt du code source de logiciel avec un agent fiduciaire tiers, tel que Iron Mountain ou SES. Le code source est géré de manière sécurisée par un tiers de confiance et neutre afin de protéger la propriété intellectuelle du développeur, tout en gardant en même temps une copie en sécurité pour les licenciés au cas où quelque chose arrive; comme par exemple le fait que le concédant de la licence ne soit plus en mesure de subvenir aux besoins du logiciel, ou qu’il fasse faillite. Si cette situation se matérialise, les licenciés demandent la communication du code source du compte séquestre et sont en mesure de garder leurs entreprises en état de marche. Cette solution d’entiercement donne, dans les faits, au licencié, le contrôle sur le code source et des options pour aller de l’avant.

2. Comment mettre l’entiercement du code source en place?

De nombreuses organisations ont une politique établie qui requiert que les développeurs de logiciel entiercent le code source des produits que ces entreprises utilisent, par le biais d’une licence.

Par conséquent, à côté de l’accord de licence d’utilisation du logiciel informatique, les juristes et avocats externes des licenciés négocient en outre les termes d’une convention d’entiercement selon laquelle le code source du programme informatique sera mis en entiercement auprès d’un tiers de confiance.

3. Cela vaut-il la peine de requérir l’entiercement du code source à côté de la licence de logiciel?

Seulement un petit pourcentage d’entiercements sont jamais libérés: Iron Mountain, le dépositaire dominant aux Etats-Unis, a des milliers de comptes séquestres et plus de 45.000 clients dans le monde qui ont placé leurs logiciels et codes source avec cet agent. Durant la période de 10 ans, de 1990 à 1999, Iron Mountain a communiqué 96 comptes séquestres, soit moins de 10 par an.

C’est très bien comme cela, étant donné que les conventions d’entiercement sont conclues comme une sorte de police d’assurance, devant uniquement être utilisées au cas où quelque chose va très mal au sein de la société du concédant de la licence, ce qui déclenche un des cas de déblocage (insolvabilité, cas de force majeure, décès du développeur informatique, etc.).

Toutefois, un inconvénient valable est que la plupart des codes sources en entiercement sont défectueux: souvent, aprés communication, le code source échoue à fournir la protection adéquate, parce qu’il est périmé, défaillant ou n’arrive pas à combler les besoins du licencié. De nouveau selon Iron Mountain, 97,4 pour cent de tous les dépôts de matériaux entiercés analysés ont été identifiés comme incomplets et 74 pour cent ont nécessité un apport supplémentaire des développeurs afin d’être compilés. Ceci est un argument valable et les licenciés du logiciel, qui insistent sur la nécessité d’obtenir une convention d’entiercement aussi, doivent y insérer des clauses par lesquelles le code source sous séquestre sera testé de manière très régulière par tant le licencié que le concédant de la licence, afin de s’assurer que ce code source entiercé sera utilisable dès qu’un ‟cas de déblocage”, stipulé dans la convention d’entiercement, se matérialise. Le concédant de licence devrait avoir une obligation de résultat de maintenir le code source entiercé à jour et pleinement opérationnel, pendant la durée de la convention d’entiercement.

Un autre point sur lequel il convient de prendre des précautions est que les licenciés peuvent être dénués de l’expertise requise pour utiliser le code source communiqué. Même si le concédant de licence a été diligent, et le code source débloqué est bien à jour, bien documenté et pleinement opérationnel, la majorité des licenciés manque des ressources techniques ou des compétences nécessaires pour utiliser le code source après sa communication. Les licenciés peuvent contourner ce problème, soit en recrutant un ingénieur qui a la compétence technique appropriée pour utiliser au mieux le code source communiqué (sachant que la plupart des accords de licence interdisent aux licenciés de piquer les salariés du concédant de licence pendant la durée contractuelle de la licence), soit en mandatant une société informatique tierce. L’approche la meilleure et la plus économe est d’autre le plus autonome possible, en tant que licencié, en développant l’expertise en interne sur les modalités de fonctionnement du logiciel, et de son code source, même avant qu’un des cas de déblocage ne se matérialise.

Un autre problème identifié est que les concédants de licence de logiciel pourraient empêcher la communication ponctuelle de ce code source placé sous séquestre, en imposant certaines conditions unilatérales au déblocage, telles que le fait que le fournisseur ait à fournir son accord écrit préalable avant que le code source ne soit communiqué par le dépositaire, au moment de la matérialisation du cas de déblocage. En outre, de nombreuses conventions d’entiercement requièrent que les parties participent à de longues procédures alternatives de résolution des litiges, telles que l’arbitrage ou la médiation, au cas de litige relatif à la divulgation du code source. Une problématique souvent litigieuse est d’établir si un cas de déblocage a effectivement eu lieu, même lorsque le concédant de la licence de logiciel est en faillite! Le long retard et la bataille juridique onéreuse nécessaire pour obtenir la communication du code source, peuvent devenir des charges très lourdes pour le licencié, aggravées par la difficulté de garder le programme informatique et logiciel du licencié en état de marché – alors que le concédant de la licence, et son support technique, ont disparu. Afin d’éviter ces retards et complications dans la divulgation du code source sous séquestre, les stipulations de la convention d’entiercement doivent initialement être revues, et négociées, par un avocat en informatique expérimenté dans ce domaine, afin que toutes les clauses soient sans faille et puissent être exécutées immédiatement de manière prompte et sans heurt, à la survenance d’un cas de déblocage.

Une autre considération de coût est que les dépenses relatives à l’ouverture et au maintien d’une convention d’entiercement sont élevés, et généralement supportés par le licencié. En sus des commissions payées à l’agent d’entiercement, le client va en outre devoir régler des honoraires d’avocats élevés relatifs à la rédaction et négociation de la convention d’entiercement, comme expliqué ci-dessus. Les concédants de licence de logiciel étant vraiment résistants à l’idée de fournir leur code source propriétaire à quiconque, les conventions d’entiercement sont souvent l’objet de longues négociations, avant d’être signées. Toutefois, lors de l’exécution d’une analyse des coûts et bénéfices de l’obtention de l’entiercement du code source, le licencié doit évaluer combien cela coûterait, au cas où un événement de déblocage survenait (faillite du concédant de la licence, cas de force majeure, etc) mais qu’aucun entiercement du logiciel n’avait été mis en place au préalable. Si le licencié a effectué un investissement considérable dans le logiciel, le coût pour protéger cet actif via une convention d’entiercement pourrait être trivial.

Certaines sociétés disent que, étant donné qu’elles s’appuient sur des solutions de ‟Software-as-a-Service” (‟SaaS”) pour certains de leurs besoins et fonctionnalités informatiques, il n’est pas nécessaire d’avoir des conventions d’entiercement puisque le SaaS s’appuie sur un système basé dans le nuage. Toutefois, le SaaS implique que vous avez besoin de penser tant au logiciel qu’aux données de votre société, qui sont en effet stockées dans le nuage – ce qui ajoute un niveau de complexité. Etant donné que la majorité des plans de continuité de l’entreprise/plans de reprise après sinistre des fournisseurs de SaaS ne s’étendent pas à l’application et aux données de la société, de nouveaux produits d’assurance ont pénétré le marché, combinant tant l’entiercement du code source et la reprise après sinistre, ainsi que des solutions de gestion des risques. Par exemple, Iron Mountain commercialise ses Solutions SaaSProtect pour la continuité de l’entreprise.

Pour conclure, les licenciés doivent conduire une analyse coûts/bénéfices sur la pertinence d’avoir une convention d’entiercement en place, à côté de l’accord de licence de leurs applications logicielles majeures, concernant chacun des programmes informatiques qui sont perçus comme absolument indispensables à la survie économique, et à la continuité des opérations, des licenciés. Une fois qu’ils ont mis en balance les avantages et les inconvénients de mettre en place des conventions d’entiercement, ils doivent rédiger une liste de leurs besoins essentiels qui doivent être énoncés dans chaque convention d’entiercement (par exemple, une liste détaillée des cas de déblocage qui amèneraient à la divulgation du code source au licencié; l’obligation trimestrielle supportée par le concédant de la licence de maintenir le code source code à jour et en bon état de fonctionnement; le détachement d’un programmeur informatique hautement qualifié, salarié du concédant de la licence, aux bureaux du licencié, soit à plein-temps, soit à temps partiel, afin de former le personnel informatique interne sur les complexités du logiciel et son code source). Ensuite, ils doivent communiquer cette liste à leur avocat mandaté – qui devrait être un avocat expert en informatique, habitué à revoir et négocier des conventions d’entiercement – pour sa revue, sa critique et son feedback constructifs. Une fois que les licenciés se sont mis d’accord sur une stratégie de ‟plan d’assurance entiercement” en interne, puis ensuite avec leur conseil, ils doivent contacter le concédant de licence, son management et son équipe juridique, et leur faire circuler un ‟term sheet” de la future convention d’entiercement, afin d’entamer la négociation sur la convention d’entiercement.

Une convention d’entiercement est, et devrait rester, une police d’assurance pour le licencié, tant qu’il – en coordination avec son conseil juridique – a préparé la voie à un plan de sauvetage et d’entiercement réussi et bien pensé. De cette façon, l’utilisateur du logiciel va éviter toutes les failles des conventions d’entiercement, et des codes sources, mal compris et rédigés, pour le présent et le futur.

Crefovi met à jour régulièrement ses réseaux de médias sociaux, tels que LinkedinTwitterInstagramYouTube et Facebook. Vérifiez nos dernières nouvelles ici!


    Votre nom (obligatoire)

    Votre email (obligatoire)

    Sujet

    Votre message

    captcha


    Laisser un commentaire

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