Une première étude de l'impact sur les services existants amène à recommander une évolution organisationnelle au sein de structures éditrices ou utilisatrices de Logiciel Libre.
Une gestion plus stricte des projets informatiques s’impose (cf [1]. supra) et les considérations développées dans ce document sur les licences des logiciels s'appliquent donc également :
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é :
Le raisonnement adopté lors de l’élaboration du logiciel s’applique aussi à la documentation [2] 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 [2] 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.
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 :
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 [3] (à 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 [1]. supra). Plus la collaboration entre le domaine 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 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.
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 :
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 :
Pour toute interaction considérée avec le logiciel libre et l'entreprise, il est capital de mettre en place une structure et des règles qui vont permettre à l'organisation de tirer le maximum de son utilisation du logiciel libre, tout en contrôlant les risques potentiels associés.
Pour ce faire, il est indispensable de mettre en place au sein de l'organisation une structure, rattachée à la direction générale, et ayant son soutien, en charge de toutes les interactions, de la politique globale de l'organisation vis-à-vis du Logiciel Libre et du contrôle de son application. Suivant la taille de l'entreprise, la variété de son utilisation des logiciels libres, une structure adaptée devra être mise en place. Au minimum, il est recommandé d'avoir un référent Open Source.
À l'instar de l'aspect modulaire de nombreux logiciels libres, il est possible de penser cette organisation en « différentes missions », afin que celles-ci puissent ensuite assurer la charge d'une ou plusieurs structures.
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 [3] Open Source, intégré dans la gouvernance [3] 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 [5])2<, 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 [3] 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 [3] 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.
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'entêtes à utiliser dans le code source [7] produit,... Là encore, on mesure les conséquences organisationnelles. Un modèle de Charte Open source est proposé en annexe106.
Pour plus de détails sur les fondamentaux de la gouvernance [3] Open Source, on se reportera avec profit à la traduction du document « Open Source Governance fundamentals »1< disponible sur le site FOSSBazaar.org
Les communautés Open Source sont des groupements de personne (physique ou morale) qui partagent un intérêt et un sens d'appartenance communs à un projet Open Source, et qui concourent à sa réalisation.
Lorsqu'une organisation souhaite se constituer en communauté autour d'un projet qu'elle édite ou se rapprocher de la communauté d'un projet Open Source qu'elle déploie, une position claire vis-à-vis de ces communautés doit être décidée et suivie.
Ainsi, il est important pour une organisation qui souhaite utiliser des logiciels libres de se poser la question de ses relations avec les communautés qui développent ces logiciels. Ceci sous plusieurs angles :
D'une manière plus générale, deux écueils sont à considérer dans ce type d'interaction avec une communauté :
Dans le premier cas, la communauté risque d’ignorer le projet si son aide est finalement nécessaire ; dans le second, les principaux avantages (qui sont la maintenance du projet par la communauté, l'évolution, etc.) sont supprimés et
cela revient à se positionner comme éditeur classique sur un logiciel Open Source mal connu (avec tous les investissements en terme de maintenance que cela peut générer).
La création d'une communauté Open Source est un projet ambitieux et nécessite un investissement non négligeable aux retours souvent aléatoires : cela revient à partager les outils qui permettront éventuellement à un concurrent de distribuer ce logiciel, mais cela permet aussi d'étendre la diffusion du logiciel (notamment grâce aux travaux de traduction, de documentation [2] et de support que la communauté peut facilement prendre en charge) et éventuellement ses fonctionnalités (le choix de la licence est ici fondamental). Enfin, l'éditeur qui souhaite développer sa communauté doit adopter un certain nombre de principes qu'il est ici difficile de détailler3<: ne réaliser aucune discrimination entre les contributeurs salariés et bénévoles, adopter une transparence maximale sur la feuille de route du projet et de la prise de décisions.
Liens:
[1] http://guideopensource.info/glossary/term/26
[2] http://guideopensource.info/glossary/term/6
[3] http://guideopensource.info/glossary/term/9
[4] http://guideopensource.info/glossary/term/14
[5] http://guideopensource.info/glossary/term/23
[6] http://guideopensource.info/glossary/term/24
[7] http://guideopensource.info/glossary/term/4
[8] https://fossbazaar.org/content/french-translation-hp-document-foss-governance-fundamentals
[9] http://guideopensource.info/glossary/term/33
[10] http://guideopensource.info/glossary/term/8