2. Impacts de l'Open Source sur la gouvernance de l'entreprise

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

2.1. Impacts sur la politique commerciale et éditoriale de l'entreprise

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.

2.1.1. Le modèle « distributeur à valeur ajoutée »

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

1.< April et collectif d'auteurs, rédaction coordonnée par Jean-Noël de Galzain de la société Wallix, publié en décembre 2007
2.< Différentes formes de suppor ts existent, notamment des services équivalents à ceux offer ts par un éditeur classique. Voir 3.2.4 Garantie contractuelle et Maintenance.

2.1.2. Le modèle de la licence double et/ou décalée

(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 :

exploiter pleinement un nouveau statut d’éditeur logiciel Open Source et,
retirer des ressources de l’exploitation commerciale des produits tout en remplaçant activités de maintenance et de développement.

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 :

Talend< [6], éditeur de solutions d’intégration de données (dual License) ;
Oracle< [7], via ses rachats successifs ;
Berkeley DB, base de données sous licence de type permissif ;
MySQL< [8], éditeur de gestionnaires de bases de données (dual License) ;
Sun Microsystems< [9], précurseur dans le développement du logiciel libre (le langage informatique Java est sous licence Open Source, ainsi que son système d'exploitation OpenSolaris), est également à l’origine du projet OpenOffice.org, qui équipe aujourd’hui les principales administrations françaises. Sun a racheté MySQL et s'est récemment fait racheter par Oracle ;
Linagora, qui édite de multiples logiciels Open Source : OBM< [10], LinPKI< [11], LinShare< [12] et LinID< [13] ;
Red Hat< [14], précurseur en matière de services informatiques basés sur l’Open Source, avec par exemple sa solution JBoss JTS disponible sous licence Open Source et sous licence propriétaire.
Nokia< [15], au travers de son rachat de la société Trolltech, éditeur de la bibliothèque Qt, diffuse sa solution sous triple licence GNU GPL [16], GNU LGPL [17] et propriétaire (cette dernière solution permettant de ne pas fournir le code source [1] sur les modifications, de créer des applications propriétaires, d'avoir une mise à jour et un support préférentiels, etc.).

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

1.< April et collectif d'auteurs, rédaction coordonnée par Jean-Noël de Galzain de la société Wallix, publié en décembre 2007
2.< On retrouve notamment cet exemple avec MySQL: la même version est disponible sous les deux licences, mais le choix de la licence commerciale assure une plus grande souplesse pour celui qui souhaite intégrer intimement MySQL dans son produit avec une licence propriétaire.
3.< Par exemple Aladdin SW.

2.1.3. L'Open Cloud Computing

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 :

La première : un choix de « forcer » la collaboration et les échanges entre des acteurs industriels concurrents (avec ou sans contrat de consortium), dans la droite lignée de ce que l'on appelle coopétition12<, ou
La seconde : une contrainte liée à l'intégration d'un des nombreux composants sous une licence du type GNU [22] Affero GPL13<.

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

1.< Notamment la crise économique, les préoccupations environnementales, la progression du Logiciel Libre (qui font abandonner la simple valorisation par la rente) et l’influence du « Cloud computing ».
2.< Voir notamment Benjamin JEAN, « Cloud Computing et Open Source », intervention réalisée lors de la journée JuriTIC sur « le point
sur le droit des logiciels... jusqu’au Cloud Computing », 6 mars 2009 à Bruxelles. Plus Livre Blanc du Cloud Computing, Syntec Informatique 2010
3.< Ainsi en est-il de la majeure par tie des logiciels utilisés pour faire fonctionner le web (Apache, PHP MySQL, GNU [22]/Linux, BSD [27], etc.), l'Internet (Postfix, Bind, etc.), mais aussi les logiciels plus spécifiques au Cloud tels Hadoop, Eucalyptus, Xen, KVM, etc.

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
4.< Il convient toutefois de distinguer deux types d'utilisateurs de Cloud Computing : les professionnels qui utilisent ces services pour y ajouter leur propre valeur, et les consommateurs qui en sont les destinataires terminaux.
5.< Et ceci, quelles que soient les clauses de responsabilité prévues.
6.< Voir à ce sujet la partie 3, sur la description des licences.
7.< Ces dernières assimilant l'usage à ceux permis sans limites « dans la sphère privée » de l'utilisateur.

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.
8.< Voir la FOSS Roadmap< [31] 2020
9.< Alors que cer tains projets reçoivent leur soutien, les modifications ou améliorations appor tées au logiciel par ces dernières ne sont pas forcément reversées.
10.< D'autres licences avaient déjà intégré en leur sein ce mécanisme : l’Honest Public licence, l’Open Software License 3.0, la Reciprocal Public License 1.5, la Common Public Attribution License Version 1.0 (CPAL). L'European Union Public Licence le fait aussi depuis sa version 1.1.
11.< Sur ce sujet, voir Anne PERNY, « SAAS [18] : quelles licences open source adopter ? », mémoire de stage sous la direction de Benjamin JEAN, septembre 2009.
12.< Néologisme qui renvoie aux notions « coopération » et « compétition ».
13.< l y a aujourd'hui plus de 421 projets sur Sourceforge sous GNU AGPL [32].
14.< Cherchant par ce biais à calquer le modèle Open Source sur les services (se servant de l'architecture, de la mutualisation, du par tage et de la structure offer te par l'Open Source).
15.< Le choix d'une licence du type GNU [22] Affero GPL étant selon nous un gage de sécurité supplémentaire.

2.1.4. Le modèle de « services à valeur ajoutée »

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

1.< April et collectif d'auteurs, rédaction coordonnée par Jean-Noël de Galzain de la société Wallix, publié en décembre 2007

2.1.5. Le modèle d'intégrateur hybride

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

1.< April et collectif d'auteurs, rédaction coordonnée par Jean-Noël de Galzain de la société Wallix, publié en décembre 2007

2.2. Impacts sur la relation client

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

1.< À l'exception du Saas [18], ainsi que précisé supra.

2.2.1. L’expression des demandes

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

2.2.2. Comprendre les motivations des demandes

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

1.< À l'opposé, le choix de l'Open Source peut aussi permettre de maîtriser le cycle de vie du logiciel, sans suppor t dégradé ou montée de version forcée

2.2.2.1. La préservation du savoir-faire

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 :

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 [1]<1<.

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 [1] 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 contrainte2<. 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.

1.< Certaines licences viennent d'ailleurs préciser ce point et l'étendre : voir notamment l'ar ticle 2 de la GNU GPL [16] v3 « You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you. »
2.< Au risque de la création d'un fork [36] si le projet est ensuite maintenu par une autre société et dans un autre sens.

2.2.2.2. Autonomie vis-à-vis du fournisseur

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.

1.< S’ajoute le cas échéant la maintenance évolutive.
2.< Option complémentaire : Il est possible de proposer au client que la version initiale comme toute version majeure qui lui sera livrée soit entièrement produite à par tir des seules sources contenues dans le séquestre. Il aura alors l'assurance de la parfaite symétrie entre les « sources séquestrées » et la version déployée. Et ceci est valable aussi bien pour du Logiciel Libre que pour du code propriétaire dans la mesure ou il n’y a pas de transfer t de propriété. En ce qui concerne le Logiciel Libre, cela permet également d'identifier clairement l'état technique des Logiciels Libres que le fournisseur aura intégrés dans sa livraison et qu'il aura testés et validés en conséquence.

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.
3.< Aussi appelé SLA [38] pour Service Level Agreement.
4.< DRP en anglais, pour Disaster Recovery Plan.
5.< Voir supra : Open Source et Cloud Computing.
6.< Et pour être efficace, le client devra former en permanence ses équipes, tant pour la livraison initiale que pour les mises à jour et développements additionnels, ce qui est très coûteux. Il perdrait ainsi les avantages financiers d’une externalisation et d’une mutualisation des coûts, son fournisseur pouvant répar tir ces coûts sur tous ses clients, à l'exception des composants spécifiques qui pourront faire l’objet d’un traitement contractuel par ticulier.

2.3.Impacts sur l'organisation des services de l'entreprise

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.

2.3.1. Impacts sur les services existants

2.3.1.1. Service technique

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 :

À 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 [37]. 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 [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.

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

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 [37]. 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 [5]).
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 [37]. 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 [39] ad hoc .

2.3.2. Évolution organisationnelle recommandée

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.

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

1.< Pour un exemple, voir l'annexe 2, la fiche de poste Open Source chez Orange.
2.< Mis en place par la CNIL [41], 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 [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.

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 [1] 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 [39] 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< [42]"

2.3.3. Relations avec la communauté Open Source

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 :

Quelle visibilité extérieure est donnée quant à l'utilisation d'un logiciel libre donné1<? Autorise-t-on les utilisateurs internes de la société à discuter ouvertement des problèmes rencontrés ? Il est important de ne pas abuser des ressources en temps et en moyens mis en place par les projets et de se conformer à leurs us et coutumes respectifs, qui peuvent fortement varier d'un projet à l'autre.
Quelles adaptations doivent être faites sur le logiciel et pour quels bénéfices par rapport à la communauté existante ? Des modifications génériques et non différenciatrices ont tout intérêt à être reversées à la communauté, pour répartir la charge de maintenance et faire un apport en retour de l'utilisation faite du logiciel. La question devra être étudiée plus sérieusement quand il s'agit de modifications soit plus importantes, soit non génériques et qui pourraient être rejetées par la communauté ou porter préjudice la à société2<. Le conseil, en général, est de maximiser les reversements pour entretenir une bonne image d'une part, et répartir la charge et réduire les coûts de maintenance d'autre part.
Quelle politique de contribution adopte l'entreprise ? Quel retour l'entreprise compte-t-elle faire à la communauté? Est-ce pris en compte dans son plan et budget marketing ? Même si aucune modification de code n'est effectuée, une contribution sous forme de documentation [4] ou de « bonnes pratiques » est généralement fortement appréciée des projets. De même un empaquetage, une traduction, des jeux de tests, toutes contributions externes, qui donnent de plus une excellente image de l'organisation, sont recommandés. Si des modifications de code ont lieu, il peut être opportun d'opter pour une politique globale de reversement au sein de l'entreprise et de réfléchir à la propriété intellectuelle associée en particulier dans le cas de licences telles que la GNU GPL [16] v3.
Quel engagement à long terme par rapport au projet ? Si le projet est capital par rapport à la stratégie commerciale de la société, il faut considérer la possibilité d'allouer des ressources de l'organisation (temps humain, moyens matériels) au bénéfice du projet. Cette implication permettra une meilleure prise en compte des aspirations de chaque contributeur quant à l'évolution du projet et donc une meilleure adéquation dans le temps de celui-ci avec son utilisation.

D'une manière plus générale, deux écueils sont à considérer dans ce type d'interaction avec une communauté :

la commercialisation du projet en tournant le dos à la communauté,
la création d'une version spécifique (fork [36] ) du projet d'origine.

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.

1.< Ne serait-ce que par la par ticipation aux listes de discussion avec une adresse professionnelle ou privée.
2.< Cet aspect dépend notamment de la licence et du fait qu'il y ait ou non redistribution.
3.< Voir notamment : Karl FOGEL, « Producing Open Source Software, How to Run a Successful Free Software Project » – une traduction quasiment terminée est disponible sur le site de l'équipe Framalang.