Guide d'adoption de l'Open Source ou des Logiciels Libres

IV-A-2-a-i. Une protection du logiciel en tant qu'œuvre▲

IV-A-2-a-ii. Une protection différenciée des composantes du logiciel▲

Les droits patrimoniaux sont les droits qui permettent l'exploitation du logiciel. C'est l'utilisation de ces droits que l'on aménage par contrat (souvent appelé « licence ») : les droits d'utilisation ou d'exploitation sont cédés, le plus souvent de façon non exclusive, par le titulaire de droits (éditeur ou SSII, par exemple) sur le logiciel à celui qui reçoit la licence (utilisateur, par exemple).

Les droits patrimoniaux sont de trois catégories :

1. le droit de reproduction (notamment le chargement, l'affichage, l'exécution, la transmission ou le stockage du logiciel(23)) - seul l'usage du logiciel en SaaS (Software as a Service) supprime la nécessité pour l'utilisateur de disposer d'un tel droit ;
2. le droit de distribution qui permet au titulaire de droits d'autoriser la mise sur le marché, à titre onéreux ou gratuit ;
3. le droit de modification22(24) : droit de correction, nécessaire pour maintenir le logiciel en état de fonctionnement et la conformité du logiciel à l'usage décrit ; et droit d'adaptation, entendu comme le droit de procéder à des modifications et évolutions fonctionnelles du logiciel.

Par ailleurs, l'auteur dispose de multiples autres prérogatives regroupées au sein de la notion de « droit moral ». Dans la tradition du droit d'auteur, le droit moral est un droit « perpétuel, inaliénable et imprescriptible »(25) de l'auteur sur son œuvre : il ne peut pas le céder et/ou le perdre par le non-usage.

Traditionnellement, ce droit se compose :

• des droits de divulgation (qui permet de décider de la première mise à disposition) ;
• du droit de repentir et de retrait ;
• du droit au respect de son nom et de sa qualité (droit de paternité) ;
• du droit au respect de l'œuvre.

En revanche, l'auteur d'un logiciel ne peut exercer son droit de repentir ou retrait (pour retirer son logiciel du marché), ni s'opposer à la modification du logiciel par son employeur(26).

Par principe, l'auteur d'une œuvre (logicielle ou non) est le seul titulaire de droits, c'est-à-dire celui qui crée l'œuvre (logicielle ou non), mais le CPI prévoit un système dérogatoire au droit commun lorsque l'auteur d'un logiciel est un salarié. Il prévoit une dévolution automatique des droits patrimoniaux à l'employeur dès lors que le salarié a créé le logiciel « dans l'exercice de ses fonctions ou d'après les instructions de son employeur »(27) (CPI, art. L. 113-9).

L'employeur est alors titulaire des droits patrimoniaux et, partant, il bénéficie de l'ensemble des prérogatives attachées à l'exploitation de l'œuvre.

Ainsi, en vertu de la dévolution automatique, c'est donc, sauf stipulation contraire(28), l'entreprise développant un logiciel qui, en tant que titulaire des droits d'auteur, décide de son développement, de sa mise sur le marché et choisit la licence sous laquelle le logiciel sera commercialisé.

La société titulaire des droits d'auteur sur le logiciel peut transférer au licencié, utilisateur, en tout ou partie, à titre exclusif ou non exclusif, ses droits patrimoniaux et plus spécifiquement, le droit de reproduction et les droits de traduction (dans un autre langage informatique), d'adaptation, d'arrangement ou de modification. Seul l'auteur - son employeur en cas de création salariale - peut décider des droits qu'il concède aux tiers (ses clients) par démembrement de son monopole d'exploitation.

Dans cette optique, tout droit qui n'est pas expressément concédé demeure strictement réservé au titulaire des droits.

Ne pouvant céder plus de droits qu'elle n'en dispose, la société doit donc s'être assurée :

• que ses salariés ont développé le code source dans l'exercice de leur fonction (cf. supra) ;
• à défaut, acquérir auprès de ses salariés la propriété intellectuelle de leurs travaux (voir clauses spécifiques, infra) ;
• que le développement du logiciel n'a pas impliqué l'insertion de code source appartenant à un tiers (ou ajouter les stipulations exactes des licences Open Source si celles-ci existent) ;
• de la cession des droits (par exemple, par voie de licence) en cas de recours à des tiers dans le développement du logiciel.

Les licences Open Source fonctionnent fondamentalement comme les licences classiques et, juridiquement, il n'y a qu'une différence de degré entre la cession sous licence Open Source d'un logiciel et la simple licence d'utilisation : la liberté de l'utilisateur est plus ou moins grande, en fonction des droits que lui a reconnus son auteur à travers la licence.

Les processus varient et dépendent fréquemment de ceux déjà en place au sein de chaque structure, mais deux documents techniques (au moins) sont nécessaires :

• le premier pour réunir toutes les informations sur les composants inclus dans la solution - qu'il s'agisse de développements spécifiques ou non :

  • informations relatives aux composants (nom, URL d'origine),
  • à leur licence (nom, version, URL, éventuellement les termes additionnels qui conditionnent son usage),
  • et à leurs auteurs (nom, informations permettant de les contacter et éventuellement société) ;

• le second décrivant précisément toutes les interactions entre ces composants (il prendra généralement la forme d'un ou plusieurs schémas et/ou d'une présentation écrite/orale). Les différents types de relations seront bien renseignés :

  • relation explicite (l'appel du composant B est codé dans le composant A),
  • relation implicite (l'appel du composant B n'est pas codé en tant que tel dans le composant A, mais le composant A appelle d'autres composants par paramétrage et le projet B fait partie de ces composants),
  • relation possible (l'utilisateur de l'application fournie par le projet peut paramétrer lui-même des relations entre les composants et un appel de B par A fait partie de cette éventualité).

Cette liste doit être mise à jour au fur et à mesure et il peut être nécessaire de conserver un historique de ce fichier. Il doit être à la disposition du service juridique et sera in fine annexé (de préférence en l'état) au contrat.

Se basant sur les documents élaborés par l'équipe technique, l'équipe juridique va réaliser un audit de l'ensemble des composants listés et décrits afin de déterminer :

• si ceux-ci sont propriété (ou copropriété) de la société ou de ses partenaires ;
• si les licences utilisées sur les composants répondent à la politique de la société et/ou du projet.

En cas d'inadéquation, le problème sera relevé et transmis à l'équipe technique.

Les risques juridiques liés à une contestation de l'utilisation faite de composants par rapport à leur(s) licence(s) sont, par nature, à apprécier par les responsables de l'entreprise susceptibles d'être mis en cause. En conséquence, il est nécessaire que l'entreprise ait défini une politique en matière de licences, avant même qu'un premier projet ne soit réalisé. À défaut, il est prudent pour les équipes de développement de proposer et de faire valider a priori par les services juridiques une telle politique (qui peut limiter l'usage de certains composants logiciels, de certaines licences Open Source, ou mettre en place un processus particulier).

Par ailleurs, chaque licence présente dans le code fera l'objet d'une fiche synthétique permettant de faciliter la comparaison et d'apprécier leur portée respective(53).

Par ailleurs, dans son cahier des charges, le client transfère beaucoup de son savoir-faire métier à la société de services. Son système d'information contribuera à le différencier de ses concurrents et à en tirer avantage. Par exemple, il peut s'agir de systèmes de fidélisation des clients, de méthodes originales de production, etc. Très logiquement, il ne souhaite pas que son savoir-faire soit communiqué à ses concurrents - ce qui pourrait être le cas si le prestataire réutilisait des développements spécifiques pour compléter sa propre offre. Nombre de progiciels sont effectivement nés de la collaboration entre un éditeur et un client.

Notons que l'impact des licences Open Source, même copyleft, sera inexistant en l'espèce puisque :

• dans le cas d'un développement spécifique, seul le client bénéficie de la cession « contrainte » des droits sur le logiciel : à sa charge ensuite de décider d'en limiter la diffusion ou de l'exploiter (les problèmes peuvent néanmoins ressurgir en cas de division de ses activités, acquisition partielle, etc.) ;
• dans le cas d'une maintenance, d'un support ou d'une assistance réalisés sur les machines du client et sous son contrôle, alors le logiciel n'est pas distribué et le client n'est pas contraint de donner accès au code source.

D'où la nécessité d'identifier en amont d'une part les objectifs du client et d'autre part les composants logiciels. Plusieurs réponses sont alors possibles, dont une relative aux licences Open Source :

• commencer par identifier clairement les composants et/ou développements correspondants aux demandes spécifiques du client. Ils seront alors distingués et un éventuel accord de transfert pourra les viser. Le fournisseur pourra ainsi écarter de la discussion tout ce qui concerne les Logiciels Libres, modifiés ou non ;
• ensuite, proposer des solutions alternatives au transfert de propriété comme une clause d'exclusivité sur le marché considéré, pour une durée et une étendue géographique à déterminer avec le client, par exemple, assurant au client qu'il ne retrouvera pas son savoir-faire chez un concurrent. C'est ici le fournisseur/l'éditeur qui s'oblige le plus, et donne plus de droits à son client, ce qui est tout à fait conforme au texte des licences ;
• transférer le code source sous licence Open Source pour garantir au client non seulement la disponibilité des sources correspondantes, mais encore la possibilité de les utiliser, modifier, développer à sa convenance et sans contrainte(99). Cette solution permet aussi d'assurer la continuité en cas de disparition du prestataire ;
• transférer les composants spécifiques en pleine propriété (c'est-à-dire céder la titularité des droits). En pareil cas, il convient d'identifier avec le client quels sont les droits patrimoniaux à transférer pour répondre à son attente. Par exemple, droits de commercialisation sur certains marchés ou zones géographiques, droits d'utilisation dans certains contextes, etc. Cela permettra également au client de bien identifier son « vrai » besoin et, au fournisseur, d'y apporter des réponses appropriées en appauvrissant aussi peu que possible son propre potentiel professionnel.

Il s'agit pour l'utilisateur d'assurer la pérennité globale de son système et donc de la problématique de dépendance envers ses fournisseurs, de leurs disponibilités pour la maintenance et/ou les développements ultérieurs, de la cohérence du système contractuel et technique (avec notamment des enjeux de cohérence entre les divers choix en matière de licences Open Source).

Par exemple, il arrive fréquemment qu'un Grand Compte détecte une solution logicielle qui lui convient parfaitement, mais dont le porteur lui semble être une société fragile financièrement. Il aura tendance à se tourner vers un Intégrateur Système qui prendra en charge la cohérence de l'ensemble et qui en sera responsable en maintenance et en suivi.

Le client veut pouvoir s'affranchir de la dépendance d'un fournisseur en cas de défaillance de celui-ci et éviter tout litige commercial, désaccord sur le prix des prestations, etc. Il souhaite donc disposer de l'ensemble des sources et ressources lui permettant d'assumer, par lui-même ou avec l'aide d'un sous-traitant, la continuité de service et les développements. Comme toute médaille à son revers, il perdra alors beaucoup de poids vis-à-vis de son fournisseur qui se sentira libre de s'affranchir, au moins partiellement ou temporairement d'obligations de maintenance et de suivi, au motif qu'il n'est plus indispensable à son client, celui-ci disposant de toute la « matière première » nécessaire. Le fournisseur peut être tenté de mettre ses moyens en priorité vers les clients qui dépendent totalement de lui. Pourtant, si le client externalise ses développements, leur maintenance et même leur hébergement, c'est bien pour ne pas avoir à le faire par lui-même. Il ne dispose généralement pas des ressources ou des compétences et connaissances nécessaires. Il restera donc, au moins à court terme, dépendant de son prestataire.

Il est possible au client de demander un transfert de l'ensemble des composants (composants matériels, composants plates-formes et composants spécifiques), dans le cadre d'une licence Open Source. Il disposera ainsi de l'ensemble des sources - y compris des plates-formes de développement et de déploiement Open Source - nécessaires pour assurer par lui-même, ou avec l'aide d'un autre prestataire, la pérennité de son système. Les prestataires qui fournissent ce genre de solutions facturent essentiellement leur expertise en matière d'architecture, de choix de composants, d'assemblage et de validation desdits composants, leur déploiement, leur paramétrage(100). Le fait pour le client de disposer de l'ensemble des sources représente non seulement un confort « psychologique », mais une réelle possibilité d'indépendance vis-à-vis de la fourniture de services : il peut ainsi changer de prestataire sans coût disproportionné. L'usage de Logiciels Libres est ainsi parfaitement adapté à ce type de demande.

La mise sous séquestre du patrimoine, accessible au client sous condition, est une alternative disponible tant à l'égard de Logiciels Libres que propriétaires, elle concernera les composants plates-formes, framework métier et composants spécifiques client. Le véritable enjeu pour le client n'est pas patrimonial, mais bien opérationnel : il souhaite pérenniser son système d'Information ou de production. Naturellement, le contenu de ce séquestre doit être soigneusement décrit (cf. infra l'annexe technique de description d'une livraison, en cas de séquestre) et surtout testé. Il doit également faire l'objet d'un suivi pour limiter de façon raisonnable la différence entre la dernière version séquestrée et la version en production(101).

En matière d'outsourcing et de mutualisation des plates-formes de production (ASP SaaS), les enjeux concernent principalement les services (en matière de Contrat de Niveau de Service(102) et de Plan de Reprise d'Activité(103)). Les problématiques sont généralement les mêmes en matière de logiciel propriétaire et de Logiciel Libre - à l'exception des acteurs qui étendent les libertés des utilisateurs à ces usages(104).

Dans bien des cas, les demandes clients peuvent être traitées par une clause de cession sous licence Open Source (si le prestataire assure le pilotage du projet Open Source), de transfert des sources (s'il peut assurer, ou faire assurer la maintenance), selon le type de composant concerné. Toutefois et dans la mesure où l'utilisateur n'a pas précisément de compétence en matière de développement et de maintenance de ladite application, disposer des « sources » peut poser plus de problèmes que cela n'apporte de solutions crédibles à ses questions sur la pérennité de son investissement, et donc de tout ou partie de son système d'information(105). Le client doit mesurer l'intérêt de disposer des « sources » à l'aune de ses objectifs.

Une gestion plus stricte des projets informatiques s'impose (cf. supra) et les considérations développées dans ce document sur les licences des logiciels s'appliquent donc également :

• à l'ensemble de l'infrastructure nécessaire au développement du logiciel, notamment dans le cas de vente d'une solution globale ;
• à toute acquisition et fabrication de matériel incluant des Logiciels Libres, y compris aux services connexes de support, de maintenance et de formation.

Au stade du développement, de la réalisation, de l'intégration, le développeur doit garder des traces de son travail au sein de l'inventaire : il doit être toujours en mesure de lister les composants du projet, mais aussi les éléments techniques permettant de réaliser le projet. L'ensemble de ces informations est destiné à devenir l'annexe technique du contrat. Le développement technique ne peut ignorer les contraintes juridiques (et doit donc être formé à cet égard).

Il est recommandé :

• de renseigner au sein de l'inventaire, au fur et à mesure de l'avancée des travaux de développement, une liste qui distingue et détaille les modules et composants logiciels utilisés (une procédure interne complémentaire de mise en place d'un référentiel permet par ailleurs d'assurer un suivi des développements, cf. supra) ;
• de collaborer étroitement avec le service juridique de façon à assurer une compréhension optimale du processus de développement et à guider les choix techniques lorsque ceux-ci reposent sur des contraintes juridiques ;
• d'intégrer au service à la fois la politique de commercialisation décidée par l'entreprise éditrice et/ou le prestataire de services informatiques, et les impératifs juridiques définis par l'utilisation de modules libres. Les contraintes du « libre » doivent donc être maîtrisées en amont aux niveaux techniques et juridiques pour recevoir une traduction claire en aval, au niveau commercial. Il s'agit de dire au client ce qui est possible, tant techniquement que juridiquement.

Le raisonnement adopté lors de l'élaboration du logiciel s'applique aussi à la documentation technique. Celle-ci peut-être soumise à une licence différente de celle régissant l'utilisation du logiciel(106). Une réflexion à l'égard de cette documentation est d'autant plus importante qu'il s'agit d'un domaine où les entreprises sont créatrices de valeur et qu'une mutualisation sous licence Open Source conformément à une politique clairement définie s'avère bien moins sujette à contrainte qu'une cession a posteriori ainsi que l'exigerait le droit d'auteur.

Dans sa recherche de solutions Open Source optimum, et dans sa confrontation aux jugements de centaines ou de milliers de développeurs en cas de libération de code, chacun des membres du service technique, acquiert un rôle dont la charge compensera (en partie) le temps gagné par la reprise de code tiers. Parallèlement, la responsabilité de chacun de ses membres sera d'autant plus forte que les choix techniques peuvent porter sur des logiciels aux licences complexes. Un processus simple de validation doit donc être mis en place auprès du service juridique.

Les services technique et juridique doivent travailler main dans la main, avant même le lancement du projet et jusqu'à sa délivrance.

L'intervention de l'équipe juridique est nécessaire en interne (validation des logiciels Open Source utilisés), pour la fabrication de produits matériels incluant du logiciel, pour l'édition ou l'intégration (dès l'étude de la rédaction de l'appel d'offres, du cahier des charges ou de la réponse). Ses compétences en termes de propriété intellectuelle doivent lui permettre lors de la conception du projet informatique :

• de participer au choix de la(les) licence(s) Open Source (en proposant si possible plusieurs options) et à la conception de la politique de la société en matière de propriété intellectuelle (droit d'auteur, mais aussi droit des marques, brevets et autres droits exclusifs) ;
• de répondre de la faisabilité de la solution vendue ;
• de sécuriser le cadre légal de l'usage de la solution par l'entreprise et de sa diffusion au sein de son organisation, à ses partenaires et/ou à ses clients.

Et, ce faisant, de sécuriser l'usage des droits d'auteur, des licences Open Source, du droit des marques et de tout autre droit exclusif. Par la suite, son intervention permettra aussi de sécuriser le contrat de service annexe.

Enfin, il doit sensibiliser les acteurs de la société aux enjeux de l'Open Source, publier une veille sur le sujet, s'assurer du respect des licences Open Source et de la stratégie globale en matière de propriété intellectuelle. Dans le cadre de la gouvernance (à la conception de laquelle il doit être associé), il peut être opportun de lui reconnaître un droit de veto en cas de problème détecté en matière de licences.

Le service achat doit s'assurer auprès des fournisseurs de l'entreprise que le statut des licences, des solutions et produits acquis est conforme aux attentes de l'entreprise, notamment dans la perspective d'une réutilisation de ces acquisitions au sein d'un produit qui sera lui-même vendu par l'entreprise.

Il est ainsi recommandé de prévoir un volet dans la politique d'achat concernant les règles en vigueur sur les licences Open Source (notamment les licences proscrites).

En définissant l'offre, il est nécessaire d'élaborer un argumentaire commercial sur les contributions de l'entreprise dans le domaine, sur les avantages, mais aussi sur l'impact du Logiciel Libre et des licences Open Source. Le porteur de l'offre - le commercial - devra pouvoir expliquer au client que les avantages du Logiciel Libre impliquent obligatoirement de renoncer à certaines idées préconçues (plus souvent à tort qu'à raison), comme la nécessité de disposer d'une propriété absolue sur la solution ou de bénéficier sur un Logiciel Libre des garanties commerciales habituelles des logiciels propriétaires.

Le personnel commercial devra adopter un discours objectif permettant d'écarter les principales demandes irréalisables des clients, notamment sur la propriété du logiciel. Ce point n'est d'ailleurs pas spécifique au Logiciel Libre et concerne tout autant le logiciel propriétaire (cf. supra). Plus la collaboration entre les domaines technique et juridique sera efficace, plus le discours commercial sera simplifié (transparence et sécurité).

Respectant les choix stratégiques de la société en faveur de l'Open Source, le service des ressources humaines est dans la nécessité d'adapter ses pratiques en matière de recrutement de gestion des compétences et mettre en place un plan de formation afin d'alerter, de sensibiliser et de responsabiliser les techniciens et les commerciaux. Ce choix peut notamment permettre de stimuler une équipe, rendre attractive l'embauche et remotiver les seniors. Il doit aussi permettre d'intégrer, en cours de projet, des compétences Open Source.

Par principe, un règlement intérieur (ou une charte) doit définir les règles à suivre lors du recours aux Logiciels Libres (notamment en fonction des licences Open Source, de l'objectif poursuivi…) et des moyens permettant de s'assurer de son application doivent être prévus.

Les critères de sélection et de rémunération des collaborateurs doivent être conçus de manière souple et attractive compte tenu de la forte proportion d'autodidactes (pionniers dans une filière en croissance) du domaine. Les grilles de salaires qui sont fonction des diplômes ne sont plus adaptées et il est nécessaire d'appliquer de nouveaux critères, comme l'implication dans les communautés, les projets, l'évaluation par ses homologues, etc. Pour stimuler les équipes, les compétences des salariés devront jouer un rôle majeur, tant au moment de l'embauche que pour l'évolution au sein de la société (mission, formation).

Enfin, les contrats de travail (et les documents annexes) doivent être repensés afin d'inclure les particularismes liés au développement libre et au business model des sociétés.

Responsabiliser les salariés : la réutilisation de composants tiers (sous licence libre ou propriétaire) doit être clairement encadrée par une charte annexée au contrat de travail.

• Clause de non-concurrence. La clause de non-concurrence doit être proportionnée aux intérêts tant de la société que des collaborateurs, sachant que de nombreux salariés apportent avec eux des compétences et des contributions ensuite valorisées par la société.
• Publication de logiciels. S'il est communément admis que la première publication d'un logiciel passe nécessairement par une validation hiérarchique (généralement de la direction), la question est moins simple lorsqu'il s'agit d'un Logiciel Libre, par définition constamment amélioré, et mis à disposition (parfois dans l'heure). Il est donc nécessaire d'encadrer précisément le rôle et le pouvoir des salariés en charge de cette mise à disposition, généralement les développeurs du projet en question (au sein d'une même charte annexée au contrat de travail - un compromis consiste, par exemple, à distinguer par type d'améliorations et de versions).

• Gérer les contributions des salariés. Rappelés à l'ordre par les dernières jurisprudences, les responsables des ressources humaines veillent dorénavant à compléter utilement les contrats qui ne sont pas exactement des contrats de travail (stagiaire, doctorant, dirigeant, prestataire externe, etc.) par une cession expresse de droit de propriété intellectuelle rejoignant le régime des salariés (cf. supra)(107). Néanmoins, il y a une autre difficulté : dans le domaine du logiciel plus qu'ailleurs, les salariés développeurs sont souvent amenés à contribuer dans des cadres juridiques multiples (au sein de la société qui les emploie sur des projets, chez eux dans le cadre de projets personnels ou pour des besoins professionnels, etc.). Sachant que la jurisprudence interprète toute ambiguïté en faveur des salariés, il y a lieu de s'alarmer lorsque le business model de la société repose sur la titularité des droits.

Ainsi, pour assurer la sécurité juridique de la société, ce point doit faire l'objet d'un dispositif normatif (par exemple une charte) entre la société et ses salariés. La société sera amenée à dissocier par période et par projet :

pour toute contribution fournie durant le temps de travail, il est possible d'imaginer que la société soit titulaire de droits sur toutes les contributions relatives à ses propres projets, ainsi qu'à ceux dans lesquels elle a un intérêt direct (projet du catalogue de la société, par exemple), alors qu'elle n'acquerra pas les droits sur les contributions portant sur des projets dans lesquels elle n'a pas d'intérêt direct. Les projets de la société et ceux dans lesquels elle aurait un intérêt seront clairement listés, afin d'éviter que la contribution d'un salarié dans un projet non connu mette en péril le patrimoine immatériel de la société (notamment en matière de brevet si la licence inclut une cession de brevets) ;

pour toute contribution fournie en dehors du temps de travail, il faudrait distinguer celles qui entrent dans le cadre d'une mission précise (soumises au même régime que précédemment), celles qui portent sur des projets pour lesquels la société est directement intéressée (assimilées aux contributions de mission), et les contributions qui n'intéressent pas la société, sur lesquelles le salarié conserve ses droits.

Les entreprises doivent prendre conscience des enjeux liés à la bonne appréhension du « Libre ». Il n'existe plus, ou à de rares exceptions, de logiciel 100 % propriétaire. 80 % des logiciels contiennent des composants sous licence Open Source et de plus en plus nombreux sont les ingénieurs qui, à chaque étape du développement, réutilisent des composants sous licence Open Source.

L'utilisation mal maîtrisée de code Open Source peut être à l'origine de risques pour l'entreprise, qu'elle soit fournisseur et/ou cliente. L'utilisation « sauvage » des ressources sous licences Open Source peut aisément compromettre les droits de propriété intellectuelle, notamment en ajoutant des frais de licence imprévus à la charge de l'utilisateur. Par ailleurs, le non-respect des licences pouvant être sanctionné par une action en contrefaçon, action pénale et/ou civile, il est indispensable d'encadrer ces utilisations pour limiter la responsabilité des décideurs (la simple évaluation des risques ne pouvant suffire).

Sous l'impulsion de la direction, l'entreprise doit :

• respecter les licences Open Source tout au long de son processus du développement à la vente ;
• maîtriser son code ;
• mettre en place une gouvernance ad hoc.

Référent Open Source (108)

Son rôle est d'être le « Monsieur Open Source » de l'organisation. Il aura en charge de piloter le développement de la politique globale Open Source de l'organisation (sous forme d'un manuel), ainsi que des procédures à mettre en œuvre dans les différents services pour prendre en compte les impacts de l'introduction du Logiciel Libre mentionnés plus haut dans ce document.

Il doit aider à développer un modèle de gouvernance Open Source, intégré dans la gouvernance informatique de l'organisation, dont les missions seront notamment de créer le Comité de Direction Open Source, de statuer sur l'opportunité de créer un comité de revue Open Source dans l'organisation et la formation du service juridique.

Il a aussi comme rôle la veille technologique externe (relais d'information sur le monde du Logiciel Libre vers l'intérieur de l'organisation, interface avec des communautés) et interne (inventaire des Logiciels Libres utilisés, relation avec le département juridique, propriété intellectuelle, achat, établissement d'une communauté interne, formation…).

Dans le cas d'organisations plus importantes, ce référent peut devenir une équipe complète, appelée alors Comité de Pilotage Open Source, au sein de laquelle les différentes fonctions précédentes seront réparties.

Le développement de cette fonction possède beaucoup de point commun avec le Correspondant Informatique et Libertés (CIL)(109), notamment celui d'être massivement déployé au sein du secteur privé en quelques années seulement.

Initié par le référent Open Source, ce comité doit être composé au minimum du référent Open Source, d'un représentant de la direction générale, d'un représentant du service juridique et d'un représentant des services techniques. Il est le garant du modèle de gouvernance mis en place et prend toutes les décisions dans l'organisation impliquant des Logiciels Libres et Open Source. Il se fait assister de toutes les compétences (internes ou externes) nécessaires à sa mission.

Son rôle est de valider la gouvernance globale Open Source, le manuel de politique Open Source la décrivant, ainsi que de fournir les moyens de son application.

Il établira le plan de communication interne de sa politique Open Source et veillera à la formation du personnel. Il statue sur l'utilisation interne des Logiciels Libres tant au sein de l'organisation que vis-à-vis de clients.

Il décide de la politique de participation des employés aux projets de Logiciels Libres, et pourra éventuellement proposer des avenants aux contrats de travail pour prendre en compte les spécificités apportées par l'Open Source quant à la propriété intellectuelle.

En étant le garant des risques vis-à-vis de la direction générale, il facilite l'utilisation de l'Open Source dans l'organisation pour que celle-ci en tire les meilleurs bénéfices possible.

Dans le cas où l'organisation serait amenée à redistribuer du Logiciel Libre (dans du matériel, avec du logiciel, propriétaire ou non, au travers de services), il est important de mettre en place une structure qui statue sur l'utilisation licite, vue de l'organisation, du Logiciel Libre dans le cadre de cette distribution, au cas par cas, en appliquant les directives promulguées par le Comité de Direction Open Source. Ce comité de revue doit comprendre le référent Open Source mentionné précédemment, mais aussi un juriste, formé aux problématiques des licences Open Source, un responsable technique, un responsable des ventes et éventuellement, suivant la taille de l'entreprise, un responsable propriété intellectuelle, un responsable des ressources humaines…

Ces personnes ont un rôle opérationnel et peuvent, suivant la taille de l'organisation, être les mêmes que celles du Comité de Direction.

Ce comité reçoit les propositions des équipes techniques demandant à utiliser des composants Logiciels Libres dans leur projet, statue sur le caractère licite de la proposition et autorise ou interdit le développement du projet considéré.

Ce comité statue aussi sur les requêtes d'employés quant à leur participation à des projets libres, sur leur temps libre ou leur temps de travail. Il peut adopter les outils présentés précédemment, pour faciliter le support de ses activités (gestion de flux, analyse de licences, analyse de code…). Son but peut être de créer un référentiel de Logiciels Libres précédemment inventoriés, analysés et classés en liste blanche, grise ou noire et en permettre la consultation par tout employé pour améliorer la qualité des requêtes lui étant soumises.

La mise en place d'une charte Open Source au sein de l'entreprise constitue une bonne pratique déjà observée dans plusieurs sociétés du secteur. Elle permet aux développeurs et aux juristes d'avoir la vision la plus exhaustive possible des licences Open Source utilisables pour chaque projet ou encore des compatibilités, voire des licences proscrites par le comité de direction. Elle permettra de mieux gérer la réutilisation de code en établissant clairement les règles de réutilisation au sein de l'entreprise et contribuera à l'amélioration de la collaboration entre direction, ingénieurs et juristes. Elle précise aussi les sanctions encourues en cas de non-respect volontaire.

La charte peut aussi couvrir des sujets connexes, comme la politique de l'organisation en matière de contribution et d'utilisation de Logiciel Libre, les contributions personnelles aux communautés Logiciel Libre, des modèles d'en-têtes à utiliser dans le code source produit…

Là encore, on mesure les conséquences organisationnelles.

Pour plus de détails sur les fondamentaux de la gouvernance Open Source, on se reportera avec profit à la traduction du document « Open Source Governance fundamentals » disponible sur le site FOSSBazaar.org(110).

Le choix de la licence traduit des intérêts juridiques, techniques et commerciaux. Plus contraint en cas de réutilisation de composants Open Source, le choix d'une licence Open Source suit un processus néanmoins simple à décrire :

La société doit adopter la licence la plus adaptée à son projet. L'existence de centaines de licences laisse présager un nombre tout aussi grand de situations particulières les ayant justifiées. Leur multiplicité préjudicie à leur compréhension, alors qu'il n'y a en réalité que quelques obligations qui différencient les licences les unes des autres(114) : les clauses copyleft, les clauses relatives aux usages par la communauté, les clauses relatives aux brevets, DRM, Tivoïzation(115), la langue utilisée, etc.

La société dresse donc, dans un premier temps, un état des lieux qui permet de constater que certaines licences ne peuvent pas être réutilisées en l'état en dehors de projets particuliers, que d'autres ne sont manifestement pas adaptées à ses intentions et, pour finir, que seules quelques-unes répondent en totalité ou partie à ses attentes.

La société peut encore faire le choix de la multilicence (décrite supra). On parle de multilicence lorsqu'une seule et même création est soumise à différentes licences : qu'elles soient toutes Open Source ou qu'au moins l'une d'elles le soit. Multiplier les licences Open Source peut parfois offrir des situations véritablement avantageuses : assurer une compatibilité au bénéfice de plusieurs licences, bénéficier de la renommée d'une licence, consolider la cession de droits, etc.

Exemple : le navigateur web Firefox, sous licence MPL/LGPL/GPL(116), est un très bon exemple de la souplesse qu'offrent les licences. En effet, le logiciel est construit de façon modulaire(117) et gagne à conserver une licence qui intègre ce particularisme(118). Cependant, afin de rassurer les développeurs et les communautés sur leur faculté de disposer du code pour d'autres projets, les licences LGPL et GPL s'ajoutent à la MPL. De cette façon, le Logiciel Libre Firefox dispose d'une licence qui lui permet d'être compatible avec les licences les plus populaires tout en bénéficiant des développements sous la licence la plus adaptée aux projets de Mozilla - notamment une portée réduite qui amenuise l'aspect contraignant de son copyleft(119).

Dans un second temps, une fois ce premier état des lieux réalisé, la société doit se poser un certain nombre de questions indirectement liées au projet : la licence doit-elle être connue et reconnue par les communautés ?

À l'inverse, bénéficier de l'expérience et de l'expertise déployée par une société concurrente peut justifier un tel choix.

Dans l'hypothèse où un logiciel est distribué sous une licence libre déjà connue, il peut être opportun d'ajouter une interprétation relativement aux clauses des licences Open Source. Lorsque l'un des termes de la licence est source d'interprétation, celui qui choisit la licence peut lever l'ambiguïté qu'elle pourrait engendrer en donnant une portée bien définie à cette clause.

Ainsi, il y a création d'un faisceau d'indices qui pourrait donner des indications aux juges lors d'un litige dont la résolution passe par l'interprétation de la licence. Ainsi le juge pourrait valider l'interprétation définie par l'entreprise qui recourt à la licence. De nombreuses clauses imprécises ou équivoques peuvent être interprétées de la sorte lors du choix de la licence.

L'usage des exceptions est une autre technique plus radicale qui consiste à modifier la licence de base en ajoutant, dans une clause jointe à la licence ou insérée dans les en-têtes, une spécificité qui déroge aux termes initiaux avec pour effet de rendre la licence finale plus ou moins contraignante. Il est à noter qu'en l'absence de stipulation contraire, une clause additionnelle qui ne fait « qu'ajouter des droits » pourra être supprimée par tout licencié au moment de la redistribution d'une copie du logiciel(120).

La maîtrise de plus en plus fine de la pratique contractuelle liée aux licences en Source conduit aujourd'hui à conseiller une pratique réfléchie et adaptée de ces exceptions et interprétations. Les premières confèrent plus de souplesse aux licences(121), les secondes assurent une plus grande sécurité juridique. Un bon usage de celles-ci peut permettre de prévoir et de résoudre a priori la plupart des situations préjudiciables : problèmes d'incompatibilité, failles au sein des licences, etc.

La rédaction des licences Open Source n'étant pas toujours l'œuvre de juristes et émanant de systèmes juridiques hétérogènes, on s'aperçoit que certaines clauses sont inutiles au regard des règles de droit d'un pays, alors que d'autres doivent être interprétées pour être contextualisées.

Parmi les licences Open Source et afin d'avoir une vision plus globale du système, plusieurs classifications peuvent être croisées(122).

VII-A-2-a-i. Classification classique : licence copyleft versus permissive▲

VII-A-2-a-ii. Classification historique▲

VII-A-2-a-iii. Par domaine▲

VII-A-2-a-iv. Par liberté▲

L'exemple de la GNU GPL (125)

Pour comprendre l'évolution des licences Open Source, il faut suivre l'évolution de la GNU General Public Licence. S'appliquant évidemment au logiciel et à la documentation technique l'accompagnant, la licence GPL fixe les conditions de diffusion : les logiciels sous licence GPL peuvent librement être copiés, adaptés et distribués de quelque manière que ce soit, à la seule condition de rester soumis aux mêmes termes. La question de l'interprétation de la GNU GPL v2 pose problème en ce qu'elle émane d'un système de droit anglo-saxon, mais la troisième version se détache de ce droit au profit d'une terminologie contractuelle plus conforme au droit français. L'objectif est de créer un « fonds commun auquel chacun peut ajouter, mais duquel personne ne peut retrancher », comme aime à le répéter Eben Moglen, l'avocat de la FSF et directeur de la SFLC.

• Le code source du logiciel diffusé sous licence GPL est communiqué à l'utilisateur. Mais une condition s'impose : le code source, auquel l'utilisateur a eu accès, doit être également transféré en cas de diffusion. Cet utilisateur ne saurait de sa seule initiative, et donc sans l'autorisation du créateur du logiciel, distribuer celui-ci sans son code source. En d'autres termes, il ne saurait introduire, dans la chaîne de diffusion du logiciel, une forme d'appropriation de facto en se réservant le code source. Il irait ainsi contre la volonté du premier programmeur et ne respecterait pas les termes de la licence.
• Compte tenu de la possibilité qui lui est faite d'accéder librement au code source, l'utilisateur peut modifier celui-ci, voire modifier le logiciel dans son entier. C'est ici une considérable exception apportée à l'interdiction de la décompilation traditionnelle, comme nous le verrons plus loin, interdiction visant précisément à empêcher toute modification du code source. Par contre, cette possibilité d'examen et de modification du code source implique une obligation : l'utilisateur doit préciser dans une notice les adaptations dont il est l'auteur, la date de ses apports et son identité. Chaque programmeur successif participe à l'enrichissement du logiciel, et par principe son droit au nom sera respecté.
• Un logiciel ainsi modifié peut également être distribué, mais cette nouvelle diffusion doit également respecter les stipulations de la licence GPL : elle doit être diffusée sous les mêmes termes : une fois qu'un logiciel a été cédé en vertu de ses stipulations, il est interdit de réintroduire un quelconque élément « propriétaire », c'est-à-dire qu'on ne peut se réserver le résultat d'une modification, ni la diffuser à titre onéreux, ni même introduire des portions de code faisant l'objet d'une réservation (par le brevet ou le droit d'auteur) dans les adaptations successives, dès lors que l'on distribue ces dernières.

• Cette licence se veut la plus ouverte, mais comporte bel et bien des obligations pour l'utilisateur :

  • obligation, pour toute redistribution et toute modification du logiciel initial, d'adopter la licence GPL et de la diffuser en même temps que le logiciel ;
  • obligation pour un programmeur travaillant à partir d'un Logiciel Libre cédé sous cette licence, de soumettre sa création dérivée à la licence GPL ;
  • obligation de porter à la connaissance des tiers et de tout cessionnaire le nom des programmeurs qui sont déjà intervenus sur le code source ;
  • Obligation d'informer tout cessionnaire ultérieur du logiciel ou de ses modifications des règles de la licence GPL.

Deux vagues successives (la première le 29 juin, et la seconde le 9 novembre 2007), ont respectivement donné lieu à publication des nouvelles versions(126) des GNU GPL (v3), GNU LGPL (v3) et de la GNU Affero GPL (v3) (dite aussi AGPL).

Sur la forme, les trois licences s'affichent avec une compatibilité parfaite au profit de la GNU GPL et s'offrent une modularité qui permet de faciliter leur utilisation conjointe. Si les améliorations ont pesé sur la lisibilité des licences, la FSF a fait attention à conserver leur similitude. Ainsi, la GNU LGPL apparaît finalement comme une exception à la GNU GPL (en se concentrant sur les droits supplémentaires accordés, et renvoyant à la GNU GPL pour le reste de ses termes). De même, l'Affero GPL ne se distingue de la GNU GPL que par une clause qui lui permet de s'adapter aux spécificités des logiciels voués à être utilisés via le réseau sans avoir à être distribués. Ces derniers devront alors permettre aux utilisateurs de bénéficier de la version du logiciel utilisée par ledit service, comblant ainsi ce que l'on avait dénommé l'« ASP loophole ». Enfin, un travail de rédaction a aussi permis d'internationaliser les licences et d'assurer leur validité pour l'ensemble des systèmes juridiques.

Sur le fond, les changements sont nombreux et ne peuvent qu'être listés :

• une « obligation de cohérence » interdit à l'utilisateur de limiter par d'autres voies, ou droits exclusifs concurrents, les libertés qu'il concède par la licence : que ce soit à l'égard des Mesures Techniques de Protection, des limitations matérielles (Tivoïsation) ou encore des brevets ;
• un encadrement des accords parallèles portant sur des brevets de l'article 123 de la Convention sur le brevet européen agit tant du côté du promettant (qui s'obligerait à ne pas opposer ses brevets) qu'à celui qui en bénéficierait ;
• une modularité est incorporée afin de permettre d'intégrer d'autres briques logicielles sous licence a minima libre (rendant la GNU GPL v3 compatibles notamment avec les licences LaTeX ou Apache) ;
• des adaptations technologiques (comme la distribution par peer to peer).

Garante du rôle qu'elle s'est donnée, la Free Software Foundation assure par ces mises à jour la pérennité des libertés qu'elle prône, sans aucune concession.

La question « particulière » est celle de la compatibilité des licences. Si la démarche qui précède permet de s'orienter vers le choix optimal d'une licence, celle-ci peut se révéler impossible à mettre en œuvre si le produit « final » intègre des composants soumis à d'autres licences, aux termes incompatibles lors de la distribution ou de l'utilisation du logiciel.

Il n'existe pas de facto de licences dominantes : toutes ont la même force obligatoire et le licencié doit renoncer à exploiter une création lorsqu'il ne peut pas respecter l'ensemble de ses engagements. La seule condition pour distribuer sous licence unique un projet comprenant des composants sous d'autres licences(128) est que cette distribution soit permise par l'ensemble des autres licences.

Après avoir été un frein majeur aux échanges entre projets libres pendant de longues années, le problème de l'incompatibilité entre licences semble se résorber progressivement grâce aux licences « de nouvelles générations » :

• la situation la plus commode réside en la compatibilité expresse : soit la licence prévoit que le logiciel peut indifféremment être redistribué selon ses propres termes ou selon ceux d'une licence déterminée(129), soit la compatibilité est limitée aux seules situations où l'ajout d'un composant sous une autre licence Open Source impose de redistribuer le tout sous cette unique autre licence(130) ;
• en l'absence d'une telle compatibilité, il convient de procéder à une analyse logique du contexte : l'enjeu consiste à gérer les flux de droits et d'obligations de la société pour savoir ce qu'elle peut faire ou ne pas faire : compatibilité induite. Lorsque l'on souhaite céder une contribution pour laquelle on est seulement licencié, la question se résume à s'assurer que l'on est bien en mesure de céder tous les droits que la licence confère et à veiller que l'on n'oblige pas moins l'utilisateur final que l'on est soi-même obligé(131).

La dernière version de la GNU GPL (V 3) s'appuie sur ce principe pour accueillir en son sein une modularité qui lui permet d'assurer la compatibilité à l'égard d'autres licences Open Source auparavant incompatibles(132) : en permettant, sur chaque nouvelle contribution, d'une part, l'ajout de « permissions additionnelles », et d'autre part, l'ajustement par l'utilisation de certains « termes supplétifs » limitativement autorisés. Le problème n'est néanmoins pas tout à fait résolu puisqu'il faudra ensuite confronter chaque licence aux différentes clauses, au cas par cas, afin d'être certain de leur compatibilité(133).

Cette réflexion peut se traduire mathématiquement grâce à la théorie des ensembles sous la forme qui suit(134) : la licence B est dite compatible (c'est-à-dire qu'elle peut être utilisée pour redistribuer le logiciel en respectant les termes de la licence originaire A) si et seulement si l'ensemble des droits de la licence B est inclus dans la licence A et que l'ensemble des obligations de la licence A est inclus dans la licence B. Ainsi, une licence est compatible avec elle-même, une licence copyleft n'est pas forcément compatible avec une licence permissive et une licence permissive ne l'est forcément pas à l'égard d'une licence copyleft.

Attention, la version des licences constitue dans certains cas un élément déterminant : même si la plupart permettent une compatibilité ascendante au bénéfice des nouvelles versions de la licence, certaines autorisent aussi aux auteurs de licences Open Source de figer la licence à une version spécifique(135). Il y a alors un copyleft en deux temps : le premier caractérisant l'étendue de la licence et le second déterminant la version sur chaque contribution.

La situation la plus confortable consiste à rester dans la même « famille de licences » : il en existe plusieurs et celles-ci couvrent en théorie un large panel de choix tout en assurant une compatibilité parfaite entre elles(136).

Certains conflits ne peuvent contractuellement être résolus. Si l'œuvre litigieuse s'avère trop complexe pour être réécrite, il faudra alors renoncer à la distribution ou à l'utilisation du tout(137).

Il reste néanmoins quelques autres solutions : contacter le ou les auteurs d'un composant litigieux pour leur demander une dérogation, une exception ou un changement de licence ; acheter une licence commerciale à ces derniers ; se faire céder la titularité de leurs droits(138) ou contourner matériellement le problème posé par la licence.

Le premier expédient possède l'avantage de la simplicité, mais son succès dépendra du nombre d'auteurs du composant, de leur personnalité et de ce que l'entreprise est prête à investir dans le projet. Les deux autres mesures dépendront aussi totalement de la volonté des titulaires de droits. Le dernier procédé se révèle le plus précaire puisqu'il nécessite une connaissance parfaite des licences afin d'estimer ce qui peut matériellement être permis et ce qui ne le serait pas (certaines formes de distribution(139), certains modes de distribution(140) et certaines constructions du logiciel(141) permettent, par exemple, d'alléger les contraintes).

En résumé, le processus visant à vérifier la compatibilité expresse entre une licence Open Source A (d'origine) et une licence B (licence finale) est le suivant :

• considérons que les droits ne posent pas de problème puisqu'à minima la licence A est libre ;

• Penchons-nous sur les obligations :

  1. La licence B contient toutes les obligations de la licence A - modulation des variations éventuellement tolérées par la licence,
  2. La licence A n'oblige pas à la redistribution sous une licence particulière OU elle permet expressément la redistribution sous la licence B (ou une licence qui lui soit compatible) ;
• la licence A n'oblige pas à la redistribution sous une licence particulière OU elle permet expressément la redistribution sous la licence B (ou une licence qui lui soit compatible) ;
• considérons une licence copyleft comme une licence qui a comme obligation de conserver les droits lors de la redistribution, alors : si la licence A est une licence Open Source copyleft, la licence B devra aussi être libre et copyleft.

La garantie d'éviction ou garantie de l'utilisateur en cas de contrefaçon implique l'obligation pour le concédant (éditeur, société de services, etc.) de ne pas perturber, par son fait personnel, le licencié dans la jouissance de la chose cédée et de faire en sorte qu'aucun tiers ne vienne perturber cette libre utilisation.

La garantie d'éviction est légale, en droit français. Ce qui signifie qu'elle s'applique même si elle n'est pas stipulée dans le contrat de cession. Elle consiste pour le concédant à garantir le cessionnaire (bien souvent le client) contre toute réclamation d'un tiers prétendant que le logiciel licencié/cédé porte atteinte à ses propres droits de propriété intellectuelle (notamment en cas de contrefaçon).

L'éditeur d'un logiciel est en mesure de garantir qu'il est titulaire de tous les droits de propriété intellectuelle applicables aux modules qu'il a intégré ou qu'il a obtenu les droits des tiers lui permettant d'intégrer le module à sa solution et de les redistribuer ensemble.

Lors de l'utilisation de composants Open Source, cette garantie n'est techniquement pas possible. L'ensemble des licences Open Source prévoient le transfert du logiciel « en l'état », c'est-à-dire sans garantie quelle qu'elle soit.

Un contributeur peu scrupuleux peut avoir inséré du code propriétaire, parfois protégé par un brevet, dans la solution développée. Il diffusera ce code « contrefaisant » sous licence Open Source, sans respecter le monopole d'exploitation de son auteur. Faute de pouvoir maîtriser la chaîne des contributeurs, les licences Open Source ne contiennent aucune garantie pour le licencié contre une éviction provenant d'un tiers. Dans les faits, les Logiciels Libres commercialisés sont développés par des communautés organisées par des sociétés commerciales qui encadrent ce risque.

Pour conclure, il faut admettre que les risques attachés à l'utilisation de composants Open Source sont réels. Cela dit, le risque est identique dans le modèle propriétaire. Il convient juste de le gérer(142).

Si la garantie d'éviction est légale pour être effective, encore faut-il qu'un contrat soit conclu avec un intermédiaire, assuré et responsable, telle qu'une société de services informatiques. Le risque du client est donc couvert par l'éditeur et/ou la société de services.

L'éditeur doit cette garantie légale qu'est la garantie d'éviction (par laquelle il déclare être le légitime détenteur de tous les droits de propriété intellectuelle qu'il cède par contrat).

À ce titre, l'éditeur garantit expressément au client la jouissance pleine et entière des droits qu'il a cédés aux termes du Contrat contre tout trouble, revendication, éviction ou réclamation quelconque.

« L'éditeur garantit le Client contre toutes réclamations, oppositions relatives au Produit, émanant de tout tiers invoquant la violation d'un droit quelconque cédé par le contrat, et notamment contre toute action en contrefaçon et/ou en concurrence déloyale et/ou parasitaire intentée par tout tiers. Il en supportera tous les frais et dommages-intérêts y afférents.

Dans le cas où l'interdiction d'utilisation du produit serait prononcée en conséquence d'une telle action ou résulterait d'une transaction signée avec le demandeur de l'action pour de telles réclamations, l'éditeur devra à ses frais :

• obtenir le droit pour le Client de poursuivre l'utilisation du Produit ;
• à défaut remplacer ou modifier le produit de façon à écarter ladite action, tout en conservant le même niveau de fonctionnalités, de performance et de pertinence ;
• à défaut rembourser au Client le montant total global du Contrat.

Ces dispositions survivront en principe à la résiliation ou à l'expiration du contrat, quelle qu'en soit la cause. »

La chaîne contractuelle qui lie le Licencié au(x) titulaire(s) de droits peut être de deux sortes :

• soit directe et unique lorsque les licences Open Source autorisent les sous-licences (chaque détenteur subséquent de l'œuvre se voit céder le droit de céder) ;
• soit distribuée lorsque les licences impliquent que chaque titulaire de droit cède au licencié final les droits relatifs à leur propre contribution.

Il n'y a pas de consensus sur le sujet et il est possible de trouver les deux types de licence. Par exemple, l'OSL 3.0 est clairement dans la première catégorie (chaîne unique) alors que les GNU GPL (version 2 ou 3) opèrent une distribution.

Plusieurs conséquences sont directement liées à ces enjeux :

• lorsque la licence met en place un mécanisme de sous-licence, tout membre de la chaîne peut agir en justice en cas de non-respect de la licence et, en cas de rupture de la chaîne de cession des droits, l'utilisateur final qui serait inquiété pourrait se retourner pour le tout contre chacun d'entre eux ayant cédé la partie du logiciel qui est litigieuse (à leur charge ensuite de remonter la chaîne) ;
• en l'absence de sous-licence, chaque contributeur cède les droits sur sa seule contribution sur le logiciel et, dans le cas où l'une des contributions serait contrefaisante, seul le contributeur de cette dernière pourra se faire assigner.

Les licences propriétaires contiennent fréquemment des clauses de garantie. Ces clauses sont en principe valides. Les licences Open Source quant à elles comportent souvent des clauses de non-garantie, sauf dispositions légales contraires. En effet, dans le modèle libre, et compte tenu de la pluralité des contributeurs et de la rédaction de la licence, il n'est pas possible de conférer aux clients les garanties classiques. En ce qui concerne les licences GNU, la notion est même incompatible.

Dans les cas où la licence ne contient pas de garantie, le client qui conclut un contrat de services souhaite obtenir une garantie.

Lorsque les entreprises recourent à une société de services (intégrateurs…) auxquels elles confient l'installation, le paramétrage, l'adaptation et la maintenance du logiciel, la différence entre Logiciel Libre et logiciel propriétaire s'efface.

Le niveau de garantie et de responsabilité sera alors négocié auprès de la société de services afin d'assurer la sécurité juridique et économique du projet.

Afin de pallier le risque de fork, il est possible de demander au prestataire de garantir au client un support qui réponde à la demande de ce dernier tout en restant cohérent avec le développement communautaire du logiciel.

Quelques SSLL proposent de la tierce maintenance applicative appliquée aux Logiciels Libres. Elles disposent des compétences permettant d'utiliser les outils de développement collaboratifs utilisés par les communautés et peuvent donc assurer un haut niveau de support, voire d'adaptation aux besoins spécifiques.

Plus classiquement, certaines entreprises définissent les niveaux d'anomalies et interviennent en fonction du niveau concerné.

VIII-C-1-a-i. Au niveau du processus de Build▲

VIII-C-1-a-ii. Au niveau du processus d'intégration/packaging▲

VIII-C-1-a-iii. Au niveau du processus de déploiement▲

Il s'agit ici de donner l'arborescence du contenu du support de livraison en listant les principaux répertoires, sous répertoires et fichiers, avec une description sommaire de leur contenu, de telle sorte que le client puisse raisonnablement rapidement identifier :

• les composants externes qui lui sont fournis avec la livraison et nécessaires pour le déploiement et/ou le fonctionnement de l'application (ceux-ci ayant été décrits ci-dessus) ;
• les modules livrables correspondant aux modules listés dans son contrat de licence ;
• tout ce qui concerne le déploiement, le peuplement et le paramétrage initial des bases de données ;
• des jeux de tests à dérouler après déploiement pour s'assurer que la procédure d'installation s'est déroulée normalement (que ces jeux de test soient déroulés par le prestataire ou par le client lui-même) ;
• les documentations techniques dont il aura besoin : pour le déploiement, pour l'exploitation, la maintenance, le support, etc. (par exemple : manuel utilisateur, manuel d'exploitation…).

Un certain nombre de contrats de fournitures logicielles prévoient une clause dite « de séquestre/défaillance » par laquelle le fournisseur s'engage à déposer sous séquestre les éléments nécessaires à la reprise de maîtrise en maintenance de l'application livrée par toute personne compétente, en cas de défaillance en maintenance du fournisseur initial.

Cela suppose que soit ajoutés à la liste fournie ci-dessus, un certain nombre de composants et documentations non fournis normalement à l'utilisateur, mais nécessaires à cette reprise de maîtrise en maintenance dans des conditions raisonnables.

La liste de ces éléments complémentaires peut varier en fonction des objectifs des parties, des types de déploiement ou de commercialisation. On pourra donc trouver les cas suivants (non exhaustifs) :

• commercialisation en mode SaaS/ASP ;
• collusions financières avec un leaser ;
• fourniture à un intégrateur ;
• système de preuve vis-à-vis d'une autorité de tutelle (sanitaire, sécurité, fiscale, traçabilité, objectif patrimonial) ;
• système de preuve en matière de droits d'auteur ;
• commercialisation en mode SaaS/ASP.

Ce dernier cas est également assimilable aux solutions outsourcing. En pareil cas, l'utilisateur est dépendant de son fournisseur, non seulement en ce qui concerne la maintenance évolutive, mais également toute la production (exploitation, sauvegardes, sécurité…). Dans la plupart des cas, le fournisseur utilise les services d'un « hébergeur ». En cas de besoin, l'utilisateur aura besoin d'informations et de composants complémentaires tels que :

• nom et coordonnées de l'hébergeur ;
• descriptif détaillé des composants fournis par l'hébergeur : type de machine (dédiée ou partagée), système d'exploitation (nom, niveau de version, procédure d'installation et de paramétrage), mots de passe d'accès au serveur, nature des composants spécifiques matériels et logiciels complémentaires fournis par l'hébergeur, dispositifs de sécurité, etc. ;
• procédure détaillée de déploiement et de paramétrage de l'application client sur l'environnement d'hébergement, mots de passe d'accès, de redirection de noms de domaines, etc. ;
• procédures complémentaires d'exploitation utilisées par le fournisseur (gestion de profils utilisateurs, purge des bases de données, procédures de mises à jour de l'application, etc.) ;
• systèmes de sauvegarde (miroring), localisation des back-up… ;
• plus généralement, toute information permettant au client comme au fournisseur de basculer la production sur un autre site en cas de défaillance de l'hébergeur, par exemple.

VIII-C-1-c-i. Solutions financières avec un Leaser (Société de leasing, de crédit-bail) ▲

VIII-C-1-c-ii. Fourniture à un intégrateur▲

VIII-C-1-c-iii. Système de preuve vis-à-vis d'une autorité de tutelle▲

VIII-C-1-c-iv. Système de preuve en matière de droits d'auteur▲

L'utilisation grandissante de logiciels issus de ___________ dans les nouveaux produits et services a un impact positif sur les coûts des développements, mais augmente les risques sur la propriété intellectuelle, à la fois en termes juridiques, en termes de capacité de protection des services France Télécom et de potentiel de valorisation. Dans l'objectif de favoriser l'utilisation de l'Open Source tout en maîtrisant les risques associés et en minimisant les impacts sur la propriété intellectuelle, la division R&D a défini sa politique de l'Open Source.

La mission du responsable Open Source est de piloter la mise en œuvre de cette politique dans la production et l'utilisation des logiciels à la Division R&D. Cette mission s'exerce en coopération avec la Direction de la Propriété Industrielle et Valorisation, et la Direction Juridique.

• Contribuer à décliner la politique Open Source dans le processus de production de la Division R&D. La politique Open Source doit être intégrée en amont du processus et suivie tout au long du cycle de vie du logiciel.
• Diffuser la connaissance des pratiques et des règles dans l'utilisation et la production de logiciels dans le contexte de l'Open Source, faire connaître la politique Open Source de la Division et la politique de propriété intellectuelle et leur déclinaison dans le processus.

• Apporter, en amont, un soutien aux projets dans les décisions liées à l'Open Source pour :

  • évaluer les avantages et les risques liés à l'utilisation ou la production de logiciels Open Source en termes de coût, délais, différentiation, maîtrise, solidité technique, maturité, pérennité, popularité de techniques ou d'usages, image de France Télécom, etc. ;
  • éliminer tous les risques ayant un impact négatif sur la potentialité de revenus de valorisation de brevets ou sur la capacité de protection des services de France Télécom, sur leurs distributions et les obligations attachées aux licences ;
  • instruire, en coopération avec l'ensemble des acteurs impliqués à R&D et dans le Groupe, les dossiers Open Source en prenant en compte les contextes de développement dans les projets (prototypes, produits), d'utilisation et de distribution dans le Groupe (y compris les filiales françaises ou étrangères), de protection des services de France Télécom et de valorisation externe et les obligations juridiques liées aux licences Open Source utilisées. Plus particulièrement, en cas de risque conséquent sur la valorisation de la propriété intellectuelle ou la capacité de protection de services, lancer une étude avec les Ingénieurs Brevet et solliciter le cas échéant un comité d'arbitrage.
• La politique Open Source s'appliquant également aux développements réalisés en externe, une attention particulière sera portée dans les dossiers intégrant des sous-traitances de logiciels, des relations avec des partenaires industriels, des achats « sur étagère » de composants.
• Contribuer à la recommandation des composants référencés dans le catalogue des logiciels France Télécom et à la décision de publication dans la communauté Open Source.
• Identifier des cas génériques et toutes les améliorations permettant de simplifier le processus d'instruction des dossiers Open Source en matière de propriété intellectuelle.