Navigation – Plan du site
Dossier

Standards ouverts et implémentations FLOSS : vers un nouveau modèle synergique de standardisation promu par l’industrie du logiciel

Laurent Adatto
p. 137-172

Résumé

Les phénomènes de standardisation ont façonné l’évolution d’une industrie du logiciel structurellement sensible aux rendements croissants d’adoption et à leur effet d’autorenforcement. Or, dans un contexte où cette industrie est toujours plus marquée par l’importance des structures résiliaires (techniques, économiques et organisationnelles), et donc par la nécessité de disposer de dispositifs interopérables, nous allons montrer les avantages et dynamiques d’un nouveau modèle synergique de standardisation, de plus en plus spontanément promu par l’industrie, et liant élaboration coopérative de spécifications en tant que standards ouverts et possibilité de mise en œuvre FLOSS (Free Libre Open Source Software).

Haut de page

Plan

Haut de page

Texte intégral

Introduction

1Les dispositifs logiciels confèrent un rôle central aux normes et aux standards en tant qu’éléments vecteurs des rendements croissants d’adoption [Arthur, 1988], très présents dans l’industrie informatique [Jullien et Zimmermann, 2006], et notamment des interrelations technologiques et des externalités de réseau [Katz et Shapiro, 1985]. Or, dans des contextes concurrentiels marqués par l’importance de ces externalités de réseau, se livrent usuellement des « guerres de standards », telles qu’analysées par David et Greenstein [1990], Besen et Farrell [1994] et Shapiro et Varian [1999], en vue de bénéficier de la profondeur stratégique qu’apporte le contrôle du standard établi.

2En fait, la maîtrise de standards dans l’industrie du logiciel – présentant la caractéristique d’être fortement maillée – a ceci de crucial qu’elle engendre des retombées importantes sur l’évolution des réseaux économico-industriels qui leur sont liés, et donc des produits et marchés y prenant place.

3En effet, les standards structurent les possibilités d’agrégation de technologies complémentaires ou concurrentes, et ainsi, dynamisme et inertie de l’industrie du logiciel sont intimement liés aux standards en présence [Foray, 1990]. Ainsi, cette industrie est tendanciellement sujette à la constitution de positions dominantes, voire de monopoles, provenant de la dynamique d’autorenforcement des rendements croissants d’adoption et de la faiblesse des coûts marginaux de duplication [Jullien et Zimmermann, 2002] et d’extension des produits logiciels [Lang, 1999], or, ces conjonctures sont vecteurs d’enfermement technologique.

4Pour éviter ces situations, nous allons montrer qu’un nouveau modèle de standardisation logicielle est en train d’être promu par l’industrie en se basant sur la définition coopérative et rendue publique de spécifications relativement à la notion de standard ouvert, permettant l’engendrement d’un écosystème concurrentiel d’implémentations, relayé par la possibilité de mise en œuvre de ces spécifications selon le développement FLOSS [Free Libre Open Source Software]. Nous allons déterminer l’impact sur l’évolution de l’industrie du logiciel de ce nouveau modèle de standardisation.

Plan

5Après avoir défini les cadres de transcription de la technologie logicielle et leurs droits de propriété intellectuelle spécifiques [car nous montrerons qu’ils sont à l’origine des différentes formes de normes et standards], nous allons analyser les caractéristiques organisationnelles et procédurales des projets de réussite du modèle FLOSS, en montrant que ces principes sont spécialement optimisés pour recevoir les contributions d’entreprises, notamment pour la production de standards, dans des consortiums de développement logiciel FLOSS. Nous analyserons les limites du cadre de la standardisation de facto relative à l’industrie du logiciel. Nous montrerons les dynamiques industrielles synergiques de l’établissement de standards ouverts implémentables selon le FLOSS. Enfin, nous verrons que le modèle liant standards ouverts et possibilité d’implémentations FLOSS tend à amorcer un nouveau cycle schumpétérien de « destruction créatrice » dans le secteur du logiciel, mais avec des spécificités industrielles nouvelles.

Méthodologie

6Nous avons fondé ces travaux suivant deux axes méthodologiques : un axe de réflexion théorique de recherches et d’analyses sous-tendues par la littérature industrielle, technique et économique relative aux TIC, aux réseaux technologiques et aux processus de standardisation ; un axe d’enquêtes qualitatives et de terrain relatives à :

  • un processus d’élaboration de type consortium de standards ouverts : le JCP [Java Community Process], qui définit les spécifications de l’ensemble des éléments de la technologie Java à la manière de standards ouverts, en enquêtant notamment sur le rôle du JCP auprès d’Alexis Moussine-Pouchkine, qui fut successivement responsable pour Sun Microsystems puis Oracle Corporation du projet GlassFish, implémentation FLOSS d’une spécification du JCP ;

  • un consortium de développement logiciel FLOSS : OW2, acteur majeur du développement de logiciels d’infrastructure FLOSS, notamment en interrogeant Alexandre Lefebvre, Directeur de la technologie d’OW2, sur les liens d’OW2 relatifs aux standards ouverts ;

  • une entreprise dans sa stratégie croisée et synergique de participation à des consortiums d’élaboration de standards ouverts et de développement FLOSS : IBM, en enquêtant notamment auprès de Philippe Bournhonesque, Directeur de la Stratégie Logicielle d’IBM France, et Olivier Bérard, relativement à son rôle d’Open Source Business Developer au sein d’IBM France ;

  • un organisme promouvant les standards ouverts, en interviewant Jochen Friedrich, Technical Relations Executive d’IBM Europe et responsable de la coordination des activités de standardisation logicielle pour l’Europe d’IBM et Président de la Standardisation Task Force d’OpenForum Europe, organisation à but non lucratif originellement fondée en 2002 pour promouvoir l’usage du modèle FLOSS en Europe, notamment auprès des entreprises et des gouvernements, et qui s’est réorientée dans la promotion des standards ouverts, tout en continuant à appuyer le modèle FLOSS, illustration de la corrélation naturelle entre ces deux concepts qui est l’objet de notre analyse dans cet article.

Cadres de transcription de la technologie logicielle et droits de propriété intellectuelle spécifiques, préambule à l’analyse de la standardisation logicielle

Technologie logicielle transcriptible selon deux cadres

7Nous allons d’abord définir que deux cadres servent spécifiquement à transcrire et codifier les technologies logicielles, pour ensuite analyser que chacun de ces cadres peut être lié à un type de DPI [Droits de Propriété Intellectuelle] particulier. Nous analyserons, en effet, que la nature de ces cadres est à l’origine des divers modèles de normes et standards logiciels.

Cadre de la spécification : purement cognitif

8Une spécification est le cadre de transposition purement cognitif d’une technologie logicielle référentielle, non pas prévue pour être directement opérationnelle, mais destinée à être mise en œuvre de manière opérationnelle dans des programmes informatiques. Une spécification est ainsi un ensemble de conditions à remplir pour pouvoir implémenter cette technologie. Une spécification peut être liée à une architecture de système ou de composant, une interface, un format de données, un langage informatique ou un protocole de communication.

  • 1 Bien que certaines méthodes de mise en œuvre, liées principalement aux algorithmes, peuvent être pa (...)

9Les procédures et techniques à employer (algorithmes, langages, outils et méthodes de programmation) pour développer ces implémentations ne font pas partie des spécifications. Ainsi, ces éléments de réalisation peuvent différer1 dans les diverses implémentations d’une même spécification, et font de ces implémentations des produits originaux, qui peuvent se concurrencer techniquement sur la qualité de leur réalisation et leur performance à l’usage.

Cadre du programme informatique : deux formes, cognitive (code-source) et opérationnelle (code-objet)

10Un programme informatique est lui le cadre de transposition dual (cognitif et opérationnel) d’une technologie logicielle destinée à être directement opérationnelle. Sa modélisation première est ainsi purement informationnelle, en revêtant la forme d’un code-source, qui représente une suite d’instructions constituant la transcription d’un algorithme codifié dans un langage de programmation. Sa forme opérationnelle est généralement liée à la compilation du code-source, c’est-à-dire, à sa transformation via un programme dédié, dit compilateur, en code-objet, qui correspond à une suite de données binaires représentant une série d’instructions directement exécutables par la machine.

Droits de propriété intellectuelle relatifs à ces deux cadres de transposition de la technologie logicielle

11La complexité et l’originalité des deux cadres de transposition de la technologie logicielle se sont transposées dans le cadre légal. Comme l’indique Zimmermann [1998, 1999], dans le but d’octroyer un système de protection juridique à la technologie logicielle, la législation américaine s’est établie à considérer trois types d’encadrement des DPI, entre la réglementation du copyright, celle du brevet, et celle du secret de fabrication [protection de l’idée sous-jacente d’une invention, sans divulgation d’informations, mais, concomitamment, sans monopole d’exploitation]. Dalle et David [2005] caractérisent ainsi l’ambivalence des DPI logiciels : « Software, being "a machine" implemented as "text", is unique in being both patentable and copyrightable ».

Brevet lié au cadre de la spécification

12Le dépôt de brevets logiciels est autorisé par certaines juridictions (notamment aux États-Unis, au Japon, mais également en Europe, même si à un niveau moindre). Dans l’industrie, le brevet repose sur la protection des DPI sur une façon novatrice et singulière d’accomplir un élément particulier, en échange de la divulgation de la méthode. Transposé au domaine du logiciel, le brevet est lié à la protection des DPI relatifs à certains procédés [l’éventail des types de procédés brevetables variant en fonction des juridictions] pouvant être mis en œuvre par un système informatique.

13Or, comme nous l’avons indiqué, l’implémentation d’une spécification peut parfois être liée à un ou plusieurs procédés susceptibles d’être couverts par des brevets et très difficilement contournables, voire sans possibilité de mise en œuvre par des méthodes alternatives. Ainsi, les DPI pouvant s’appliquer au cadre de la spécification sont ceux du brevet. Pour pouvoir faire l’objet d’un brevet logiciel, le procédé est censé être inédit et non trivial. Un procédé couvert par un brevet logiciel est alors publié avec un droit exclusif d’exploitation pour une période de vingt ans, comme dans le cas général d’un brevet industriel. En lien à ce droit d’exploitation, peut être contractualisée une licence d’implémentation de brevet logiciel entre le détenteur des DPI du brevet et le licencié, possiblement liée au versement d’une redevance dont le montant peut, par exemple, être indexé sur le nombre de copies distribuées du logiciel implémentant ce brevet.

Copyright/droit d’auteur lié au cadre du programme informatique

14Le copyright/droit d’auteur protège la formulation singulière d’une idée et non pas le concept lui-même. Or, comme nous l’avons vu, le programme informatique formalise justement l’expression particulière d’une abstraction. Ainsi, c’est cette forme de protection des DPI qui s’est établie pour couvrir le logiciel. Le copyright/droit d’auteur est encadré par une licence qui est un contrat entre le détenteur des DPI du logiciel et le licencié. Cette licence stipule les modalités d’utilisation du programme. Généralement, seule l’utilisation est autorisée dans un cadre restrictif privé pour un logiciel propriétaire. Mais, cette licence peut également réglementer les possibilités de diffusion et de modification du programme, ce qui est le cas, comme nous allons le voir maintenant, pour une licence du modèle FLOSS.

Le modèle FLOSS : de la projection d’un cadre de définition de licences à un ensemble de bonnes pratiques procédurales et organisationnelles optimisant le développement logiciel

15Nous avons choisi d’utiliser la terminologie FLOSS, issue des rapports de la Commission européenne, et qui désigne littéralement le « Free Libre Open Source Software », car elle a l’avantage de proposer un générique large et non exclusif du domaine, en se voulant la conjonction du « Logiciel Libre », coordonné par la FSF (Free Software Foundation), et du « Logiciel Open Source », défini par l’OSI (Open Source Initiative).

16Comme nous l’avons indiqué, relativement aux DPI du cadre du programme informatique, le mouvement FLOSS, visant à délimiter des conditions d’utilisation, de modification et de redistribution de logiciels, s’est naturellement incarné en un modèle de licences de logiciels.

17Les principales caractéristiques des licences entrant dans les critères de définition de la FSF et de l’OSI sont que, relativement aux programmes informatiques qu’elles couvrent, sont permis pour tous :

  • l’accès aux codes-sources des programmes ;

  • la modification de ces codes-sources ;

  • la redistribution des programmes, modifiés ou non, incluant leurs codes-sources ;

    • 2 Ces principes d’ouverture du modèle FLOSS le rapprochent des pratiques de contributions scientifiqu (...)

    l’usage de ces programmes sans limitation par rapport aux champs d’applications2.

Les bonnes pratiques du modèle FLOSS : une optimisation des possibilités de coopérations ouvertes

18Les caractéristiques théoriques du modèle FLOSS tendent à lui conférer des particularités de pratiques organisationnelles et procédurales, notamment liées à ses aptitudes à augurer des développements coopératifs de la part de communautés distantes [Demazières, Horn et Jullien, 2005]. En effet, en analysant des projets majeurs du modèle FLOSS, comme le noyau de système d’exploitation Linux, la distribution de système d’exploitation autour du noyau Linux Debian, le système d’exploitation type UNIX FreeBSD, le serveur Web Apache HTTP et l’environnement de bureau KDE, nous allons établir les caractéristiques de leur processus de développement et distinguer l’architecture-type de leur organisation.

Caractéristiques de réussite du développement FLOSS

  • 3 La gestion du noyau Linux, avec à sa tête son créateur et dépositaire de sa licence, Linus Torvalds (...)

19L’analyse du processus de développement de ces projets FLOSS majeurs montre qu’il est itératif, au sens où, basé sur un ajustement constant relativement à des cycles courts de publication de nouvelles versions du programme. Ceci permet ainsi d’intégrer les modifications et évolutions les plus récentes dans un dispositif opérationnel3. L’avantage du modèle FLOSS de pouvoir se référer à la communauté la plus large possible joue un grand rôle dans cette phase d’ajustement constant (remontée de bugs et d’anomalies / correction / perfectionnement), qui est un des vecteurs du haut niveau de qualité des logiciels résultants.

20Ce processus est lié à un découpage des projets en unités logiques permettant un développement modulaire et flexible.

21Il est ouvert et collaboratif entre équipes de programmeurs affiliés, au sein de ces équipes, et au niveau des contributeurs externes provenant de la communauté au sens large. Toutes ces caractéristiques de bonnes pratiques liées au modèle FLOSS en font un vecteur optimisant le développement de logiciels fiables et innovants.

Bonnes pratiques organisationnelles FLOSS

  • 4 Les comités directeurs des grands projets FLOSS comptent généralement une à deux dizaines de membre (...)
  • 5 De l’ordre de 50 pour le serveur Web Apache HTTP et de 400 pour Debian.

22L’analyse de l’architecturation de ces projets FLOSS montre qu’ils sont très généralement organisés selon une structure subordonnée à un comité directeur fixant les axes d’évolution du projet qui guideront les avancées de développement4. Ce développement est pris en charge par des équipes de programmeurs affiliés qui ont accès en écriture aux codes-sources officiels5, auquel s’adjoint l’envoi de contributions de participants extérieurs émanant de la communauté étendue. La promotion permettant d’intégrer les équipes de développement et d’occuper des postes de responsabilités est essentiellement liée au niveau de contribution et d’engagement personnel, et à l’expertise technique.

23Comité directeur, équipes de réalisation et contributeurs ponctuels peuvent être liés à des membres et représentants d’entreprises. Dans les projets FLOSS ayant une importance stratégique pour l’industrie, les contributions provenant d’entreprises sont même souvent très fortement majoritaires par rapport aux contributions bénévoles. L’illustration type pourrait être le projet le plus fondamental du FLOSS, le noyau Linux : 75 % de ses développements jusqu’en mars 2012 ont été réalisés dans un cadre professionnel par des programmeurs rémunérés pour ce faire par des entreprises ayant un lien industriel avec ce projet. Parmi ces sociétés contributrices, on trouve notamment Red Hat (11,9 % des apports), Novell (6,4 %) et IBM (6,1 %) 6. Zimmermann [2005] parle de « virage » dû à la hausse du taux de programmeurs salariés rémunérés pour contribuer à la production FLOSS.

Les consortiums FLOSS : applications des bonnes pratiques du FLOSS dans des structures particulièrement destinées à optimiser la contribution d’entreprises

24Ces bonnes pratiques productives et organisationnelles des projets FLOSS majeurs se trouvent généralisées dans le cadre des consortiums de développement logiciel FLOSS. Les consortiums FLOSS, comme OW2 ou les fondations Apache et Eclipse, sont des associations à but non lucratif dédiées à la production de logiciels FLOSS par la coordination et la mise en commun de ressources humaines et financières fournies par leurs membres. Les choix des orientations de développement, comme l’accès aux comités directeurs des projets et du consortium, se font de manière consensuelle par les membres. L’adhésion est ouverte à tous, le niveau de cotisations commençant généralement à un seuil très modéré à l’échelle d’une entreprise et pouvant dépendre de l’implication souhaitée. Enfin, ces consortiums sont indépendants de tout intérêt externe.

25Ces caractéristiques, ainsi que l’emploi majoritaire de licences FLOSS plus adaptées à un usage commercial et que nous allons analyser, ont été prévues pour faire de ces consortiums FLOSS, des vecteurs privilégiés de larges contributions d’entreprises [d’ailleurs, ces consortiums sont généralement fondés par des entreprises], et en premier lieu, comme nous le montrerons, dans le développement de standards.

Industrie du logiciel, standards de facto et inclinaison à l’établissement de positions dominantes

Standard de facto

26Un standard de facto d’une technologie logicielle est lié à tout élément technologique logiciel dont l’usage a pu s’imposer largement sans avoir eu besoin d’être approuvé par un organisme de normalisation ou géré par un consortium de développement de standard. L’élément technologique concerné peut ainsi être lié à un des deux cadres de transcription de la technologie logicielle précédemment définis, c’est-à-dire, soit un logiciel, soit une spécification.

27Comme nous l’avons indiqué en introduction, l’agrégation d’acteurs économico-industriels vers une technologie nouvelle [pas forcément innovante] dans une gamme encore non défrichée peut en faire un standard de facto par le jeu des rendements croissants d’adoption [Arthur, 1988] qui ont toujours été prééminents dans le domaine du logiciel [Jullien et Zimmermann, 2006], cette inclinaison s’étant renforcée suivant l’évolution résiliaire de l’industrie informatique, de plus en plus constituée en étroits maillages de dispositifs technologiques interconnectés.

Le rôle déterminant des interfaces de programmation et des formats de données

28Comme nous allons maintenant l’analyser, relativement à ces structures de réseaux où se déploie la technologie logicielle, la centralité et l’importance des éléments d’interfaces tendent à faire que la standardisation de facto puisse rapidement aboutir à des situations de positions dominantes autour des standards ainsi engendrés.

29En informatique, une interface correspond au dispositif technique qui permet aux différents acteurs et composants impliqués [programmes informatiques, données, matériels, humains] d’interagir et d’échanger des informations. Deux types d’interfaces ont une importance cruciale dans l’industrie du logiciel, car la fermeture et le contrôle de leurs spécifications de manière privée peuvent octroyer à leurs détenteurs un pouvoir certain quant aux futurs développements du marché lié :

  • les interfaces de programmation ou API [Application Programming Interface], qui permettent les interactions relatives aux programmes informatiques entre eux ;

  • les formats de données, qui sont les interfaces liées aux interactions entre les programmes informatiques et le contenu de ces données.

30Microsoft a notamment pu maintenir une situation quasi monopolistique de ses systèmes d’exploitation MS-DOS puis Windows dans l’équipement des compatibles PC, car, plus que tout autre logiciel, les systèmes d’exploitation portent à son paroxysme l’importance des interfaces de programmation, car elles formalisent les conditions de compatibilité entre ces systèmes et l’ensemble des applications pouvant y prendre place.

31Les interfaces de programmation ont deux faces pour permettre l’interfaçage entre deux types de dispositifs logiciels. Ainsi, dans le cas des interfaces de programmation relatives aux systèmes d’exploitation, elles ont une face liée aux systèmes d’exploitation et une autre face relative aux applications pouvant être chargées sur ces systèmes d’exploitation.

  • 7 Successivement, l’API de MS-DOS, MS-DOS API, puis les API de Windows, Win16, Win32 et Win64, pour r (...)

32Or, pour les interfaces de programmation liées à ses systèmes d’exploitation7, Microsoft a ouvert leurs spécifications sur leur face application pour que des développeurs et éditeurs de logiciels externes puissent réaliser des applications compatibles avec ses systèmes d’exploitation, et ainsi renforcer leur position de standards de facto due aux rendements croissants d’adoption liés à la possibilité du développement du plus grand nombre d’applications. Mais, Microsoft a laissé fermer les spécifications de ces interfaces sur leur face système d’exploitation pour être le seul acteur à détenir la connaissance de leurs informations spécifiques, et qu’ainsi des acteurs extérieurs ne puissent les mettre en œuvre dans le développement de systèmes d’exploitation concurrents pouvant prendre en charge les mêmes applications que les systèmes d’exploitation de Microsoft, et donc bénéficier du même parc d’applications, et proposer des systèmes d’exploitation substituables par rapport à ceux de Microsoft. Ainsi, Microsoft a pu maintenir sa domination du marché par ce biais, après avoir bénéficié d’une présence sans concurrence réelle au début de l’ère du compatible PC.

33Ainsi, un acteur détenant le contrôle des spécifications de ces interfaces peut moduler sa stratégie en fonction de ses intérêts.

34Dans le cas des interfaces de programmation :

  • soit fermer complètement la spécification de son interface [c’est-à-dire, la contrôler seul dans un cadre strictement privé], comme dans le cas analysé par Zimmermann [1999], lorsque Sega a fermé l’interface de programmation du système d’exploitation de ses consoles Megadrive/Genesis sorties en 1988 pour avoir un monopole sur l’édition de jeux pouvant y être chargés, et donc contrôler leur marge de prix pour des utilisateurs enfermés dans un marché captif ;

  • soit ouvrir la spécification de son interface sur une seule face [c’est-à-dire, rendre publique la seule partie de la spécification concernant cette face, et garder secret la partie de la spécification concernant l’autre face], comme nous venons d’en analyser les tenants pour les systèmes d’exploitation de Microsoft ;

  • soit même, ouvrir la spécification de son interface sur ses deux faces [c’est-à-dire, rendre la spécification de l’interface intégralement publique], si le but est d’optimiser son adoption sans vouloir en contrôler, seul, une partie. La recherche de modèles d’affaires a alors lieu à un autre niveau que sur le contrôle de l’interface. C’est par exemple ce que Sun a fait en ouvrant complètement les spécifications des différents éléments de sa technologie Java, interfaces comprises, et en développant des stratégies de monétisation annexes (nous reviendrons sur ce cas relativement à l’analyse industrielle des standards ouverts et des implémentations FLOSS dans la partie 5 de nos travaux).

35Le contrôle privé de spécifications de formats de données est lié à un schéma analogue : leurs détenteurs peuvent conserver leurs spécifications fermées, ou en moduler l’ouverture, pour permettre, ou non, l’implémentation au sein de programmes tiers de tout ou partie des traitements relatifs à ces formats (lecture, création et modification de données liées à ces formats), selon le souhait de vouloir garder un monopole sur les logiciels supportant ces formats ou de vouloir les diffuser.

36La fermeture partielle ou complète des spécifications de ces interfaces liées à des produits logiciels en position dominante peut ainsi empêcher la possibilité d’une concurrence réelle, conduire à un enfermement technologique, et inhiber la dynamique d’innovation, comme l’analyse Zimmermann [1998, 1999], pour qui, idéalement et relativement à la notion de système ouvert, les interfaces devraient être normalisées dans un souci de promouvoir l’interopérabilité. Au sein des produits logiciels, seule la couche constituant ces interfaces nécessiterait d’être normalisée, le reste pouvant demeurer de l’ordre du design propriétaire. L’interopérabilité implique, en effet, que l’ensemble des spécifications d’interfaces entre produits ou systèmes interopérables soit entièrement référencé, et publiquement et librement accessible et implémentable. Nous allons maintenant voir que ces conditions de spécifications posant les bases de l’interopérabilité peuvent être attachées, de façon optimale, à la notion de standard ouvert, pour notamment permettre une mise en œuvre selon le modèle FLOSS.

Vers un nouveau modèle de standardisation, les standards ouverts : de la nécessité d’une adéquation avec le modèle FLOSS

37Nous allons tout d’abord analyser les distinctions entre normes et standards ouverts.

Norme

38Une norme correspond à une spécification qui a été validée et publiée par un organisme de normalisation reconnu pour ce faire, comme l’ISO (International Organization for Standardization) ou l’IEC (International Electrotechnical Commission).

  • 8 La dénomination FRAND étant plus courante en Europe, alors qu’aux États-Unis, le sigle RAND est dav (...)
  • 9 ISO et IEC employant la dénomination RAND.

39Nous avons vu qu’une spécification peut être liée à des brevets sur des procédés potentiellement incontournables pour en réaliser une implémentation. Or, un critère exigé pour que des spécifications soient validées en tant que normes par l’essentiel des organismes de normalisation est que les détenteurs des brevets relatifs à ces spécifications licencient leur droit d’implémentation selon des termes FRAND ou RAND8. Une licence d’implémentation de brevet dite F/RAND (Fair / Reasonable And Non-Discriminatory) implique qu’elle soit contractable par tous, et que, si une redevance est associée à la licence, cette redevance soit modérée par rapport à un usage marchand du logiciel implémentant le brevet, et que le taux de la redevance éventuelle soit le même pour tous les licenciés. Par exemple, la redevance relative aux brevets liés à la mise en œuvre des spécifications d’encodage et de décodage du format de vidéo compressé MPEG2 du groupe homonyme, qui sont normalisées par l’ISO et l’IEC, et donc, à ce titre, qui sont liées à des termes RAND9, est, depuis le 1er janvier 2010, de 2 dollars pour chacune des deux spécifications implémentées et par unité distribuée du produit incorporant une implémentation.

Standard ouvert

40Un standard ouvert recouvre toujours une spécification visant à permettre des implémentations de la technologie concernée comme la norme. Il existe de multiples définitions relatives à la notion de standard ouvert, émanant notamment d’institutions gouvernementales, d’entreprises, d’associations FLOSS, et même de consortiums qui se définissent eux-mêmes comme coordonnant le développement de standards ouverts.

41Pour notre analyse, nous avons essayé d’établir une définition consensuelle sur une base convergente : dans cette perspective, nous avons abouti au fait qu’un standard ouvert doit être élaboré, approuvé et maintenu dans le cadre d’un processus collaboratif transparent coordonné par un organisme technologiquement et commercialement neutre (c’est-à-dire, n’orientant pas ses décisions pour privilégier subjectivement des technologies déjà en place ou des intérêts marchands particuliers). Ce processus doit être basé sur la recherche de consensus, et ouvert à tout acteur souhaitant y prendre part. Les avancements des travaux doivent être accessibles, et la spécification résultante doit être publiquement publiée pour permettre sa mise en œuvre par tout acteur souhaitant en réaliser une implémentation.

  • 10 Mark Ferrar, National Technology Officer de Microsoft Grande-Bretagne, en relation à une consultati (...)
  • 11 Free Software Foundation Europe, filiale européenne de la FSF.
  • 12 Nous pouvons même dire que ce consortium a été l’un des principaux vecteurs ayant permis un dévelop (...)

42Néanmoins, sur cette base commune que nous avons établie, les définitions des standards ouverts peuvent diverger sur un point dont nous montrerons qu’il est crucial pour l’implémentation selon le modèle FLOSS : le type d’encadrement des DPI. Un standard ouvert étant une spécification, il peut donc être lié à des DPI relatifs à des brevets. Dans ce cadre, deux types de définitions diffèrent. Celle qui lie les DPI à des termes F/RAND, cette définition provenant notamment de grandes firmes10 du logiciel. Et celle qui implique que ses termes soient uniquement Royalty Free, sans autre formalité, cette définition émanant de plusieurs sources institutionnelles, gouvernementales ou juridiques (notamment en Europe, l’Union européenne, la France, le Danemark et l’Espagne), de fondations FLOSS (dont l’OSI et la FSFE11), et de consortiums gérant le développement de standards ouverts, notamment le W3C (World Wide Web Consortium), très important consortium dans le domaine des technologies Web12, qui publie des recommandations définissant des spécifications à valeur de standards ouverts, parmi lesquelles le HTML (HyperText Markup Language) et le XML (eXtensible Markup Language).

43Justement concernant le W3C, au début de la décennie 2000, plusieurs entreprises membres du consortium avaient plaidé pour une prise en compte de la possibilité de licencier selon le F/RAND des brevets logiciels au niveau des recommandations du consortium. Mais, la position du W3C a été réaffirmée en novembre 2002 par le PPWG (Patent Policy Work Group) du consortium, qui a notamment rejeté par un vote la possibilité de lier des recommandations W3C à des licences d’implémentations de brevets sur des termes F/RAND. Les propriétaires de brevets couvrant des technologies soumises au consortium ont donc dû continuer à s’engager à renoncer à leurs DPI concernant ces brevets si leurs spécifications sont reconnues comme recommandations, et donc standards ouverts, par le consortium. Sir Timothy John Berners-Lee, le célèbre pionnier des technologies web, et président et fondateur du W3C, s’était notamment élevé contre une évolution du consortium favorable à l’incorporation des brevets logiciels, même selon des termes F/RAND.

44Il est possible qu’un standard ouvert soit également une norme. Des consortiums, comme justement toujours W3C, coordonnant le développement de standards ouverts, peuvent soumettre leurs spécifications à des organismes de normalisation pour en faire, en plus de standards ouverts, des normes. Il peut même y avoir des accords entre ces deux types de structures pour accélérer le processus de normalisation des spécifications proposées. Ainsi, le W3C a un agrément avec les organismes internationaux de normalisation ISO et IEC. Cet agrément [dit procédure de soumission d’une Spécification Publiquement Disponible, ou Publicly Available Specification] confère aux organismes accrédités, la possibilité de soumettre les spécifications issues de leurs travaux, et situées dans le champ des technologies de l’information couvertes par le JTC1 (Joint Technical Committee 1), qui est le comité technique conjoint à l’ISO et à l’IEC, directement à la phase de vote par pays du processus de normalisation ISO/IEC. Ainsi, la version 4.01 de la spécification HTML est un standard ouvert W 3 C13 et une norme ISO/IEC14.

Position de la Commission européenne sur les spécifications et standards ouverts

  • 15 Successivement, IDA (Interchange of Data between Administrations) lancé en 1995 (version 1, puis ve (...)

45La Commission européenne a mis en place, depuis 1995, une suite de programmes quinquennaux consécutifs15 dans le but de favoriser l’interopérabilité des systèmes logiciels pris en charge par les administrations publiques des États membres, pour notamment faciliter la transmission de données numériques et optimiser les possibilités de coopérations à l’échelle européenne. Ces programmes se sont formalisés dans l’établissement du cadre européen d’interopérabilité EIF (European Interoperability Framework for pan-european egovernment), dont le but est de définir une série de recommandations et principes visant à améliorer l’interopérabilité dans cette perspective.

46Or, ces travaux ont eu une grande importance, puisqu’ils ont abouti à ce que la Commission européenne, dans le cadre d’une communication sur l’interopérabilité datant du 13 février 2006, préconise officiellement l’utilisation des standards ouverts en en précisant sa définition basée sur le rapport EIF (version 1.0), publié en novembre 2004. Cette définition était très proche de celle dont nous avons fait la synthèse précédemment, et était explicite sur le point litigieux que nous avons mis en exergue : les DPI d’un standard ouvert devaient être mis à disposition sans redevance, et ceci de manière irrévocable.

47Or, nous allons voir que la donne a considérablement changé lorsque la Commission européenne a adopté, dans le cadre d’une nouvelle communication datant du 16 décembre 2010, les préconisations de la seconde version du rapport EIF16. Celle-ci est décrite par Trond Undheim, directeur de la stratégie standards d’Oracle comme : « The most controversial document in the history of the European Commission’s IT policy. »17

48L’ouverture est dans ce rapport transcrite par la notion d’openness, et la nouvelle formulation de spécifications ouvertes remplace celle de standards ouverts.

  • 18 « Intellectual property rights related to the specification are licensed on FRAND terms or on a roy (...)

49Si le rapport préconise l’emploi de spécifications ouvertes, il en modifie la forme, car, contrairement à la définition des standards ouverts, celle des spécifications ouvertes n’implique pas que les éléments de DPI inclus soient forcément licenciés sur une base Royalty Free. Ils peuvent en effet l’être également selon des termes FRAND, le rapport indiquant que les licences FRAND ou Royalty Free associées aux brevets liés aux spécifications permettent leur implémentation selon un développement propriétaire ou FLOSS. Et qu’ainsi, les sociétés liées à ces différents modèles économiques sont mises en situation égale de concurrence pour fournir des solutions mettant en œuvre ces spécifications à destination des administrations publiques européennes18.

50Pourtant, nous allons analyser que les modifications apportées par cette seconde version de l’EIF ont des implications certaines sur les possibilités d’implémenter ces spécifications dans le cadre du développement FLOSS.

Licences F/RAND et conséquences sur les possibilités de développements FLOSS

  • 19 L’article correspondant de la licence GPL 3 indiquant : « Each contributor grants you a non-exclusi (...)

51Les licences F/RAND qui imposent le versement de redevances ne peuvent faire l’objet d’implémentations sous de nombreuses licences FLOSS, à commencer par la plus employée d’entre elles, la GPL (GNU General Public License) versions 2 et 3, dont les termes impliquent des redistributions Royalty Free19.

52Cependant, les licences F/RAND peuvent ne pas demander l’acquittement de redevances (elles sont alors parfois désignées en tant que F/RAND-Z : F/RAND-Zero royalty ou F/RAND-RF : F/RAND-Royalty Free).

53Mais, les licences F/RAND, y compris celles qui n’impliquent pas le paiement de redevances, nécessitent la passation d’un contrat entre le détenteur du brevet et le licencié souhaitant implémenter le brevet, dont les termes peuvent ne pas autoriser au souscrivant de sous-licencier le droit d’implémentation du brevet, c’est-à-dire, de le conférer à un tiers lors d’une redistribution de l’implémentation. Ainsi, il existe une différence notable entre des brevets licenciés sur des termes F/RAND-Royalty Free liés à ces conditions, et Royalty Free sans condition, car, contrairement aux seconds, les premiers prohibent le sous-licenciement des brevets.

  • 20 Les termes de la licence GPL 3 précisent à ce propos : « For purposes of this definition, “control” (...)

54Or, dans le cadre du FLOSS, cette différence s’avère fondamentale, car l’interdiction de sous-licenciement des brevets est proscrite dans les termes de nombreuses licences FLOSS, notamment, encore une fois, la GPL20. Or, la licence GPL s’est imposée comme la pierre angulaire du développement FLOSS, et est estimée couvrir 60 % des projets FLOSS en janvier 2013. Son succès s’explique notamment par son principe de copyleft fort.

55La notion de copyleft fort implique que la licence originale intégrant cette notion s’applique également à toute redistribution, comprenant d’éventuelles modifications, du programme qu’elle couvre (caractère héréditaire du copyleft), et que, si des composants lui sont adjoints, ils doivent aussi être couverts par cette licence (caractère viral du copyleft fort). Ainsi, par ses caractéristiques, une licence comme la GPL est la plus à même de permettre la création d’un patrimoine FLOSS inappropriable de manière privative. Jullien [2001] voit ainsi en la GPL « un puissant outil pour lutter contre le hasard moral ».

  • 21 La licence LGPL 3 incorporant les termes de la licence GPL 3, notamment ceux faisant référence aux (...)
  • 22 L’article de la licence Apache 2.0 référent étant : « 2. Grant of Copyright License. Subject to the (...)

56De plus, les licences F/RAND ne sont pas uniquement discriminantes pour la licence GPL. En effet, de nombreuses autres licences FLOSS, même présentant un niveau plus faible de copyleft, sont incompatibles avec l’interdiction du sous-licenciement des brevets lors des redistributions. C’est notamment le cas pour la licence LGPL21 (GNU Lesser General Public License), ayant un niveau de faible (héréditaire, mais non virale, c’est-à-dire, que, relativement au programme sur lequel cette licence s’applique, ses modifications doivent être couvertes par la même licence, mais que le programme peut être combiné à des composants couverts par d’autres licences), ou la licence Apache22 (issue de la fondation FLOSS homonyme), sans (non héréditaire et non virale, c’est-à-dire, que les redistributions du programme lié peuvent être couvertes par d’autres licences).

57Ces deux dernières catégories de licences FLOSS peuvent parfois être privilégiées par les entreprises, car elles permettent respectivement de combiner et d’intégrer les programmes couverts à des logiciels propriétaires. C’est pour cela qu’elles sont employées très majoritairement par les consortiums FLOSS (la licence Eclipse Public License présentant des caractéristiques analogues à celles de la LGPL), comme nous l’avons indiqué, vecteurs privilégiés et optimisés pour la contribution FLOSS d’entreprises. Ainsi, les licences d’implémentation de brevets F/RAND sont incompatibles avec l’essentiel des licences FLOSS, et sont davantage en adéquation avec des licences hybrides permissives, telles qu’analysées par Jullien et Zimmermann [2006].

Nouveau règlement européen sur la normalisation entré en vigueur le 1er janvier 2013 et spécifications techniques dans le domaine des TIC

58Relativement à notre travail sur les standards ouverts et les possibilités d’implémentations FLOSS, nous avons analysé la modification d’approche des communications de la Commission européenne sur le sujet, faisant d’abord référence, dans la communication du 13 février 2006, à des standards ouverts, avec une définition excluant toute redevance relative aux éventuels brevets logiciels liés, puis, dans la communication du 16 décembre 2010, à des spécifications ouvertes pouvant intégrer des DPI inhérents à des licences FRAND et donc, comme nous l’avons analysé, ne permettant pas que ces spécifications ouvertes puissent être implémentées selon un très grand nombre de licences FLOSS, alors que, comme nous l’avons vu, le rapport EIF 2.0, à l’origine de cette seconde communication, fait référence à ces spécifications ouvertes en indiquant qu’elles doivent permettre d’augurer d’une pluralité d’implémentations possibles, aussi bien selon le modèle propriétaire que FLOSS, et encourage les services publics européens à les adopter, notamment dans un souci d’interopérabilité à l’échelle de l’Union.

59Dans ce contexte, il convient d’analyser le nouveau règlement européen sur la normalisation entré en vigueur le 1er janvier 2013 : Règlement (UE) N° 1025/2012 du Parlement et du Conseil du 25 octobre 2012 relatif à la normalisation européenne, modifiant les directives 89/686/CEE et 93/15/CEE du Conseil ainsi que les directives 94/9/CE, 94/25/CE, 95/16/CE, 97/23/CE, 98/34/CE, 2004/22/CE, 2007/23/CE, 2009/23/CE et 2009/105/CE du Parlement européen et du Conseil et abrogeant la décision 87/95/CEE du Conseil et la décision N° 1673/2006/CE du Parlement européen et du Conseil.

60Ce règlement met en exergue l’importance des normes et de l’identification des spécifications techniques dans le cas où compatibilité et interopérabilité avec des produits ou systèmes tiers s’avèrent déterminantes.

61Le règlement stipule l’intérêt de la normalisation dans le développement de la technologie et de l’innovation. Il est fait état de l’intérêt des normes et des spécifications techniques pour étendre l’interopérabilité des réseaux et la qualité des outils et des moyens de communication. La normalisation, telle que décrite dans ce règlement, a également pour objet de permettre une meilleure circulation des biens et services. L’ensemble des avantages attendus par ce règlement devant avoir un impact potentiellement très positif sur l’activité des institutions publiques (les organismes publics sont sollicités pour davantage prendre part à ces travaux de normalisation, ainsi que les associations de consommateurs et tous les acteurs sociaux ayant des intérêts liés), la compétitivité des entreprises (le texte insiste notamment sur le rôle accru que doivent jouer les PME dans les processus de normalisation) et sur la croissance économique.

  • 23 Annexe II : Exigences applicables pour l’identification de spécifications techniques des TIC

62L’annexe II du règlement est particulièrement importante dans notre analyse, car elle traite des spécifications techniques dans le domaine des TIC23. Cette annexe stipule, pour l’identification et la prise en compte par l’Union des spécifications techniques dans le domaine des TIC, des principes proches de ceux énoncés pour les spécifications ouvertes du rapport EIF 2.0, l’essentiel convenant à notre définition optimale et souhaitable des standards ouverts, sauf, comme au niveau du rapport EIF 2.0, concernant les DPI liés à ces spécifications, où des licences de brevets selon les termes FRAND sont encore admises, ce qui, comme nous l’avons analysé, exclu une mise en œuvre selon l’essentiel des licences du modèle FLOSS.

63Ainsi, en conclusion et concernant notre domaine d’analyse, ce nouveau règlement ne propose pas de changement par rapport aux derniers rapports et communications de la Commission sur le sujet.

Standards ouverts, potentialités optimales de mises en œuvre selon la plus grande pluralité de modèles économiques et implémentations FLOSS

64Nous allons montrer l’intérêt des standards ouverts inclusifs d’un développement selon l’ensemble du modèle FLOSS, et donc relatifs à des termes Royalty Free, en adoptant ainsi une définition analogue à celle des instances gouvernementales qui ont déjà statué sur ce sujet, Jochen Friedrich, responsable de la coordination des activités de standardisation logicielle pour l’Europe d’IBM et Président de la Standardisation Task Force d’OpenForum Europe, organisation à but non lucratif chargée de promouvoir l’usage des standards ouverts et de soutenir le modèle FLOSS en Europe, notamment auprès des entreprises et des gouvernements, nous indiquant à ce propos : « When we use the term in OpenForum Europe, we mean a standard that is available Royalty Free. »

65Ceci est important puisqu’un standard ouvert permet potentiellement d’engendrer un écosystème optimisant la possibilité d’une mise en œuvre concurrentielle d’implémentations relatives à la spécification qu’il recouvre, et que cette définition permet aux implémentations FLOSS d’enrichir cet écosystème. Les utilisateurs et/ou clients de ce standard ouvert peuvent ainsi déterminer le choix d’adoption de l’implémentation qu’ils utilisent, aussi bien sur la qualité de mise en œuvre de la spécification, que sur son modèle d’affaires, parmi les implémentations proposées, qu’elles soient licenciées de manière propriétaire ou FLOSS.

66Les utilisateurs et/ou clients ne sont, en outre, pas enfermés dans un marché captif, puisque la conformité à la spécification du standard ouvert garantit la substituabilité des implémentations. La portabilité du standard ouvert, c’est-à-dire, la possibilité d’en réaliser des implémentations opérationnelles dans différents environnements d’exécution logiciels (systèmes d’exploitation) et/ou matériels (types d’architectures de processeurs), est aussi optimale, puisque, par définition, un standard ouvert ne peut imposer une mise en œuvre restreinte à une solution technique logicielle ou matérielle. Or, pour Zimmermann [1999], ces deux notions de substituabilité et de portabilité des produits logiciels sont les deux principales conditions nécessaires à l’avènement d’un marché du logiciel réellement concurrentiel.

Standards ouverts et amoindrissement des risques d’investissements

67L’intérêt des standards ouverts est aussi d’optimiser le retour sur investissement relatif aux spécifications et aux implémentations liées. En effet, nous avons vu que le développement de pré-standards dans l’industrie du logiciel était très incertain, et que beaucoup étaient abandonnés en cours de route dans la lutte entre acteurs industriels pour établir la domination de leur standard dans un domaine donné. Les standards ouverts, même à l’état de pré-standard, c’est-à-dire, pas encore établis dans l’industrie, maximisent, eux, leur potentiel d’adoption par le marché, puisque les acteurs peuvent coopérer à leur définition, et réduisent donc les risques d’investissement à perte très présents dans le cadre de pré-standards non ouverts.

Interopérabilité optimisée

68Les standards ouverts permettent, d’un point de vue technique, la mise en œuvre en toute transparence des spécifications d’interfaces qui leur sont liées (puisque celles-ci sont incluses dans les spécifications globales des standards ouverts), et garantissent ainsi l’interopérabilité. Celle-ci est, de plus, renforcée en permettant que des implémentations FLOSS puissent faire partie des dispositifs interopérables. Dans cette perspective, Jochen Friedrich nous a indiqué : « For standardisation in the area of software interoperability, it is clear that Open Standards should be required so that implementation in Open Source is possible. Software interoperability has proved to be a key driver for innovation. The availability and broad adoption of Open Standards is key here. »

Standards ouverts et dynamique de coopétition

69Nous allons analyser que le modèle lié aux standards ouverts peut engendrer une dynamique de « coopétition », relativement au concept mêlant coopération et compétition théorisé par Brandenburger et Nalebuff [1996].

70En effet, appliquée aux standards ouverts, la dynamique de coopétition repose sur :

  • une partie « protégée » et non soumise à la compétition où les acteurs peuvent d’abord définir et faire évoluer de manière mutualiste et consensuelle la spécification constituant le standard ouvert, ce qui permet de renforcer sa stabilité technologique ;

  • un domaine « concurrentiel » où est laissée aux acteurs la possibilité de se concurrencer dans le domaine de la mise en œuvre de cette spécification standardisée relativement à leur implémentation produit propre.

71En fait, la coopétition dérive de la théorie des jeux dans l’intérêt des ententes entre rivaux. Elle trouve son intérêt dans des contextes mouvants avec des probabilités de fortes discontinuités, dont justement l’histoire de la standardisation industrielle logicielle de facto a été coutumière : il est de l’intérêt des acteurs industriels engagés de mutualiser leurs efforts pour creuser un sillon commun qui limite les risques relatifs à l’évolution globale de la technologie et du tissu industriel lié. Les entreprises peuvent alors se recentrer sur les éléments les différenciant, et où elles peuvent chercher à établir un avantage concurrentiel : elles redeviennent ainsi compétitrices hors de ce sillon. La compétition est d’autant plus saine que ce sillon constitue un standard ouvert, donc, comme nous l’avons vu, élaboré de façon neutre, au-dessus duquel prennent place les actifs de compétition. Relativement à un standard ouvert, les clients de « coopétiteurs » ont le choix entre des produits rivaux implémentant la même spécification standardisée. Ainsi, l’avantage concurrentiel peut s’établir sur la qualité, les services liés, le modèle économique et/ou les orientations propres du produit. Cet avantage concurrentiel n’est ainsi plus lié à l’infrastructure de portage, c’est-à-dire, la spécification relative à un standard ouvert, puisque cette infrastructure ne peut brider la compétition industrielle en étant détenue de manière privative, puisqu’en l’occurrence il s’agit du sillon commun et standardisé.

Avantages de la combinaison standards ouverts et implémentations FLOSS

72Si la notion d’ouverture fait référence à une spécification pour un standard ouvert, et à un code-source pour un logiciel FLOSS, néanmoins, ces deux principes d’ouverture peuvent se combiner lors de la mise en œuvre d’un standard ouvert dans une implémentation FLOSS. Nous allons analyser les dynamiques et avantages industriels liés à cette association.

Mutualisations d’efforts induites par la notion d’ouverture commune aux standards ouverts et aux logiciels FLOSS

73Relativement aux standards ouverts et aux implémentations FLOSS, les efforts de développement des acteurs industriels tendent à être portés, non sur le souhait de maintenir leur position de force comme au niveau de produits logiciels standards de facto propriétaires fermés cloisonnant un marché, mais sur l’innovation et la recherche de la meilleure qualité intrinsèque :

  • concernant l’évolution de la spécification du standard ouvert ;

  • relative à la mise en œuvre au niveau des implémentations de cette spécification pour établir un avantage compétitif par rapport aux implémentations concurrentes ;

  • mutualisée, si cette mise en œuvre est liée à une implémentation FLOSS, puisque l’ouverture des codes-sources, ainsi que la liberté pour chacun de participer à leur développement, optimisent les possibilités que des implémentations FLOSS soient réalisées de manière coopérative.

Consortiums de standards ouverts et consortiums de développement logiciel FLOSS : de nombreux points communs

74Relativement à ce dernier cas, un nouveau modèle de standardisation semble s’établir, liant, pour des mêmes acteurs industriels, élaboration coopérative des spécifications de standards ouverts au sein de consortiums dédiés, et réalisation mutualisée de leurs implémentations FLOSS à l’intérieur de consortiums de développement logiciel FLOSS, tels que précédemment définis. Comme nous l’avons analysé, ces deux types de consortiums présentent de nombreux points communs, notamment liés à la volonté de recueillir l’adhésion et la contribution d’entreprises, allant de l’indépendance technologique et commerciale, jusqu’à l’élaboration d’un processus de développement consensuel et ouvert.

Consortiums de standards ouverts, consortiums FLOSS et contributions des acteurs industriels : des liens de plus en plus symbiotiques, enquêtes de terrain

75Relativement aux synergies possibles entre ces deux types d’organisations et les acteurs industriels membres, nous avons mené plusieurs enquêtes qualitatives et de terrain.

  • 24 L’OSGi (Open Services Gateway initiative) Alliance est un consortium coordonnant, en tant que stand (...)

76Dans ce cadre, Alexandre Lefebvre, CTO / Directeur de la technologie du consortium FLOSS OW2, nous a indiqué à propos des dynamiques en cours et espérées : « La décision a été prise au départ : OW2 n’est pas une instance de normalisation ou de standardisation. Il s’agit là d’un métier différent qui requiert des ressources et des processus différents. Il a donc été décidé qu’OW2 inciterait les projets à se conformer aux standards existants. Cependant, il est également encouragé que chaque membre d’OW2 participe, dans la mesure du possible, aux instances de standardisation. Ceci est le cas par exemple pour OSGi24 ou encore Java et le JCP. »

77Nous avons justement mené une enquête relative au JCP [Java Community Process], processus gérant l’élaboration de l’ensemble des spécifications liées à la technologie Java à la manière de standards ouverts.

78Le JCP a été institué en 1998 par Sun, créateur de la technologie Java, devant la multiplication, à partir du milieu des années 1990, des environnements parallèles à Java développés par d’autres entreprises et présentant des incompatibilités avec le Java original, ce qui faisait encourir le risque d’un affaiblissement de l’universalité de réalisation et d’exécution de Java, qui était le credo de Sun depuis le lancement de sa technologie (dont le slogan reflétait à lui seul l’exigence de compatibilité : « Write once, run anywhere »). Ainsi, l’ouverture et la possibilité pour l’ensemble des acteurs industriels de participer à l’évolution des spécifications des différents éléments de la technologie Java dans une structure de type consortium a permis de contrer ce risque en désamorçant l’essentiel des velléités d’acteurs tiers de créer leur propre Java incompatible, ce qui constitue un autre avantage industriel des standards ouverts.

79La technologie Java, telle que standardisée par le JCP, relève des deux formes liées aux standards analysées par Foray [1993] :

  • standard de qualité : au sens où la technologie porte sur des spécifications intrinsèques jugées comme estimables par les acteurs extérieurs (puisque, dans le cas de Java, élaborées de façon mutualiste), permettant ainsi une cohérence des activités industrielles liées ;

  • standard de compatibilité : au sens où d’importants efforts tendent à s’exercer sur l’élaboration des interfaces de la technologie standardisée afin qu’elle demeure compatible.

80Relativement au fonctionnement du JCP, JBoss, la division de Red Hat à l’origine du serveur d’application FLOSS JBoss Application Server, implémentant sous licence LGPL la spécification de la plate-forme Java Enterprise Edition a pu, par la qualité de ses contributions à la définition de cette spécification, intégrer les structures exécutives du JCP, Alexis Moussine-Pouchkine nous indiquant : « Je dois dire que le comportement de JBoss est assez exemplaire en matière de participation à la définition de standards communs. Oracle / Sun propose un cadre de travail : le JCP, certains sont de bons élèves, d’autres pensent un peu trop que l’affrontement doit avoir lieu sur la définition du standard plutôt que sur les qualités de son implémentation. La compatibilité reste une qualité majeure de Java. Il n’y a qu’un seul Java, et sa compatibilité, même si elle peut frustrer certains, est la raison de son succès en entreprise. »

81Oracle, à la suite de Sun après son rachat de l’entreprise en avril 2009, est l’un des contributeurs les plus actifs à l’élaboration des spécifications de Java à l’intérieur du JCP, et à leur mise en œuvre selon le modèle FLOSS, puisque, depuis la seconde moitié des années 2000, Sun avait ouvert les codes-sources selon le modèle FLOSS de toutes ses implémentations des différents éléments de la technologie Java.

82IBM est également membre du comité directeur du JCP et contribue, depuis 2010, au développement d’OpenJDK, implémentation FLOSS d’Oracle de la spécification définie au sein du JCP de la plate-forme Java Standard Edition.

83Dans cette voie, nous avons justement mené une enquête à propos du développement d’IBM relatif aux standards ouverts et au modèle FLOSS, Philippe Bournhonesque, directeur de la stratégie logicielle d’IBM France, nous a indiqué que c’était pour IBM :

  • le moyen de créer de manière collaborative des composants logiciels essentiels FLOSS, ainsi que des standards ouverts. Par exemple, IBM coopère notamment avec Oracle à un double niveau : à l’élaboration du jeu de spécifications SCA (Service Component Architecture), qui est coordonné par le consortium OASIS (Organization for the Advancement of Structured Information Standards) en tant que standard ouvert, et au développement de son implémentation FLOSS, Apache Tuscany, au sein de la fondation Apache ;

  • la possibilité d’intégrer des composants logiciels FLOSS dans les propres logiciels d’IBM, faisant ainsi baisser les coûts pour l’entreprise, et permettant à IBM de se focaliser sur des briques à plus forte valeur ajoutée, ainsi que de fournir des solutions intégrées ;

  • en participant à leur développement, le moyen de renforcer plusieurs technologies FLOSS pour faire reculer certains compétiteurs, par exemple sur la gamme des systèmes d’exploitation, IBM étant l’un des principaux sponsors et contributeurs de Linux, ou celle des suites bureautiques. Dans cette optique, IBM participe à l’élaboration du standard ouvert de format de données pour applications bureautiques ODF (Open Document Format), toujours au sein du consortium OASIS, et contribue également au développement de la suite bureautique FLOSS implémentant ce format, Apache OpenOffice (IBM a, dans ce cadre, annoncé, en juillet 2012, le don du code-source de sa suite bureautique Lotus Symphony au projet Apache OpenOffice).

84IBM avait également soutenu le développement de la fondation Apache, dont le principal projet, le serveur web Apache HTTP qui implémente le protocole HTTP, standard ouvert en tant que RFC (Request For Comments) de l’IETF (Internet Engineering Task Force), avait été rapidement inclus dans le dispositif de la compagnie. Une conséquence de ces efforts est qu’Apache a été choisi par IBM comme serveur pour son offre e-business [Zimmermann, 2005]. IBM tend, via ce dispositif au fort potentiel de gain, à développer ses activités de conseil en affaires stratégiques globales à destination d’entreprises clientes.

85Comme l’analysent Jullien et Zimmermann [2009], IBM a aussi été à l’origine de la création de la fondation FLOSS Eclipse, pour y déposer son projet d’environnement de développement logiciel, domaine apte à fédérer une large participation d’acteurs industriels. IBM a notamment développé plusieurs logiciels commerciaux basés sur Eclipse (Lotus Notes, Lotus Symphony ou WebSphere Studio Application Developer). La spécification de l’interface de programmation d’Eclipse est développée au sein même du consortium et librement accessible. IBM a réussi à faire d’Eclipse un standard de facto FLOSS, puisqu’en 2013, il est estimé détenir 65 % des parts de marché dans son domaine.

86L’essentiel des stratégies d’IBM analysées repose sur des licences non virales (notamment les licences Apache et Eclipse). Olivier Bérard, relativement à son rôle d’Open Source Business Developer au sein d’IBM France, nous a indiqué à propos de cette particularité : « Les fondations Eclipse et Apache sont pour moi l’illustration parfaite de la spécificité d’IBM dans l’Open Source. Une volonté de rechercher des synergies entre l’Open Source et les logiciels commerciaux. Ce qui impose l’usage de licences non virales, pas de licences de type GPL, et ce qui implique une grande autonomie de la fondation, mais avec un support soutenu pour prendre une grande place dans l’écosystème Open Source. Au final : l’unification des technologies Open Source et commerciales qui permet aux produits IBM d’utiliser les standards de fait, ceux propagés par l’Open Source, mais avec une obligation d’avoir des produits toujours meilleurs que l’Open Source pour en justifier l’acquisition, dans le cadre d’une autoconcurrence. »

Bilan

87Ainsi, au travers de ces enquêtes, nous avons pu analyser que la double contribution d’un même acteur industriel à l’élaboration d’un standard ouvert et de son implémentation FLOSS, au sein des deux types de consortiums spécifiques, a de nombreux avantages industriels, et peut s’établir comme modèle pérenne de développement de standards, Jochen Friedrich nous indiquant à ce sujet : « Open Source implementations of Open Standards are an excellent way to promulgate the respective standards. To have experts available for standardisation that, at the same time, implement the standards in real-life applications is a great advantage. It opens up for a fast return cycle regarding problem identification and standards maintenance and improvements. It is always good if there is a close connection between the standardisers and the implementers. »

88Le modèle où une implémentation du standard ouvert est elle-même objet d’un développement mutualiste entre acteurs industriels relatif à une mise en œuvre FLOSS permet de bénéficier de tous les avantages de développement des bonnes pratiques du modèle FLOSS précédemment analysés, et notamment d’en mutualiser les coûts et de réaliser une double économie d’échelle pour les acteurs impliqués, et d’essayer de faire de cette implémentation FLOSS une référence par rapport à ses éventuelles rivales propriétaires, pour possiblement en faire un double standard : logiciel standard de facto FLOSS, lui-même issu de la spécification d’un standard ouvert. C’est, par exemple, le cas, comme nous l’avons vu, de l’environnement de développement Eclipse et également du serveur Web Apache HTTP, standard de facto FLOSS, détenant en janvier 2013 une part de marché de 55 % dans son domaine25, et dont nous avons indiqué qu’il implémentait le standard ouvert HTTP, ces deux projets étant, comme nous l’avons vu, inclus dans la stratégie de développement des standards ouverts / FLOSS d’IBM.

89Il se peut également que le but recherché dans le développement de cette implémentation FLOSS soit de l’intégrer dans les infrastructures logicielles et/ou matérielles des acteurs industriels ayant contribué à sa réalisation. Nous avons vu que c’était également une des stratégies d’IBM, soit dans le cadre de modèles d’affaires liés à la commercialisation de ces infrastructures imbriquées [d’où le choix de licences FLOSS non virales], soit sans stratégie commerciale directe, mais pour renforcer son patrimoine technologique interne.

90L’avantage concurrentiel lié à une implémentation FLOSS de standard ouvert n’est pas recherché dans la commercialisation de l’implémentation elle-même, puisqu’il ne s’agit pas d’un logiciel propriétaire fermé, mais peut alors être recherché dans les services liés à cette implémentation FLOSS : on passe d’une logique de vente de produit logiciel à un modèle de commercialisation de services liés à un logiciel FLOSS, comme lorsque IBM propose des services en lien au serveur Web Apache HTTP.

91Dans ce cadre, l’essor du FLOSS et des standards ouverts a fait évoluer et a créé de nouveaux modèles d’affaires, comme ce fut le cas pour Oracle/Sun, dont n o u s avons vu qu’il implémentait de façon FLOSS les spécifications de l’ensemble de l’écosystème Java établies collectivement au sein du JCP. Ainsi, concernant le modèle d’affaires d’un des standards ouverts que l’entreprise implémente, le serveur d’applications Java Enterprise Edition FLOSS GlassFish, Alexis Moussine-Pouchkine nous a indiqués : « La stratégie de monétisation de GlassFish consiste à offrir à un coût raisonnable des mises à jour intermédiaires – les patchs releases –, un accès au support par escalades, des outils de gestion de production – enterprise manager –, et une protection juridique. Cette stratégie a été déclinée dans d’autres produits. », en nous précisant également que, d’une manière générale : « La grande difficulté consiste à ajuster en permanence le produit Open Source à sa stratégie commerciale pour répondre aux attentes, à la fois de la communauté, tout en donnant des raisons d’acheter un abonnement pour assurer la fiabilité financière du projet dans le long terme. »

92Jochen Friedrich nous indiquant à propos de cette adaptation des entreprises : « Openness – open innovation – is part of the transformation of companies in order to adapt to a changing global environment. There is hardly any company which does not make use of open innovation practices and means, work with Open Source, etc. Success in the market almost requires some constant change and openness is one element that needs to be considered in transformation processes. »

Innovation relative aux standards ouverts et au modèle FLOSS

  • 26 Qu’elles portent sur des spécifications dans le premier cas, et des codes-sources dans le second.

93Relativement à cette innovation ouverte, les standards ouverts et le modèle FLOSS permettent, de par leur faculté optimum de diffusion et leur principe de rendre la technologie, et donc les innovations intégrées, publiques26, une propagation du meilleur état de l’art et de l’innovation. Jullien et Zimmermann [2011] ont développé une théorie sur le lien entre les implications des entreprises relatives au FLOSS et leur marché. Or, dans le cadre d’implémentations FLOSS de standards ouverts, cette innovation peut, de la manière la plus rapide possible, passer des pôles de création et de développements mutualisés respectifs [innovations concernant les spécifications et les logiciels d’implémentation] à l’industrie et aux utilisateurs, et donc renforcer les marchés liés.

94En outre, l’interopérabilité, dont nous avons vu qu’elle découlait de cette ouverture, est également un facteur important d’innovation, en optimisant les possibilités d’adjonctions de produits et technologies complémentaires, et donc, encore une fois, de croissance des marchés concourants. Les avantages de la production d’innovation du modèle FLOSS relatifs à son processus de développement sont présents et renforcés par la dynamique propre aux standards ouverts, et permettent l’engendrement d’innovations itératives, mutualisées et synergiques. Von Hippel et Von Krogh [2003] voient en ce modèle FLOSS d’innovation, un dispositif d’inventions collectives privées qui aboutit à la création d’un patrimoine public ouvrant à des retombées pour des acteurs privés. Ce qui est, comme nous l’avons analysé, notamment le cas des entreprises concernant les implémentations FLOSS de standards ouverts.

6. Standards ouverts, implémentations FLOSS et début d’un cycle schumpétérien de « destruction créatrice », mais ici sans fin théorique, dans le secteur du logiciel

Du passage d’une importante partie de l’activité des entreprises du logiciel de la commercialisation de programmes informatiques à une économie de services en lien au domaine du logiciel

95Nous avons analysé au travers de cet article que les standards ouverts, si liés à la définition souhaitable, dont nous avons établi les principes et intérêts, et offrant par là la possibilité d’être à l’origine d’implémentations selon l’ensemble des licences du modèle FLOSS, permettent également la mise en œuvre de ces spécifications dans des logiciels propriétaires. Or, comme on l’a montré, l’industrie peut s’avérer friande de cette flexibilité offrant la possibilité de s’adapter aux différentes stratégies d’entreprises (d’ailleurs stratégies éventuellement plurielles ou changeantes selon les contextes économiques). Or, ce syncrétisme de facto des standards ouverts peut, par là même, concilier les tenants des modèles FLOSS et propriétaire, dans un rapport symbiotique gagnant-gagnant. En effet, la puissance des moyens de production de l’industrie du logiciel (humains, organisationnels et financiers) étant, comme nous l’avons montré, notamment via les taux de participation induits, un très grand accélérateur du progrès dans l’élaboration des standards ouverts et des logiciels FLOSS.

96Ce développement industriel de technologies portées par le modèle FLOSS, dont nous avons donc montré au travers de cet article qu’il est accru par l’émergence et l’évolution rapide du couplage standards ouverts / possibilité d’implémentations FLOSS, au-delà des effets d’interopérabilité engendrés, suit également la logique dialectique apparente en marche tendant à faire passer une partie importante de l’industrie anciennement liée à la facturation de logiciels – contractualisation commerciale de biens immatériels (possiblement portés par un vecteur support matériel de type DVD ou directement téléchargés via Internet) – à une nouvelle économie de services.

97Cette dialectique industrielle du passage d’une partie importante de l’activité du secteur de l’informatique logicielle, de la commercialisation de logiciels, aux prestations de services, a des ferments multifactoriels, et en particulier nous pouvons analyser :

  • le développement des réseaux (notamment d’Internet, mais également de tous les réseaux, globaux ou non, pouvant véhiculer des données numériques, par exemple, les réseaux de téléphonie mobile, des efforts étant faits pour viser à une interconnexion et à une interopérabilité des réseaux des TIC) ;

  • la recherche de l’extension de cette interopérabilité aux logiciels communiquant sur ces réseaux ;

  • le rôle des normes – et, comme nous l’avons montré au travers de cet article – encore davantage des standards ouverts, afin de parvenir à cette interopérabilité ;

  • l’émergence et la montée en puissance des logiciels FLOSS, aussi bien sur des critères qualitatifs (comme nous l’avons analysé, cette haute qualité provenant en particulier d’une gestion des projets FLOSS d’envergure comme savant mélange entre hiérarchie et flexibilité, d’une mutualisation optimale des apports ouverts de la part des communautés FLOSS et des acteurs industriels impliqués, et de cycles très réactifs détections d’erreurs / corrections), que quantitatifs (notamment, en lien à la crise économique ayant débuté en 2008, ayant pu avoir comme répercussion une nécessité pour les entreprises de réaliser des économies sur leur Système d’Information, cette réduction des budgets a notamment été un important levier récent d’intégration de logiciels FLOSS par les DSI : Directions des Systèmes d’Information).

98Certes, différents pans de l’activité économique de l’informatique logicielle sont encore liés à la commercialisation de logiciels, notamment :

  • à destination d’entreprises clientes : des programmes informatiques ayant une très forte valeur ajoutée et constituant des avantages concurrentiels pour les sociétés qui les commercialisent ;

  • à destination de clients non professionnels : les systèmes d’exploitation acquis en ventes liées à de nombreux ordinateurs et autres types d’appareils électroniques commercialisés.

99Néanmoins, ce mouvement indicatif de la commercialisation de programmes informatiques au redéploiement de l’activité des entreprises liées au logiciel [et à l’apparition de nouvelles sociétés entrantes] vers des activités de services est un phénomène marquant de l’époque. Ce passage vers une économie globalisée de services est notamment fort bien montré par le très récent ouvrage collectif « Services sans frontières : Mondialisation, normalisation et régulation de l’économie des services » [2013] sous la direction de Jean-Christophe Graz et Nafi Niang.

  • 27 Formats prévus pour prendre en charge l’ensemble des données liées au domaine de la bureautique, no (...)

100Comme très bien analysé dans ce livre, ce mouvement de l’industrie logiciel de la commercialisation de programmes informatiques vers l’édification d’offres de services peut trouver une incarnation dans le long feuilleton de la normalisation de deux différentes spécifications de formats de données pour applications bureautiques27 relatives au langage de balisage extensible XML, concomitamment format d’échange de données et métadonnées, et lui-même, comme nous l’avons indiqué précédemment, recommandation W3C depuis 1998 (et donc, comme nous l’avons vu, selon les principes du W3C, simultanément standard ouvert).

101Ces deux formats sont :

    • 28 Format initial nommé OpenOffice.org XML.
    • 29 Devenue, depuis 2012, Apache OpenOffice, suite au placement par Oracle du projet OpenOffice.org au (...)
    • 30 Un fork étant un projet dérivé d’un programme FLOSS souche, ici en l’occurrence OpenOffice.org, com (...)
    • 31 Référence ISO/IEC 26300.

    le format Open Document Format for office applications (ODF), souvent abrégé en OpenDocument : la spécification de ce format étant gérée comme standard ouvert par le consortium OASIS dont nous avons précédemment parlé. ODF, dont la version 1.0 date de mai 2005, est le très proche successeur du format initial de la suite bureautique FLOSS OpenOffice.org28 développée par Sun.
    ODF a ensuite été intégré notamment aux nouvelles versions d’OpenOffice.org29 et du fork30 LibreOffice géré directement par une communauté indépendante de développeurs (dont de nombreux transfuges d’OpenOffice.org) pour continuer le développement du projet sous la licence initiale d’OpenOffice.org, LGPL, alors qu’Apache OpenOffice est maintenant lié à une licence Apache, comme nous l’avons vu précédemment, parfois plus propice à une coopération d’entreprises, mais concomitamment moins garante d’une perpétuation FLOSS de ces contributions privées. ODF est également implémenté dans de très nombreux autres logiciels, propriétaires et FLOSS. Des entreprises comme IBM, Google et Adobe contribuent à l’évolution du format ODF. ODF est une norme ISO/IEC depuis 200631 ;

    • 32 Référence ISO/IEC 29500.

    le format Office Open XML (OOXML) : cette spécification étant principalement développée par Microsoft, et notamment destinée à être intégrée aux différents logiciels de sa suite bureautique propriétaire Office. Après un parcours de normalisation rocambolesque, la spécification OOXML est devenue une norme ISO/IEC32 en 2008.

102À propos de cet épisode relatif à la normalisation des spécifications dérivées du langage XML, le livre sous la direction de Jean-Christophe Graz et Nafi Niang, dans le chapitre 7 [Vion, Diaz, Dudouet et Graz, 2013], indique très bien :

« Le rapport au temps entre les tenants de l’open source (Sun, IBM) d’une part, et Microsoft d’autre part, était radicalement différent. Alors que les premiers pouvaient souhaiter l’adoption rapide d’un standard ouvert sur le XML, la firme de Redmond avait toutes les raisons de la redouter et d’en repousser l’échéance. Ainsi que nous l’avons indiqué, le modèle d’affaires de Sun et IBM orienté sur les services informatiques s’accommodait très bien d’un standard ouvert, la différence se faisant sur le service, et non sur le code en tant que tel. Pour Microsoft c’était l’inverse, et même si la firme s’était dès cette époque résolument engagée vers les services informatiques, la transformation complète de l’entreprise ne pouvait se faire du jour au lendemain. »,

et, en concluant :

« ...même si l’OOXML est un standard "maison", il n’en reste pas moins un langage ouvert qui acte la conversion forcée de Microsoft à l’open source. Loin d’être une consécration de la puissance de la firme de Redmond, l’adoption de l’OOXML est plutôt une victoire à la Pyrrhus qui sanctionne le déclin d’un modèle économique (la propriété intellectuelle) et la victoire d’un autre (le service). Consciente de cette "révolution", Microsoft est contrainte d’implémenter les deux normes (OOXML et ODF) dans sa suite bureautique pour limiter les effets de réseau et les risques de basculement des utilisateurs vers les suites de logiciels gratuits. Au-delà de la victoire de tel ou tel standard, c’est plus fondamentalement le modèle d’affaires de la bureautique d’entreprise pour les prochaines années qui s’est joué avec l’institutionnalisation de la norme XML [Robertson et Paoli, 2007 ; Blind, 2008]. »

IBM et contributions à la technologie de suite bureautique relative au standard ouvert ODF et à son implémentation FLOSS Apache OpenOffice

103Comme nous l’avons vu, IBM est lié au consortium OASIS dans l’élaboration de la spécification du format ODF en tant que standard ouvert, et prend une importante part au développement de la suite bureautique FLOSS Apache OpenOffice, notamment au travers du don au projet Apache OpenOffice de sa suite bureautique Lotus Symphony.

104Ces actions d’IBM tendent à constituer, comme nous l’avons vu précédemment, une stratégie visant à faire reculer un compétiteur, ici Microsoft, dans le domaine des suites bureautiques.

105Si certaines voix dans l’industrie pouvaient penser que cette contribution d’IBM à ODF et à Apache OpenOffice visait, pour IBM, à sortir une suite bureautique en fermant le code d’Apache OpenOffice (comme, on l’a vu, la licence Apache le permettant), et en y adjoignant des fonctionnalités exclusives pour créer une valeur ajoutée et commercialiser cette suite, cela a été démenti par des responsables d’IBM.

106Ainsi, Ed Brill, directeur marketing management pour IBM Mobile Enterprise, et Eric Otchet, product manager pour IBM de Lotus Symphony / Apache OpenOffice, ont indiqué sur le blog professionnel d’Ed Brill, au début de l’année 2012, qu’IBM soutenait Apache OpenOffice, sans intention de clôturer l’accès à un fork « maison » en en changeant la licence. Ed Brill précisant que :

« This (IBM Lotus Symphony 3.0.1) will also likely be the last release of IBM’s own fork of the OpenOffice codebase. Our energy from here is going into the Apache OpenOffice project, and we expect to distribute an "IBM edition" of Apache OpenOffice in the future. We have contributed the Lotus Symphony code into the OpenOffice project, along with human resource across development/product management/marketing organi zations. I’m excited by what I see happening at Apache, but for now, the new release of Symphony keeps the current project updated for existing and potential customers. » [...] « Symphony 3.0.1 is the current release, only days old. It will be supported for years into the future. Our next release will be an IBM Edition of the NEXT version of OpenOffice. We are contributing to that. So for now Symphony 3.0.1 represents our best work, then the Apache OpenOffice 4 will in the future. »

107Eric Otchet poursuivant :

« We are doing exactly what you mention. We are contributing the Symphony source code to the Apache OpenOffice project. We are working with the community to get those code contributions into a future release of the Apache OpenOffice code. We are proposing that for version 4. That release with Symphony code will be open source. Assuming the community accepts the code and builds a release with it. Our plans for the "IBM Edition" are to distribute an identical release of the Apache OpenOffice code under the Apache license simply bundled with some Extensions that we will create to link the Apache OpenOffice code to our portfolio. These Extensions will be no-charge and will also be posted in the Extensions Repository for anyone to access. If someone prefers to download the Apache OpenOffice code and then go get a specific extension for IBM Connections for example and install it themselves, they are free to do that. We are going to bundle Extensions for IBM Connections, IBM Smartcloud for Social Business and others together in an all-in-one package for install. We are not going to release a version of the Apache OpenOffice code with a different license. »

108Eric Otchet précisant encore sur son site professionnel LinkelIn :

« IBM Lotus Symphony / Apache OpenOffice providing a no cost alternative to Microsoft Office. Symphony provided significant savings to Notes Domino customers and increased the value of IBM’s offerings by being included as part of the product. »

109Ainsi, une part des efforts de contributions d’IBM à ODF et à Apache OpenOffice vise à assurer le bon développement d’une suite bureautique gratuite et compétitive par rapport à Microsoft Office pour les clients de son logiciel de travail collaboratif à destination professionnelle, et très utilisé dans les entreprises, IBM Lotus Notes.

110En effet, il faut noter que Microsoft dispose d’un logiciel équivalent intégré à Microsoft Office avec Microsoft SharePoint Workspace 2010, et qu’ainsi, pour IBM, il était préférable de pouvoir lier IBM Lotus Notes à Apache OpenOffice.

111De plus, et en ce but, la contribution au standard ouvert ODF et à la suite FLOSS Apache OpenOffice, par définition, deux projets élaborés de manière mutualisée, permet potentiellement à IBM de faire d’importantes économies par rapport à ce qu’aurait coûté la continuation du développement internalisé de sa suite bureautique IBM Lotus Symphony qui était, en outre, distribuée gratuitement par IBM depuis 2007.

112Ainsi, les contributions d’IBM aux technologies bureautiques ouvertes s’expliquent notamment par une stratégie dont la suite Apache OpenOffice implémentant le standard ouvert ODF est le vecteur (vecteur d’ailleurs attrayant pour les entreprises puisque gratuit, et bénéficiant des qualités de développement des grands projets standards ouverts / FLOSS analysées précédemment) : les logiciels qu’IBM souhaite vendre s’intégrant à une telle suite bureautique : le logiciel propriétaire IBM Lotus Notes comme nous l’avons vu, ou d’autres programmes comme les logiciels également propriétaires IBM Connections, logiciel de réseau social d’entreprise, ou IBM Lotus Quickr, logiciel de groupe de travail / groupware, toujours à vocation professionnelle.

113Un autre pan très important de la stratégie d’IBM est lié au mouvement de la commercialisation de logiciels vers cette économie de services, et les contributions d’IBM au duo pour technologies bureautiques – standard ouvert ODF et implémentation Apache OpenOffice – s’expliquent aussi par le fait que de nombreuses activités de services d’IBM sont liées au vecteur suite bureautique.

« Destruction créatrice » de Schumpeter, standards ouverts et modèle FLOSS

114Dans cette perspective, on peut considérer que ce mouvement d’une économie de commercialisation de logiciels vers une économie de services relatifs au secteur du logiciel, par l’ampleur de ses courants porteurs, s’inscrit dans un processus de « destruction créatrice », selon la théorie de Schumpeter [Schumpeter, 1942].

115En effet, pour Schumpeter, le processus continu d’innovation entrepreneuriale, moteur de croissance dans le système capitaliste, engendre cette dynamique immuable de destruction créatrice : des activités économiques antérieures tendent à devenir obsolètes et à s’arrêter, concomitamment à l’apparition de nouvelles activités économiques résultant de cette innovation.

116Schumpeter analyse que ce processus de destruction créatrice peut même affecter des entreprises en position conférant au monopole, et ainsi rebattre les cartes d’un secteur d’activités, en permettant aux entreprises vectrices de cette innovation d’être les nouvelles dépositaires des avantages concurrentiels de ce domaine. Dans la théorie de Schumpeter, ces nouveaux avantages concurrentiels sont même amenés à être à l’origine de nouvelles situations de monopoles et rentes de situation conférées aux entreprises incorporant ces dernières innovations porteuses, le cycle de destruction créatrice se répétant de manière récursive sans limites apparentes.

117Nous avons montré et analysé, au travers de nos travaux, la tendance industrielle de plus en plus opérante de contribution au développement du double modèle synergique et mutualisé d’élaboration de standards ouverts, potentiellement et optimalement relayée par la réalisation de logiciels FLOSS les implémentant.

118Or, nous pouvons analyser que ce nouveau phénomène industriel dual est lié à deux types d’innovation référentes à la théorie de Schumpeter : l’innovation concernant l’organisation du travail et l’innovation liée au procédé de production ou de commercialisation.

119En effet, nous avons montré que ce double modèle d’élaboration de standards ouverts / implémentations FLOSS est justement lié à de nouvelles méthodes d’organisation et dynamiques de développement coopératives, distantes, modulaires, flexibles, à itérations fréquentes, participatives selon la communauté la plus large, et autorégulées par ses instances. Concernant le procédé de commercialisation, plus exactement ici de distribution, ce double modèle est également innovant, puisqu’il met à libre disposition universelle les technologies logicielles produites.

120Ainsi, ce double modèle industriel innovant augure du début d’un nouveau cycle de cette destruction créatrice dans le secteur du logiciel, en pouvant contrer les monopoles en présence. Cependant, et contrairement à la théorie habituelle de la destruction créatrice qui aboutit, à la fin de chaque nouveau cycle, à la formation de nouveaux monopoles, comme nous l’avons montré, les principes d’ouverture liés aux standards ouverts et au modèle FLOSS pouvant les implémenter, prémunissent de l’instauration de nouveaux monopoles dans le secteur du logiciel.

Prolongement des travaux

121Dans des travaux en cours, et poursuivant ceux de notre présent article, nous entendons essayer de montrer comment pourrait s’intégrer l’évolution de l’industrie du logiciel, en relation à un recours de plus en plus accentué aux standards ouverts et à leurs implémentations selon le modèle FLOSS, dans les principaux modèles économiques de la croissance et de l’innovation : le modèle qualitatif de Schumpeter tel qu’analysé ici, et également les modèles de la croissance exogène de Solow et de la croissance endogène de Romer, Lucas et Barro.

Conclusion

122Jullien et Zimmermann [2009] ont montré que la recherche d’avantages concurrentiels portés par des stratégies FLOSS, après avoir engendré un secteur professionnel intrinsèque (éditeurs de logiciels FLOSS, sociétés de services relatifs à des dispositifs FLOSS), est maintenant adoptée de manière croissante par des entreprises informatiques traditionnelles qui, dans ce cadre, ouvrent ou développent une partie de leur infrastructure logicielle selon le modèle FLOSS. De ce fait, l’intégration de développements FLOSS à des modèles d’affaires pourrait devenir le point de référence pour les acteurs de l’industrie sur les marchés d’application, et induire une hausse du contrôle de ces développements FLOSS par les entreprises, ainsi qu’une croissance massive de la production de logiciels FLOSS dans le parc logiciel global.

123Dans cette voie, nous avons essayé de montrer au travers de cet article que ces stratégies industrielles relatives au domaine du FLOSS pouvaient largement être liées au développement mutualisé, le plus souvent au sein de consortiums FLOSS spécifiquement optimisés pour recevoir ces contributions à objectif professionnel, d’implémentations FLOSS de spécifications de standards ouverts, par définition, eux-mêmes élaborés de manière ouverte et coopérative.

124Nous avons tenté d’analyser que ce nouveau double modèle synergique d’élaboration de standards ouverts / implémentations FLOSS, de plus en plus adopté par l’industrie, tend à initier le début d’un nouveau cycle de destruction créatrice. Mais, le caractère perpétuellement ouvert de ce modèle l’extirpe, de fait, de deux principes de la théorie de Schumpeter des cycles de destruction créatrice, en lui permettant de ne pas augurer de monopoles, même temporaires et transitoires, et de ne pas avoir de fin théorique. Ce qui aboutirait ainsi à la constitution d’un contexte industriel inédit dans le secteur du logiciel, où ce modèle dual de standardisation aurait une place prépondérante.

125Cela pourrait constituer, comme nous avons essayé de le montrer dans nos travaux, une très grande opportunité, aussi bien pour les acteurs économiques, que pour les utilisateurs, de l’industrie du logiciel. En effet, ce modèle prémunit de l’inertie industrielle liée à la constitution de monopoles et de marchés captifs, et est le vecteur d’une dynamique maximisant le potentiel d’innovation et d’excellence de réalisation de la technologie logicielle produite.

Haut de page

Bibliographie

ARTHUR, W.B., « Competing Technologies : An Overview », Dosi G. et al (eds.), Technical Change and Economic Theory, pp. 590-608, Pinter, London, 1988.

BESEN S.M., FARRELL J., « Choosing how to compete - strategies and tactics in standardization », Journal of Economic Perspectives, 8 (2), pp. 117-131, 1994.

BLIND K., « A welfare analysis of standards Competition : The example of the ECMA OpenXML standard and the ISO ODF standard », 6th ZEW Conference on the Economics of Information and Communication Technologies, Manheim, 2008.

BRANDENBURGER A., NALEBUFF B., « La Co-opétition, une révolution dans la manière de jouer concurrence et coopération », Village Mondial, 1996.

DAVID P.A., GREENSTEIN S., « The economics of compatibility standards : An introduction to recent research », Economics of Innovation and New Technology, 1, pp. 3-42, 1990.

DALLE J.M., DAVID P.A., « Simulating code growth in Libre (Open Source) model », Stanford institute for economic policy research SIEPR Discussion paper, n° 4-02, 2005.

DEMAZIÈRE D., HORN F., JULLIEN N., « Le travail des développeurs de logiciels libres. La mobilisation dans des "communautés distantes" », Cahiers lillois d’économie et de sociologie, 2e semestre, 46, pp. 171-194, 2005.

FORAY D., « Exploitation des externalités de réseau vs. évolution des normes : les formes d’organisation face au dilemme de l’efficacité dans le domaine des technologies de réseau », Revue d’Économie Industrielle, n° 51, 1990.

FORAY D., « Standardisation et concurrence : des relations ambivalentes », Revue d’Économie Industrielle, n° 63, 1993.

FORAY D., ZIMMERMANN J.B., « L’économie du logiciel libre : organisation coopérative et incitation à l’innovation », Revue économique, n° 52, 2001.

GRAZ J.C., NIANG N., « Services sans frontières : Mondialisation, normalisation et régulation de l’économie des services », SciencesPo. Les Presses, 2013.

JULLIEN N., « Impact du logiciel libre sur l’industrie informatique », Thèse Université de Bretagne occidentale, 2001.

JULLIEN N., ZIMMERMANN J.B., « Le logiciel libre : une nouvelle approche de la propriété intellectuelle », Revue d’Économie Industrielle, n° 99, 2002.

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

JULLIEN N., ZIMMERMANN J.B., « Firms’ Contribution to Open Source Software and the Dominant User Skill », European Management Review, vol. 6, Issue 2, pp. 130-139, 2009.

JULLIEN N., ZIMMERMANN J.B., « FLOSS firms, users and communities : a viable match ? », Journal of Innovation Economics, n° 7, pp. 31-53, De Boeck Supérieur, 2011.

KATZ M.L., SHAPIRO C., « Network Externalities, Competition, and Compatibility », The American Economic Review, vol. 75, n° 3, June 1985, pp. 424-440, 1985.

LANG B., « Logiciels libres et entreprises », Revue Terminal, n° 80-81, 1999.

RAYMOND E., YOUNG B., « The Cathedral & the Bazaar », O’Reilly, 2001.

ROBERTSON T., PAOLI J., « Interoperability, Choice and Open XML », lettre ouverte publiée sur le site du forum d’interopérabilité de Microsoft le 14 février 2007, 2007.

SCHUMPETER J., « Capitalisme, socialisme et démocratie », Payot, 1990 (première édition : 1942).

SHAPIRO C., VARIAN H.R., « Économie de l’information, guide stratégique de l’économie des réseaux », Éditions De Boeck, 1999.

VION A., DIAZ P.A., DUDOUET F.X., GRAZ J.C., « Services sans frontières : Mondialisation, normalisation et régulation de l’économie des services (Chapitre 7 du livre sous la direction de Graz J.C., Niang N.) », SciencesPo. Les Presses, 2013.

VON HIPPEL E., VON KROGH G., « Open source software and the private-collective innovation model », Organization Science, n° 14, pp. 209-223, 2003.

ZIMMERMANN J.B., « Un régime de droit d’auteur : la propriété intellectuelle du logiciel », Revue Réseaux, n° 88-89, 1998.

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

ZIMMERMANN J.B., « Logiciel Libre et marchandisation : le paradoxe de l’excellence », Revue Science de la société, n° 66, Octobre, 2005.

Haut de page

Notes

1 Bien que certaines méthodes de mise en œuvre, liées principalement aux algorithmes, peuvent être parfois très difficilement évitables, voire indispensables, dans l’implémentation d’une spécification. Nous verrons que c’est ce qui est à l’origine des DPI sur les spécifications quand ces procédés potentiellement nécessaires sont liés à des brevets logiciels.

2 Ces principes d’ouverture du modèle FLOSS le rapprochent des pratiques de contributions scientifiques (Foray et Zimmermann, 2001).

3 La gestion du noyau Linux, avec à sa tête son créateur et dépositaire de sa licence, Linus Torvalds, est à ce titre symbolique de la devise d’Eric Raymond (Raymond et Young, 2001) concernant les bonnes pratiques du modèle FLOSS : « Release early, release often. », avec une méthode de publication très fréquente de nouvelles versions (environ tous les deux mois).

4 Les comités directeurs des grands projets FLOSS comptent généralement une à deux dizaines de membres. Parmi les projets analysés, le comité technique de Debian en comptait récemment 8, le core team de FreeBSD 9, le comité directeur du serveur Web Apache HTTP 10, et celui de KDE 20.

5 De l’ordre de 50 pour le serveur Web Apache HTTP et de 400 pour Debian.

6 Source : Linux Foundation http://go.linuxfoundation.org/who-writes-linux-2012

7 Successivement, l’API de MS-DOS, MS-DOS API, puis les API de Windows, Win16, Win32 et Win64, pour respectivement les versions de Windows adaptées aux architectures de microprocesseurs x86 16 bits, 32 bits et 64 bits, et l’API Windows Runtime pour Windows 8 et Windows RT. Ainsi que les API liées aux différentes versions du framework .NET pour les applications développées pour la plate-forme .NET de Microsoft, le framework .NET étant inclus dans les dernières versions de Windows, ou devant être installé pour les versions antérieures, afin de supporter les applications liées.

8 La dénomination FRAND étant plus courante en Europe, alors qu’aux États-Unis, le sigle RAND est davantage employé, mais, les deux termes se réfèrent sensiblement à des interprétations analogues.

9 ISO et IEC employant la dénomination RAND.

10 Mark Ferrar, National Technology Officer de Microsoft Grande-Bretagne, en relation à une consultation publique britannique relative aux standards ouverts indiquait en juin 2012 : « We support a broad definition of open standards that includes Fair Reasonable and Non Discriminatory (FRAND) licensing terms with or without a royalty (at the option of the patent holder), because we believe this fosters innovation for upstream and vertically integrated innovators, as well as allowing downstream participants access to new and innovative technologies. » (http://blogs.technet.com/b/uknto/archive/2012/06/06/microsoft-response-to-cabinet-office-open-standards-public-consultation.aspx).

11 Free Software Foundation Europe, filiale européenne de la FSF.

12 Nous pouvons même dire que ce consortium a été l’un des principaux vecteurs ayant permis un développement accéléré du Web.

13 W3C Recommendation www.w3.org/TR/REC-html40/.

14 Référence ISO/IEC 15445:2000.

15 Successivement, IDA (Interchange of Data between Administrations) lancé en 1995 (version 1, puis version 2 à partir de 2000), puis, à partir de 2005, IDABC (Interoperable Delivery of european egovernment services to public Administrations, Businesses and Citizens http://ec.europa.eu/idabc/), doté d’un budget de 148,7 millions d’euros, et, depuis 2010, ISA (Interoperability Solutions for european public Administrations http://ec.europa.eu/isa/), dont l’enveloppe est de 164,1 millions d’euros.

16 Disponible à cette adresse : http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf.

17 https://blogs.oracle.com/trond/entry/european_interoperability_fram.

18 « Intellectual property rights related to the specification are licensed on FRAND terms or on a royalty-free basis in a way that allows implementation in both proprietary and open source software (this fosters competition since providers working under various business models may compete to deliver products, technologies and services based on such specifications). »

19 L’article correspondant de la licence GPL 3 indiquant : « Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims, to make, use, sell offer for sale, import and otherwise run, modify and propagate the contents of its contributor version. »

20 Les termes de la licence GPL 3 précisent à ce propos : « For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this Licence (GPL 3). »

21 La licence LGPL 3 incorporant les termes de la licence GPL 3, notamment ceux faisant référence aux brevets, en ajoutant seulement des permissions complémentaires pour restreindre son copyleft.

22 L’article de la licence Apache 2.0 référent étant : « 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. »

23 Annexe II : Exigences applicables pour l’identification de spécifications techniques des TIC

24 L’OSGi (Open Services Gateway initiative) Alliance est un consortium coordonnant, en tant que standard ouvert, la spécification d’une plate-forme de services basée sur le langage Java, dont sont notamment membres IBM et Oracle. Plusieurs consortiums FLOSS implémentent la spécification de l’OSGi Alliance, notamment Apache et Eclipse, en plus d’OW2 qui la met en œuvre dans son principal projet, le serveur d’applications FLOSS sous licence LGPL JOnAS (Java Open Application Server).

25 Source : Netcraft http://news.netcraft.com/archives/2013/01/07/january-2013-web-server-survey-2.html.

26 Qu’elles portent sur des spécifications dans le premier cas, et des codes-sources dans le second.

27 Formats prévus pour prendre en charge l’ensemble des données liées au domaine de la bureautique, notamment traitements de texte, tableurs, bases de données bureautiques, présentations multimédias...

28 Format initial nommé OpenOffice.org XML.

29 Devenue, depuis 2012, Apache OpenOffice, suite au placement par Oracle du projet OpenOffice.org au sein de la fondation FLOSS Apache, afin qu’elle gère ses futures évolutions, après le rachat par Oracle de Sun, qui était détenteur du projet.

30 Un fork étant un projet dérivé d’un programme FLOSS souche, ici en l’occurrence OpenOffice.org, comme, par définition, le modèle FLOSS le permet.

31 Référence ISO/IEC 26300.

32 Référence ISO/IEC 29500.

Haut de page

Pour citer cet article

Référence papier

Laurent Adatto, « Standards ouverts et implémentations FLOSS : vers un nouveau modèle synergique de standardisation promu par l’industrie du logiciel », Terminal, 113-114 | 2013, 137-172.

Référence électronique

Laurent Adatto, « Standards ouverts et implémentations FLOSS : vers un nouveau modèle synergique de standardisation promu par l’industrie du logiciel », Terminal [En ligne], 113-114 | 2013, mis en ligne le 25 décembre 2014, consulté le 29 juin 2017. URL : http://terminal.revues.org/293 ; DOI : 10.4000/terminal.293

Haut de page

Droits d’auteur

tous droits réservés

Haut de page
  • Logo Télécom École de Management
  • Logo CREIS terminal
  • Revues.org