Ce chapitre décrit de manière globale les business model Open Source et leur impact sur l’écosystème de l’entreprise.
Après avoir défini son business model (2.1.), l’entreprise affinera son discours pour répondre aux principales préoccupations du client (2.2.).
Les bonnes pratiques organisationnelles internes aux entreprises, liées à la réalisation et/ou l’utilisation des solutions informatiques comprenant des composants libres, feront l’objet d’un développement (2.3.).
Le logiciel libre bouleverse les conceptions classiques du modèle industriel des éditeurs. Ainsi la gestion de la propriété intellectuelle ne doit plus être pensée uniquement en termes d'interdiction, mais aussi en termes d'autorisation – la gageure étant pour les sociétés d'ouvrir tout en conservant le contrôle.
Dès lors que l’éditeur ouvre et diffuse le code source [1] de ses produits gratuitement, il ne peut plus compter sur les redevances de licences pour rentabiliser les travaux de Recherche & Développement effectués en amont. En outre, et à l’évidence, l’éditeur perd l’avantage concurrentiel que constituent la confidentialité et le secret d’affaires.
Il doit affiner l’usage qu’il entend faire des droits de propriété intellectuelle et prendre l’avantage sur d’autres axes de compétition, ce qui revient à modifier son « business model ». Cette évolution se traduit par la mise en place d'une politique en matière de propriété intellectuelle (permettant de dissocier, mais aussi de rendre cohérente, la gestion des différents droits de propriété intellectuelle : droit des marques, brevets, droits d'auteur, etc.).
L'Open Source n'est donc pas un business model en soi, mais une combinaison de différents modèles existant.
(Ce passage est tiré du "Livre blanc sur les modèles économiques du logiciel libre< [2]"1<, disponible sous GNU FDL [3] 1.3 uniquement).
Les Logiciels Libres sont généralement des applications fortement paramétrables, auxquelles sont associés des modules librement réutilisables, modifiables, personnalisables, en fonction des besoins de chaque utilisateur. Ce caractère « protéiforme » des applications proposées et des licences liées engendre une valorisation inéluctable des services associés, tendance encore renforcée par l'amélioration des outils (gestion de projets, méthodes de collaboration innovantes entre le client et le prestataire, supervision et pilotage, etc.). Cela conduit à concilier innovation, standardisation, distribution et personnalisation spécifique. D'où la spécialisation progressive des sociétés du secteur en faveur de modèles hybrides d'édition de logiciel, de distribution et d'intégration spécifique, très orientés
vers une économie de services.
Lors de l'achat de logiciels propriétaires, le client paie généralement un premier prix pour utiliser le logiciel, un second prix pour les services de maintenance (pour une durée déterminée et renouvelable) ainsi qu'un troisième prix pour le paramétrage du logiciel.
Parallèlement, lors de l'acquisition de Logiciels Libres auprès d'un distributeur, l'utilisateur a souvent le choix entre télécharger son produit ou acheter un support physique (incluant le média et la documentation [4]). C’est alors un abonnement à une prestation récurrente de maintenance et d'assistance qui permet d'accéder au système automatique de mises à jour, ainsi qu'aux services variés tels que l'assistance technique ou la formation. L'utilisateur est donc libre de consommer les services proposés, selon ses besoins, auprès du prestataire le plus compétitif. Les sociétés génèrent donc leurs revenus à partir de la vente des supports physiques du logiciel, et/ou surtout de la commercialisation de services à valeur ajoutée tels que formation, support technique et assistance2<.
(Ce passage est tiré du "Livre blanc sur les modèles économiques du logiciel libre< [2]"1<, disponible sous GNU FDL [3] 1.3 uniquement).
Cette pratique, de plus en plus répandue, consiste à exploiter un même logiciel sous deux types de licences (il est donc possible d'en jouir selon l'une ou l'autre des licences) et de proposer diverses options et services connexes. Ce modèle est adopté à la fois par des éditeurs classiques qui révolutionnent leur modèle économique (Ingres, Sun) et des éditeurs 100% Open Source (MySQL, TrollTech, etc.).
De plus en plus d’éditeurs adoptent une politique de doubles licences (ou dual licensing ). Le but est double :
Les éditeurs proposent de publier pour la Communauté une version standardisée et stabilisée de leur offre, afin de prendre position sur leur marché, et continuent d'investir sur de nouvelles versions [5] vendues sous forme d'offres additionnelles ou de maintenance autour de leur noyau de base. En parallèle, ces éditeurs proposent une offre
supérieure ou équivalente2< en fonctionnalités aux clients demandeurs, sur la base d'une tarification traditionnelle, selon une autre licence (mixte ou propriétaire). Le principal effet vertueux de ce modèle consiste à imposer peu à peu sur le marché un standard technique par ouverture systématique de son code source [1], ce qui augmente l'accessibilité du client et le prototypage potentiel. La rémunération de l’éditeur est acquise via les services connexes et celui-ci assure le pilotage du projet Open Source.
Les éditeurs et prestataires les plus connus sur le marché des logiciels libres ont d’ores et déjà adopté une politique de dual licensing :
Ces éditeurs distinguent une version « communautaire », soumise à une licence Open Source et une version « entreprise », soumise à une licence propriétaire classique – les deux versions [5] étant généralement identiques. Mais attention seul un éditeur qui détient l'intégralité des droits de propriété intellectuelle sur son produit est en mesure d’adopter ainsi des licences distributives sur les produits qu’il développe.
Une variante (le modèle à licence décalée) consiste pour l’éditeur, sur un principe équivalent, à ne facturer que les versions [5] récentes de ses logiciels (6 à 12 mois) et ensuite à les publier sous licence Open Source dès commercialisation d'une nouvelle version majeure. Le client standard de l’éditeur ne paie ainsi que pour l'innovation fonctionnelle et technique, et éventuellement pour le support, tandis que l’éditeur oriente son modèle économique vers davantage de services (maintenance logicielle, support revendeur, assistance utilisateur) et de vente de modules additionnels3<.
Le modèle SaaS [18] (Software as a Service) existe depuis plusieurs années maintenant et le contexte économique actuel1< est particulièrement favorable à son développement – voire à son extension2<. Derrière les différents termes couvrant le Cloud Computing (Infrastructure as a Service, Platform as a Service, Software as a service, Pay per use, On demand , etc.), il y a une idée commune, un concept fédérateur : celui de ressources informatiques disponibles à la demande et facturées uniquement en fonction de leur utilisation. Ces ressources peuvent être des services, des applications, des plates-formes applicatives permettant d'héberger les applications des entreprises, du stockage, de la CPU [19] ou de l’infrastructure réseau, voire un mélange de l'ensemble. Même si le recours aux logiciels sous licence Open Source, sans frais de licence et fournis en mode Cloud , tend à se développer3<, les services prennent bien souvent le pas sur ceux-ci (les logiciels étant accessoires et substituables)4<.
Dans ce contexte, aux problèmes classiques posés par le Cloud (dépendance vis-à-vis du fournisseur, sensibilité des données hébergées, aucune maitrise sur la pérennité et stabilité des services5<), s'ajoutent ceux liés à l'impact du Cloud Computing sur les Logiciels Libres. Ainsi, en l'absence de distribution des Logiciels Libres6<, la majeure partie des licences (même copyleft ) n'imposent aucune communication des codes sources des logiciels lors de leur utilisation sous forme de service7<. En effet, la mise à disposition d'un service sur le web ne nécessite pas l'installation d'un logiciel par l'utilisateur final. Dès lors qu'il n'y a pas distribution de logiciel, les droits et devoirs des licences ne s'imposent pas. Il s'agit ainsi de problématiques similaires à celles rencontrées avec les logiciels propriétaires, puisqu'il y a une possibilité de rendre « indisponible » le code source [1] du logiciel délivrant le service.
D'où la question : « le Logiciel Libre est-il soluble dans le Cloud ? »8< car de nombreuses sociétés proposent des services sur Internet qui reposent sur des Logiciels Libres en adoptant une position plus ou moins ambiguë vis-à-vis de l'Open Source9<. Devant la lacune des licences traditionnelles, dénommée « ASP [20] Loophole ». Littéralement « Faille ASP [20] ». Voir à ce sujet « GNU Af fero GPL version 3 and the " ASP loophole" »< [21] », une série de nouvelles licences10< – la licence GNU [22] Affero GPL en tête – fait en sorte que le licencié qui utilise un logiciel pour fournir un service à des utilisateurs via le réseau ne puisse le faire sans redistribuer les modifications qu’il aura apportées à ce logiciel11<.
Deux raisons semblent pouvoir motiver le choix de ces licences :
Parallèlement et réaffirmant la liberté de l'utilisateur, un certain nombre de sociétés essaient de casser le modèle actuel grâce à l'Open Source14<: en utilisant la version communautaire de leur Logiciel Libre15< pour leur service et en donnant aux utilisateurs la possibilité d'exporter le code, le thème et les données sur une autre instanciation (mutualisée ou dédiée) de ce même logiciel (c'est notamment le choix réalisé par la société Acquia, à l'origine du CMS Drupal, avec son offre « Drupal Garden< [23] »). Il n'y a donc aucun blocage au détriment de l'utilisateur, ce qui s'avère intéressant pour le projet Open Source, les utilisateurs et les sociétés qui se greffent sur le modèle : les Logiciels Libres offrent la faculté de déployer pour soi et chez soi une nouvelle instanciation d'un logiciel auparavant utilisé comme service, afin de maintenir une indépendance vis-à-vis d'un fournisseur, un contrôle sur ses services et une confidentialité quant à ses données.
Les enjeux dépassent les simples droits de propriété intellectuelle : la vie privée et les données personnelles sont impactées ainsi que les données libres, l'interopérabilité et la standardisation. C'est ce constat qui a motivé la création d'initiatives, telles que l'Open Cloud Consortium< [24], l'Open Cloud Manifesto< [25] ou TIOLive< [26]. Et bien qu'aucune de ces initiatives n'arrive à fédérer les efforts, voire à faire émerger des standards, elles convergent vers un même but retrouver dans le monde du Cloud les mêmes qualités que celles que nous trouvons dans le monde Open Source (l'absence de barrière d'entrée et de sortie, l'absence de discrimination, l'interopérabilité, la neutralité technologique et la transparence).
Voir notamment l’édition 2009 du Baromètre « Atouts & Bénéfices du modèle SaaS [18]/on demand », réalisée par le Cabinet Markess International, janvier 2009. Voir : www.markess.fr< [28].
Voir également : http://developers.facebook.com/opensource.php< [29] et http://blog.twitter.com/2008/01/twitters-starling-released-as-< [30]
open.html
L’explication est simple : 1) L’utilisateur accède via son navigateur au site du licencié ; 2) à sa demande, une requête est envoyée au licencié ; 3) Celui-ci traitera cette requête en interne sur ces propres PC hébergeant le logiciel (et donc le service). Ainsi, le licencié enverra la réponse sans jamais avoir distribué le logiciel.
Il faut néanmoins reconnaître que cer tains logiciels (tel le code javascript récupéré dans le navigateur, AJAX, etc.) interagissent directement avec l'utilisateur.
(Ce passage est tiré du "Livre blanc sur les modèles économiques du logiciel libre< [2]"1<, disponible sous GNU FDL [3] 1.3 uniquement).
Il s'agit ici des équivalents Open Source des SSII [33] : leurs métiers consistent principalement à l'intégration, la maintenance, le paramétrage, etc., de Logiciels Libres et à l'accompagnement des clients dans cette intégration.
On parle généralement de SSLL [34] (« sociétés spécialisées en logiciels libres ») pour les sociétés spécialisées dans l'intégration et les services autour des logiciels libres, mais les éditeurs de Logiciels Libres ont eux-mêmes fréquemment une offre de ce type (Red Hat, Novell, etc.) et les grands intégrateurs commencent à développer en interne des compétences similaires (même s'ils dépendent fréquemment des compétences fournies par les SSLL [34]).
(Ce passage est tiré du "Livre blanc sur les modèles économiques du logiciel libre< [2]"1<, disponible sous GNU FDL [3] 1.3 uniquement).
On entend par « hybride » le fait de fédérer des offres « produits » et des offres « services » au sein d'un prestataire unique positionné soit sur un axe métier (par exemple la sécurité), soit sur l'axe du système d'information global de l'entreprise (par exemple le système d'information d'une collectivité locale, d'une filiale ou division d'une entreprise du CAC 40) en garantissant au client la cohérence et la pérennité de l'ensemble. Il s’agit là du développement de structures concurrentes des intégrateurs traditionnels (Capgemini, Atos Origin, Steria...).
Les modèles doubles ou hybrides connaissent une croissance forte depuis quelques années et cette croissance se confirme pour les années à venir. Le marché connait une grande prolifération d’acteurs de petite taille, éditeurs pratiquant le dual licensing et SSLL [34] avec des outils libres notamment qui suivent des stratégies de niche. Mais surtout, le Logiciel Libre passe d’un marché émergent à un marché d’expansion (tous les aspects d’un système d’information, toutes les activités impliquant des ressources logicielles) et de maturation (avec la consolidation des modèles économiques en question).
Les business model construits autour de Logiciels Libres, dans la mesure où ils comprennent l’accès au code source [1] et à l'exploitation du logiciel, modifient la relation client1<.
Le Logiciel Libre permet de répondre à certaines demandes du client, demandes relatives à la pérennité de son système d’information et à l’indépendance vis-à-vis d’un fournisseur. Néanmoins, un véritable travail d'explication et de sensibilisation est nécessaire pour tempérer certaines demandes inadaptées (tirées de l’expérience passée de certains clients), et rechercher la solution optimale pour tous.
L'enjeu est ici de permettre au client d'évaluer l'impact potentiel d'une utilisation de l'Open Source en lieu et place d'un composant [35] traditionnel. Même si l’impact peut s’avérer moindre que ce à quoi le client s’attend, il n’est pas dénué d'effet).
Les clients demandent souvent à disposer des « sources » (comprendre le code source [1]) ou bien encore à se voir attribuer l'ensemble des droits patrimoniaux attachés au logiciel.
Dans la logique propriétaire, l’éditeur titulaire des droits d’auteur ne donnera que très rarement accès au code source [1] et le compromis réside souvent dans la mise sous séquestre de ce code source [1]. La question est résolue d’office en
matière de Logiciel libre puisque chaque utilisateur se voit transférer un logiciel, avec son code source [1] et la liberté (notamment) de le modifier.
Pour autant, il est impératif de connaître les motivations des clients afin de leur fournir la meilleure réponse et la meilleure solution technique. Ainsi, il ne suffira pas d’avoir accès au code source [1] ou d’être cessionnaire des droits pour assurer la pérennité du système si tel est l'objectif. Encore faudra-t-il être en mesure d’assurer la continuité.
Pourquoi le client demande-t-il à être propriétaire des « sources » ou au moins à en disposer ?
De façon classique, les demandes relatives au code source [1] ou à la propriété intellectuelle sont souvent animées par un souci d’ordre sécuritaire, d’assurer la pérennité des systèmes. Ces demandes seront d'autant plus insistantes que l'enjeu est lourd pour le client et que le risque de défaillance du projet est susceptible d'avoir des répercussions importantes sur le fonctionnement de l'entreprise. On ne peut blâmer un client préoccupé de savoir comment fonctionne (et fonctionnera) son logiciel. Le logiciel est un outil clé de l’entreprise, il fait tourner les ordinateurs, les téléphones et de nombreux appareils. Pour autant, disposer du code source [1] ou des droits de propriété intellectuelle permet-il d’atteindre l’objectif fixé ?
Il est nécessaire de rappeler au client que le transfert de propriété implique également transfert des droits et devoirs attachés à cette propriété. Ainsi, le client n'aura plus nécessairement intérêt à rester propriétaire de l'application : en adoptant un logiciel propriétaire, il bénéficiera d'une maintenance évolutive mutualisée par la SSII [33] pour tous les utilisateurs concernés ; en optant pour un Logiciel Libre, il aura accès, en plus de la maintenance évolutive mutualisée par une SSLL [34]<1<, aux évolutions et améliorations apportées par la communauté (directement ou par le biais de son prestataire).
Autre explication : 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 :
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 :
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étrage1<. 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 [37]. 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 production2<.
En matière d'Outsourcing et de mutualisation des plates-formes de production (ASP [20] SaaS [18]), les enjeux concernent principalement les services (en matière de Contrat de Niveau de Service3< et de Plan de Reprise d’Activité4<). 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 usages5<.
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 [35] 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'information6<. Le client doit mesurer l’intérêt de disposer des « sources » à l’aune de ses objectifs.
Cette solution permet également d'identifier clairement l'état du patrimoine concerné en cas de litige et notamment en cas d'intervention simultanée sur le fonctionnement du logiciel de la par t du client comme du fournisseur. Par exemple, état des structures des bases de données, paramétrages...
Ne disposant pas des sources, l'utilisateur ne peut être mis en cause dans ce type de cas. De même, le prestataire sera assuré qu'aucune intervention intempestive ne sera effectuée par l'utilisateur, mettant en cause le bon fonctionnement de l'application.
Le séquestre pourra également recevoir un cer tain nombre de documents, procédures, composants qui ne sont généralement pas fournis au client, mais dont la disponibilité est impor tante en matière de reprise de maîtrise de l'application : règles internes de développement et de nommage, copie des bases de source, dossiers d'architectures, procédures automatisées de mise à jour et de maintenance, etc.
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 [37]. 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 [4] 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 [4] 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 [39] (à 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 [37]. 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 [39] Open Source, intégré dans la gouvernance [39] 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 [40])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 [39] 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 [39] 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 [1] 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 [39] 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 [4] 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/4
[2] http://www.april.org/articles/livres-blancs/modeles-economiques-logiciel-libre
[3] http://guideopensource.info/glossary/term/34
[4] http://guideopensource.info/glossary/term/6
[5] http://guideopensource.info/glossary/term/14
[6] http://fr.talend.com/products-data-integration/matrix.php
[7] http://www.oracle.com/technology/software/products/berkeley-db/htdocs/oslicense.html
[8] http://dev.mysql.com/downloads/
[9] http://fr.sun.com/practice/software/solaris/get.jsp
[10] http://obm.org/doku.php
[11] http://www.linpki.org/
[12] http://linshare.org/
[13] http://www.linid.org/
[14] http://www.redhat.com/software/rhelorfedora/
[15] http://qt.nokia.com/products/licensing
[16] http://guideopensource.info/glossary/term/33
[17] http://guideopensource.info/glossary/term/35
[18] http://guideopensource.info/glossary/term/62
[19] http://guideopensource.info/glossary/term/25
[20] http://guideopensource.info/glossary/term/16
[21] http://www.opensource.org/node/152
[22] http://guideopensource.info/glossary/term/31
[23] http://www.drupalgardens.com/
[24] http://www.opencloudconsor tium.org/
[25] http://www.opencloudmanifesto.org/
[26] http://tio.ffii.org/
[27] http://guideopensource.info/glossary/term/17
[28] http://www.markess.fr
[29] http://developers.facebook.com/opensource.php
[30] http://blog.twitter.com/2008/01/twitters-starling-released-as-
[31] http://www.2020flossroadmap.org/roadmap/head-in-the-clouds/#head
[32] http://guideopensource.info/glossary/term/32
[33] http://guideopensource.info/glossary/term/65
[34] http://guideopensource.info/glossary/term/66
[35] http://guideopensource.info/glossary/term/3
[36] http://guideopensource.info/glossary/term/8
[37] http://guideopensource.info/glossary/term/26
[38] http://guideopensource.info/glossary/term/64
[39] http://guideopensource.info/glossary/term/9
[40] http://guideopensource.info/glossary/term/23
[41] http://guideopensource.info/glossary/term/24
[42] https://fossbazaar.org/content/french-translation-hp-document-foss-governance-fundamentals