Navigation – Plan du site
Stratégies

Récupération ou hybridation

Quel marché pour le logiciel libre ?
Marie Coris

Résumé

Dans cet article, nous analysons certaines formes de rencontres marchandes possibles entre les communautés de développeurs de logiciels libres et les acteurs économiques. Il s’agit de questionner l’intérêt des industriels à “faire” du logiciel libre au regard des projets portés par ces communautés. Deux formes concrètement observables de l’hybridation sont alors successivement étudiées : celle des “licences hybrides” perçues sous l’angle de la “récupération” marchande du phénomène et celle des consortiums ouverts laissant entrevoir une coopération véritable entre firmes et communautés autour des questions de standardisation du logiciel.

Haut de page

Entrées d’index

Mots-clés :

logiciels libres, marché

Keywords :

free software, market
Haut de page

Texte intégral

1Parce que les logiciels libres sont bénévolement produits par les communautés de développeurs, les chercheurs en sciences sociales, et notamment les économistes, ont consacré un nombre conséquent de publications à l’analyse des motivations à contribuer à leur production1. Aujourd’hui, c’est plus la question des formes d’hybridation entre la sphère communautaire de production de ces logiciels et la sphère marchande qui se pose à l’analyste. En effet, les logiciels libres ont largement débordé du cadre des communautés pour se diffuser auprès d’un nombre croissant d’utilisateurs, d’abord informaticiens puis non-informaticiens.

  • 2 Pour une analyse du devenir du logiciel libre menée du « côté de la demande », voir Jullien et Zimm (...)
  • 3 La Licence GPL (GNU General Public License) est la principale licence de logiciel. Nous la présento (...)

2À l’exception de Microsoft, rares sont les industriels de l’informatique qui n’intègrent pas aujourd’hui les logiciels libres les plus réputés dans leur offre, tels Linux, Apache, MySQL et PHP. Que dire de l’évolution des logiciels libres quand sont introduits des intérêts commerciaux ? Leur diffusion croissante témoigne de leur viabilité marchande. En cela, rien de très novateur : la production non marchande a toujours représenté une part non négligeable de la production globale de logiciels et il n’est guère surprenant de constater l’intérêt des acteurs marchands pour la réalisation de bénéfices privés fondés sur la récupération d’efforts de développement auxquels ils n’ont pas contribué (Zimmermann, 2003). Cependant, n’est démontrée ici que la viabilité des logiciels en tant que produits2. Or, les communautés ne proposent pas simplement des logiciels. Elles sont porteuses d’une alternative pour l’industrie (Stallman, 1984 ; Coris 2006a), l’alternative libre, qui s’exprime en deux temps : 1) le logiciel doit être libre au sens de la licence GPL3 et 2) cette acception particulière de ce que doit être un logiciel n’est pas contradictoire avec le capitalisme puisqu’elle permet la génération de la valeur ajoutée par la vente de services liés. C’est la question de la réalisation ou de la condamnation de cette alternative qui interroge l’observateur du phénomène.

3Une première rencontre envisageable entre les logiciels libres et le marché est celle de l’alternative pure, c’est-à-dire de la tentative de valorisation marchande émanant directement des communautés. À la question “y a-t-il une place dans l’industrie pour un modèle alternatif issu d’une logique purement communautaire ?” plusieurs contributions ont répondu que seules semblent se justifier des activités d’”éditeurs” de logiciels libres, d’abord de Linux (RedHat, Mandrake…) puis d’un ensemble de logiciels, consistant à transformer le travail des communautés en un produit commercial répondant aux besoins des utilisateurs non-experts et à fournir les services d’expertise et de support nécessaires à leur déploiement dans divers environnements de travail (Coris, 2006b ; Genthon et Phan, 1999…).

4Posons-nous ici la question de l’intérêt des industriels à “faire” du logiciel libre, c’est-à-dire à participer à leur développement. Et pour y répondre, appuyons-nous sur les formes concrètement observables de l’hybridation de ces deux sphères. Nous envisagerons d’abord (section 2) le cas de la mise sous licence “ouverte” des logiciels produits par la firme. Nous verrons alors comment les firmes récupèrent le phénomène. Nous considérerons ensuite (section 3) le cas des consortiums ouverts, formes d’hybridation des deux logiques conciliant les deux types d’intérêts en présence.

5Partant du cas de Linux autour duquel s’est créée une véritable coopération entre communautés et acteurs marchands pour favoriser la standardisation autour du système d’exploitation, nous verrons que ces formes de coopération concernent aussi des projets non plus initiés par les communautés auxquels les firmes prennent part, mais initiés par les industriels eux-mêmes et sur lesquels ils détiennent des droits de propriété intellectuelle. Parce que les formes d’hybridation s’expriment au travers des contrats de licences de logiciels, faisons dans un premier un détour par la présentation des composantes de ces contrats (section I) qui sera l’occasion d’exposer l’opposition entre logiciels libre et propriétaire puis de préciser les objectifs poursuivis par les communautés.

Contrats de licences et objectifs stratégiques : retour sur la sphère de production des logiciels libres

6L’opposition entre le logiciel libre et le logiciel propriétaire s’exprime au travers des objectifs stratégiques valorisés par leur sphère de production réciproque, communautaire et marchande, et formalisés par les contrats de licences retenus.

Les composantes stratégiques des licences de logiciels : l’opposition entre logiciels libre et propriétaire

7Bessy et Brousseau (1998, 2003) ont montré que les accords de licence de technologie sont mis en place afin de répondre à des objectifs stratégiques variés et non exclusifs. Ainsi, ils n’ont pas pour unique objet de servir la valorisation patrimoniale de l’entreprise. Ils s’inscrivent dans des stratégies souvent sophistiquées associant des objectifs immédiats en termes de revenu avec des objectifs à plus long terme de maîtrise des évolutions techniques et concurrentielles (Ibid). Et, pour y parvenir, ils combinent quatre composantes stratégiques.

  1. La valorisation patrimoniale des connaissances de l’entreprise est permise par l’exploitation des droits de propriété intellectuelle détenus par la firme. Nous utiliserons le terme de “valorisation patrimoniale” pour désigner cette composante.

    • 4 Le code source est la version d’un logiciel écrite en langage de programmation sur laquelle l’humai (...)

    Le contrôle des firmes concurrentes s’exprime au travers des accords de licence conclus entre firmes qui permettent au détenteur d’une technologie de s’accorder un droit de contrôle sur ses concurrents. Deux clauses sont à considérer : celle de “grant-back” qui consiste à obliger le licencié à rétrocéder des droits d’exploitation pour les innovations dérivées du logiciel initial ; celle interdisant le “reverse-engineering”, procédé qui permet d’analyser le fonctionnement d’un programme (son code source par opposition au code objet4 dans le but de créer des produits complémentaires compatibles. Cette composante sera qualifiée de “contrôle” dans la suite du propos.

  2. La création de coopération en tant que source de création d’ “économies de recherche et développement”. Compte tenu de la structure de coûts des biens d’information, caractérisée par l’importance des coûts fixes et la faiblesse des coûts marginaux [Shapiro et Varian, 1999], la recherche d’une position dominante peut conduire à la mise en place de contrats de co-production. L’ensemble des co-contractants est propriétaire des droits de propriété intellectuelle de la technologie et se partage la rente de monopole associée. Nous parlerons de “mutualisation” pour qualifier cette composante.

  3. La diffusion en vue de l’établissement d’un standard. La firme éditrice peut choisir d’ “ouvrir” son logiciel dans le but d’en favoriser la diffusion comme standard de facto. Cette stratégie est choisie pour encourager l’adoption du logiciel par un maximum d’utilisateurs et pour inciter les autres industriels à la production de technologies affluentes compatibles. Cette stratégie consiste alors à diffuser gratuitement le logiciel et/ou à fournir le code source du logiciel. Dans le cas de la diffusion gratuite, c’est l’exploitation de la “valorisation patrimoniale” qui est reportée dans le temps (une fois le standard établi) ou sur un produit complémentaire offert par la même firme. Par exemple, la firme Adobe propose deux versions de son logiciel : l’une, gratuite, aux fonctionnalités restreintes (lecture de documents au format PDF) et l’autre, payante, aux fonctionnalités étendues (création de documents au format PDF). La libre diffusion de la première a permis à la firme d’imposer de facto le format PDF. Elle exploite ainsi les deux composantes de contrôle du format et de valorisation patrimoniale (sur la deuxième version).

8Dans le cas de l’ouverture du code source, c’est le contrôle des concurrents qui est reporté. Nous qualifierons cette composante de “diffusion” dans la suite du propos.

9Les licences de logiciels libre et propriétaire reposent sur des combinaisons de composantes stratégiques totalement opposées. Les licences propriétaires le sont au sens où le logiciel est exclusivement disponible sous forme de code objet et où sa licence concède un simple droit d’utilisation contre le paiement de royalties. Le logiciel est fermé et sa licence se fonde sur une intégration maximale des clauses de “valorisation patrimoniale” et de “contrôle des concurrents”. À l’opposé du logiciel propriétaire, le logiciel libre l’est au sens des libertés d’utiliser, de copier, de modifier le logiciel et de redistribuer la version modifiée. Diffusé sous forme de code source, il est protégé par la licence GPL conférant ces quatre droits mais imposant à toute version modifiée d’être protégée par la même licence. Celle-ci intègre ainsi les plus hauts degrés de “mutualisation” et de “diffusion”.

Deux communautés pour deux visées distinctes sur l’industrie

  • 5 Selon Lévy (1984), six principes définissent l’éthique des hackers : 1) L’accès aux ordinateurs dev (...)

10Avant d’en envisager l’hybridation avec les acteurs marchands, il convient de caractériser la sphère de production des logiciels libres, c’est-àdire de qualifier les communautés. La notion de communauté renvoie d’abord à l’engagement volontaire de ses membres sur la base de l’acception de règles de conduite et du partage d’un sentiment d’appartenance [Gresle et alii, 1994]. Dans le monde informatique, elle désigne la communauté bien connue des hackers, reposant sur le partage d’une culture commune relative au développement logiciel5 et se définissant au sens des communautés de la “science ouverte” qui caractérisent plus généralement les communautés scientifiques dont l’objectif essentiel est l’avancée des connaissances et qui s’opposent ainsi à leur appropriation privée [Dasgupta et David, 1994]. La fin poursuivie par la communauté des hackers n’est pas la production de logiciels mais la volonté que les ordinateurs fonctionnent sur la base de l’ouverture des programmes informatiques.

  • 6 Selon l’enquête FLOSS menée auprès des communautés de développeurs (FLOSS, 2002) 48 % des interrogé (...)

11Or, la communauté n’est pas homogène et les hackers6 eux-mêmes considèrent qu’il n’existe pas une mais deux communautés : celle du logiciel libre et celle du logiciel open source. Souvent présenté à tort comme une simple divergence sémantique, ce clivage ne s’exprime pas au sein de la communauté des hackers mais dans les relations qu’elle entretient avec l’”extérieur”, c’est-à-dire avec la sphère marchande [Coris, 2006a]. Ces relations sont explicitées dans la ligne générale des contrats de licences “libres” et “open source” définie par les communautés (tableau 1).

Tableau 1. Droits et libertés inclus dans les contrats de licence

La communauté du logiciel libre : l’hybridation par la contagion

12Incarnée par la Free Software Foundation (FSF ; http://fsf.org), la communauté du logiciel libre représente la partie la plus engagée des hackers bien que son objectif ne soit pas tant de s’opposer au capitalisme : il est possible de générer du revenu avec le logiciel libre. C’est d’ailleurs l’objet des sociétés éditrices de Linux. Pour cette communauté, le logiciel doit être libre, c’est-à-dire protégé par la licence GPL ou toute autre licence reconnue par la fondation. C’est en ce sens que la GPL peut d’ailleurs être perçue comme la principale réalisation de la Free Software Foundation (FSF)  : elle n’est pas contradictoire avec le capitalisme puisqu’elle permet la génération de la valeur ajoutée par la vente de services liés. En ce sens, alors que les deux sphères marchande et communautaire semblent opposées, elles ne s’excluent pas l’une l’autre. Dans la communauté, l’acte de produire n’a pas pour visée de répondre ou de susciter une demande marchande et il n’y a, a priori, aucune raison pour qu’un critère d’efficacité marchande guide l’action des développeurs, mais les hackers ne nient pas les intérêts commerciaux. Rien n’interdit de penser l’hybridation des deux logiques.

13La licence GPL a été créée afin d’éviter les travers du “domaine public” supposant un abandon des droits de propriété et permettant ainsi l’appropriation privée des codes sources qu’il protège. L’article 2 est l’article clef de cette licence : tous les travaux dérivés d’un logiciel sous licence GPL doivent eux-mêmes être placés sous GPL. Ceci définit le copyleft qui s’entend comme la liberté de modifier le logiciel et de le redistribuer, y compris commercialement, mais à la condition que le logiciel dérivé reste sous GPL et que soit spécifiée son origine. Toute version modifiée d’un code source protégé par la GPL sera automatiquement placée sous la même licence. La volonté de contagion, ou dimension virale de la licence, est formalisée par la spécification, dans le même article 2, que lorsqu’un logiciel sous GPL est combiné avec d’autres logiciels ou modules de logiciels et que la combinaison forme un tout, alors l’ensemble du logiciel, le tout, doit être placé sous licence GPL.

  • 7 Les termes de la licence semblent toutefois ambigus car il est difficile de savoir à partir de quel (...)

14La licence GPL autorise toutefois l’agrégation de différents logiciels de licences différentes sur un même médium par exemple. Dans ce cas, l’agrégation ne forme pas un tout et la licence GPL ne contamine pas les autres logiciels7. Autre point soulignant la dimension virale de la licence, si un module sous GPL est intégré à un code source, ce dernier ne peut plus être fermé. Il faut alors souligner l’existence d’une seconde licence de logiciel libre créée par la Free Software Foundation, la licence LGPL (Lesser GPL) s’appliquant aux bibliothèques de composants pour laquelle la dimension virale ne s’applique qu’aux modifications portant sur les modules et les composants de la bibliothèque, non aux modules et composants initialement placés sous d’autres licences de logiciels auxquels ils sont combinés. Cette licence favorise l’hybridation des deux types de logiciels dans un contexte de production de plus en plus modulaire.

15La visée de la communauté du libre ne semble pas contradictoire avec les intérêts marchands mais suppose leur adhésion au modèle de propriété intellectuelle porté par le logiciel libre. A contrario, la communauté de l’open source propose, quant à elle, une forme d’hybridation dans laquelle un logiciel “libre” peut se voir partiellement approprié.

La communauté open source : l’hybridation sans la contagion

16L’Open Source Initiative (OSI, www.opensource.org), va se créer en réaction à la popularité de la Free Software Foundation devenant le portailde la communauté avec le succès de Linux. En 1998, un groupe de hackers décide ainsi de remplacer le terme “free software” par “open source software” afin d’offrir une visée qualifiée de plus “pragmatique” par ses défenseurs que celle défendue par la communauté du libre.

17L’Open Source Initiative fait depuis office d’organisme régulateur de l’appellation open source car, plus qu’une licence, la définition de l’open source est un ensemble de recommandations. Seules les licences respectant l’ensemble des conditions et accordant les trois droits présentés dans le tableau 1 peuvent être qualifiées d’open source. Ainsi open source ne signifie pas seulement “à code source ouvert”. Mais au regard de la sphère marchande, la définition de l’open source autorise que les programmes dérivés ne respectent pas l’ensemble des conditions. C’est ici l’article 3 qui apparaît fondamental au regard des rapports qu’entretient la communauté de l’open source avec l’industrie du logiciel.

18Il y est énoncé qu’un code source sans droit de modification ne “sert pas à grand-chose”, mais qu’on ne peut pas imposer ce droit aux travaux dérivés. Pour qu’un logiciel soit reconnu par l’open source initiative, il faut que la licence permette les modifications et qu’elle autorise les programmes dérivés à le faire. Cependant, les licences open source ne visent pas la contagion car elles autorisent la privatisation des modifications et leur redistribution sous licence propriétaire. Un éditeur peut alors récupérer des logiciels ou des modules open source, les combiner à sa guise, et placer le tout sous la licence qu’il souhaite. Pour les partisans de l’open source, le logiciel devrait être libre.

  • 8 Selon Bonaccorsi et Rossi, 2003.

19À première vue, plus encline à l’hybridation avec la logique marchande, la communauté open source pourrait la remettre en cause, ce qui explique sûrement que 80 % des logiciels créés par les communautés sont placés sous licence GPL8. Il existe en effet un risque à voir les projets détournés par les firmes dès lors qu’elles peuvent en prendre un contrôle partiel. En effet, à partir du moment où la firme s’approprie un logiciel, la question est posée de son évolution : alors qu’au sein des communautés, il évolue sous la responsabilité d’un leader collectivement reconnu dans un sens satisfaisant le critère d’excellence technique, l’évolution serait ici guidée par des critères visant à satisfaire les intérêts commerciaux de la firme.

20À partir du moment où l’on reconnaît au logiciel sa nature profondément évolutive, l’appropriation devient contradictoire avec les avantages attendus, en termes de mutualisation des efforts de développement, de l’hybridation pour la firme qui ne saurait alors se garantir la participation future des membres des communautés. Surtout, une confusion peut naître du terme open source qui se traduit par “à code source ouvert”. Se pose alors le problème de l’usage frauduleux du terme open source pouvant qualifier des licences propriétaires dont le code source serait ouvert, mais sans garantie des droits de copie, de modification et de redistribution. Il s’agit là de la récupération marchande du mouvement lui-même, par la qualification, à tort, d’open source de ce qui est en réalité fermé.

Les licences hybrides : la réalisation de la visée de la communauté “open source”

21Les firmes font du logiciel libre, et elles le font d’abord pour servir leur intérêt direct, en plaçant sous “licence ouverte” certains de leurs logiciels afin de vendre d’autres produits sur un segment de marché complémentaire. Les industriels optent alors souvent pour une stratégie dite de licence hybride ou de double-licence qui consiste à fournir deux versions d’un même logiciel, l’une sous licence ouverte et l’autre sous licence propriétaire (Muselli, 2004). Mais l’ouverture du code source du logiciel n’est généralement que partielle et la licence GPL n’est que très rarement utilisée par les firmes en raison de son incompatibilité avec les fins poursuivies par les acteurs marchands, ainsi que l’ont déjà démontré de nombreuses études (voir notamment Feller et Fitzgerald, 2002 ; Fink, 2002 ; RNTL, 2002 ; Valïmako, 2003 ; Muselli, 2004).

La licence hybride : principe général

22Les licences hybrides sont mises au point par les éditeurs et combinent, à la fois et sous formes de clauses, les licences libre et propriétaire. Elles ne peuvent être totalement assimilées aux licences libres puisqu’elles n’en remplissent pas tous les critères, et trouvent leur fondement dans une exploitation particulière des différentes composantes stratégiques précitées. Chaque licence étant spécifique, il en existe presque autant qu’il y a de firmes. Cependant, l’ensemble des licences hybrides repose sur le même principe d’association de clauses (schématisé par la figure 1). Cette association permet une combinaison des quatre composantes stratégiques par la coexistence d’une version “ouverte” et d’une version “propriétaire” de la licence.

Source : Élaboration d’après Valïmako (2003)

La version “ouverte” de la licence

23La version “ouverte” du logiciel s’adresse à la communauté dans un sens étendu à la collectivité prise dans son ensemble. Son objet est de valoriser les deux composantes stratégiques de “mutualisation” et de “diffusion”. La valorisation de la composante “mutualisation” se considère au niveau de la coopération avec les communautés de développeurs. En diffusant le code source de son logiciel, la firme espère en retour pouvoir profiter de la force de travail bénévole des communautés (Lerner et Tirole, 2002). Elle peut ainsi tenter de créer sa propre communauté. C’est la raison pour laquelle une entité autonome (sous la forme d’un site web indépendant de type www.nomduprojet.org) est associée à la version “ouverte” du logiciel. La société commerciale recherche la génération d’économies d’échelle de production par mutualisation des coûts futurs de développement concernant principalement la maintenance évolutive (améliorations proposées par la communauté) et corrective (en profitant du débogage en parallèle) du logiciel.

24Par la diffusion gratuite du logiciel auprès d’un grand nombre d’utilisateurs, la société tente de générer une utilisation maximale de son logiciel en misant sur le fait qu’une partie des utilisateurs “gratuits” deviendra des clients “payants”.

La version “propriétaire” de la licence

25Dans sa version propriétaire, la licence permet une exploitation, plus ou moins importante en fonction des clauses qui sont intégrées, des deux autres composantes stratégiques de “valorisation patrimoniale” et de “contrôle” des concurrents. Déjà, la version “propriétaire” suppose le paiement d’une redevance. Son paiement semble justifié du fait qu’en règle générale, la version payante du logiciel est différente de la version “ouverte”. Elle comprend a minima le panel de services de garantie et de maintenance. Elle peut aussi différer par l’étendue des fonctionnalités offertes.

26Ensuite, la licence intègre des clauses permettant le contrôle de l’évolution de la technologie. Par la diffusion du code source, la firme détentrice des droits de propriété intellectuelle favorise, en le réalisant, le reverse-enginee ring. C’est donc la clause de “grant-back” qui peut être intégrée à la licence, spécifiant le versement de droits à la firme en cas de redistribution avec ou sans modification(s), dans un cadre commercial ou non.

27Les licences hybrides reposent ainsi sur une différenciation des droits accordés, soit en fonction de la version du logiciel considérée (dernière version ou version “complète” sous licence propriétaire, versions antérieures ou version “amoindrie” sous licence ouverte), soit en fonction de l’utilisation qui en est faite (la licence ouverte pour les utilisations non commerciales de recherche, de test, ou d’évaluation privée, la version propriétaire pour les utilisations commerciales). Il semble évident que les éditeurs ne vont pas placer leurs logiciels sous licences hybrides pour des raisons éthiques. Ainsi, si ces licences sont qualifiées d’open source par les firmes, elles ne respectent pas, dans leur grande majorité, l’ensemble des clauses permettant d’être certifiées par l’Open Source Initiative, encore moins pour être reconnues comme licences de logiciels libres par la Free Software Foundation (Fink, 2002). Elles s’inscrivent plus dans des stratégies de détournement de la qualification open source malgré quelques initiatives marginales laissant entrevoir la possible communion des deux logiques. Avant de les illustrer de quelques exemples, nous présentons ici un autre cas particulier d’hybridation des logiques orientée vers la demande, celui des licences collaboratives.

L’exemple des licences “collaboratives” : la mutualisation par la demande

  • 9 http://www.collaborativesource.org/
  • 10 La société Codeva est le relais commercial et le centre de développement français pour ces deux log (...)
  • 11 Elle est gratuite pour les organisations caritatives et pour les autres développements open source.

28La licence collaborative semble n’être que peu répandue, puisqu’elle ne s’appliquerait qu’à deux projets logiciels9 : Jahia (logiciel d’agrégation d’applications) et Sensei (moteur de gestion et d’orchestration de services web)10. Cependant, elle présente une forme originale d’hybridation des deux logiques libre et propriétaire puisqu’elle tente de transposer l’absence de clivage entre consommateurs et producteurs au sein de la firme sur la base d’un principe relativement simple : l’utilisateur a le choix de contribuer ou de payer. La licence collaborative se décline selon trois versions, “R&D”, “Clients” et “Contributeurs”, en fonction du type d’utilisation faite du logiciel. La version “R&D” s’adresse aux utilisateurs dans le cadre de la réalisation de test ou de développement complémentaire et accorde les droits d’utilisation, de copie, de modification et de redistribution sous la même licence. Lorsque le produit a pour vocation d’être utilisé dans un cadre commercial, le “client” doit s’acquitter d’un droit de licence11.

29L’originalité provient de la troisième version de la licence puisque le client, dès lors qu’il contribue au développement du logiciel et que sa contribution est reconnue par le comité de sélection attaché au projet, se voit octroyer une remise, partielle ou totale, sur le prix de la licence commerciale. La licence collaborative des projets Jahia ou Sensei n’est pas reconnue par l’Open Source Initiative mais elle propose une hybridation des logiques commerciale et communautaire qui, tout en valorisant les droits de propriété intellectuelle, tente de transposer le modèle de l’utilisateur-développeur [von Hippel, 2007] à la création commerciale de logiciels.

30Cette problématique s’inscrit dans celle, plus large, de la mutualisation par la demande, suivie par d’autres firmes. Par exemple, la division GrandAngle de la société Unilog, qui commercialise le progiciel propriétaire “GrandAngle” de gestion pour les collectivités territoriales, a mis au point un “club” à destination des utilisateurs du logiciel. Ceux-ci, une fois acquittés les droits de licence, adhèrent au club qui décide, par voie de vote, des évolutions futures du progiciel, alors financées par les cotisations des membres. Dans le monde du logiciel libre, un modèle similaire est suivi par la société IdealX qui, en 2003, a initié le “club des clients contributeurs”, regroupant les utilisateurs de la PKI (une quarantaine de membres dont Auchan, le GAN, Gaz de France…). Un comité stratégique, composé du club des utilisateurs et de la direction du département R&D de la société, se réunit tous les six mois afin de décider des évolutions du logiciel, les modifications réalisées étant, comme dans le cas précédent, financées par les cotisations. Bien que le logiciel soit sous GPL, sa publication intervient avec un temps de retard, de manière à ce que la version modifiée du logiciel soit dans un premier temps exclusivement disponible pour les utilisateurs qui en financent la réalisation. Les clients sont ainsi incités à contribuer. Par leur participation à la prise de décision, ils peuvent influencer les modifications dans un sens qui satisfait leurs propres intérêts.

La complémentarité des licences propriétaires et libres : quelques exemples de logiciels sous licence GPL

  • 12 Pour plus de détails, le lecteur intéressé peut se référer à Muselli (2004).

31Licence libre et licence propriétaire peuvent être compatibles, voire complémentaires. A titre d’illustration, nous pouvons retenir le cas de la société TrollTech développant la bibliothèque de composants pour environnement graphique Qt et celui de la société MySQL AB développant le système de gestion de bases de données relationnelles MySQL12.

32Initié en 1995 par deux développeurs bénévoles, le logiciel MySQL était placé sous une licence proche des licences propriétaires. Devenant très populaire dans le monde Linux, MYSQL fut placé sous licence GPL en 2000 et la société MySQL AB, détentrice des droits de propriété intellectuelle, fut créée en 2001. Depuis, la société pratique une politique de double licence13 avec une volonté affichée de promouvoir les développements en GPL. Soit l’utilisateur paye, soit il diffuse ses réalisations sous GPL. MySQl est ainsi disponible sous licence GPL lorsque le logiciel dans lequel il sera intégré est de même protégé par la licence GPL, quelle qu’en soit l’utilisation, commerciale ou communautaire. Les modifications sont autorisées et peuvent être redistribuées tant que la version modifiée est placée sous GPL.

33En revanche, la licence commerciale s’applique lorsque le logiciel dans lequel MySQL sera intégré n’est pas sous licence libre. Dans ce cas, le choix de la licence GPL s’explique en partie par l’origine communautaire du logiciel, en partie par la volonté de MySQL de devenir le standard des systèmes de gestion de base de données sous environnement Linux.

34Le cas de Qt illustre quant à lui le passage d’une double-licence “tendance propriétaire” à une double-licence “tendance GPL” sous l’influence de la communauté. Développé par la société commerciale TrollTech, l’outil Qt est utilisé par le projet communautaire KDE (environnement de travail pour système d’exploitation, il est inclus dans les différentes versions de Linux). À l’origine, la version ouverte de la licence de Qt autorisait l’utilisation et la copie du logiciel, mais interdisait toute forme de modification. Un projet d’environnement graphique concurrent fut alors initié par la communauté (GNOME, sous licence GPL et de même inclus dans les différentes versions de Linux), sur la base d’une bibliothèque concurrente, développée à l’occasion, la GTK (GPL). La pression exercée par la communauté, directement auprès de la firme et indirectement par la création du projet concurrent, a contrarié la stratégie de standardisation de la société TrollTech. Celle-ci opta, en 2001, pour la licence hybride suivante14 : une licence GPL à destination des utilisateurs non-commerciaux et une licence propriétaire pour les applications commerciales d’intégration de Qt dans un projet propriétaire ou d’utilisation nécessitant la fourniture des services de support et de garantie.

35Enfin, la récente mise sous GPL par Sun de son langage de développement Java est sûrement le cas le plus mis en avant par les communautés pour démontrer la viabilité économique de la licence GPL.

36Alors que dès le lancement du projet au milieu des années 1990, la firme avait fait le choix de la stratégie d’ouverture afin de favoriser la diffusion de Java dans la compétition qui l’oppose aux technologies .net et c# de Microsoft, la licence qui protégeait Java jusqu’en 2007 (SCLS) permettait à Sun d’en conserver le contrôle. Étaient autorisées l’utilisation gratuite et la copie dans un cadre non commercial quand un paiement de royalties était demandé dans le cadre d’une utilisation professionnelle ou de l’intégration de Java dans une offre commerciale, mais la licence SCSL interdisait toute forme de modifications en dehors des corrections de bugs.

37Les propositions de modifications devaient obligatoirement être soumises à Sun qui se réservait le droit, soit de les intégrer directement au projet Java, soit de certifier la version modifiée contre le paiement de royalties. La clause de “grant-back” permettait la valorisation de la composante “contrôle des concurrents” quand le paiement de royalties permettait celle de la composante “valorisation patrimoniale”. La licence n’était pas reconnue par l’Open Source Initiative. Java jouissant d’une popularité et d’une diffusion très importantes au sein de l’industrie du logiciel comme au sein des communautés, ces dernières, suivies notamment par IBM, ont fait pression sur Sun pour qu’elle place Java sous licence libre, ce que la firme a longtemps refusé compte tenu des profits générés par le contrôle de Java.

  • 15 Il s’agit alors simplement d’une stratégie de reconquête de parts de marché. Nous renvoyons le lect (...)

38Ces cas montrent la compatibilité des intérêts commerciaux avec l’utilisation de la licence GPL. Toutefois, ne sont généralement mis sous licence ouverte que les logiciels pour lesquels le retour sur investissement est soit réalisé, soit abandonné compte tenu de la position concurrentielle de l’éditeur15. En outre, la GPL n’est que très rarement la licence retenue par les acteurs marchands. [Valïmako, 2003 ; Feller et Fitzgerald, 2002]. In fine, il ressort que la visée de la communauté du logiciel libre entre en contradiction avec la volonté des firmes de conserver le contrôle de leurs technologies. Dès lors que le développement initial du logiciel est supporté par la firme, le recours à la licence propriétaire se justifie pour assurer à la firme le retour sur investissement. Bien que l’alternative libre semble viable, elle ne pourrait ainsi trouver à se pérenniser que si l’ensemble de l’industrie en respectait les règles. Au regard de la distinction introduite au sein de la communauté des hackers, c’est ici la réalisation de la visée de la communauté open source qui semble réalisée. Impliquant l’action collective, une autre forme d’hybridation des deux logiques est observable, conciliant les intérêts marchands avec ceux de la communauté du logiciel libre.

Une hybridation des deux logiques est-elle possible ? Les consortiums ouverts de standardisation

39Parmi les motivations avancées par les analystes des formes d’hybridation entre communautés et acteurs marchands [Floss, 2002 ; Bonaccorsi et Rossi, 2003 ; Jullien, 2003], celle de disposer d’un standard ouvert tient une place centrale pour éclairer la participation des industriels au développement du Linux : l’ouverture du standard permettrait de s’affranchir du contrôle exercé par Microsoft. Grâce aux modèles de propriété intellectuelle qu’il incarne, le logiciel libre ravive ainsi les débats sur les opportunités de disposer de standards ouverts [Jullien et Zimmermann, 2002 ; Coris, 2006c]. Et il apparaît que ces opportunités s’étendent à des projets initiés par firmes auxquels les communautés prennent part.

L’enjeu de la standardisation de Linux : coopérer pour évincer Windows

40Le système d’exploitation est le nœud de compatibilité de toute architecture informatique : il permet l’interaction des logiciels entre eux, avec la machine et avec l’être humain [Dréan, 1996]. Le cas de Linux permet de reconsidérer l’intérêt de disposer d’un standard ouvert tout en montrant celui de mettre en place un consortium ouvert afin de garantir l’ouverture du standard et la participation de la communauté dans son évolution.

Pourquoi Linux ? Les avantages d’un standard ouvert

41La sauvegarde des parts de marché ne peut, seule, expliquer le ralliement à Linux d’un nombre croissant d’industriels de l’informatique. C’est parce qu’elles souhaitent encourager la standardisation autour de Linux que les grandes firmes généralistes (SUN, IBM, HP, BULL…) ou éditrices (Oracle, SAP, Borland…) participent à son développement. Linux incarne en effet l’intérêt commun des industriels à disposer d’un système d’exploitation ouvert au sens où il ne peut être “détourné” par sa fermeture ou par la revendication de droits de propriété intellectuelle. Le ralliement à Linux s’explique par les enjeux liés à la standardisation ouverte qui offre une voie de résolution des deux dilemmes inhérents au processus de standardisation dans l’industrie du logiciel.

  • 16 Dans tout système composé d’éléments interdépendants entre eux, comme le système informatique liant (...)

42Relatif à l’application des droits de propriété intellectuelle (DPI), le dilemme de Schumpeter s’exprime à travers la tension entre le retour sur investissement pour l’innovateur – incitation par les DPI – et la dynamique de l’innovation pouvant être remise en cause par ces droits – l’incitation n’a de sens, in fine, que si l’innovation se diffuse au sein de la structure industrielle [Zimmermann, 1999]. D’un côté, considérer le logiciel comme un produit le rend susceptible de protection par les DPI. À l’inverse, ses interfaces de communication ne devraient pouvoir y prétendre, leur ouverture garantissant l’interopérabilité entre les éléments du système informatique nécessaire au maintien de la dynamique d’innovation16 [Robien, 1987].

43Or, le logiciel est sujet aux DPI sans qu’aucune distinction ne soit faite entre produit et interface. Dans le cas des logiciels libres, le dilemme de Schumpeter est résolu car aucun droit privé de propriété intellectuelle ne pèse réellement sur le standard, ce qui permet de disposer d’interfaces de communication ouvertes tout en autorisant la protection des logiciels complémentaires qui restent, eux, la propriété de la firme et sur lesquels elle génère ses sources de profit. Le second dilemme est relatif à la situation paradoxale mise en évidence par David (1994) entre la standardisation de facto permettant, a priori, la diversité mais pouvant conduire au contrôle de marché, et la normalisation par les institutions publiques permettant de garantir la compatibilité des technologies mais qui, lorsqu’elle est envisagée, arrive souvent soit trop tôt soit trop tard. Ce paradoxe est lui aussi contourné : l’ouverture des interfaces permet que soit préservée la diversité non seulement en amont (matériel) et en aval (autres logiciels d’infrastructure, logiciels applicatifs…) mais aussi concernant les logiciels basés sur ces standards, par différenciation des versions entre lesquelles l’interopérabilité est alors garantie. La tentative de standardisation implique alors la mise en place d’une action collective sous forme d’un consortium ouvert.

Le consortium ouvert  : la compatibilité des intérêts des firmes et des communautés

44Les “éditeurs” de Linux doivent respecter les termes de la licence GPL. Mais le respect de la licence ne garantit pas la compatibilité des différentes versions entre elles. En effet, l’unique élément véritablement commun à l’ensemble de ces distributions est le “noyau” dont la fonction est l’uniformisation de la gestion de la mémoire. Les firmes ont toute latitude concernant la combinaison des différents composants qui seront assemblés dans le package final. De plus, elles sont libres concernant le choix de l’architecture et de l’arborescence du logiciel. Il peut en résulter une incompatibilité des différentes versions de Linux entre elles : les éléments matériels et logiciels risquent de ne pas être interopérables avec l’ensemble de ces versions. Afin d’éviter cela, une organisation sans but lucratif, le Free Standards Group, est créée en 2000 à l’initiative de Caldera, Mandrake et SuSE, soutenu par IBM, Oracle et HP, et par la communauté des développeurs.

45Le consortium reprend le projet LSB (Linux standard base), projet de standardisation du système d’exploitation initié en 1997, mais ne se donne plus pour objectif de créer une version universelle de Linux, simplement de standardiser les interfaces de communication afin de garantir l’interopérabilité des distributions et de faciliter le développement des technologies complémentaires [Lioubareva, 2006]. Toute application développée en respectant ces protocoles est compatible avec l’ensemble des distributions les respectant aussi. Financée par ses membres, l’organisation est indépendante et contrôlée par la communauté qui y participe. Une procédure de certification garantit le respect des standards d’interface. L’initiative semble aujourd’hui un succès puisque les trois principales distributions de Linux (SuSE, RedHat et Mandrake) ont obtenu cette certification, tout comme la version communautaire Debian, ce qui prouve la reconnaissance de l’initiative par la communauté. Collectivement, firmes et communautés parviennent à “contrôler” l’évolution de Linux afin qu’aucune firme ne puisse en prendre le contrôle.

46Il y a bien ici hybridation des deux sphères au sens où il y a reconnaissance marchande de la licence GPL comme du modèle de développement collectif propre aux logiciels libres. En contrôlant le consortium et en participant à l’élaboration des standards d’interface, les communautés contribuent au devenir de leur projet. Leurs versions de Linux sont compatibles avec les versions commerciales et avec les logiciels complémentaires des industriels. Symétriquement, les firmes interviennent dans le processus de standardisation et poursuivent la recherche de la satisfaction d’un intérêt commercial par la vente de produits liés. Toutefois, la conciliation des deux logiques est doublement spécifique au cas de Linux. D’abord parce que les positionnements des firmes ici concernées ne portent pas directement sur les droits qui sont attachés au système d’exploitation mais dépendent de son ouverture. Ensuite parce que la participation des industriels est largement facilitée par le fait que les coûts initiaux de développement ont été supportés par les communautés.

Vers la généralisation des consortiums ouverts ?

  • 17 Ils désignent l’ensemble des outils de développement de logiciels (langages de programmation, bibli (...)

47Deux grands cas de consortiums ouverts initiés par les firmes sont clairement identifiables, l’Eclipse Foundation et le consortium ObjectWeb, qui concernent des technologies clefs de l’architecture informatique (outils d’infrastructure)17 et qui réunissent un nombre non négligeable des acteurs majeurs de l’industrie. Dans les consortiums privés, plusieurs firmes s’allient pour mutualiser les coûts de développement en vue de contrôler conjointement le standard et de se répartir les gains issus de l’exploitation des droits de propriété intellectuelle. À l’inverse, la possibilité de profiter des composantes de “valorisation patrimoniale” et de “contrôle” est remise en cause par le consortium ouvert qui suppose l’ouverture de l’oligopole et des technologies réalisées [West, 2003]. Il entre ainsi en contradiction avec les règles du jeu en place au sein d’une industrie structurée par les droits de propriété intellectuelle. Quel peut alors être l’intérêt des firmes à y participer ?

Deux cas de consortiums ouverts

48L’Eclipse Foundation18 est dédiée à la plateforme de développement d’applications, Eclipse, originellement financée par IBM et en concurrence avec NetBeans de Sun, spécifique au langage Java, et VirtualStudio.net de Microsoft, spécifique aux technologies Microsoft. À la différence de ses concurrents, le projet Eclipse est conçu de manière à être indépendant des architectures matérielles et logicielles de mise en œuvre. Contrairement aux cas précédemment exposés de “licence double”, IBM place Eclipse, dès 2001, sous une seule licence de logiciel libre, la Common Public License19 (CPL). Le projet attire ainsi certains membres des communautés et IBM instaure un consortium dont la firme conserve le contrôle. Le ralliement au projet est encore assez faible et ne fait l’adhésion que d’une petite dizaine de firmes. Fin 2003, la décision est prise par IBM d’abandonner le contrôle du consortium et, par là, celui d’Eclipse. Le consortium évolue et prend la forme d’une organisation sans but lucratif, l’Eclipse Foundation, contrôlée par un comité d’experts indépendants d’IBM. Par l’abandon du contrôle de la technologie, IBM vise le ralliement d’un maximum d’industriels au consortium qui compte une cinquantaine de membres industriels, dont BEA, Oracle, SAP, SAS, HP, Bull et Novell.

49Créé en 1999 par Bull, l’INRIA et France Telecom R&D, le consortium ObjectWeb a pour vocation de réaliser des outils modulaires de middleware (outils d’infrastructure, intermédiaires entre l’infrastructure “basse” de type Eclipse, et les applications) sous licences libres. La principale réalisation du consortium est le serveur d’applications JoNAS placé sous la licence libre LGPL (Library General Public Licence, licence dérivée de la GPL). Les concurrents directs de JoNAS sont les logiciels propriétaires WSAS (WebSphère Application Server, IBM), Weblogic (BEA) et 9iAS (Oracle). En 2004, le consortium réunit déjà 34 firmes dont Mandrake, RedHat, SuSE, Thalès, Dassault Aviation, un certain nombre d’organismes publics de recherche, et il entretient des partenariats avec les organisations communautaires Debian et Apache Foundation. Depuis 2005, un consortium chinois de même nature, Orientware, a rejoint ObjectWeb.

Le choix du consortium ouvert  : la standardisation par la mutualisation

50Dans le cas d’un consortium ouvert, les chances de diffusion du logiciel sont doublement renforcées par la stratégie d’ouverture. Ce sont d’abord les membres du consortium qui favorisent la diffusion du logiciel en offrant les technologies liées. C’est ensuite l’ensemble des industriels qui bénéficient de l’ouverture du logiciel et qui participent à la diffusion du standard en le rendant compatible avec leurs produits. Mais le principal intérêt du consortium réside dans l’exploitation de la composante de mutualisation des coûts de développement. Lorsque les consortiums sont ouverts, l’ouverture des technologies et le mode de gouvernance des consortiums favorisent la participation des communautés. Dans les deux cas précités, la structure de gouvernance est clairement ouverte aux développeurs des communautés qui peuvent, tout aussi légitimement que les acteurs marchands, prendre part aux comités d’experts chargés de la sélection des contributions et de l’évolution des projets. L’Eclipse Foundation intègre des développeurs indépendants dans le comité directeur du projet en charge de la définition des grandes orientations stratégiques et techniques du consortium. Dans le cas d’ObjectWeb, les développeurs sont cooptés en fonction de leurs qualités techniques pour participer au conseil d’architectes en charge des spécifications techniques et sont éligibles au comité directeur. Bien que la représentation des firmes au sein des organes de décision dépende de leur contribution financière et, qu’à ce titre, les consortiums diffèrent des projets spécifiquement communautaires, il semble que le mode d’organisation s’en approche, l’indépendance du consortium étant l’une des conditions de sa viabilité.

51Ainsi, l’ouverture du consortium permet la participation des communautés et favorise la diffusion des logiciels mais remet en cause l’exploitation des droits de propriété intellectuelle, ce qui pose la question de l’intérêt des firmes à participer.

L’intérêt des firmes à participer : le déplacement du jeu concurrentiel

52Dans un consortium privé, l’incitation à innover se justifie par l’exploitation collective des droits de propriété intellectuelle. Elle repose sur le régime particulier de propriété intellectuelle qui s’y observe, la propriété diffuse, ou collective, intermédiaire entre les connaissances publiques impossibles à s’approprier et les connaissances privées qu’une organisation peut légalement s’approprier [Ouchi, 1998]. Dans un consortium ouvert en revanche, la propriété est collective, mais au sens de la collectivité prise dans sa généralité, c’est-à-dire s’étendant en dehors du consortium. Même mutualisés, les coûts de développement doivent être supportés par des firmes qui ne pourront exploiter, y compris de manière partagée, les droits de propriété intellectuelle.

53S’il n’est pas lié à l’exploitation de la composante de “valorisation patrimoniale”, c’est que l’intérêt stratégique des firmes participant au consortium se situe ailleurs. Ailleurs, c’est-à-dire sur d’autres technologies que celles qui y sont développés. Le choix de licences de logiciel libre “non GPL” s’explique alors. Les deux licences CPL et LGPL autorisent la combinaison d’éléments CPL et LGPL à des éléments logiciels placés sous d’autres licences (notamment propriétaires), tant que l’ensemble n’est pas fermé. L’utilisation de ces deux licences permet ainsi de favoriser la diffusion, y compris auprès des firmes non-membres, des développements réalisés au sein des consortiums : Eclipse et JoNAS sont des ensembles de modules pouvant être combinés à d’autres modules propriétaires sur lesquels les firmes exploitent la composante de “valorisation patrimoniale”.

54Elle sert de la même manière les stratégies des firmes membres : la volonté d’ouverture exprimée par les industriels dans le cadre des consortiums ouverts ne concerne pas l’ensemble des technologies logicielles produites par ces firmes. IBM se positionne aujourd’hui en amont et en aval, par un recentrage de ses activités sur la vente de serveurs (machines), sur les couches logicielles “supérieures” et sur la vente de services d’expertise “surmesure”. Bull trouve un intérêt à participer au développement de JoNAS afin de favoriser son positionnement sur la vente des serveurs. IBM ne participe pas au consortium ObjectWeb du fait de son positionnement sur les serveurs d’application, tandis que Bull a intérêt à participer à Eclipse afin de rendre interopérable JoNAS. Les firmes ne font pas du logiciel libre là où se situent leurs sources de valeurs ajoutées.

55Pas de profits liés aux droits de propriété intellectuelle, pas de contrôle non plus. À l’instar de la licence GPL, les licences CPL et LGPL garantissent qu’aucune clause de “contrôle” ne peut y être incluse, à défaut de ne plus être reconnues comme licences de logiciels libres. Les innovations portant directement sur les codes sources des projets logiciels doivent se faire en respectant les contrats de licence, c’est-à-dire qu’elles doivent être diffusées librement. Cet aspect est très important pour le processus de standardisation collective : s’il permet d’éviter que l’un des membres prenne le contrôle du standard, il empêche surtout que des firmes concurrentes prennent le contrôle des technologies en distribuant sous licence propriétaire les modifications qu’elles pourraient apporter aux logiciels réalisés par le consortium. Elles sont donc le garant d’un contrôle collectif des standards, contrairement aux licences hybrides. In fine, les firmes trouvent un intérêt à participer car l’ouverture des standards et le développement mutualisé d’outils d’infrastructure permettent  : de participer au processus de décision afin de favoriser l’orientation de la technologie dans un sens qui satisfasse aux intérêts commerciaux de la firme et dont le coût sera mutualisé ; d’acquérir l’expertise nécessaire à la vente de services et au développement de produits complémentaires car, si le code source des logiciels est disponible pour tout un chacun, l’avantage, pour les participants au consortium, réside dans l’accès privilégié aux connaissances tacites qui permettent la maîtrise de ces logiciels et qui sont nécessaires à la fourniture de l’expertise liée, cette propriété relativisant le défaut d’appropriabilité précitée [Larrue, 2000] ; de bénéficier des avantages de la standardisation ouverte.

Conclusion

56Si l’hybridation des sphères marchandes et communautaires peut, dans certains cas, prendre des formes satisfaisant les firmes comme les communautés, rien ne saurait garantir leur pérennité. En effet, l’implication actuelle des firmes dans ces consortiums pourrait être perçue comme une simple stratégie transitoire d’acteurs visant, à terme, le contrôle de l’industrie. Après avoir axé des années durant leur modèle de profitabilité sur l’exploitation des droits de propriété intellectuelle et les rapports de contrôle, ces firmes ne vont pas les remettre en cause. Elles semblent simplement se saisir des opportunités offertes par les licences libres pour s’affranchir de la domination de quelques éditeurs et se repositionner sur leur cœur de métier.

57Toutefois, et pour un certain nombre d’outils logiciels génériques d’infrastructure, les industriels reconsidèrent leur intérêt commun à disposer de standards véritablement ouverts. Ce sont alors les caractéristiques mêmes des produits et de leur modalité de production qui conduisent à ces formes de coopération, en dépassant les débats idéologiques. Dans cette optique, le modèle de propriété intellectuelle proposé par le logiciel libre et figuré par les consortiums ouverts semble permettre une gestion collective des dilemmes de Schumpeter et de David satisfaisant les firmes en présence dans leurs repositionnements stratégiques sur la vente de technologies liées. Ces cas de consortiums relancent les débats sur la standardisation ouverte, c’est-à-dire sur le statut de bien public des interfaces de communication et le rôle des pouvoirs publics dans le processus de standardisation/normalisation. Mais surtout, ces cas de consortiums relancent le débat sur les droits de propriété intellectuelle s’appliquant au logiciel, la possibilité de contrôle des interfaces étant liée à la détention de ces droits. S’il semble évident que les pouvoirs publics américains ne remettront pas en cause la brevetabilité du logiciel fondant la profitabilité de leurs éditeurs de logiciels, l’expérience des consortiums ouverts pourrait alimenter les débats toujours d’actualité en Europe sur la question du brevet logiciel.

Haut de page

Bibliographie

BESSY C., BROUSSEAU E., « Technology Licensing Contracts : Features and Diversity »,

International Review of Law and Economics, Vol. 18, December, pp. 451-489., 1998.

BESSY C., BROUSSEAU E., « Contrats de licence et innovation », in Mustar P. et Pénan H. (dir.), Encyclopédie de l’Innovation, Economica, Paris, pp. 341-366, 2003.

BONACORSI A., ROSSI C., « Why Open Source software can succed », Research Policy, n° 32, Issue 7, pp.1243-1258, 2003.

CORIS M., « La culture du don dans la modernité : les communautés du logiciel libre », Réseaux, n° 140, vol.24, pp.161-191, 2006a.

CORIS M., « Chronique d’une absorption par la sphère marchande : les Sociétés de Services en Logiciels Libres », Gérer et Comprendre, n° 84, pp.12-23, 2006b.

CORIS M.., « Les consortiums ouverts : une nouvelle approche pour la standardisation des logiciels ? », Revue d’Economie Industrielle, n° 116, pp.105-126, 2006c.

DASGUPTA P., DAVID P. A., « Toward a new economics of science », Policy Research, Vol. 23, pp. 487-521, 1994.

DAVID P. A., Les standards des technologies de l’information, les normes de communication et l’Etat  : un problème de biens publics », in Orléan A. (dir.), Analyse Economique des Conventions, Presses Universitaires de France, Paris, pp. 249-280, 1994.

DREAN G., L’industrie Informatique. Structure, économie, perspectives, Masson Collection Stratégies et Systèmes d’Information, Paris, 1996.

FELLER J., FITZGERALD B.,Understanding Open Source Software Development, Addison-Wesley, UK, 2002.

FINK M., The Business and Economics of Linux and Open Source, Prentice Hall PTR, 2002.

FLOSS, Free/Libre and Open Source Software : Survey and Study,

GENTHON C., PHAN D., « Les logiciels libres : un nouveau modèle ? », Terminal, n° 80-81, pp.167188, 1999.

GRESLE F. ET ALII, Dictionnaire des sciences humaines, Nathan, nouvelle édition, 1994.

GOËNC R., « Enjeux industriels des normes dans les technologies de l’information », Revue d’Economie Industrielle, n° 39, 1er trimestre, pp.208-219, 1987.

HIPPEL VON E., « Horizontal innovation networks-by and for users », Industrial and Corporate Change, n° 16, pp. 293-315, 2007.

JULLIEN N. « Le marché francophone du logiciel libre », Systèmes d’Information et Management, n° 1, vol.8, pp.77-89, 2003.

JULLIEN N., ZIMMERMANN J.B., « Le logiciel libre : une nouvelle approche de la propriété intellectuelle », Revue d’Economie Industrielle, n° 99, 2ème trimestre, pp. 159-178, 2002.

JULLIEN N., ZIMMERMANN J.B., « Peut-on envisager une écologie du Libre favorable aux nuls ? », Terminal, n° 97-98, 2006.

LARRUE P., La coordination des activités de recherche et d’innovation dans les phases d’émer gence : le cas des batteries pour véhicules électriques et hybrides, Thèse de doctorat en Sciences Economiques, Université Bordeaux IV, 2000.LERNER J., TIROLE J., « Some Simple Economics of Open Source », Journal of Industrial Economics, Vol.50, Issue 2, pp.197-234, 2002.

LEVY S., Hackers : Heroes of the Computer Revolution, Anchor Press/Doubleday, New York, 1984.

LIOUBAREVA I., « Les standards comme dispositifs de coordination. Linux Standard Base comme interaction entre marché et communauté », Terminal, n° 97-98, 2006.MUSELLI L., Les licences informatiques. Un instrument stratégique des éditeurs de logiciels », Réseaux, n° 125, pp.143-174, 2004.

OUCHI W.G., « The new joint R&D », Proceedings of the IEEE, Vol.77, 9, pp.1318-1326, 1989. RNTL, Nouveaux Modèles Economiques, Nouvelle Economie du Logiciel, Rapport, 2002.

DE ROBIEN E., « Les stratégies de normalisation dans le domaine de l’information », Revue d’Economie Industrielle, n° 39, 1er trimestre, pp.220-227, 1987.

SHAPIRO C. ET VARIAN HAL R., Economie de l’information, Guide stratégique de l’économie des réseaux, De Boeck Université, Collection Balises, Paris, 1999.

STALLMAN R., Le Manifeste GNU, http://www.gnu.org 1984.

VALIMAKÖ M., 2003, « Dual Licensing in Open Source Software Industry », Systèmes d’Information et Management, Vol.8, n° 1, pp.63-75.

WEST J., 2003, « How Open is Open Enough? Melding Proprietary and Open Source Platform Strategies », in Research Policy n° 32, Issue 7, pp. 1259-1285.

ZIMMERMANN J.B., « Logiciel et propriété intellectuelle : du copyright au Copyleft », Terminal, n° 80-81, pp.149-166, 1999.

ZIMMERMANN J.B., « Logiciel Libre et marchandisation : un problème d’incitation pour les développeurs », Rencontres « Autour du Libre » 2003, Paris, 21-23 mai 2003.

Haut de page

Notes

1 Le site du MIT (http://opensource.mit.edu/) référence plus de deux cents « working papers » sur la thématique.

2 Pour une analyse du devenir du logiciel libre menée du « côté de la demande », voir Jullien et Zimmermann (2006).

3 La Licence GPL (GNU General Public License) est la principale licence de logiciel. Nous la présentons dans la première partie de l’article.

4 Le code source est la version d’un logiciel écrite en langage de programmation sur laquelle l’humain peut intervenir. Traduit en langage machine, il devient le code objet, exécutable par l’ordinateur mais incompréhensible par l’humain.

5 Selon Lévy (1984), six principes définissent l’éthique des hackers : 1) L’accès aux ordinateurs devrait être illimité et total ; 2) L’information devrait être libre et gratuite ; 3) Il faut se méfier de l’autorité et promouvoir la décentralisation ; 4) Les gens devraient être jugés en fonction de la valeur de ce qu’ils créent, et non en fonction de leur position sociale ou des diplômes qu’ils détiennent ; 5) Il est possible de créer de l’art et de la beauté sur un ordinateur ; 6) Les ordinateurs peuvent améliorer la vie humaine.

6 Selon l’enquête FLOSS menée auprès des communautés de développeurs (FLOSS, 2002) 48 % des interrogés se « sentent » appartenir à la communauté du logiciel libre, 33 % à celle du logiciel open source quand 19 % ne font pas la différence.

7 Les termes de la licence semblent toutefois ambigus car il est difficile de savoir à partir de quel moment l’agrégation forme un tout.

8 Selon Bonaccorsi et Rossi, 2003.

9 http://www.collaborativesource.org/

10 La société Codeva est le relais commercial et le centre de développement français pour ces deux logiciels.

11 Elle est gratuite pour les organisations caritatives et pour les autres développements open source.

12 Pour plus de détails, le lecteur intéressé peut se référer à Muselli (2004).

13 http://www-fr.mysql.com/products/licensing.html

14 http://www.trolltech.com/products/licensing.html

15 Il s’agit alors simplement d’une stratégie de reconquête de parts de marché. Nous renvoyons le lecteur au rapport RNTL (2002) pour une étude des stratégies d’ouverture du code source des sociétés OpenCascade et EDF où elle est envisagée suite aux échecs rencontrés par les versions commerciales des logiciels.

16 Dans tout système composé d’éléments interdépendants entre eux, comme le système informatique liant composants logiciels et matériels, l’interopérabilité de ces éléments reposent sur leurs interfaces de communication (Goënç, 1987).

17 Ils désignent l’ensemble des outils de développement de logiciels (langages de programmation, bibliothèques de composants, plates-formes de développement, voire bases de données).

18 http://www.eclipse.org/

19 Le texte de la licence, rédigée spécialement pour Eclipse par IBM : http://www.eclipse.org/legal/cpl-v10.html

Haut de page

Table des illustrations

URL http://journals.openedition.org/terminal/docannexe/image/4716/img-1.png
Fichier image/png, 46k
Crédits Source : Élaboration d’après Valïmako (2003)
URL http://journals.openedition.org/terminal/docannexe/image/4716/img-2.png
Fichier image/png, 18k
Haut de page

Pour citer cet article

Référence électronique

Marie Coris, « Récupération ou hybridation », Terminal [En ligne], 101 | 2008, mis en ligne le 06 septembre 2019, consulté le 22 octobre 2019. URL : http://journals.openedition.org/terminal/4716 ; DOI : 10.4000/terminal.4716

Haut de page

Auteur

Marie Coris

Gretha (UMR CNRS 5113), Université Bordeaux IV. Courriel : marie.coris@u-bordeaux4.fr.

Haut de page

Droits d’auteur

tous droits réservés

Haut de page
  • Logo Télécom École de Management
  • Logo CREIS terminal
  • OpenEdition Journals