2.3.1.1. Service technique

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. 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.

2.3.1.2. Service juridique

Le service technique et le 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 terme 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.

2.3.1.3. Service achat

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).

2.3.1.4. Service marketing et commercial

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 le domaine technique et juridique sera efficace, plus le discours commercial sera simplifié (transparence et sécurité).

2.3.4.5. Service ressources humaines

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 séniors. 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)1. 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.

• 1. Même si l'hypothèse ne peut être développée dans ce document, les entreprises doivent veiller à récupérer, par des mécanismes a
  posteriori, les créations salariales qui, n'étant concernées par l'exception au profit des seuls logiciels, restent la propriété des auteurs salariés.

2.3.4.6. Direction générale

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 .

2.3.2.1. Référent Open Source

Son rôle est d'être le « Monsieur Open Source » de l'organisation1. 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)2, notamment celui d’être massivement déployé au sein du secteur privé en quelques années seulement.

• 1. Pour un exemple, voir l'annexe 2, la fiche de poste Open Source chez Orange.
• 2. Mis en place par la CNIL, avec le succès qu'on lui connait.

2.3.2.2. Comité de direction Open Source

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 des logiciels libres interne 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 possibles.

2.3.2.3. Comité de revue Open Source

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.

2.3.2.4. Charte Open Source de l'entreprise

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'entêtes à utiliser dans le code source produit,... Là encore, on mesure les conséquences organisationnelles. Un modèle de Charte Open source est proposé en annexe106.

2.3.2.5. Approfondissements

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 »1 disponible sur le site FOSSBazaar.org

• 1. Voir la traduction réalisée par Bruno Cornec : “ French translation of the HP document FOSS Governance Fundamentals"