SlideShare une entreprise Scribd logo
1  sur  36
Télécharger pour lire hors ligne
Standards ouverts et logiciel libre
                         Clarification des notions

                               Observatoire Technologique
                          Centre des technologies de l’information
                            République et Canton de Genève

                                     P. Genoud, G. Pauletto

                                       30 septembre 2005




Observatoire Technologique
Centre des Technologies de l’Information
République et Canton de Genève
CP 2285, 1211 Genève 2, Suisse
http://www.geneve.ch/ot/
ot@etat.ge.ch



                                               1
Standards ouverts et logiciel libre                                                   Clarification des notions




Copyright c 2005 CTI, Observatoire Technologique.

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view
a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/2.5/ or send a let-
ter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.

You are free:

    • to copy, distribute, display, and perform the work
    • to make derivative works

Under the following conditions:

 Attribution.          ou must attribute the work in the manner specified by the author or licensor.
 Noncommercial.        You may not use this work for commercial purposes.
 Share Alike.          If you alter, transform, or build upon this work, you may distribute the resulting
                       work only under a license identical to this one.

    • For any reuse or distribution, you must make clear to others the license terms of this work.
    • Any of these conditions can be waived if you get permission from the copyright holder.

Your fair use and other rights are in no way affected by the above.

This is a human-readable summary of the Legal Code (the full license http://creativecommons.org/
licenses/by-nc-sa/2.5/legalcode.


Observatoire Technologique, CTI                                                                             2
Standards ouverts et logiciel libre                                                      Clarification des notions




Table des matières

1 Introduction                                                                                                    5


2 Interopérabilité                                                                                                5


3 Logiciel libre                                                                                                  7

   3.1 Le modèle open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      8

   3.2 Les communautés open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .          8

   3.3 Catégories de logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9

         3.3.1 Domaine public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     9

         3.3.2 Propriétaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9

         3.3.3 Shareware / Freeware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       9

         3.3.4 Commercial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     9

         3.3.5 Logiciel libre (Free Software) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9

         3.3.6 Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

         3.3.7 Licences doubles ou multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

   3.4 Perspectives open source dans le secteur public . . . . . . . . . . . . . . . . . . . . . . . . . . 11


4 Les standards ouverts                                                                                           12

   4.1 Définitions et critères . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

   4.2 Degré d’ouverture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17


5 Organismes de normalisation                                                                                     19


6 Standard ouvert vs logiciel libre                                                                               21


7 Politiques gouvernementales                                                                                     22

   7.1 Belgique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

   7.2 Brésil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

   7.3 Danemark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

   7.4 États-Unis, Massachusetts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

   7.5 France . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

   7.6 Norvège . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

   7.7 Pays-Bas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

   7.8 Royaume-Uni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

   7.9 Suisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

   7.10 Union Européenne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30


8 Domaine de l’éducation et de la recherche                                                                       30




Observatoire Technologique, CTI                                                                                   3
Standards ouverts et logiciel libre                                                  Clarification des notions




9 Conclusions                                                                                             33




Révisions
 Version        Date / auteurs        Objet de la révision
   0.1        2005-02-18 / pge        Version initiale
   0.2         2005-06-17 / gip       Ajout section logiciel libre
   0.3      2005-07-04 / pge, gip     Ajout autres sections
   0.4      2005-07-15 / pge, gip     Avant relecture finale
   0.9      2005-07-21 / pge, gip     Pour soumission à la direction du projet
   0.91     2005-09-05 / pge, gip     Modifications après retour de la direction du projet
   1.0      2005-09-30 / pge, gip     Après validation par la direction du projet


Observatoire Technologique, CTI                                                                            4
Standards ouverts et logiciel libre                                                    Clarification des notions




1       Introduction

Au cours de l’année 2004, plusieurs signaux ont été émis affirmant la volonté de l’administration genevoise
de se tourner d’ici 2009 d’une part vers le logiciel libre, mais aussi et surtout vers les standards ouverts. Des
déclarations dans ce sens ont d’abord été émises en interne1 , puis relayées dans les médias locaux (jour-
naux2 3 , télévision4 ) et également reprises par le site Web de l’IDABC5 (site de la Commission Européenne
dédié à l’échange de données entre les administrations).

Ces annonces suscitent, et vont susciter des réactions, que ce soit au niveau des collaborateurs de l’ad-
ministration genevoise, des représentants des autres cantons et de la Confédération ou des entreprises
informatiques partenaires. Les informations fournies sont plus ou moins bien comprises et appréciées par
les différents acteurs concernés. Elles suscitent de nombreuses questions auxquelles il faudra répondre
clairement et rapidement si l’on entend atteindre efficacement les objectifs visés.

Un travail de clarification est donc nécessaire et est à l’origine du projet « Standards Ouverts et Logiciel
Libre » (SOLL) confié conjointement à l’Observatoire Technologique (OT) par la Direction Générale du Centre
des technologies de l’information de l’État de Genève (CTI), par la Direction Informatique de l’Université de
Genève et par le Partenariat de l’OT.

Les notions de logiciel libre et de standard ouvert ne sont pas aussi bien comprises qu’on pourrait l’imaginer,
même au sein de la communauté informatique. Cela tient d’une part au fait que ces concepts sont relative-
ment nouveaux. D’autre part, les définitions que l’on en donne varient selon les auteurs ou les communautés
concernées, surtout en ce qui concerne l’aspect plus ou moins restrictif des critères que doivent respecter
les logiciels et les standards pour être qualifiés de libres et d’ouverts respectivement.

Il est donc important de définir précisément ces notions afin qu’il ne subsiste pas d’ambiguïté dans les
esprits, que ce soit en interne ou en externe à l’entreprise ou à l’organisation concernées. Ce document
reprend ainsi les définitions communément proposées dans la littérature. Il met en évidence les interpréta-
tions et les implications relatives aux différentes définitions d’une même notion, ceci afin de permettre aux
mandants du projet SOLL d’en proposer leur propre acception en toute connaissance de cause. La notion
d’interopérabilité est développée en préambule, car elle constitue le concept de base autour duquel viennent
naturellement s’articuler les standards ouverts et le logiciel libre. Un chapitre est également consacré à la
clarification des relations que l’on peut pressentir entre logiciel libre et standards ouverts.

Certains gouvernements se sont déjà clairement positionnés par rapport au logiciel libre et aux standards
ouverts. Nous proposons dans ce document une brève description de quelques politiques gouvernementales
qui illustrent les diverses manières d’aborder cette problématique et qui peuvent servir de référence dans ce
domaine. Enfin, un recensement de quelques initiatives phares dans le milieu académique est également
proposé.



2       Interopérabilité

Comme le souligne un récent document de travail de la Commission Européenne6 , l’administration électro-
nique n’est pas une simple administration traditionnelle à laquelle on aurait ajouté l’Internet. Elle recouvre
l’utilisation de nouvelles technologies en vue de transformer les administrations publiques et d’améliorer
radicalement les contacts avec leurs clients (citoyens, entreprises ou autres administrations).

Ces transformations passent notamment par un décloisonnement des divers services et départements de
l’administration, dans la mesure où cela respecte les lois en vigueur et la sphère privée des citoyens. Mais
    1
     Vers les Standards Ouverts, Echo No 1, CTI, Automne 2004.
    2
     Article du Matin, 17 novembre 2004.
   3
     Article de la Tribune de Genève, 24 novembre 2004.
   4
     Reportage TSR Journal des Régions, 15 décembre 2004.
   5
     Geneva moves towards open standards, http://europa.eu.int/idabc/en/document/3528 et
Geneva to switch to open source by 2009, http://europa.eu.int/idabc/en/document/3601, Site
de l’IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses
and Citizens), Novembre 2004.
   6
     Interconnecter l’Europe : l’importance de l’interopérabilité des services de l’administration électronique,
document de travail des services de la Commission Européenne, 2003.


Observatoire Technologique, CTI                                                                                5
Standards ouverts et logiciel libre                                                     Clarification des notions




une transversalité croissante ne va pas sans poser des problèmes, à la fois techniques et organisationnels,
lorsqu’il s’agit de faire communiquer entre eux les différents systèmes d’information concernés.

Les technologies peuvent faciliter la communication et le partage de l’information pour autant qu’elles soient
interopérables. L’interopérabilité se situe alors au cœur du rapprochement des services des administrations
publiques. Elle désigne ici la capacité qu’ont les technologies de l’information et de la communication ainsi
que les processus qu’elles soutiennent à échanger des données et à permettre le partage de l’information et
de la connaissance. Elle garantit ainsi la pérennité des données et leur accessibilité dans le futur. Elle consti-
tue donc une exigence fondamentale pour développer une administration en ligne efficace, performante et
pérenne. Plus généralement, elle doit être considérée comme un élément clé des architectures actuelles,
qu’elles soient techniques, applicatives ou métier.

La Commission Européenne a parfaitement intégré ces enjeux et a lancé le programme IDABC7 (Interope-
rable Delivery of European eGovernment Services to Public Administrations, Businesses and Citizens) afin
notamment d’encourager et de faciliter l’échange d’informations et de connaissances entre les secteurs pu-
blics des différents pays de l’Union Européenne.

Le document de travail de la Commission Européenne insiste sur la nécessité de considérer l’interopérabilité
comme un problème global. En effet l’interopérabilité passe d’abord par la réorganisation des processus
administratifs et par la nécessité d’inclure la notion de partage de l’information. On considère ainsi trois
aspects fondamentaux liés à l’interopérabilité des systèmes d’information :
   1. L’interopérabilité organisationnelle qui concerne principalement la modélisation des processus mé-
      tiers dans le but de prendre en compte la collaboration entre services qui n’ont pas les mêmes struc-
      tures organisationnelles et qui ne gèrent pas des processus similaires. Pratiquement, il s’agit de s’as-
      surer que les processus pourront être facilement intégrés les uns aux autres et exploités par d’autres
      utilisateurs. L’interopérabilité organisationnelle a notamment pour objectif de prendre en compte les
      besoins des utilisateurs en proposant des services accessibles, aisément identifiables et orientés vers
      eux. Cela passe par la nécessité de rendre la complexité organisationnelle des services transparente
      pour les utilisateurs.
   2. L’interopérabilité sémantique qui garantit que le sens exact des informations échangées peut être
      compris par toute application qui n’a pas été conçue initialement dans ce but. L’interopérabilité séman-
      tique facilite l’agrégation et la réutilisation d’informations hétérogènes (de par leur nature ou leur mode
      de création) et participe ainsi de manière essentielle à la valorisation du patrimoine informationnel
      d’une organisation. Cela va donc beaucoup plus loin que la simple connexion de différentes sources
      d’information, l’objectif plus fondamental étant de faciliter le passage de l’information à la connais-
      sance. La prise en compte de l’interopérabilité sémantique passe concrètement par une nécessaire
      réflexion sur la réutilisabilité et la standardisation des données, par l’utilisation de métadonnées qui
      renseignent sur le contexte lié à la création des données et par la mise en œuvre de technologies
      XML conçues pour répondre à cette problématique.
   3. L’interopérabilité technique concerne les aspects liés à la connexion des systèmes et des services
      informatiques. Cela touche des domaines aussi variés que la définition d’interfaces et de standards
      ouverts, l’intégration des données, la couche middleware, la présentation et l’échange d’informations,
      l’accessibilité ou les services de sécurité. Le référentiel NPT8 (Nouvelles Plateformes Technologiques)
      réalisé par l’Observatoire Technologique du canton de Genève propose quelques pistes pour prendre
      en compte et mesurer l’interopérabilité technique d’une solution informatique.
Prendre en compte les aspects techniques de l’interopérabilité est donc nécessaire mais pas suffisant
lorsque l’on désire atteindre une interopérabilité effective. Les notions d’interopérabilité sémantique et or-
ganisationnelle sont tout aussi importantes, si ce n’est plus. Lorsque l’on entend définir une politique dans le
domaine, il est essentiel de ne pas considérer l’interopérabilité comme une question uniquement technique.

Une telle vision de l’interopérabilité la positionne comme un problème politique (stratégie et réglementation).
Un certain nombre de pays européens l’ont bien compris et l’ont inscrit dans leur agenda. Cela se traduit
notamment par la mise en œuvre d’un cadre commun d’interopérabilité sur le modèle de ce qui a déjà été
   7
     Site Web du programme IDABC lancé par la Commission Européenne http://europa.eu.int/
idabc/en/home.
   8
     Référentiel Nouvelles Plateformes Technologiques, P. Genoud et G. Pauletto, Observatoire Technolo-
gique, Centre des technologies de l’information du canton de Genève, 2003, http://www.geneve.ch/
ot/.




Observatoire Technologique, CTI                                                                                 6
Standards ouverts et logiciel libre                                                   Clarification des notions




réalisé par la France9 , l’Allemagne10 , le Royaume-Uni11 , la Belgique12 ou l’Union Européenne13 .



     Un cadre commun d’interopérabilité peut être défini comme un ensemble de politiques, de
     normes, de conseils et de directives décrivant comment des organisations s’accordent, ou de-
     vraient s’accorder, pour échanger informations et processus.



C’est donc un instrument dynamique qui doit pouvoir s’adapter à l’évolution des technologies, des normes
et des besoins métiers dans les domaines concernés. Chacun des cadres communs d’interopérabilité men-
tionnés ci-dessus correspond à des situations et des besoins différents. Mais ils représentent, à divers titres,
des modèles de référence parfaitement réutilisables. Tous reflètent la prise de conscience croissante du fait
que l’interopérabilité des systèmes d’information des institutions gouvernementales constitue une condition
préalable indispensable si l’on désire mettre en place un secteur public plus compétitif et orienté vers les
services aux citoyens.

L’approche retenue dans les exemples mentionnés ci-dessus part de principes de base (impératifs straté-
giques) comme l’accessibilité, l’éthique, la sécurité ou la transversalité que l’on retrouve dans le référentiel
e-Société proposé par l’Observatoire Technologique du canton de Genève14 . Les administrations et les gou-
vernements prennent en outre conscience de la valeur stratégique de l’information qu’ils créent et qu’ils
gèrent au quotidien, ce qui amène naturellement à revendiquer une plus grande maîtrise de leurs systèmes
d’information. C’est donc logiquement que la notion d’indépendance vis-à-vis des fournisseurs constitue un
principe de base également mis en avant.

Nous verrons ci-dessous que les standards ouverts et le logiciel libre viennent répondre de façon très na-
turelle à ces impératifs stratégiques. L’Union Européenne ainsi qu’un certain nombre de gouvernements
placent d’ailleurs ces notions au cœur de leur stratégie.



3    Logiciel libre

Les technologies appartenant au domaine dit du logiciel libre ou « open source » sont présentes depuis un
certain nombre d’années, mais le concept n’a pris de l’ampleur dans le monde informatique que depuis peu
avec notamment le succès du système d’exploitation Linux. Le logiciel libre présente des facettes multiples :
c’est en partie un phénomène très médiatisé, mais aussi et surtout un mouvement social, une définition de
licence et un modèle de développement. La section suivante présente une perspective très partielle de ce
sujet qui mériterait un éclairage bien plus conséquent. Mais la littérature consacrée au logiciel libre abonde
et le lecteur trouvera sans difficulté une publication de référence. Pour n’en citer qu’une, nous mentionnerons
le récent livre blanc Organisations et logiciels libres15 qui permet une première approche du secteur à la fois
pour un néophyte, ou un approfondissement pour un lecteur déjà averti.

En 1984, la Free Software Foundation16 a introduit la notion de free software, traduit en français par logiciel
libre. Malheureusement, le terme anglais « free » signifie aussi bien libre que gratuit ce qui a causé beaucoup
de confusion dans les esprits.
     9
       CCI — Cadre commun d’interopérabilité des systèmes d’information publics, Agence pour Déve-
loppement de l’Administration Électronique, France, Septembre 2003, http://www.adae.gouv.fr/
rubrique.php3?id_rubrique=41.
    10
       SAGA — Standards and Architectures for e-Government Applications, KBSt unit, Ministère Fédéral de
l’Intérieur, Allemagne, Décembre 2003, http://www.kbst.bund.de/-,182/SAGA.htm.
    11
       E-GIF — e-Government Interoperability Framework, Office of the e-Envoy, Royaume-Uni, Avril 2004,
http://www.govtalk.gov.uk/schemasstandards/egif.asp.
    12
       BELGIF — BELgian Governement Interoperability Framework, Belgique, http://www.belgif.be
    13
       EIF — European Interoperability Framework for Pan-European eGovernment Services, IDABC, Com-
mission Européenne, 2004, http://europa.eu.int.
    14
       Référentiel e-Société, P. Genoud et G. Pauletto, Observatoire Technologique, Centre des technologies
de l’information du canton de Genève, 2002, http://www.geneve.ch/ot/.
    15
       Organisations et logiciels libres, Diane Revillard, Diemark SARL, France, Septembre 2005, http://
www.diemark.net/.
    16
       FSF — Free Software Foundation, http://www.fsf.org/.


Observatoire Technologique, CTI                                                                               7
Standards ouverts et logiciel libre                                                       Clarification des notions




Il serait faux de penser que parce qu’un logiciel est gratuit, il est libre. Il serait également erroné de croire
que parce que son code source est disponible, un logiciel est libre ou encore gratuit.

Le terme open source est également apparu plus récemment, en grande partie, pour éviter ce malentendu
et dédramatiser les débats entre les tenants du logiciel propriétaire et du logiciel libre, en amenant une vue
plus pragmatique et moins philosophique.

Nous détaillons ici les définitions aussi bien de logiciel libre que de open source et leur différences de phi-
losophie. Pour la suite de ce rapport les deux termes sont utilisés comme synonymes ce qui est aujourd’hui
largement reconnu par les communautés d’usagers et de développeurs.

Un logiciel est protégé par le droit d’auteur17 . L’auteur d’un programme peut choisir de protéger son œuvre
par une autre licence lui permettant de modifier les droits et devoirs donnés par défaut. La règle de discrimi-
nation est la suivante :


       L’appartenance d’un logiciel à une catégorie (libre, propriétaire, etc.) est établie grâce à la licence
       sous laquelle le logiciel est distribué.



Les catégories de licences les plus fréquemment rencontrées sont explicitées ci-après. Une présentation
détaillée de cette problématique est donnée ailleurs18 .



3.1 Le modèle open source

On peut définir la notion de modèle open source comme l’ensemble des principes et des bonnes pratiques
régissant le développement, le déploiement et le support de ce type de logiciel. Au cœur de ce modèle
on retrouve le mouvement open source dont la préoccupation majeure est de protéger les privilèges des
utilisateurs plutôt que celui des auteurs19 . dans ce domaine.



3.2 Les communautés open source

Le modèle open source s’appuie sur des communautés de développeurs qui travaillent en mode collaboratif
à une échelle souvent planétaire. Les membres de ces communautés proviennent de tous les horizons :
milieu académique, petites sociétés de service, passionnés du développement logiciel ou, plus récemment,
poids lourds du monde informatique qui se sont positionnés dans ce domaine. Ces membres jouent souvent
des rôles multiples au sein de leur communauté et se sentent très concernés par la réussite ou l’échec du
projet auquel ils participent.

La communauté rassemblée autour d’un projet substitue au concept traditionnel de propriété la notion de
service. Puisqu’aucune entité ne possède le logiciel, personne ne peut le contrôler, même si un petit groupe
de développeurs fait office de leaders du projet. Si l’orientation donnée à un projet open source ne corres-
pond pas aux aspirations d’une partie des membres de la communauté, le projet peut se scinder en un
autre projet distinct (forking). Cette dynamique conduit à la création d’un écosystème de projets au sein
duquel s’effectue une véritable sélection naturelle favorisant les projets de qualité qui répondent le mieux
aux besoins des utilisateurs. La taille de la communauté associée à un projet constitue en principe un bon
indicateur de sa vitalité et de sa qualité.
  17
      Loi fédérale sur le droit d’auteur et les droits voisins, Titre 2, Article 2, Paragraphe 3, « Les programmes
d’ordinateurs (logiciels) sont également considérés comme des œuvres. » http://www.admin.ch/ch/
f/rs/231_1/a2.html.
   18
      Guide de choix et d’usage des licences de logiciels libres pour les administrations, et L’analyse dé-
taillée des licences, ADAE, France, Décembre 2002, http://www.adae.gouv.fr/article.php3?id_
article=172,
Licences Open Source, Annexe du rapport du projet Nouvelles Plateformes Technologiques, P. Genoud et
G. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève,
Juin 2003, http://www.geneve.ch/ot/.
   19
      Open-Source Solutions Will Restructure the Software Industry, Mark Driver, Gartner Group, Février
2005.


Observatoire Technologique, CTI                                                                                  8
Standards ouverts et logiciel libre                                                    Clarification des notions




3.3 Catégories de logiciel

3.3.1    Domaine public

Les logiciels dans le domaine public ne sont pas protégés par des droits d’auteur. Ils sont explicitement
déposés dans le domaine public par leur(s) auteur(s), car par défaut, tout programme est protégé par le
copyright attribué automatiquement à son auteur. Pour un logiciel dans cette catégorie toute modification est
possible, mais il peut basculer vers une autre licence à tout moment. De plus, rien ne garantit que le code
source soit disponible.


3.3.2    Propriétaire

Le logiciel propriétaire est le modèle auquel l’industrie est encore aujourd’hui le plus souvent confrontée :
son utilisation, sa redistribution ou sa modification sont interdites, ou exigent une autorisation spécifique. Les
droits de propriété sont détenus par la société qui le distribue ou par son auteur. Le code source peut être
mis à disposition ou non, mais sa protection reste garantie par le droit d’auteur et la propriété intellectuelle
appartient au fournisseur du programme.


3.3.3    Shareware / Freeware

La catégorie shareware / freeware est souvent confondue à tort avec l’open source. Un logiciel freeware
est un logiciel gratuit qui permet l’utilisation et la redistribution de l’exécutable ; les codes sources ne sont
généralement pas fournis et la modification n’est pas autorisée. Cette catégorie n’a en général pas de réel
point commun avec l’open source, mise à part dans certains cas, la gratuité. Un logiciel shareware est
un freeware limité dans le temps qui devient payant une fois une date limite ou un nombre d’utilisations
dépassés.


3.3.4 Commercial

Il faut également savoir qu’un logiciel commercial est un produit vendu par une entreprise dans le but de réa-
liser un profit. Cela n’est pas incompatible avec la notion de logiciel libre : les sociétés commerciales comme
RedHat, Novell et Mandriva en sont la preuve. Ces entreprises commercialisent des solutions open source et
y ajoutent de la valeur en offrant des services tels que le packaging, l’intégration, le support ou la documen-
tation. A contrario, il existe également des logiciels non commerciaux qui ne sont pas dans la catégorie du
logiciel libre. Il devient de plus en plus important d’utiliser le vocabulaire adéquat pour éviter les ambiguïtés
comme par exemple éviter d’utiliser l’adjectif « commercial » pour qualifier un logiciel « propriétaire ».


3.3.5    Logiciel libre (Free Software)

Selon la Free Software Foundation, un logiciel est considéré comme libre si sa licence garantit à l’utilisateur
les quatre libertés suivantes qu’elle numérote de zéro à trois :



         0. La liberté d’exécuter le programme, pour tous les usages.
         1. La liberté d’étudier le fonctionnement du programme et de l’adapter aux besoins. Pour
            ceci l’accès au code source est une condition requise.
         2. La liberté de redistribuer des copies, donc d’aider son voisin.
         3. La liberté d’améliorer le programme et de publier des améliorations, pour en faire profiter
            toute la communauté. Pour ceci l’accès au code source est une condition requise.




Observatoire Technologique, CTI                                                                                9
Standards ouverts et logiciel libre                                                      Clarification des notions




La licence GNU General Public License (GPL) concrétise ces quatre libertés sous la forme d’une licence
juridique20 .

Une particularité de la licence GPL est le copyleft, qui impose que les mêmes conditions se transmettent
pour les œuvres dérivées. Ceci assure qu’un objet sous licence GPL reste indéfiniment couvert par cette
même licence lors de modifications. D’autres licences que la GPL possèdent cette même propriété.

Il existe un effort d’adaptation de cette licence au droit français avec la création de la licence CeCILL21 .


3.3.6 Open Source

L’Open Source Initiative définit pour sa part le concept de logiciel open source en 10 points :

   1. Redistribution libre : La licence ne doit pas restreindre la vente ou la distribution du logiciel libre
      intégré dans un autre logiciel contenant des programmes de différentes origines. La licence ne doit
      pas exiger de compensation en échange de cette intégration.
   2. Code source : Le programme doit inclure le code source, et doit autoriser la distribution du code
      source comme de l’exécutable compilé. Quand une forme quelconque du produit est distribuée sans
      le code source, il doit être clairement indiqué par quel moyen il est possible d’obtenir le code source,
      pour une somme qui ne doit pas excéder un coût raisonnable de reproduction, ou en le chargeant
      gratuitement via Internet. Le code source doit être la forme privilégiée par laquelle un programmeur
      modifie le programme. Un code source délibérément confus est interdit. Les formes intermédiaires de
      code source, telles que celles résultant d’un pré-processeur ou d’un traducteur, sont interdites.
   3. Travaux dérivés : La licence doit autoriser les modifications et les travaux dérivés, et doit permettre
      leur distribution dans les mêmes termes que la licence du logiciel d’origine.
   4. Intégrité du code source de l’auteur : La licence peut restreindre la distribution du code source
      modifié seulement si elle autorise la distribution de fichiers patchs avec le code source, dans le but de
      modifier le programme à la compilation. L’auteur peut ainsi garantir l’intégrité de son code source dans
      le processus de diffusion successive du logiciel. La licence doit explicitement permettre la distribution
      de logiciels obtenus à partir du code source modifié. La licence peut exiger que les travaux dérivés
      portent un nom ou un numéro de version différents du logiciel d’origine.
   5. Absence de discrimination envers des personnes ou des groupes : La licence ne doit pas être
      discriminante à l’encontre de personnes ou de groupes de personnes.
   6. Absence de discrimination envers des domaines d’activité : La licence ne doit pas restreindre
      ni interdire l’usage du logiciel à un quelconque domaine d’activité. Par exemple, il ne peut interdire
      l’usage du logiciel dans le cadre d’une activité professionnelle, ou en exclure l’usage pour la recherche
      génétique.
   7. Distribution de licence : Les droits attachés au programme doivent s’appliquer à tous ceux à qui il
      est distribué sans qu’il leur soit besoin de se conformer à des termes de licence complémentaires.
   8. La licence ne doit pas être spécifique à un produit : Les droits attachés au programme ne doivent
      pas dépendre du fait que le programme fait partie d’un logiciel en particulier. Si le programme est
      séparé du logiciel dans lequel il est intégré, et utilisé ou distribué selon les termes de la licence, toutes
      les parties à qui le programme est redistribué doivent avoir les mêmes droits que ceux accordés avec
      le logiciel dans lequel il est intégré à l’origine.
   9. La licence ne doit pas imposer de restrictions sur d’autres logiciels : La licence ne doit pas
      imposer de restrictions sur d’autres logiciels distribués avec le programme sous licence. Par exemple,
      la licence ne doit pas exiger que les autres programmes distribués sur le même support physique
      soient aussi des logiciels libres.
  10. La licence doit être neutre par rapport à la technologie : Aucune disposition de la licence ne doit
      dépendre d’une technologie ou d’une interface particulières. Par exemple, on ne peut pas obliger un
      utilisateur à décharger le logiciel uniquement depuis un site Web dans le but d’afficher de la publicité.

La figure 1 présente quelques catégories de licences en regard des libertés accordées.
  20
     Le texte complet de la licence GNU GPL est donné sur http://www.fsf.org/licensing/
licenses/gpl.html.
  21
     Voir le site Web dédié à CeCILL, http://www.cecill.info/.


Observatoire Technologique, CTI                                                                                 10
Standards ouverts et logiciel libre                                                   Clarification des notions




                              Figure 1 – Types de licences et libertés.



3.3.7 Licences doubles ou multiples

Les lois régissant le droit d’auteur permettent à ceux-ci de publier leurs œuvres simultanément sous plusieurs
types de licences. Ceci rend possible de différencier les contrats de licence appliqués selon le modèle que
les utilisateurs veulent (ou parfois doivent) adopter. Cette pratique est désignée par le terme anglais (dual
licensing).

Ceci permet également d’envisager un modèle économique pour la distribution du logiciel. D’une part, une
utilisation à but commercial et/ou lucratif est régie par un contrat de licence propriétaire payante, alors que,
d’autre part, une projet de logiciel libre peut intégrer exactement le même logiciel gratuitement en utilisant
une licence open source et gratuite.

Ce type de modèle est, par exemple, utilisé par la société MySQL fournissant la base de données du même
nom ou encore par TrollTech qui maintient la librairie de construction d’interface utilisateur Qt.

Par ailleurs, plusieurs organisations développant du logiciel libre recourent à ce même artifice en panachant
des licences du monde open source afin de faciliter l’intégration de composants propriétaires ou de permettre
une réutilisation plus large dans la sphère commerciale. Les projets les plus connus utilisant des licences
multiples de type libre sont OpenOffice.org, Perl et Mozilla.



3.4 Perspectives open source dans le secteur public

L’intérêt du secteur public pour l’open source est aujourd’hui indéniable, en particulier parce qu’il met en
œuvre des standards ouverts, qu’il brise les positions de lock-in et qu’il permet une plus grand adaptabilité
aux besoins particuliers22 .

Les motivations essentielles avancées par les gouvernements sont une meilleure maîtrise de leurs propres
systèmes d’information, une plus grande neutralité dans le choix de vendeurs de solutions ainsi qu’une
ouverture vers les entreprises et les citoyens désirant ou devant interagir avec les administrations.

De plus, on peut également voir un intérêt sociétal global car le modèle même du logiciel libre est fondé sur
le partage des connaissances et la réutilisation des composants. L’accessibilité des solutions open source
est garantie pour tous : autres organismes du secteur public, entreprises privées, organisations non gouver-
nementales, association ou simples citoyens.

Par ailleurs, le développement économique local pour les sociétés de services informatiques peut être favo-
   22
      Pour une analyse plus détaillée de ces sujets voir aussi :
Perspective Open Source, Rapport final du projet Nouvelles Plateformes Technologiques, P. Genoud et G.
Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève, Juin
2003, http://www.geneve.ch/ot/
Le logiciel libre dans les administrations, Annexe du projet Nouvelles Plateformes Technologiques, P. Genoud
et G. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève,
Juin 2003, http://www.geneve.ch/ot/.


Observatoire Technologique, CTI                                                                              11
Standards ouverts et logiciel libre                                                 Clarification des notions




risé lors de l’adoption de technologies open source.

Les solutions open source les plus mûres sont aujourd’hui encore celles touchant aux serveurs d’infrastruc-
ture : web, messagerie, serveurs de fichiers et d’imprimantes, ainsi que le système d’exploitation du serveur
lui-même. Plus récemment, les bases de données propriétaires classiques ont-elles aussi vu apparaître des
alternatives libres crédibles.

L’argumentation fondée uniquement sur une motivation de coûts est aujourd’hui dépassée : une analyse,
souvent très onéreuse, ne permet généralement pas de discriminer clairement une solution propriétaire et
une solution open source équivalente. Les administrations ont dans la plupart des cas compris que les
enjeux se situent au-delà du débat unidimensionnel du coût financier, même si celui-ci reste un élément de
décision non négligeable.

Le logiciel libre dépasse aujourd’hui très largement un phénomène de mode passager. Le support profes-
sionnel s’organise et de grandes, moyennes et petites entreprises offrent aujourd’hui leurs compétences
dans le domaine. Des projets open source d’envergure se fédèrent autour de communautés organisées qui
ont un mode de fonctionnement et une feuille de route clairs relativement aux produits qu’ils développent et
à leur processus de gestion. Le modèle même du logiciel libre est robuste aux changements économiques,
car le produit ne dépend plus d’un seul acteur, mais d’un écosystème qui lui permet de vivre et d’évoluer.
Les références d’utilisation de solutions open source au sein des administrations et des entreprises sont de
plus en plus fréquentes, même si le domaine est encore jeune et les expérimentations souvent en cours.



4    Les standards ouverts

Comme le relève M. Erkki Liikanen23 , commissaire européen chargé des entreprises et de la société de
l’information :


     « Les standards ouverts sont un élément essentiel de la mise au point de solutions interopérables
     et abordables pour tous. En outre, ils stimulent la concurrence en établissant des conditions tech-
     niques égales pour tous les acteurs du marché, ce qui se traduit par des réductions de coût au
     profit des entreprises et, en définitive, des consommateurs. »


Cette déclaration reflète le large consensus que l’on note actuellement autour des aspects positifs liés à la
notion d’ouverture. Il est cependant important d’examiner précisément quelle signification, quelles implica-
tions et quelles limitations y sont associées.

Du point de vue des organismes étatiques et para-étatiques, l’ouverture constitue une qualité première
lorsque l’on désire développer une relation tournée directement vers les citoyens et les entreprises. Elle
garantit un accès large et équitable aux services proposés. Dans ce contexte, l’ouverture implique que les
services publics garantissent un accès aux applications au travers de technologies variées qui n’imposent
aucune plateforme, aucun système d’exploitation ni aucun matériels particuliers24 .

L’utilisation de standards ouverts participe naturellement à cette notion d’ouverture avec pour vocation de
répondre à des objectifs stratégiques tels que :

    – Maximiser l’indépendance des utilisateurs en augmentant leur liberté d’action, en évitant de leur im-
      poser des décisions technologiques et en prévenant les phénomènes de lock-in de la part des four-
      nisseurs informatiques.
    – Assurer que tous les acteurs soient au même niveau en ce qui concerne l’utilisation de ces standards,
      ce qui favorise l’innovation (faible coût d’entrée sur le marché).
    – Contribuer à la maîtrise et à la flexibilité des systèmes informatiques en garantissant leur interopéra-
      bilité.
  23
     Journée mondiale de la normalisation, 14 octobre 2003, http://europa.eu.int/rapid/
pressReleasesAction.do?reference=IP/03/1374&format=HTML&aged=1&language=
FR&guiLanguage=fr.
  24
     How Open Can Europe Get ?, Open Forum Europe, Novembre 2004, http://www.
openforumeurope.org.


Observatoire Technologique, CTI                                                                            12
Standards ouverts et logiciel libre                                                      Clarification des notions




       – Amener à une bonne gestion des coûts via une diminution du prix des licences due à une augmen-
         tation de la concurrence. L’utilisateur peut ainsi choisir le composant logiciel présentant le meilleur
         rapport qualité/prix.
       – Garantir un meilleur équilibre entre stabilité et innovation car aussi bien l’orientation que la vitesse
         d’évolution d’un standard ne peuvent être imposées par un seul acteur.
       – Favoriser la pérennité de l’information puisque l’accès à celle-ci n’est plus lié à un fournisseur infor-
         matique ou à un produit particuliers.
       – Améliorer l’échange et l’accessibilité à l’information.
       – Capitaliser sur le savoir en favorisant la valorisation des données et des informations.
       – Réduire la fracture numérique en plaçant les standards ouverts au rang de biens communs de l’hu-
         manité (gratuits, libres d’accès et de droits).

Pour un développement détaillé de la plupart des points ci-dessus on peut se référer à l’article de Erik
Sliman25 qui propose un intéressant business case de la contribution des standards ouverts à l’économie
numérique. A un autre niveau, le livre blanc du programme OSOSS26 lancé par le gouvernement néerlandais
constitue une illustration de la façon de positionner certaines des contributions énoncées ci-dessus en regard
des objectifs stratégiques gouvernementaux.

Michael Totschnig27 complète ce tableau en ajoutant deux points particulièrement importants en terme de
vision sociétale :


        « En comparaison avec les standards fermés et propriétaires, les standards ouverts présentent
        deux caractéristiques essentielles qui ont des conséquences importantes sur la possibilité d’un
        espace public numérique. D’une part, leur définition et leur évolution constituent les enjeux d’un
        débat public dans lequel peuvent intervenir un grand nombre d’acteurs concernés ; d’autre part,
        comme leur utilisation ne peut être contrôlée par un seul acteur, tout acteur qui veut les intégrer à
        de nouveaux produits peut se les approprier. Cependant, en tant que biens collectifs, ils n’appar-
        tiennent à personne dans le sens où aucun acteur ne peut profiter plus qu’un autre de la valeur
        ajoutée générée par l’adoption publique d’un standard. »



Il ne faut pas négliger ces enjeux politiques et sociaux auxquels peuvent répondre les standards ouverts.
Les rapports entre l’administration et les citoyens sont en effet en train de changer. Ces derniers, dans un
souci de transparence des institutions, revendiquent toujours plus vivement la possibilité de pouvoir accéder
aux standards mis en œuvre. Or seul le processus d’élaboration d’un standard ouvert permet de prendre en
compte valablement les intérêts de la société civile.



4.1 Définitions et critères

La notion de standard ouvert reste cependant un concept relativement flou qu’il est important de clarifier.
Nous en donnons donc ci-dessous les définitions les plus communément utilisées afin de mieux comprendre
les différents points de vue concernés et de pouvoir ainsi en dégager celle qui semble la mieux adaptée à
la vision des différents partenaires de l’OT. Les notions générales de norme et de standard ont quant à elles
déjà été clarifiées ailleurs28 et nous n’y reviendrons pas ici.

Rappelons cependant que l’on distingue en général deux types de standards : ceux créés par le marché (de
facto) et ceux validés par un organisme de normalisation (de jure).
  25
      Business Case for Open Standards, Erik Sliman, Mai 2002, http://www.openstandards.net/.
  26
      Programme for open standards and open source software in government, ICTU, Pays-Bas, 2004, http:
//www.ososs.nl/.
   27
      Les standards ouverts de l’informatique et l’espace public numérique, Michael Totschnig, Université
du Québec à Montréal, Canada, 2001, http://commposite.uqam.ca/2001.1/articles/totsch.
html.
   28
      Normes et standards ouverts, Annexe du rapport du projet Nouvelles Plateformes Technologiques, Pa-
trick Genoud et Giorgio Pauletto, Observatoire Technologique, Centre des technologies de l’information du
canton de Genève, Juin 2003, http://www.geneve.ch/ot/.


Observatoire Technologique, CTI                                                                                 13
Standards ouverts et logiciel libre                                                       Clarification des notions




       Un standard de facto est introduit par un acteur du marché et s’établit de lui-même comme le ou
       l’un des standards dominants sans l’aval d’un organisme officiel de standardisation.



       Un standard de jure est établi par un organisme officiel de standardisation.


Un standard de jure est habituellement le résultat d’un consensus entre les différents membres d’un orga-
nisme officiel de standardisation qui est la plupart du temps composé à la fois de membres provenant d’ins-
titutions publiques et d’acteurs du marché. Les processus de standardisation de ce type peuvent prendre un
temps jugé excessif par certains mais ils ont le grand mérite de présenter un agenda très prévisible.

Lorsque l’on parle de standard ouvert, c’est souvent par opposition au standard propriétaire. Il est alors
question de savoir dans quelle mesure les restrictions d’usage placées par le propriétaire du standard sont
importantes. Dans ce cas les propriétaires du standard sont ceux qui, au travers de leur savoir-faire et/ou
de la mise en application de brevets et de droits de propriété intellectuelle sont à même de décider qui peut
utiliser le standard et à quel prix. L’évolution du standard est également de leur ressort.


       Un standard propriétaire est caractérisé par le fait qu’il est la propriété de quelqu’un qui y met
       (ou peut y mettre) des restrictions d’usage et d’accès.


Il est important de noter qu’un standard n’est en général jamais complètement fermé, ce qui irait à l’encontre
de sa diffusion. Le propriétaire choisit en fait le degré d’ouverture qu’il accorde à son standard afin d’optima-
liser ses bénéfices. Plus le standard est diffusé et plus il est attractif pour l’utilisateur, mais plus le revenu par
utilisateur (en terme de licences) a tendance à baisser.

Dans cette logique d’opposition au standard propriétaire, le gouvernement français, au travers de la LCEN29
définit un standard ouvert comme suit :


       « On entend par standard ouvert tout protocole de communication, d’interconnexion ou d’échange
       et tout format de données interopérable et dont les spécifications techniques sont publiques et
       sans restriction d’accès ni de mise en œuvre. »


En France on fait souvent référence à cette définition, même si elle manque selon nous de précision car
elle n’aborde qu’une partie seulement des caractéristiques importantes liées à l’ouverture des standards.
On y élude en effet les aspects liés au processus de validation par un organisme officiel de standardisation
qui prennent une dimension essentielle lorsque l’on raisonne en termes d’indépendance et d’évolution du
standard.

Une définition beaucoup plus complète des standards ouverts à laquelle on se réfère fréquemment est celle
de Bruce Perens30 qui propose une perspective axée utilisateur et basée sur les six principes ci-dessous.
Pour concrétiser la mise en œuvre de chacun de ces principes, une liste de meilleures pratiques (dont
certaines sont mentionnées ici) est proposée par l’auteur.

   1. Disponibilité : l’accès et l’implémentation des standards sont ouverts à tous.
           – Le bon usage veut que la description et l’implémentation de référence d’un standard ouvert
             soient disponibles gratuitement en téléchargement sur Internet.
           – Chaque projet devrait être capable de fournir une copie sans frais excessifs.
           – Les licences attachées à la documentation des standards ne doivent restreindre aucune partie
             d’implémenter ce standard en utilisant quelque type de licence que ce soit.
  29
     LCEN — Loi pour la confiance dans l’économie numérique, Loi 2004-575 du 21 juin 2004, article 4,
chap. Ier, titre Ier, http://www.foruminternet.org/documents/lois/lire.phtml?id=733.
  30
     Open Standards Principles and Practice, Bruce Perens, http://perens.com/OpenStandards/
Definition.html.


Observatoire Technologique, CTI                                                                                  14
Standards ouverts et logiciel libre                                                  Clarification des notions




          – Le bon usage veut que les licences des plateformes de référence d’une application soient com-
            patibles avec toutes les formes de licences, libres ou propriétaires.
   2. Maximiser le choix de l’utilisateur final : les standards ouverts créent un marché équitable et
      compétitif pour l’implémentation des standards. Ils ne lient pas les clients à un vendeur (ou un groupe
      de vendeurs) particulier.
          – Les standards ouverts doivent donc permettre une large gamme d’implémentations, que ce soit
            dans des projets métiers, académiques ou publiques.
          – Ils doivent supporter des solutions couvrant une large gamme de prix.
   3. Pas de droits d’auteur : les standards ouverts sont libres de frais et de droits d’auteur. Seule l’émis-
      sion d’un certificat de conformité par l’organisme de standardisation peut impliquer des frais.
          – La licence des brevets contenus dans des standards doit être libre de droits et non discrimina-
            toire.
   4. Pas de discrimination : les standards ouverts et les organismes qui les administrent ne doivent pas
      favoriser une implémentation plutôt qu’une autre pour une raison autre que la conformité technique
      de l’implémentation. Les organismes de certification doivent fournir le moyen de faire valider des
      implémentations à coût nul. Ils doivent également fournir des services de certification étendus.
   5. Extension ou sous-ensemble : les implémentations de standards ouverts peuvent être étendues
      ou proposées sous forme de sous-ensembles. Cependant les organismes de certification peuvent
      refuser de certifier des sous-ensembles d’implémentations et peuvent imposer des exigences sur des
      extensions (voir Pratiques de prédateurs).
   6. Pratiques de prédateurs : les standards ouverts peuvent recourir à des termes de licence qui les
      protègent contre des tactiques du type « englober / étendre ». Les licences attachées au standard
      peuvent exiger la publication d’informations de référence pour les extensions, et une licence pour la
      création, la distribution et la vente de software qui est compatible avec ces extensions. Un standard
      ouvert ne peut cependant pas interdire des extensions.

Selon Ken Krechmer31 , la notion de standard ouvert peut être appréhendée en combinant les trois perspec-
tives différentes que l’on peut en avoir, selon que l’on se place du point de vue du créateur du standard, de
celui qui l’implémente ou de celui qui l’utilise. Chaque perspective est naturellement guidée par des consi-
dérations très différentes.

   1. Les organismes de standardisation qui représentent les créateurs de standards considèrent que
      ces derniers sont ouverts si leur élaboration suit les principes de séances ouvertes, de décisions par
      consensus et de processus clairement définis.
   2. Les organismes qui implémentent un standard le considèrent comme ouvert lorsqu’il sert leurs
      marchés, lorsque son coût est nul, lorsqu’il n’empêche pas une innovation future, lorsqu’il ne rend
      pas obsolètes leurs implémentations précédentes et lorsqu’il ne favorise pas un concurrent.
   3. Les utilisateurs de l’implémentation d’un standard le considèrent comme ouvert lorsque plusieurs
      implémentations (provenant de différentes sources) de ce standard sont disponibles, lorsque les im-
      plémentations de ce standard fonctionnent partout où nécessaire, lorsqu’elles sont supportées durant
      tout le cycle de vie des services utilisés et lorsque de nouvelles implémentations souhaitées par les
      utilisateurs sont compatibles avec les plus anciennes.

Il est important de considérer ces trois points de vue afin de bien comprendre les attentes des différents
acteurs concernés. La combinaison de ces trois perspectives se traduit selon Krechmer dans dix droits
associés à la notion de standard ouvert :

   1. Séance ouverte : le processus de développement des standards est ouvert à tous.
   2. Consensus : les intérêts de chacun sont discutés et pris en compte de manière équivalente.
   3. Processus clairement définis : des processus de vote et de recours peuvent être utilisés pour
      résoudre un problème.
   4. Droits de propriété intellectuelle ouverts : ils sont disponibles pour tous les implémenteurs.
   5. Diffusion mondiale : pour des capacités données, un standard unique au niveau mondial.
  31
   The Meaning of Open Standards, Ken Krechmer, Hawaii International Conference on System Sciences,
Janvier 2005, http://www.csrstds.com/openstds.html.


Observatoire Technologique, CTI                                                                            15
Standards ouverts et logiciel libre                                                  Clarification des notions




   6. Modifications ouvertes : toutes les modifications sont présentées et approuvées par un forum fonc-
      tionnant selon les cinq droits précédents.
   7. Documentation ouverte : la documentation des standards comme de leurs avant-projets sont faci-
      lement accessibles, que ce soit pour leur implémentation ou pour leur utilisation.
   8. Interfaces ouvertes : les interfaces doivent supporter des migrations et permettre un avantage pro-
      priétaire mais les interfaces standardisées ne doivent être ni cachées ni contrôlées.
   9. Usage ouvert : les implémenteurs doivent pouvoir s’assurer objectivement de la conformité de leur
      implémentation. De leur côté les utilisateurs doivent avoir la garantie qu’elle répond à leurs besoins.
  10. Suivi du support : les standards sont supportés jusqu’à ce que l’intérêt des utilisateurs cesse, et non
      jusqu’à ce que l’intérêt des implémenteurs diminue.

On retrouve un certain nombre des critères énoncés par Perens. Mais le fait de tenir compte des points
de vue des créateurs et des implémenteurs de standards en donne une vision plus pragmatique. Krechmer
y introduit également la notion de processus d’élaboration ouvert. Il a ainsi comparé les principaux orga-
nismes de standardisation selon ces dix critères. Aucun n’obtient la note maximale. Selon lui, jusqu’à ce
que chaque organisme de standardisation indique clairement lesquels de ces dix critères il soutient et dans
quelle mesure, la notion de standard ouvert ne restera qu’un slogan publicitaire.

Entre la définition succincte de la LCEN française et celles relativement complexes mais plus complètes
proposées par Perens ou Krechmer il y a donc de la place pour des propositions intermédiaires, à la fois plus
simples à mettre en œuvre et à communiquer. On citera ici deux définitions qui nous semblent pertinentes
et qui vont dans ce sens. Celle proposée par le service gouvernemental belge Fedict32 , et celle de l’EIF, le
cadre commun d’interopérabilité33 de la Commission Européenne.

La définition de Fedict s’appuie sur les notions de spécification ouverte et de spécification libre pour définir
un standard ouvert.


       Une spécification ouverte doit être gratuite, disponible en ligne et suffisante pour développer
       une implémentation complète.
       Une spécification libre doit être ouverte et ne doit pas comprendre de restrictions juridiques (à
       l’exception de « licences open source ») qui compliquent la diffusion et l’utilisation.
       Un standard ouvert est une spécification libre et doit être approuvé par une organisation de
       standardisation indépendante.



Comme schématisé à la figure 2, cette définition permet de distinguer très directement les différents cas.

Le standard PDF par exemple, qui est parfois présenté (à tort) comme un standard ouvert, y apparaît comme
une spécification ouverte mais propriétaire. Elle est en effet la propriété de la société Adobe qui en contrôle
l’évolution. On y retrouve les éléments clés liés à la notion d’ouverture comme l’accès gratuit à la spéci-
fication, la liberté d’usage et l’adoption par une organisation indépendante et ouverte. Cette définition se
concentre sur les aspects jugés comme essentiels liés à l’ouverture du standard mais n’est pas aussi com-
plète que celles proposées par Perens ou Krechmer.

Avec le même souci de simplification, la Commission Européenne énonce une définition très similaire ins-
pirée de celle en vigueur aux Pays-Bas (voir la section 7). Ainsi, selon l’EIF, un standard peut être qualifié
d’ouvert si :
  32
     Directives et recommandations pour l’usage de standards ouverts et/ou spécifications ouvertes dans
les administrations fédérales, Jean Jochmans et Peter Strickx, Gouvernement fédéral de Belgique, 2003,
http://www.belgium.be.
  33
     EIF — European Interoperability Framework for Pan-European eGovernment Services, IDABC, Com-
mission Européenne, 2004, http://europa.eu.int.




Observatoire Technologique, CTI                                                                            16
Standards ouverts et logiciel libre                                                     Clarification des notions




       Figure 2 – Des standards propriétaires aux standards ouverts (selon Fedict).




         1. Il est adopté et maintenu par une organisation à but non lucratif. Son développement se
            fait sur la base d’une procédure décisionnaire ouverte disponible à toutes les parties inté-
            ressées (par consensus ou à la majorité par exemple).
         2. Il a été publié et sa spécification est disponible soit gratuitement, soit à un coût nominal. Il
            doit être permis à chacun de le copier, de le distribuer et de l’utiliser soit gratuitement, soit
            à un coût nominal.
         3. La propriété intellectuelle, c’est-à-dire les brevets éventuels, de tout ou partie du standard
            est cédée irrévocablement sur une base libre de royalties.
         4. Il n’y a aucune contrainte à sa réutilisation.



On y voit apparaître la notion de réutilisation du standard. Par contre la référence au fait que la spécifi-
cation soit suffisante pour développer une implémentation complète n’y apparaît pas. On y introduit enfin
la notion de coût nominal (synonyme de faible) qui peut prêter à interprétation et donc à confusion. Cette
dernière notion est en effet relativement floue et n’entre d’ailleurs pas dans les critères proposés par Bruce
Perens. Lorsqu’un gouvernement ou une administration propose l’utilisation d’un standard ouvert à quelques
dizaines ou centaines de milliers de ses citoyens, cette notion de coût nominal peut amener des contraintes
financières fortes selon l’interprétation qu’on lui donne.

La simplicité de la définition de l’EIF a par contre le mérite de faciliter sa mise en œuvre et sa communication.
Dans la mesure ou elle a été émise au niveau européen et qu’on s’y réfère dans plusieurs pays (la Norvège
et les Pays-Bas notamment, voir la section 7), on peut supposer qu’elle constituera, en Europe du moins,
une définition de référence de la notion de standard ouvert.



4.2 Degré d’ouverture

Plusieurs standards se situent dans une zone grise entre standards propriétaires et standards ouverts. Ainsi
les définitions proposées ci-dessus ne devraient pas être vues comme une exigence stricte pour qu’un



Observatoire Technologique, CTI                                                                                 17
Standards ouverts et logiciel libre                                                   Clarification des notions




standard puisse être qualifié d’ouvert. Dans la pratique ces définitions devraient plutôt fournir les paramètres
d’évaluation à utiliser pour qualifier le degré d’ouverture du standard étudié.

La figure 3 illustre cette notion de zone grise. Quelques standards y sont sommairement positionnés en fonc-
tion d’une part de la facilité d’accès à leurs spécifications et d’autre part du degré d’ouverture de l’organisme
qui l’a validé. Le schéma ne présente que deux des critères liés à la notion de standard ouvert. Si l’on s’en
tenait à ces deux critères uniquement, le standard ouvert idéal se situerait dans la zone en haut à droite du
graphique.




                            Figure 3 – Degré d’ouverture d’un standard.


L’exemple du coût nominal introduit dans la définition de l’EIF est illustratif. Le développement et la mainte-
nance d’un standard efficace impliquent souvent des frais importants de la part du sponsor de ce standard.
Ces coûts ne sont pas couverts si le standard peut être utilisé gratuitement, sauf au travers de la vente de
produits ou de services dérivés. La gratuité est donc une qualité idéale que l’on peut attendre d’un standard
ouvert mais qui se heurte à une vision pragmatique des choses. Dans de nombreux cas, on ne peut ainsi
pas s’attendre à ce que le standard ouvert idéal n’existe que parce qu’il correspond à un besoin exprimé.
D’un autre côté, il est évident que la gratuité est un pré-requis nécessaire (mais pas suffisant) lorsque l’on
considère des implémentations de logiciels libres qui doivent par essence pouvoir être redistribuées gratui-
tement.

On se trouve alors face à deux cas de figure. Soit l’on propose, comme l’EIF, une définition laissant une
marge d’interprétation qui permet de prendre en compte la zone grise autour du standard ouvert idéal. Mais
on y perd alors en terme de clarté de la définition puisque un certain nombre de termes peuvent être sujets à
interprétation. Soit l’on suit une approche similaire à celle du gouvernement danois34 qui donne une définition
du standard ouvert dans sa forme la plus pure (propriétés fondamentales que l’on désire promouvoir) et qui
met en œuvre une politique de standardisation pragmatique. Cette approche laisse une certaine marge de
manœuvre par rapport à cet idéal en incluant le degré d’ouverture du standard dans les critères d’évaluation.
  34
    Definition of open standards, National IT and Telecom Agency, Ministry of Science, Technology and
Innovation, Danemark, Juin 2004, http://www.itst.dk/.




Observatoire Technologique, CTI                                                                              18
Standards ouverts et logiciel libre                                                 Clarification des notions




Joel West35 a étudié cette notion de degré d’ouverture et propose un certain nombre de dimensions per-
mettant d’apporter une métrique lors de l’évaluation d’un standard. On peut les résumer au travers des 3
questions suivantes.

     1. QUI : Qui a accès au standard ?
     2. QUOI : Dans quel(s) but(s) le standard est-il ouvert ?
     3. COMMENT : Quel est l’accès donné au standard ?

La figure 4 présente un tableau constituant un point de départ pour l’élaboration d’une telle métrique.




Figure 4 – Questions permettant d’évaluer le degré d’ouverture d’un standard (selon
West).




5        Organismes de normalisation

Cette section recense les principaux consortiums et organismes de standardisation œuvrant dans le do-
maine des nouvelles technologies de l’information et de la communication. Cette liste n’est naturellement
pas exhaustive. Les consortiums et organismes recensés ici travaillent à l’élaboration de standards que l’on
peut considérer à divers degrés comme ouverts.

AFNOR Association Française de Normalisation. http://www.afnor.fr/
           – Normalisation dans le domaine des technologies de l’information http://forum.afnor.fr/
ANSI American National Standards Institute. http://www.ansi.org/
ATIS Alliance for Telecommunications Industry Solutions. http://www.atis.org/
    35
   What are Open Standards ? Implications for Adoption, Competition and Policy., J. West, Standards and
Public Policy Conference, Chicago, USA, Mai 2004, http://www.cob.sjsu.edu/west_j.



Observatoire Technologique, CTI                                                                          19
Standards ouverts et logiciel libre                                            Clarification des notions




CEN Comité Européen de Normalisation. http://www.cenorm.be/
Dublin Core Dublin Core Metadata Initiative, Groupe engagé dans le développement de standards de mé-
      tadonnées. http://dublincore.org/
ECMA European association for standardizing information and communication systems. http://www.
    ecma-international.org/
ETSI European Telecommunications Standards Institute. http://www.etsi.org/
FreeStandards.org The Free Standards Group. http://www.freestandards.org/
ICTSB Information & Communications Technologies Standards Board. http://www.ictsb.org/
IEC International Electrotechnical Commission. http://www.iec.ch/
IEEE Institute of Electrical and Electronics Engineers. http://www.ieee.org/
IETF Internet Engineering Task Force. http://www.ietf.org/
ISO Organisation Internationale de Normalisation. http://www.iso.ch/
ITU The International Telecommunication Union. http://www.itu.int/
JCP Java Community Process. http://jcp.org
Liberty Alliance Liberty Alliance Project. http://www.projectliberty.org
LSB Linux Standard Base. http://www.linuxbase.org/
NIST National Institute of Standards and Technology. http://www.nist.gov/
          – Le sous-domaine ITL : Information Technology Lab. http://www.itl.nist.gov/
OASIS Organization for the Advancement of Structured Information Standards. http://www.oasis-open.
     org/
          – Liste de tous les standards de base associés aux technologies Markup Language. http://
            xml.coverpages.org/coreStandards.html
          – Une introduction à ces standards. http://xml.coverpages.org/library.html
ODMG Object Data Management Group. http://www.odmg.org/
OMA Open Mobile Alliance. http://www.openmobilealliance.org/
OMG Object Management Group. Organisation internationale dont le but est de produire et de maintenir
    des spécifications pour des applications interopérables. http://www.omg.org/, notamment :
          – CORBA (Common Object Request Broker Architecture). http://www.corba.org/
          – UML (Unified Modeling Language). http://www.uml.org/
          – MDA (Model Driven Architecture). http://www.omg.org/mda/
OpenGroup The Open Group. http://www.opengroup.org/
OSGi Open Services Gateway Initiative. http://www.osgi.org/
RosettaNet Open e-business process standards. http://www.rosettanet.org/
TCG Trusted Computing Group. https://www.trustedcomputinggroup.org/
UDDI.org Universal Description, Discovery, and Integration. http://www.uddi.org/
VoiceXML Voice XML Forum. http://www.voicexml.org/
W3C World Wide Web Consortium. http://www.w3.org/
          – La liste de la cinquantaine de recommandations émises par le W3C. http://www.w3.org/
            TR/#Recommendations
          – Ainsi que les domaines d’activités correspondants. http://www.w3.org/Consortium/Activities
          – Méthodes de travail du W3C par Alain Michard (en français). http://www.editions-eyrolles.
            com/livres/michard/w3c-present.asp
WS-I Web Services Interoperability Organization. http://www.ws-i.org/




Observatoire Technologique, CTI                                                                     20
Standards ouverts et logiciel libre                                                     Clarification des notions




6    Standard ouvert vs logiciel libre

Les chapitres précédents montrent combien les fondements des standards ouverts et des logiciels libres
sont basés sur des objectifs et des modes de fonctionnement similaires. Mais ces deux concepts différent
malgré tout : schématiquement, les standards ouverts concernent le contenu et l’échange d’information alors
que le logiciel libre ne relève que de l’accès au code source.

Comme le souligne Jack Verhoosel36 , les développeurs de logiciels libres implémentent volontiers des stan-
dards ouverts pour deux raisons. La première est que l’utilisation de standards propriétaires va à l’encontre
des principes d’ouvertures et d’interopérabilité qui sont prônés par la communauté du libre et qu’ils n’ont
aucun intérêt à lier les utilisateurs à leurs développements. La seconde concerne les coûts et les licences
d’utilisation éventuels des standards propriétaires qui vont à l’encontre de certaines licences open source.

Il n’y a d’ailleurs pas toujours incompatibilité entre logiciel libre et standards propriétaires, pour autant que
ceux-ci soient publiquement accessibles, gratuits et libres d’utilisation. A l’inverse il est possible et même
souhaitable qu’un logiciel propriétaire implémente sans aucune restriction des standards ouverts. Ceci dé-
pend fortement des conditions concurrentielles prévalant sur le marché.

En principe la communauté open source préconise l’usage des standards ouverts. Mais ce n’est pas for-
cément la règle. Cela peut provenir du fait qu’un standard ouvert potentiellement utilisable est incomplet,
immature, de qualité insuffisante ou simplement qu’il n’existe pas. C’est parfois aussi tout bonnement lié
au manque de maturité de la communauté de développeurs concernée par rapport à l’utilisation des stan-
dards ouverts. Les spécialistes réunis lors de la conférence de Scottsdale37 tenue récemment sur le sujet,
estiment qu’il y a encore un travail de sensibilisation à effectuer auprès de la communauté open source afin
de la pousser à mieux implémenter les standards ouverts.



     « Le logiciel libre fait face à des défis importants, mais non insurmontables, dans son évolution
     actuelle. En tête de liste on retrouve les préoccupations liées à la propriété intellectuelle, à la
     nécessité de fournir des options de support et d’intégration aux usagers (et de les convaincre qu’ils
     sont fiables) et de gérer le risque tout en maximisant l’utilité des logiciels. Les standards (ouverts)
     proposent un outil efficace pour apporter une réponse à plusieurs de ces préoccupations. »



Les logiciels libres auraient alors le double mérite d’implémenter des standards ouverts et de constituer une
métrique pour la qualité de ces standards. En effet un standard devrait de manière générale être pensé et
conçu en considérant son implémentation future. Mais quel que soit son degré d’ouverture, il ne démontre
sa réelle utilité que dans la mesure où l’on peut se référer à des implémentations certifiées et accessibles.
A ce niveau le lien entre logiciel libre et standards ouverts est manifeste car il est difficile de cacher l’implé-
mentation d’un standard lorsque le code source est ouvert. Comme la communauté open source implémente
généralement des solutions interopérables aussi conformes que possible aux standards ouverts, les logiciels
libres de bonne qualité peuvent alors constituer des implémentations de référence accessibles.

L’Union Européenne38 présente à cet égard le logiciel libre comme un modèle de développement idéal pour
s’assurer que les standards ouverts peuvent être correctement mis en œuvre et intégrés. Le cadre com-
mun d’interopérabilité européen relève que : « Les logiciels libres sont, par leur nature, des spécifications
publiquement accessibles et l’ouverture de leur code source, promeut un débat ouvert et démocratique sur
les spécifications, ce qui les rend à la fois plus robustes et interopérables. En tant que tels, le logiciel libre
correspond aux objectifs du présent programme et devrait être évalué et considéré favorablement aux côtés
d’alternatives propriétaires. »

D’un autre côté, il est essentiel que les organismes de standardisation comprennent et acceptent les prin-
cipes du logiciel libre. Le monde du libre aurait alors tout à y gagner. Certains comme Lawrence Rosen39
  36
     Open Standards and Open Source Software : Similarities and Differences, J. Verhoosel, Entschede,
Pays-Bas, http://www-i4.informatik.rwth-aachen.de/~jakobs/Interop/Verhoosel.pdf.
  37
     Conference « Open Source, Open Standards : Maximizing Utility While Managing Exposure », 12-14
Septembre 2004, Scottsdale, USA, http://www.thebolingroup.com/OSOSAnalysis.pdf
  38
     EIF — European Interoperability Framework for Pan-European eGovernment Services, IDABC, Com-
mission Européenne, 2004, http://europa.eu.int.
  39
     Lawrence Rosen, http://www.rosenlaw.com/.



Observatoire Technologique, CTI                                                                                21
Standards ouverts et logiciel libre                                                       Clarification des notions




proposent même une redéfinition de la notion de standard ouvert afin de faciliter l’alignement des deux
communautés. C’est principalement au niveau des droits de propriété intellectuelle et de gratuité que les
définitions actuelles peuvent en effet poser problème.



7        Politiques gouvernementales

Plusieurs gouvernements ont déjà pris position sur l’adoption des standards ouverts et du logiciel libre. Ces
positions sont parfois très différentes et couvrent une large palette allant d’une non entrée en matière, à une
volonté politique très affirmée en passant par une attitude agnostique.

La section suivante résume les prises de position gouvernementales qui nous paraissent les plus intéres-
santes dans ce domaine. Cette liste n’est bien entendu pas exhaustive et évolue continuellement. Un recueil
de liens est également disponible sur le site de l’IDABC40 .

Le Center for Strategic and International Studies produit un document41 qui recense dans un tableau sy-
noptique les politiques, les recommandations et les textes de loi considérés au niveau des administrations
nationales, régionales et locales sur la planète.

Voici notre analyse en date du mois de juillet 2005.



7.1 Belgique

Le Conseil des Ministres du 25 juin 2004 a approuvé les directives et recommandations aux services publics
fédéraux pour l’usage de standards, de logiciels d’application et de logiciels libres, faits sur mesure42 :

« Pour les nouveaux systèmes informatiques, les services publics fédéraux utiliseront désormais exclusive-
ment des standards ouverts et/ou spécifications ouvertes pour les formats de données et les protocoles de
communication lors de l’archivage, de l’échange et de la communication de données électroniques. Pour les
applications existantes qui, lors de l’archivage, de l’échange ou de la communication de données électro-
niques à des parties externes, n’utilisent pas encore de standards ouverts et/ou de spécifications ouvertes,
pour les formats de données et les protocoles de communication, les services publics fédéraux lanceront et
achèveront une migration conformément à un planning convenu lors de la fixation de chaque standard ou-
vert et/ou spécification ouverte. Les administrations fédérales disposeront des droits de propriété pour tout
logiciel fait sur mesure. Ce logiciel sera fourni en code source et sans droit de licence. Les services publics
fédéraux pourront mettre ce logiciel à la disposition d’autres services publics en tant que logiciel libre. »

La stratégie 2005 du gouvernement belge est décrite par Peter Vanvelthoven, Secrétaire d’État à l’Informa-
tisation de l’État43 . Le point 3.4 stipule clairement que toute nouvelle application informatique utilisera des
standards ouverts et que les applications existantes devront être migrées progressivement vers ceux-ci. La
liste des standards ouverts utilisés par l’État sera rassemblée au sein du Cadre Fédéral Belge d’Interopera-
bilité en concertation avec les Communautés et Régions.

De plus, le texte continue sur la position face au logiciel libre : « Les logiciels libres doivent être sérieusement
pris en compte au sein de l’administration fédérale. Quelques services publics ont déjà commencé à migrer
d’un environnement de logiciels propriétaires vers un environnement de logiciels libres. Fedict suivra ces
projets pilotes et évaluera les résultats et formulera des recommandations pour l’ensemble de l’administra-
tion. »

Le service gouvernemental Fedict44 définit la notion de standard ouvert comme : « une spécification gratuite,
    40
     Section du site Web du programme IDABC consacrée au logiciel libre : http://europa.eu.int/
idabc/en/document/1677/471.
  41
     CSIS — Center for Strategic and International Studies, 13 décembre 2004, http://www.csis.org/
tech/OpenSource/0408_ospolicies.pdf.
  42
     Standards et Logiciels, Chancellerie du Premier Ministre — Conseil des Ministres, Belgique, 2004,
http://www.belgium.be/eportal/application?pageid=contentPage&docId=35409.
  43
     Note stratégique 2005, Secrétaire d’État à l’Informatisation de l’État, Peter Vanvelthoven, Belgique, 2005,
http://www.belgium.be/eportal/application?pageid=contentPage&docId=36796.
  44
     Fedict a pour tâche d’initier, d’élaborer et d’accompagner des projets d’e-government pour l’administra-



Observatoire Technologique, CTI                                                                                 22
Standards ouverts et logiciel libre                                                    Clarification des notions




disponible en ligne, suffisante pour développer une implémentation complète, qui ne doit pas comprendre de
restrictions juridiques (à l’exception de « licences open source ») qui compliquent la diffusion et l’utilisation
et qui doit être approuvée par une organisation de standardisation indépendante45 . »

Cette définition est similaire à celle de la Commission Européenne, mais ne fait notamment pas intervenir les
notions d’organisation de standardisation indépendante à but non lucratif, avec des procédures de décision
ouvertes et la mise à disposition gratuite et irrévocable des droits de propriété intellectuelle contenus dans
le standard. En revanche, elle précise bien que l’implémentation doit être possible ce qui ne ressort pas
clairement de la définition européenne.

Le gouvernement belge a défini un cadre commun d’interopérabilité46 dans lequel il concrétise sa vision
relative au logiciel libre et aux standards ouverts. La consultation de ce référentiel est largement ouverte
(même aux contributions externes) dans le but de définir les standards techniques à travers un wiki 47 qui en
permet la mise à jour continue.



7.2 Brésil

Le président brésilien, Luís Inácio Lula da Silva, a donné le mandat le 29 octobre 2003 à l’Institut Natio-
nal de Technologie Informatique (ITI) de planifier, coordonner et implémenter les projets du gouvernement
concernant le logiciel libre48 (article 1).

Le ITI intègre le Comité Exécutif du Gouvernement Électronique, lequel coordonne le Comité Technique
d’Implémentation du Logiciel Libre du Gouvernement Fédéral49 .

Dans son plan stratégique de mai 2004, le comité Exécutif du Gouvernement Électronique précise d’entrée
que « le logiciel libre doit être utilisé comme une ressource stratégique » (page 8).

La position du gouvernement brésilien face aux technologies de l’information est clairement une vision très
large de développement économique et social, ainsi que de diminution de la fracture numérique. Le 18 juin
2004 Sérgio Amadeu da Silveira, directeur de l’ITI, déclarait : « Nous n’optons pas pour un produit, nous
optons pour un modèle de développement et d’utilisation de logiciel. C’est une décision politique, et j’insiste
sur ce point, fondée sur une raison économique — une réduction du paiement de royalties. Cette décision
augmente aussi l’autonomie technologique du Brésil et renforce notre intelligence collective. »

La plupart des sites web gouvernementaux brésiliens utilisent des composants libres et le gouvernement
impose aux organismes d’état ou aux compagnies privées bénéficiant de financements gouvernementaux
de développer et d’éditer leurs logiciels sous licence libre GNU/GPL50 .

Un autre point intéressant est que le gouvernement préfère le logiciel libre pour éviter la gestion coûteuse
les licences de produits propriétaires ou le risque de piratage qui le mettrait également face à des coûts et
des poursuites judiciaires possibles.

Microsoft a proposé une version moins coûteuse, mais amputée de plusieurs fonctionnalités de Windows XP
(baptisée Windows Starter Edition) au Brésil. Toutefois, cette option a été finalement écartée par le gouver-
nement brésilien. La décision a été très largement influencée par le rapport commandé par le gouvernement
à Walter Blender, directeur exécutif du MIT MediaLab (Massachussets Institute of Technology), qui a chau-
dement recommandé l’usage des logiciels libres de bonne qualité qui sont, selon lui, plus intéressants que

tion fédérale. Il dépend des services publics fédéraux et de programmation dans le cadre des technologies
de l’information et de la communication http://www.belgium.be/eportal/application?pageid=
indexPage&navId=9513.
   45
      Directives et recommandations pour l’usage de standards ouverts et/ou spécifications ouvertes dans
les administrations fédérales, Jean Jochmans et Peter Strickx, Gouvernement fédéral de Belgique, 2003,
http://www.belgium.be.
   46
      BELGIF — BELgian Governement Interoperability Framework, http://www.belgif.be.
   47
      Un wiki est un site web dynamique dont tout visiteur peut modifier les pages à volonté. Pour plus d’infor-
mation voir http://fr.wikipedia.org/wiki/Wiki.
   48
      Voir le site du Gouvernement brésilien, http://www.governoeletronico.gov.br/
governoeletronico/index.html.
   49
      Software Livre, Gouvernement du Brésil, http://www.softwarelivre.gov.br/.
   50
      Brazil : Free Software’s Biggest and Best Friend, Todd Benson, The New-York Times, 29 mars 2005,
http://www.nytimes.com/2005/03/29/technology/29computer.html.


Observatoire Technologique, CTI                                                                               23
Standards ouverts et logiciel libre                                                   Clarification des notions




les versions propriétaires limitées.



7.3 Danemark

Le gouvernement danois (Ministère des sciences et technologies, et de l’innovation) a adopté le 13 juin 2003
une stratégie relative à l’utilisation de logiciels dans le but d’accroître la concurrence du marché du logiciel
et d’augmenter la qualité et la cohérence des produits logiciels déployés dans le secteur public51 . Cette
stratégie est déclinée selon une série de principes :

   1. Valeur monétaire : Le principe gouvernant le choix, l’approvisionnement et l’utilisation de logiciels
      dans le secteur public est la recherche de la valeur maximale, fondée sur une approche coûts/bénéfices,
      indépendamment du fait d’utiliser du logiciel propriétaire ou libre.
   2. Concurrence, indépendance et liberté de choix : Une concurrence effective est un pré-requis es-
      sentiel pour un marché du logiciel compétitif et diversifié. Les distributeurs de logiciel doivent pouvoir
      se concurrencer à « armes égales » et les barrières d’entrée doivent être éliminées.
   3. Interopérabilité et flexibilité : La priorité doit être donnée aux logiciels qui sont construits de façon
      modulaire et qui peuvent s’interconnecter avec d’autres types de programmes et de systèmes. Ceci
      permet d’assurer que les modules du système logiciel peuvent être changés ou modifiés indépen-
      damment et ainsi augmenter la flexibilité et permettre la réutilisation.
   4. Développement et innovation : Le secteur public doit être ouvert aux nouvelles méthodes d’approvi-
      sionnement et de développement de logiciel. En particulier, il existe un besoin de tester de nouvelles
      méthodes comme celles de développement du logiciel libre afin de les évaluer et d’en mesurer les
      avantages et les inconvénients à large échelle dans le cadre des administrations publiques.

Pour soutenir ces objectifs stratégiques, les activités suivantes sont lancées :
       – Développer une signature numérique publique basée sur une solution open source.
       – Développer une analyse du coût total de possession (Total Cost of Ownership).
       – Démarrer des projets pilotes dans les administrations centrales, régionales et locales.
       – Suivre l’usage de standards ouverts et la définition d’un format de document ouvert.
       – Élargir le marché du logiciel pour le secteur public.
       – Favoriser la collecte et la dissémination de l’information.
Un travail conséquent de standardisation des informations est entrepris. Ces résultats enrichissent un ré-
férentiel XML afin de soutenir l’ensemble de la démarche. Le projet est nommé Infostructurebase52 et son
objectif est de déterminer des standards pour l’échange de données en interne ainsi qu’entre les autorités
gouvernementales, le public et les entreprises. La standardisation est une étape nécessaire vers l’utilisation
et la réutilisation des données sur le long terme en s’assurant de l’absence de blocage (lock-in) dans des
outils propriétaires ou des formats non documentés.

La méthodologie de standardisation adoptée est très intéressante. Elle laisse des groupes d’utilisateurs,
appelés communautés de pratique, définir les standards relatifs à leurs métiers en collaboration avec les
informaticiens. Le rôle de ces communautés de pratique est de classifier et clarifier les termes et concepts
utilisés lors d’échanges d’informations ainsi que leurs besoins d’interopérabilité en créant des définitions
standard d’objets informationnels. Ces standards sont ensuite proposés à un comité XML qui revoit, accepte
et publie les résultats. Ces résultats forment une base de référence pour le groupe de travail technique qui
est ensuite chargé de rédiger les schémas XML correspondants.

Ceci permet de réconcilier les architectures métier et technique. D’une part, les communautés de pratique
définissent les concepts, la terminologie, les significations et les associations ainsi que les manières de
travailler avec l’information. D’autre part, ces inputs sont intégrés dans les schémas par les informaticiens
qui, eux, n’ont pas toujours une compréhension complète du domaine ou un ressenti exact de l’importance
des relations spécifiques au métier.
  51
     ICA Country    Report,    Danemark, 2003,   http://e.gov.dk/english/results/2003/
benchmarking_ica_country_report_denmark_2003/index.html.
  52
     OIO —     Infostructurebase,  Danemark,   http://isb.oio.dk/Info/Standardization/
Standardization.htm.



Observatoire Technologique, CTI                                                                              24
Standards ouverts et logiciel libre                                                     Clarification des notions




7.4 États-Unis, Massachusetts

Le gouvernement de l’État du Massachusetts a publié le 13 janvier 2003 deux documents concernant sa
position vis-à-vis des standards ouverts et du logiciel libre.

Le premier53 exige l’utilisation de standards ouverts comme critère sélectif lors de la création, de l’acquisition
ou de la refonte d’applications informatiques afin d’assurer que les investissements dans les technologies
de l’information soient consacrés à des solutions suffisamment interopérables pour satisfaire aux exigences
métier de ses départements et servir au mieux le public.

L’État du Massachusetts propose la définition suivante du standard ouvert : « Une spécification qui est dis-
ponible publiquement, développée par une communauté ouverte et confirmée par un organisme de norma-
lisation. »

Le second document54 concerne l’acquisition de logiciels et stipule que les solutions doivent être sélection-
nées selon la valeur mesurée au-delà du pur aspect financier.

Il est nécessaire de considérer au minimum : le coût total de possession sur la durée de vie de la solution,
l’adéquation aux besoins métier, la stabilité, la performance, la scalabilité, la sécurité, les exigences de
maintenance, les risques légaux, la facilité de d’adaptation et la facilité de migration.

Toutes les alternatives incluant en particulier, les logiciels propriétaires, les logiciels libres ainsi que les
logiciels dont le code est partagé entre les administrations doivent être examinées.

La position de cet état a eu une grande visibilité médiatique. Les déclarations de ses représentants, le CIO
Peter J. Quinn et le Secrétaire d’État Eric Kriss55 ont poussé Microsoft à négocier et à proposer une version
« moins fermée » du format XML des fichiers MS Office.

L’état du Massachussets a pris position sur les formats de données et identifie le OASIS Open Document
Format comme le standard choisi pour les applications bureautiques56 . Depuis le 21 septembre 2005, le
format OpenDocument est l’un des standards de données référencés par leur modèle de référence technique
qui catalogue les standards officellement adoptés57 .

Au niveau fédéral américain, l’Office of Management and Budget recommande que les agences gouver-
nementales aient des politiques d’acquisition de logiciels « neutres quant aux technologies et aux fournis-
seurs. »



7.5 France

L’Agence pour le Développement de l’Administration Électronique58 (ADAE) met à disposition des ministères
et des services un guide de choix et d’usage des licences de logiciels libres pour les administrations. Ce
guide recommande de privilégier l’utilisation de la licence GNU GPL pour les développements en logiciels
libres réalisés par ou pour les administrations. Il préconise également une démarche qui s’appuie sur le
code des marchés publics. L’ADAE a aussi largement soutenu l’information sur les solutions de logiciel libre
  53
      Enterprise Open Standards Policy, Commonwealth of Massachusetts, Massachusetts, USA, 13 janvier
2004, http://www.mass.gov/Aitd/docs/policies_standards/openstandards.pdf.
   54
      Enterprise Information Technology Acquisition Policy, Commonwealth of Massachusetts, Mas-
sachusetts, USA, 13 janvier 2004, http://www.mass.gov/Aitd/docs/policies_standards/
itacquisitionpolicy.pdf.
   55
      Une retranscription officielle des commentaires informels donnés lors de la confé-
rence          de     presse    http://www.mass.gov/eoaf/open_formats_comments.html                et
leur         traduction      en     français     http://formats-ouverts.org/blog/2005/01/21/
255-traduction-du-texte-officiel-du-massachussets-sur-les-formats-ouverts.
   56
      Déclaration de Peter Quinn du 29 août 2005 sur le site du http://www.mass.gov/Aitd/ et in-
formations sur le site de News.com Massachusetts to adopt ’open’ desktop http://news.com.com/
2102-1012_3-5845451.html.
   57
      Voir le document Enterprise Technical Reference Model Version 3.5 http://www.mass.gov/Aitd/
docs/policies_standards/etrm3dot5/etrmv3dot5informationdomain.pdf page 18.
   58
      ADAE - Agence pour le Développement de l’Administration Électronique, http://www.adae.gouv.
fr/.



Observatoire Technologique, CTI                                                                                25
Standards ouverts et logiciel libre                                                    Clarification des notions




à travers ses publications et colloques59 .

Notons également que depuis la rédaction du guide du choix de licences, le CEA, le CNRS et l’INRIA ont
élaboré CeCILL60 , la première licence reprenant les principes de la GNU GPL et qui définit les principes
d’utilisation et de diffusion des logiciels libres en conformité avec le droit français.

A travers l’ADAE, le gouvernement propose de créer et développer une plate-forme de services destinée aux
organismes publics, visant le développement des technologies de l’information et de la communication. L’un
des objectifs est de mettre en place un entrepôt d’informations pour la diffusion de la connaissance relative
notamment aux méthodes, aux chartes et aux guides et d’en assurer la gestion. Il s’agit par ailleurs de pro-
poser un espace de développement collaboratif qui sera également un point d’entrée pour le référencement
des logiciels et des composants réutilisables.

L’un des résultats de cette démarche est AdmiSource61 , une plate-forme collaborative proposée à l’ensemble
des administrations françaises pour leurs développements de logiciels libres. Chacun est le bienvenu pour
utiliser, participer et contribuer à la hauteur de ses intérêts. Ce portail permet de fédérer et partager les
développements réalisés par les administrations françaises en leur offrant un outil de gestion de projet ouvert
et collaboratif.

Un démarche très similaire est proposée par l’ADULLACT62 , une association sans but lucratif, dont l’objectif
est de soutenir et coordonner l’action des administrations et des collectivités territoriales pour promouvoir,
développer, mutualiser et maintenir un patrimoine commun de logiciels libres utiles aux missions de service
public63 .

On peut également citer la loi 2004-575 du 21 juin 2004 pour la confiance dans l’économie numérique
(LCEN), qui précise une définition de standard ouvert dans son article 4 : « On entend par standard ouvert
tout protocole de communication, d’interconnexion ou d’échange et tout format de données interopérable et
dont les spécifications techniques sont publiques et sans restriction d’accès ni de mise en œuvre. »

Au cours d’une interview dans l’émission de Stéphane Paoli sur France Inter le 26 mai 2004, l’ancien premier
ministre Jean-Pierre Raffarin a brièvement évoqué l’idée que l’administration française pourrait utiliser des
logiciels libres au lieu d’acheter des logiciels propriétaires. Seul l’aspect économique a été invoqué : M. Raf-
farin veut « faire en sorte que les communications inter-administrations passent par internet et l’utilisation
des logiciels libres. » Il juge ainsi qu’il y aurait plus de 100 millions d’euros à économiser.



7.6 Norvège

Dans son plan stratégique pour le gouvernement électronique eNorway200964 le ministre norvégien de la
modernisation, Morten Andreas Meyer, a annoncé que le secteur public devra utiliser des standards ou-
verts dans ses systèmes informatiques : « Les formats propriétaires ne seront plus acceptables dans les
communications entre les citoyens et le gouvernement. »

Le calendrier suivant est proposé65 :
       – D’ici 2006, un ensemble de standards administratifs et de gestion devront être établis pour les échanges
         de données et de documents.
       – D’ici 2006, tous les services du secteur public devront avoir établi des plans pour l’introduction de
         standards ouverts, d’architecture orientée services et de logiciels libres.
       – D’ici 2008, tous les échanges de données et de documents du secteur public devront satisfaire les
         standards administratifs et de gestion.
  59
      Réutilisation des logiciels et bouquet du libre, http://www.adae.gouv.fr/spip/rubrique.php3?
id_rubrique=33.
   60
      Voir le site Web dédié à CeCILL, http://www.cecill.info/.
   61
      Voir le site Web http://admisource.gouv.fr/.
   62
      ADULLACT — Association des Développeurs et des Utilisateurs de Logiciels Libres pour les Adminis-
trations et les Collectivités Territoriales, http://adullact.net/.
   63
      AdmiSource et ADULLACT.net utilisent d’ailleurs le même outil libre GForge http://www.gforge.
org/.
   64
      Voir http://europa.eu.int/idabc/en/document/4415/194 et http://www.odin.dep.no/
mod/english/bn.html.
   65
      Voir http://europa.eu.int/idabc/en/document/4403/469.


Observatoire Technologique, CTI                                                                              26
Standards ouverts et logiciels libres
Standards ouverts et logiciels libres
Standards ouverts et logiciels libres
Standards ouverts et logiciels libres
Standards ouverts et logiciels libres
Standards ouverts et logiciels libres
Standards ouverts et logiciels libres
Standards ouverts et logiciels libres
Standards ouverts et logiciels libres
Standards ouverts et logiciels libres

Contenu connexe

Similaire à Standards ouverts et logiciels libres

Web2.0(lr)
Web2.0(lr)Web2.0(lr)
Web2.0(lr)CEFRIO
 
ANDROID_Developper_des_applications_mobi.pdf
ANDROID_Developper_des_applications_mobi.pdfANDROID_Developper_des_applications_mobi.pdf
ANDROID_Developper_des_applications_mobi.pdfsamsungofficielcom
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsUniversité de Rennes 1
 
Living Lab e-Inclusion - Rapport de pré-étude
Living Lab e-Inclusion - Rapport de pré-étudeLiving Lab e-Inclusion - Rapport de pré-étude
Living Lab e-Inclusion - Rapport de pré-étudePatrick Genoud
 
Le webdocumentaire, une nouvelle opportunité d’appréhender le monde
Le webdocumentaire, une nouvelle opportunité d’appréhender le mondeLe webdocumentaire, une nouvelle opportunité d’appréhender le monde
Le webdocumentaire, une nouvelle opportunité d’appréhender le mondeOlivier Crou
 
Manuel ns1.3
Manuel ns1.3Manuel ns1.3
Manuel ns1.3thiedia
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testahmed oumezzine
 
Guide Mediametrie Netratings - Interface France
Guide Mediametrie Netratings - Interface FranceGuide Mediametrie Netratings - Interface France
Guide Mediametrie Netratings - Interface FranceRomain Fonnier
 
Model Based Testing des applications du protocole MQTT
Model Based Testing des applications du protocole MQTTModel Based Testing des applications du protocole MQTT
Model Based Testing des applications du protocole MQTTymelka
 
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...nuntiis
 
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes TechnologiquesLe Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes TechnologiquesGenève Lab
 
2010 Stratégie de Portail by Beijaflore
2010 Stratégie de Portail by Beijaflore2010 Stratégie de Portail by Beijaflore
2010 Stratégie de Portail by BeijafloreZoely Mamizaka
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Mohamed Boubaya
 

Similaire à Standards ouverts et logiciels libres (20)

Web2.0(lr)
Web2.0(lr)Web2.0(lr)
Web2.0(lr)
 
ANDROID_Developper_des_applications_mobi.pdf
ANDROID_Developper_des_applications_mobi.pdfANDROID_Developper_des_applications_mobi.pdf
ANDROID_Developper_des_applications_mobi.pdf
 
Glpidoc 0.80.1
Glpidoc 0.80.1Glpidoc 0.80.1
Glpidoc 0.80.1
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
 
Living Lab e-Inclusion - Rapport de pré-étude
Living Lab e-Inclusion - Rapport de pré-étudeLiving Lab e-Inclusion - Rapport de pré-étude
Living Lab e-Inclusion - Rapport de pré-étude
 
Le webdocumentaire, une nouvelle opportunité d’appréhender le monde
Le webdocumentaire, une nouvelle opportunité d’appréhender le mondeLe webdocumentaire, une nouvelle opportunité d’appréhender le monde
Le webdocumentaire, une nouvelle opportunité d’appréhender le monde
 
Guide open source-bdef
Guide open source-bdefGuide open source-bdef
Guide open source-bdef
 
Manuel ns1.3
Manuel ns1.3Manuel ns1.3
Manuel ns1.3
 
vanderpypendaniel_msc
vanderpypendaniel_mscvanderpypendaniel_msc
vanderpypendaniel_msc
 
Rapport PFE2021.pdf
Rapport PFE2021.pdfRapport PFE2021.pdf
Rapport PFE2021.pdf
 
Rapport
RapportRapport
Rapport
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
 
Guide Mediametrie Netratings - Interface France
Guide Mediametrie Netratings - Interface FranceGuide Mediametrie Netratings - Interface France
Guide Mediametrie Netratings - Interface France
 
Model Based Testing des applications du protocole MQTT
Model Based Testing des applications du protocole MQTTModel Based Testing des applications du protocole MQTT
Model Based Testing des applications du protocole MQTT
 
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
 
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes TechnologiquesLe Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
 
Tpe nguyen tien-thinh
Tpe nguyen tien-thinhTpe nguyen tien-thinh
Tpe nguyen tien-thinh
 
2010 Stratégie de Portail by Beijaflore
2010 Stratégie de Portail by Beijaflore2010 Stratégie de Portail by Beijaflore
2010 Stratégie de Portail by Beijaflore
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
 
Deploy automatic in the cloud
Deploy automatic in the cloudDeploy automatic in the cloud
Deploy automatic in the cloud
 

Plus de Genève Lab

L'innovation ouverte à l'ère du COVID
L'innovation ouverte à l'ère du COVIDL'innovation ouverte à l'ère du COVID
L'innovation ouverte à l'ère du COVIDGenève Lab
 
Open data - leçons en temps de crise
Open data - leçons en temps de criseOpen data - leçons en temps de crise
Open data - leçons en temps de criseGenève Lab
 
COVID-19 - L'impact des données ouvertes dans la couverture médiatique
COVID-19 - L'impact des données ouvertes dans la couverture médiatiqueCOVID-19 - L'impact des données ouvertes dans la couverture médiatique
COVID-19 - L'impact des données ouvertes dans la couverture médiatiqueGenève Lab
 
Reduction to practice: From DP3T to EN to SwissCovid
Reduction to practice: From DP3T to EN to SwissCovidReduction to practice: From DP3T to EN to SwissCovid
Reduction to practice: From DP3T to EN to SwissCovidGenève Lab
 
Mobilising collective intelligence to tackle the COVID-19 threat
Mobilising collective intelligence to tackle the COVID-19 threatMobilising collective intelligence to tackle the COVID-19 threat
Mobilising collective intelligence to tackle the COVID-19 threatGenève Lab
 
La littératie des données comme une pierre angulaire d'une nouvelle culture n...
La littératie des données comme une pierre angulaire d'une nouvelle culture n...La littératie des données comme une pierre angulaire d'une nouvelle culture n...
La littératie des données comme une pierre angulaire d'une nouvelle culture n...Genève Lab
 
Les ingrédients de la créativité
Les ingrédients de la créativitéLes ingrédients de la créativité
Les ingrédients de la créativitéGenève Lab
 
Collective Intelligence: what is it and why is it good for cities?
Collective Intelligence: what is it and why is it good for cities?Collective Intelligence: what is it and why is it good for cities?
Collective Intelligence: what is it and why is it good for cities?Genève Lab
 
Pluralisme des modes numériques de participation des habitants
Pluralisme des modes numériques de participation des habitantsPluralisme des modes numériques de participation des habitants
Pluralisme des modes numériques de participation des habitantsGenève Lab
 
Consul project : improving democracy through digital participation
Consul project : improving democracy through digital participationConsul project : improving democracy through digital participation
Consul project : improving democracy through digital participationGenève Lab
 
L'art au service de l'innovation sociale
L'art au service de l'innovation socialeL'art au service de l'innovation sociale
L'art au service de l'innovation socialeGenève Lab
 
RGPD et citoyens : et si le mariage prenait ?
RGPD et citoyens : et si le mariage prenait ?RGPD et citoyens : et si le mariage prenait ?
RGPD et citoyens : et si le mariage prenait ?Genève Lab
 
Plateforme de consultation et participation citoyenne Consul
Plateforme de consultation et participation citoyenne ConsulPlateforme de consultation et participation citoyenne Consul
Plateforme de consultation et participation citoyenne ConsulGenève Lab
 
Introduction à Linked Data
Introduction à Linked DataIntroduction à Linked Data
Introduction à Linked DataGenève Lab
 
La question éthique à l'ère de la data economy, de l'intelligence artificiell...
La question éthique à l'ère de la data economy, de l'intelligence artificiell...La question éthique à l'ère de la data economy, de l'intelligence artificiell...
La question éthique à l'ère de la data economy, de l'intelligence artificiell...Genève Lab
 
L'économie inclusive et les enjeux du numérique comme relais de croissance
L'économie inclusive et les enjeux du numérique comme relais de croissanceL'économie inclusive et les enjeux du numérique comme relais de croissance
L'économie inclusive et les enjeux du numérique comme relais de croissanceGenève Lab
 
Entreprise Numérisée : Ethique et GouvernanceS
Entreprise Numérisée : Ethique et GouvernanceSEntreprise Numérisée : Ethique et GouvernanceS
Entreprise Numérisée : Ethique et GouvernanceSGenève Lab
 
Exponentail Ethics
Exponentail EthicsExponentail Ethics
Exponentail EthicsGenève Lab
 
Notre avenir numérique
Notre avenir numérique  Notre avenir numérique
Notre avenir numérique Genève Lab
 

Plus de Genève Lab (20)

L'innovation ouverte à l'ère du COVID
L'innovation ouverte à l'ère du COVIDL'innovation ouverte à l'ère du COVID
L'innovation ouverte à l'ère du COVID
 
Open data - leçons en temps de crise
Open data - leçons en temps de criseOpen data - leçons en temps de crise
Open data - leçons en temps de crise
 
COVID-19 - L'impact des données ouvertes dans la couverture médiatique
COVID-19 - L'impact des données ouvertes dans la couverture médiatiqueCOVID-19 - L'impact des données ouvertes dans la couverture médiatique
COVID-19 - L'impact des données ouvertes dans la couverture médiatique
 
Reduction to practice: From DP3T to EN to SwissCovid
Reduction to practice: From DP3T to EN to SwissCovidReduction to practice: From DP3T to EN to SwissCovid
Reduction to practice: From DP3T to EN to SwissCovid
 
Mobilising collective intelligence to tackle the COVID-19 threat
Mobilising collective intelligence to tackle the COVID-19 threatMobilising collective intelligence to tackle the COVID-19 threat
Mobilising collective intelligence to tackle the COVID-19 threat
 
La littératie des données comme une pierre angulaire d'une nouvelle culture n...
La littératie des données comme une pierre angulaire d'une nouvelle culture n...La littératie des données comme une pierre angulaire d'une nouvelle culture n...
La littératie des données comme une pierre angulaire d'une nouvelle culture n...
 
Les ingrédients de la créativité
Les ingrédients de la créativitéLes ingrédients de la créativité
Les ingrédients de la créativité
 
Collective Intelligence: what is it and why is it good for cities?
Collective Intelligence: what is it and why is it good for cities?Collective Intelligence: what is it and why is it good for cities?
Collective Intelligence: what is it and why is it good for cities?
 
Pluralisme des modes numériques de participation des habitants
Pluralisme des modes numériques de participation des habitantsPluralisme des modes numériques de participation des habitants
Pluralisme des modes numériques de participation des habitants
 
Consul project : improving democracy through digital participation
Consul project : improving democracy through digital participationConsul project : improving democracy through digital participation
Consul project : improving democracy through digital participation
 
L'art au service de l'innovation sociale
L'art au service de l'innovation socialeL'art au service de l'innovation sociale
L'art au service de l'innovation sociale
 
Open Geneva
Open GenevaOpen Geneva
Open Geneva
 
RGPD et citoyens : et si le mariage prenait ?
RGPD et citoyens : et si le mariage prenait ?RGPD et citoyens : et si le mariage prenait ?
RGPD et citoyens : et si le mariage prenait ?
 
Plateforme de consultation et participation citoyenne Consul
Plateforme de consultation et participation citoyenne ConsulPlateforme de consultation et participation citoyenne Consul
Plateforme de consultation et participation citoyenne Consul
 
Introduction à Linked Data
Introduction à Linked DataIntroduction à Linked Data
Introduction à Linked Data
 
La question éthique à l'ère de la data economy, de l'intelligence artificiell...
La question éthique à l'ère de la data economy, de l'intelligence artificiell...La question éthique à l'ère de la data economy, de l'intelligence artificiell...
La question éthique à l'ère de la data economy, de l'intelligence artificiell...
 
L'économie inclusive et les enjeux du numérique comme relais de croissance
L'économie inclusive et les enjeux du numérique comme relais de croissanceL'économie inclusive et les enjeux du numérique comme relais de croissance
L'économie inclusive et les enjeux du numérique comme relais de croissance
 
Entreprise Numérisée : Ethique et GouvernanceS
Entreprise Numérisée : Ethique et GouvernanceSEntreprise Numérisée : Ethique et GouvernanceS
Entreprise Numérisée : Ethique et GouvernanceS
 
Exponentail Ethics
Exponentail EthicsExponentail Ethics
Exponentail Ethics
 
Notre avenir numérique
Notre avenir numérique  Notre avenir numérique
Notre avenir numérique
 

Standards ouverts et logiciels libres

  • 1. Standards ouverts et logiciel libre Clarification des notions Observatoire Technologique Centre des technologies de l’information République et Canton de Genève P. Genoud, G. Pauletto 30 septembre 2005 Observatoire Technologique Centre des Technologies de l’Information République et Canton de Genève CP 2285, 1211 Genève 2, Suisse http://www.geneve.ch/ot/ ot@etat.ge.ch 1
  • 2. Standards ouverts et logiciel libre Clarification des notions Copyright c 2005 CTI, Observatoire Technologique. This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/2.5/ or send a let- ter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. You are free: • to copy, distribute, display, and perform the work • to make derivative works Under the following conditions: Attribution. ou must attribute the work in the manner specified by the author or licensor. Noncommercial. You may not use this work for commercial purposes. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. • For any reuse or distribution, you must make clear to others the license terms of this work. • Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. This is a human-readable summary of the Legal Code (the full license http://creativecommons.org/ licenses/by-nc-sa/2.5/legalcode. Observatoire Technologique, CTI 2
  • 3. Standards ouverts et logiciel libre Clarification des notions Table des matières 1 Introduction 5 2 Interopérabilité 5 3 Logiciel libre 7 3.1 Le modèle open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Les communautés open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Catégories de logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1 Domaine public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2 Propriétaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.3 Shareware / Freeware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.4 Commercial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.5 Logiciel libre (Free Software) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.6 Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.7 Licences doubles ou multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Perspectives open source dans le secteur public . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4 Les standards ouverts 12 4.1 Définitions et critères . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2 Degré d’ouverture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5 Organismes de normalisation 19 6 Standard ouvert vs logiciel libre 21 7 Politiques gouvernementales 22 7.1 Belgique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2 Brésil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.3 Danemark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.4 États-Unis, Massachusetts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.5 France . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.6 Norvège . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.7 Pays-Bas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.8 Royaume-Uni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.9 Suisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.10 Union Européenne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8 Domaine de l’éducation et de la recherche 30 Observatoire Technologique, CTI 3
  • 4. Standards ouverts et logiciel libre Clarification des notions 9 Conclusions 33 Révisions Version Date / auteurs Objet de la révision 0.1 2005-02-18 / pge Version initiale 0.2 2005-06-17 / gip Ajout section logiciel libre 0.3 2005-07-04 / pge, gip Ajout autres sections 0.4 2005-07-15 / pge, gip Avant relecture finale 0.9 2005-07-21 / pge, gip Pour soumission à la direction du projet 0.91 2005-09-05 / pge, gip Modifications après retour de la direction du projet 1.0 2005-09-30 / pge, gip Après validation par la direction du projet Observatoire Technologique, CTI 4
  • 5. Standards ouverts et logiciel libre Clarification des notions 1 Introduction Au cours de l’année 2004, plusieurs signaux ont été émis affirmant la volonté de l’administration genevoise de se tourner d’ici 2009 d’une part vers le logiciel libre, mais aussi et surtout vers les standards ouverts. Des déclarations dans ce sens ont d’abord été émises en interne1 , puis relayées dans les médias locaux (jour- naux2 3 , télévision4 ) et également reprises par le site Web de l’IDABC5 (site de la Commission Européenne dédié à l’échange de données entre les administrations). Ces annonces suscitent, et vont susciter des réactions, que ce soit au niveau des collaborateurs de l’ad- ministration genevoise, des représentants des autres cantons et de la Confédération ou des entreprises informatiques partenaires. Les informations fournies sont plus ou moins bien comprises et appréciées par les différents acteurs concernés. Elles suscitent de nombreuses questions auxquelles il faudra répondre clairement et rapidement si l’on entend atteindre efficacement les objectifs visés. Un travail de clarification est donc nécessaire et est à l’origine du projet « Standards Ouverts et Logiciel Libre » (SOLL) confié conjointement à l’Observatoire Technologique (OT) par la Direction Générale du Centre des technologies de l’information de l’État de Genève (CTI), par la Direction Informatique de l’Université de Genève et par le Partenariat de l’OT. Les notions de logiciel libre et de standard ouvert ne sont pas aussi bien comprises qu’on pourrait l’imaginer, même au sein de la communauté informatique. Cela tient d’une part au fait que ces concepts sont relative- ment nouveaux. D’autre part, les définitions que l’on en donne varient selon les auteurs ou les communautés concernées, surtout en ce qui concerne l’aspect plus ou moins restrictif des critères que doivent respecter les logiciels et les standards pour être qualifiés de libres et d’ouverts respectivement. Il est donc important de définir précisément ces notions afin qu’il ne subsiste pas d’ambiguïté dans les esprits, que ce soit en interne ou en externe à l’entreprise ou à l’organisation concernées. Ce document reprend ainsi les définitions communément proposées dans la littérature. Il met en évidence les interpréta- tions et les implications relatives aux différentes définitions d’une même notion, ceci afin de permettre aux mandants du projet SOLL d’en proposer leur propre acception en toute connaissance de cause. La notion d’interopérabilité est développée en préambule, car elle constitue le concept de base autour duquel viennent naturellement s’articuler les standards ouverts et le logiciel libre. Un chapitre est également consacré à la clarification des relations que l’on peut pressentir entre logiciel libre et standards ouverts. Certains gouvernements se sont déjà clairement positionnés par rapport au logiciel libre et aux standards ouverts. Nous proposons dans ce document une brève description de quelques politiques gouvernementales qui illustrent les diverses manières d’aborder cette problématique et qui peuvent servir de référence dans ce domaine. Enfin, un recensement de quelques initiatives phares dans le milieu académique est également proposé. 2 Interopérabilité Comme le souligne un récent document de travail de la Commission Européenne6 , l’administration électro- nique n’est pas une simple administration traditionnelle à laquelle on aurait ajouté l’Internet. Elle recouvre l’utilisation de nouvelles technologies en vue de transformer les administrations publiques et d’améliorer radicalement les contacts avec leurs clients (citoyens, entreprises ou autres administrations). Ces transformations passent notamment par un décloisonnement des divers services et départements de l’administration, dans la mesure où cela respecte les lois en vigueur et la sphère privée des citoyens. Mais 1 Vers les Standards Ouverts, Echo No 1, CTI, Automne 2004. 2 Article du Matin, 17 novembre 2004. 3 Article de la Tribune de Genève, 24 novembre 2004. 4 Reportage TSR Journal des Régions, 15 décembre 2004. 5 Geneva moves towards open standards, http://europa.eu.int/idabc/en/document/3528 et Geneva to switch to open source by 2009, http://europa.eu.int/idabc/en/document/3601, Site de l’IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens), Novembre 2004. 6 Interconnecter l’Europe : l’importance de l’interopérabilité des services de l’administration électronique, document de travail des services de la Commission Européenne, 2003. Observatoire Technologique, CTI 5
  • 6. Standards ouverts et logiciel libre Clarification des notions une transversalité croissante ne va pas sans poser des problèmes, à la fois techniques et organisationnels, lorsqu’il s’agit de faire communiquer entre eux les différents systèmes d’information concernés. Les technologies peuvent faciliter la communication et le partage de l’information pour autant qu’elles soient interopérables. L’interopérabilité se situe alors au cœur du rapprochement des services des administrations publiques. Elle désigne ici la capacité qu’ont les technologies de l’information et de la communication ainsi que les processus qu’elles soutiennent à échanger des données et à permettre le partage de l’information et de la connaissance. Elle garantit ainsi la pérennité des données et leur accessibilité dans le futur. Elle consti- tue donc une exigence fondamentale pour développer une administration en ligne efficace, performante et pérenne. Plus généralement, elle doit être considérée comme un élément clé des architectures actuelles, qu’elles soient techniques, applicatives ou métier. La Commission Européenne a parfaitement intégré ces enjeux et a lancé le programme IDABC7 (Interope- rable Delivery of European eGovernment Services to Public Administrations, Businesses and Citizens) afin notamment d’encourager et de faciliter l’échange d’informations et de connaissances entre les secteurs pu- blics des différents pays de l’Union Européenne. Le document de travail de la Commission Européenne insiste sur la nécessité de considérer l’interopérabilité comme un problème global. En effet l’interopérabilité passe d’abord par la réorganisation des processus administratifs et par la nécessité d’inclure la notion de partage de l’information. On considère ainsi trois aspects fondamentaux liés à l’interopérabilité des systèmes d’information : 1. L’interopérabilité organisationnelle qui concerne principalement la modélisation des processus mé- tiers dans le but de prendre en compte la collaboration entre services qui n’ont pas les mêmes struc- tures organisationnelles et qui ne gèrent pas des processus similaires. Pratiquement, il s’agit de s’as- surer que les processus pourront être facilement intégrés les uns aux autres et exploités par d’autres utilisateurs. L’interopérabilité organisationnelle a notamment pour objectif de prendre en compte les besoins des utilisateurs en proposant des services accessibles, aisément identifiables et orientés vers eux. Cela passe par la nécessité de rendre la complexité organisationnelle des services transparente pour les utilisateurs. 2. L’interopérabilité sémantique qui garantit que le sens exact des informations échangées peut être compris par toute application qui n’a pas été conçue initialement dans ce but. L’interopérabilité séman- tique facilite l’agrégation et la réutilisation d’informations hétérogènes (de par leur nature ou leur mode de création) et participe ainsi de manière essentielle à la valorisation du patrimoine informationnel d’une organisation. Cela va donc beaucoup plus loin que la simple connexion de différentes sources d’information, l’objectif plus fondamental étant de faciliter le passage de l’information à la connais- sance. La prise en compte de l’interopérabilité sémantique passe concrètement par une nécessaire réflexion sur la réutilisabilité et la standardisation des données, par l’utilisation de métadonnées qui renseignent sur le contexte lié à la création des données et par la mise en œuvre de technologies XML conçues pour répondre à cette problématique. 3. L’interopérabilité technique concerne les aspects liés à la connexion des systèmes et des services informatiques. Cela touche des domaines aussi variés que la définition d’interfaces et de standards ouverts, l’intégration des données, la couche middleware, la présentation et l’échange d’informations, l’accessibilité ou les services de sécurité. Le référentiel NPT8 (Nouvelles Plateformes Technologiques) réalisé par l’Observatoire Technologique du canton de Genève propose quelques pistes pour prendre en compte et mesurer l’interopérabilité technique d’une solution informatique. Prendre en compte les aspects techniques de l’interopérabilité est donc nécessaire mais pas suffisant lorsque l’on désire atteindre une interopérabilité effective. Les notions d’interopérabilité sémantique et or- ganisationnelle sont tout aussi importantes, si ce n’est plus. Lorsque l’on entend définir une politique dans le domaine, il est essentiel de ne pas considérer l’interopérabilité comme une question uniquement technique. Une telle vision de l’interopérabilité la positionne comme un problème politique (stratégie et réglementation). Un certain nombre de pays européens l’ont bien compris et l’ont inscrit dans leur agenda. Cela se traduit notamment par la mise en œuvre d’un cadre commun d’interopérabilité sur le modèle de ce qui a déjà été 7 Site Web du programme IDABC lancé par la Commission Européenne http://europa.eu.int/ idabc/en/home. 8 Référentiel Nouvelles Plateformes Technologiques, P. Genoud et G. Pauletto, Observatoire Technolo- gique, Centre des technologies de l’information du canton de Genève, 2003, http://www.geneve.ch/ ot/. Observatoire Technologique, CTI 6
  • 7. Standards ouverts et logiciel libre Clarification des notions réalisé par la France9 , l’Allemagne10 , le Royaume-Uni11 , la Belgique12 ou l’Union Européenne13 . Un cadre commun d’interopérabilité peut être défini comme un ensemble de politiques, de normes, de conseils et de directives décrivant comment des organisations s’accordent, ou de- vraient s’accorder, pour échanger informations et processus. C’est donc un instrument dynamique qui doit pouvoir s’adapter à l’évolution des technologies, des normes et des besoins métiers dans les domaines concernés. Chacun des cadres communs d’interopérabilité men- tionnés ci-dessus correspond à des situations et des besoins différents. Mais ils représentent, à divers titres, des modèles de référence parfaitement réutilisables. Tous reflètent la prise de conscience croissante du fait que l’interopérabilité des systèmes d’information des institutions gouvernementales constitue une condition préalable indispensable si l’on désire mettre en place un secteur public plus compétitif et orienté vers les services aux citoyens. L’approche retenue dans les exemples mentionnés ci-dessus part de principes de base (impératifs straté- giques) comme l’accessibilité, l’éthique, la sécurité ou la transversalité que l’on retrouve dans le référentiel e-Société proposé par l’Observatoire Technologique du canton de Genève14 . Les administrations et les gou- vernements prennent en outre conscience de la valeur stratégique de l’information qu’ils créent et qu’ils gèrent au quotidien, ce qui amène naturellement à revendiquer une plus grande maîtrise de leurs systèmes d’information. C’est donc logiquement que la notion d’indépendance vis-à-vis des fournisseurs constitue un principe de base également mis en avant. Nous verrons ci-dessous que les standards ouverts et le logiciel libre viennent répondre de façon très na- turelle à ces impératifs stratégiques. L’Union Européenne ainsi qu’un certain nombre de gouvernements placent d’ailleurs ces notions au cœur de leur stratégie. 3 Logiciel libre Les technologies appartenant au domaine dit du logiciel libre ou « open source » sont présentes depuis un certain nombre d’années, mais le concept n’a pris de l’ampleur dans le monde informatique que depuis peu avec notamment le succès du système d’exploitation Linux. Le logiciel libre présente des facettes multiples : c’est en partie un phénomène très médiatisé, mais aussi et surtout un mouvement social, une définition de licence et un modèle de développement. La section suivante présente une perspective très partielle de ce sujet qui mériterait un éclairage bien plus conséquent. Mais la littérature consacrée au logiciel libre abonde et le lecteur trouvera sans difficulté une publication de référence. Pour n’en citer qu’une, nous mentionnerons le récent livre blanc Organisations et logiciels libres15 qui permet une première approche du secteur à la fois pour un néophyte, ou un approfondissement pour un lecteur déjà averti. En 1984, la Free Software Foundation16 a introduit la notion de free software, traduit en français par logiciel libre. Malheureusement, le terme anglais « free » signifie aussi bien libre que gratuit ce qui a causé beaucoup de confusion dans les esprits. 9 CCI — Cadre commun d’interopérabilité des systèmes d’information publics, Agence pour Déve- loppement de l’Administration Électronique, France, Septembre 2003, http://www.adae.gouv.fr/ rubrique.php3?id_rubrique=41. 10 SAGA — Standards and Architectures for e-Government Applications, KBSt unit, Ministère Fédéral de l’Intérieur, Allemagne, Décembre 2003, http://www.kbst.bund.de/-,182/SAGA.htm. 11 E-GIF — e-Government Interoperability Framework, Office of the e-Envoy, Royaume-Uni, Avril 2004, http://www.govtalk.gov.uk/schemasstandards/egif.asp. 12 BELGIF — BELgian Governement Interoperability Framework, Belgique, http://www.belgif.be 13 EIF — European Interoperability Framework for Pan-European eGovernment Services, IDABC, Com- mission Européenne, 2004, http://europa.eu.int. 14 Référentiel e-Société, P. Genoud et G. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève, 2002, http://www.geneve.ch/ot/. 15 Organisations et logiciels libres, Diane Revillard, Diemark SARL, France, Septembre 2005, http:// www.diemark.net/. 16 FSF — Free Software Foundation, http://www.fsf.org/. Observatoire Technologique, CTI 7
  • 8. Standards ouverts et logiciel libre Clarification des notions Il serait faux de penser que parce qu’un logiciel est gratuit, il est libre. Il serait également erroné de croire que parce que son code source est disponible, un logiciel est libre ou encore gratuit. Le terme open source est également apparu plus récemment, en grande partie, pour éviter ce malentendu et dédramatiser les débats entre les tenants du logiciel propriétaire et du logiciel libre, en amenant une vue plus pragmatique et moins philosophique. Nous détaillons ici les définitions aussi bien de logiciel libre que de open source et leur différences de phi- losophie. Pour la suite de ce rapport les deux termes sont utilisés comme synonymes ce qui est aujourd’hui largement reconnu par les communautés d’usagers et de développeurs. Un logiciel est protégé par le droit d’auteur17 . L’auteur d’un programme peut choisir de protéger son œuvre par une autre licence lui permettant de modifier les droits et devoirs donnés par défaut. La règle de discrimi- nation est la suivante : L’appartenance d’un logiciel à une catégorie (libre, propriétaire, etc.) est établie grâce à la licence sous laquelle le logiciel est distribué. Les catégories de licences les plus fréquemment rencontrées sont explicitées ci-après. Une présentation détaillée de cette problématique est donnée ailleurs18 . 3.1 Le modèle open source On peut définir la notion de modèle open source comme l’ensemble des principes et des bonnes pratiques régissant le développement, le déploiement et le support de ce type de logiciel. Au cœur de ce modèle on retrouve le mouvement open source dont la préoccupation majeure est de protéger les privilèges des utilisateurs plutôt que celui des auteurs19 . dans ce domaine. 3.2 Les communautés open source Le modèle open source s’appuie sur des communautés de développeurs qui travaillent en mode collaboratif à une échelle souvent planétaire. Les membres de ces communautés proviennent de tous les horizons : milieu académique, petites sociétés de service, passionnés du développement logiciel ou, plus récemment, poids lourds du monde informatique qui se sont positionnés dans ce domaine. Ces membres jouent souvent des rôles multiples au sein de leur communauté et se sentent très concernés par la réussite ou l’échec du projet auquel ils participent. La communauté rassemblée autour d’un projet substitue au concept traditionnel de propriété la notion de service. Puisqu’aucune entité ne possède le logiciel, personne ne peut le contrôler, même si un petit groupe de développeurs fait office de leaders du projet. Si l’orientation donnée à un projet open source ne corres- pond pas aux aspirations d’une partie des membres de la communauté, le projet peut se scinder en un autre projet distinct (forking). Cette dynamique conduit à la création d’un écosystème de projets au sein duquel s’effectue une véritable sélection naturelle favorisant les projets de qualité qui répondent le mieux aux besoins des utilisateurs. La taille de la communauté associée à un projet constitue en principe un bon indicateur de sa vitalité et de sa qualité. 17 Loi fédérale sur le droit d’auteur et les droits voisins, Titre 2, Article 2, Paragraphe 3, « Les programmes d’ordinateurs (logiciels) sont également considérés comme des œuvres. » http://www.admin.ch/ch/ f/rs/231_1/a2.html. 18 Guide de choix et d’usage des licences de logiciels libres pour les administrations, et L’analyse dé- taillée des licences, ADAE, France, Décembre 2002, http://www.adae.gouv.fr/article.php3?id_ article=172, Licences Open Source, Annexe du rapport du projet Nouvelles Plateformes Technologiques, P. Genoud et G. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève, Juin 2003, http://www.geneve.ch/ot/. 19 Open-Source Solutions Will Restructure the Software Industry, Mark Driver, Gartner Group, Février 2005. Observatoire Technologique, CTI 8
  • 9. Standards ouverts et logiciel libre Clarification des notions 3.3 Catégories de logiciel 3.3.1 Domaine public Les logiciels dans le domaine public ne sont pas protégés par des droits d’auteur. Ils sont explicitement déposés dans le domaine public par leur(s) auteur(s), car par défaut, tout programme est protégé par le copyright attribué automatiquement à son auteur. Pour un logiciel dans cette catégorie toute modification est possible, mais il peut basculer vers une autre licence à tout moment. De plus, rien ne garantit que le code source soit disponible. 3.3.2 Propriétaire Le logiciel propriétaire est le modèle auquel l’industrie est encore aujourd’hui le plus souvent confrontée : son utilisation, sa redistribution ou sa modification sont interdites, ou exigent une autorisation spécifique. Les droits de propriété sont détenus par la société qui le distribue ou par son auteur. Le code source peut être mis à disposition ou non, mais sa protection reste garantie par le droit d’auteur et la propriété intellectuelle appartient au fournisseur du programme. 3.3.3 Shareware / Freeware La catégorie shareware / freeware est souvent confondue à tort avec l’open source. Un logiciel freeware est un logiciel gratuit qui permet l’utilisation et la redistribution de l’exécutable ; les codes sources ne sont généralement pas fournis et la modification n’est pas autorisée. Cette catégorie n’a en général pas de réel point commun avec l’open source, mise à part dans certains cas, la gratuité. Un logiciel shareware est un freeware limité dans le temps qui devient payant une fois une date limite ou un nombre d’utilisations dépassés. 3.3.4 Commercial Il faut également savoir qu’un logiciel commercial est un produit vendu par une entreprise dans le but de réa- liser un profit. Cela n’est pas incompatible avec la notion de logiciel libre : les sociétés commerciales comme RedHat, Novell et Mandriva en sont la preuve. Ces entreprises commercialisent des solutions open source et y ajoutent de la valeur en offrant des services tels que le packaging, l’intégration, le support ou la documen- tation. A contrario, il existe également des logiciels non commerciaux qui ne sont pas dans la catégorie du logiciel libre. Il devient de plus en plus important d’utiliser le vocabulaire adéquat pour éviter les ambiguïtés comme par exemple éviter d’utiliser l’adjectif « commercial » pour qualifier un logiciel « propriétaire ». 3.3.5 Logiciel libre (Free Software) Selon la Free Software Foundation, un logiciel est considéré comme libre si sa licence garantit à l’utilisateur les quatre libertés suivantes qu’elle numérote de zéro à trois : 0. La liberté d’exécuter le programme, pour tous les usages. 1. La liberté d’étudier le fonctionnement du programme et de l’adapter aux besoins. Pour ceci l’accès au code source est une condition requise. 2. La liberté de redistribuer des copies, donc d’aider son voisin. 3. La liberté d’améliorer le programme et de publier des améliorations, pour en faire profiter toute la communauté. Pour ceci l’accès au code source est une condition requise. Observatoire Technologique, CTI 9
  • 10. Standards ouverts et logiciel libre Clarification des notions La licence GNU General Public License (GPL) concrétise ces quatre libertés sous la forme d’une licence juridique20 . Une particularité de la licence GPL est le copyleft, qui impose que les mêmes conditions se transmettent pour les œuvres dérivées. Ceci assure qu’un objet sous licence GPL reste indéfiniment couvert par cette même licence lors de modifications. D’autres licences que la GPL possèdent cette même propriété. Il existe un effort d’adaptation de cette licence au droit français avec la création de la licence CeCILL21 . 3.3.6 Open Source L’Open Source Initiative définit pour sa part le concept de logiciel open source en 10 points : 1. Redistribution libre : La licence ne doit pas restreindre la vente ou la distribution du logiciel libre intégré dans un autre logiciel contenant des programmes de différentes origines. La licence ne doit pas exiger de compensation en échange de cette intégration. 2. Code source : Le programme doit inclure le code source, et doit autoriser la distribution du code source comme de l’exécutable compilé. Quand une forme quelconque du produit est distribuée sans le code source, il doit être clairement indiqué par quel moyen il est possible d’obtenir le code source, pour une somme qui ne doit pas excéder un coût raisonnable de reproduction, ou en le chargeant gratuitement via Internet. Le code source doit être la forme privilégiée par laquelle un programmeur modifie le programme. Un code source délibérément confus est interdit. Les formes intermédiaires de code source, telles que celles résultant d’un pré-processeur ou d’un traducteur, sont interdites. 3. Travaux dérivés : La licence doit autoriser les modifications et les travaux dérivés, et doit permettre leur distribution dans les mêmes termes que la licence du logiciel d’origine. 4. Intégrité du code source de l’auteur : La licence peut restreindre la distribution du code source modifié seulement si elle autorise la distribution de fichiers patchs avec le code source, dans le but de modifier le programme à la compilation. L’auteur peut ainsi garantir l’intégrité de son code source dans le processus de diffusion successive du logiciel. La licence doit explicitement permettre la distribution de logiciels obtenus à partir du code source modifié. La licence peut exiger que les travaux dérivés portent un nom ou un numéro de version différents du logiciel d’origine. 5. Absence de discrimination envers des personnes ou des groupes : La licence ne doit pas être discriminante à l’encontre de personnes ou de groupes de personnes. 6. Absence de discrimination envers des domaines d’activité : La licence ne doit pas restreindre ni interdire l’usage du logiciel à un quelconque domaine d’activité. Par exemple, il ne peut interdire l’usage du logiciel dans le cadre d’une activité professionnelle, ou en exclure l’usage pour la recherche génétique. 7. Distribution de licence : Les droits attachés au programme doivent s’appliquer à tous ceux à qui il est distribué sans qu’il leur soit besoin de se conformer à des termes de licence complémentaires. 8. La licence ne doit pas être spécifique à un produit : Les droits attachés au programme ne doivent pas dépendre du fait que le programme fait partie d’un logiciel en particulier. Si le programme est séparé du logiciel dans lequel il est intégré, et utilisé ou distribué selon les termes de la licence, toutes les parties à qui le programme est redistribué doivent avoir les mêmes droits que ceux accordés avec le logiciel dans lequel il est intégré à l’origine. 9. La licence ne doit pas imposer de restrictions sur d’autres logiciels : La licence ne doit pas imposer de restrictions sur d’autres logiciels distribués avec le programme sous licence. Par exemple, la licence ne doit pas exiger que les autres programmes distribués sur le même support physique soient aussi des logiciels libres. 10. La licence doit être neutre par rapport à la technologie : Aucune disposition de la licence ne doit dépendre d’une technologie ou d’une interface particulières. Par exemple, on ne peut pas obliger un utilisateur à décharger le logiciel uniquement depuis un site Web dans le but d’afficher de la publicité. La figure 1 présente quelques catégories de licences en regard des libertés accordées. 20 Le texte complet de la licence GNU GPL est donné sur http://www.fsf.org/licensing/ licenses/gpl.html. 21 Voir le site Web dédié à CeCILL, http://www.cecill.info/. Observatoire Technologique, CTI 10
  • 11. Standards ouverts et logiciel libre Clarification des notions Figure 1 – Types de licences et libertés. 3.3.7 Licences doubles ou multiples Les lois régissant le droit d’auteur permettent à ceux-ci de publier leurs œuvres simultanément sous plusieurs types de licences. Ceci rend possible de différencier les contrats de licence appliqués selon le modèle que les utilisateurs veulent (ou parfois doivent) adopter. Cette pratique est désignée par le terme anglais (dual licensing). Ceci permet également d’envisager un modèle économique pour la distribution du logiciel. D’une part, une utilisation à but commercial et/ou lucratif est régie par un contrat de licence propriétaire payante, alors que, d’autre part, une projet de logiciel libre peut intégrer exactement le même logiciel gratuitement en utilisant une licence open source et gratuite. Ce type de modèle est, par exemple, utilisé par la société MySQL fournissant la base de données du même nom ou encore par TrollTech qui maintient la librairie de construction d’interface utilisateur Qt. Par ailleurs, plusieurs organisations développant du logiciel libre recourent à ce même artifice en panachant des licences du monde open source afin de faciliter l’intégration de composants propriétaires ou de permettre une réutilisation plus large dans la sphère commerciale. Les projets les plus connus utilisant des licences multiples de type libre sont OpenOffice.org, Perl et Mozilla. 3.4 Perspectives open source dans le secteur public L’intérêt du secteur public pour l’open source est aujourd’hui indéniable, en particulier parce qu’il met en œuvre des standards ouverts, qu’il brise les positions de lock-in et qu’il permet une plus grand adaptabilité aux besoins particuliers22 . Les motivations essentielles avancées par les gouvernements sont une meilleure maîtrise de leurs propres systèmes d’information, une plus grande neutralité dans le choix de vendeurs de solutions ainsi qu’une ouverture vers les entreprises et les citoyens désirant ou devant interagir avec les administrations. De plus, on peut également voir un intérêt sociétal global car le modèle même du logiciel libre est fondé sur le partage des connaissances et la réutilisation des composants. L’accessibilité des solutions open source est garantie pour tous : autres organismes du secteur public, entreprises privées, organisations non gouver- nementales, association ou simples citoyens. Par ailleurs, le développement économique local pour les sociétés de services informatiques peut être favo- 22 Pour une analyse plus détaillée de ces sujets voir aussi : Perspective Open Source, Rapport final du projet Nouvelles Plateformes Technologiques, P. Genoud et G. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève, Juin 2003, http://www.geneve.ch/ot/ Le logiciel libre dans les administrations, Annexe du projet Nouvelles Plateformes Technologiques, P. Genoud et G. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève, Juin 2003, http://www.geneve.ch/ot/. Observatoire Technologique, CTI 11
  • 12. Standards ouverts et logiciel libre Clarification des notions risé lors de l’adoption de technologies open source. Les solutions open source les plus mûres sont aujourd’hui encore celles touchant aux serveurs d’infrastruc- ture : web, messagerie, serveurs de fichiers et d’imprimantes, ainsi que le système d’exploitation du serveur lui-même. Plus récemment, les bases de données propriétaires classiques ont-elles aussi vu apparaître des alternatives libres crédibles. L’argumentation fondée uniquement sur une motivation de coûts est aujourd’hui dépassée : une analyse, souvent très onéreuse, ne permet généralement pas de discriminer clairement une solution propriétaire et une solution open source équivalente. Les administrations ont dans la plupart des cas compris que les enjeux se situent au-delà du débat unidimensionnel du coût financier, même si celui-ci reste un élément de décision non négligeable. Le logiciel libre dépasse aujourd’hui très largement un phénomène de mode passager. Le support profes- sionnel s’organise et de grandes, moyennes et petites entreprises offrent aujourd’hui leurs compétences dans le domaine. Des projets open source d’envergure se fédèrent autour de communautés organisées qui ont un mode de fonctionnement et une feuille de route clairs relativement aux produits qu’ils développent et à leur processus de gestion. Le modèle même du logiciel libre est robuste aux changements économiques, car le produit ne dépend plus d’un seul acteur, mais d’un écosystème qui lui permet de vivre et d’évoluer. Les références d’utilisation de solutions open source au sein des administrations et des entreprises sont de plus en plus fréquentes, même si le domaine est encore jeune et les expérimentations souvent en cours. 4 Les standards ouverts Comme le relève M. Erkki Liikanen23 , commissaire européen chargé des entreprises et de la société de l’information : « Les standards ouverts sont un élément essentiel de la mise au point de solutions interopérables et abordables pour tous. En outre, ils stimulent la concurrence en établissant des conditions tech- niques égales pour tous les acteurs du marché, ce qui se traduit par des réductions de coût au profit des entreprises et, en définitive, des consommateurs. » Cette déclaration reflète le large consensus que l’on note actuellement autour des aspects positifs liés à la notion d’ouverture. Il est cependant important d’examiner précisément quelle signification, quelles implica- tions et quelles limitations y sont associées. Du point de vue des organismes étatiques et para-étatiques, l’ouverture constitue une qualité première lorsque l’on désire développer une relation tournée directement vers les citoyens et les entreprises. Elle garantit un accès large et équitable aux services proposés. Dans ce contexte, l’ouverture implique que les services publics garantissent un accès aux applications au travers de technologies variées qui n’imposent aucune plateforme, aucun système d’exploitation ni aucun matériels particuliers24 . L’utilisation de standards ouverts participe naturellement à cette notion d’ouverture avec pour vocation de répondre à des objectifs stratégiques tels que : – Maximiser l’indépendance des utilisateurs en augmentant leur liberté d’action, en évitant de leur im- poser des décisions technologiques et en prévenant les phénomènes de lock-in de la part des four- nisseurs informatiques. – Assurer que tous les acteurs soient au même niveau en ce qui concerne l’utilisation de ces standards, ce qui favorise l’innovation (faible coût d’entrée sur le marché). – Contribuer à la maîtrise et à la flexibilité des systèmes informatiques en garantissant leur interopéra- bilité. 23 Journée mondiale de la normalisation, 14 octobre 2003, http://europa.eu.int/rapid/ pressReleasesAction.do?reference=IP/03/1374&format=HTML&aged=1&language= FR&guiLanguage=fr. 24 How Open Can Europe Get ?, Open Forum Europe, Novembre 2004, http://www. openforumeurope.org. Observatoire Technologique, CTI 12
  • 13. Standards ouverts et logiciel libre Clarification des notions – Amener à une bonne gestion des coûts via une diminution du prix des licences due à une augmen- tation de la concurrence. L’utilisateur peut ainsi choisir le composant logiciel présentant le meilleur rapport qualité/prix. – Garantir un meilleur équilibre entre stabilité et innovation car aussi bien l’orientation que la vitesse d’évolution d’un standard ne peuvent être imposées par un seul acteur. – Favoriser la pérennité de l’information puisque l’accès à celle-ci n’est plus lié à un fournisseur infor- matique ou à un produit particuliers. – Améliorer l’échange et l’accessibilité à l’information. – Capitaliser sur le savoir en favorisant la valorisation des données et des informations. – Réduire la fracture numérique en plaçant les standards ouverts au rang de biens communs de l’hu- manité (gratuits, libres d’accès et de droits). Pour un développement détaillé de la plupart des points ci-dessus on peut se référer à l’article de Erik Sliman25 qui propose un intéressant business case de la contribution des standards ouverts à l’économie numérique. A un autre niveau, le livre blanc du programme OSOSS26 lancé par le gouvernement néerlandais constitue une illustration de la façon de positionner certaines des contributions énoncées ci-dessus en regard des objectifs stratégiques gouvernementaux. Michael Totschnig27 complète ce tableau en ajoutant deux points particulièrement importants en terme de vision sociétale : « En comparaison avec les standards fermés et propriétaires, les standards ouverts présentent deux caractéristiques essentielles qui ont des conséquences importantes sur la possibilité d’un espace public numérique. D’une part, leur définition et leur évolution constituent les enjeux d’un débat public dans lequel peuvent intervenir un grand nombre d’acteurs concernés ; d’autre part, comme leur utilisation ne peut être contrôlée par un seul acteur, tout acteur qui veut les intégrer à de nouveaux produits peut se les approprier. Cependant, en tant que biens collectifs, ils n’appar- tiennent à personne dans le sens où aucun acteur ne peut profiter plus qu’un autre de la valeur ajoutée générée par l’adoption publique d’un standard. » Il ne faut pas négliger ces enjeux politiques et sociaux auxquels peuvent répondre les standards ouverts. Les rapports entre l’administration et les citoyens sont en effet en train de changer. Ces derniers, dans un souci de transparence des institutions, revendiquent toujours plus vivement la possibilité de pouvoir accéder aux standards mis en œuvre. Or seul le processus d’élaboration d’un standard ouvert permet de prendre en compte valablement les intérêts de la société civile. 4.1 Définitions et critères La notion de standard ouvert reste cependant un concept relativement flou qu’il est important de clarifier. Nous en donnons donc ci-dessous les définitions les plus communément utilisées afin de mieux comprendre les différents points de vue concernés et de pouvoir ainsi en dégager celle qui semble la mieux adaptée à la vision des différents partenaires de l’OT. Les notions générales de norme et de standard ont quant à elles déjà été clarifiées ailleurs28 et nous n’y reviendrons pas ici. Rappelons cependant que l’on distingue en général deux types de standards : ceux créés par le marché (de facto) et ceux validés par un organisme de normalisation (de jure). 25 Business Case for Open Standards, Erik Sliman, Mai 2002, http://www.openstandards.net/. 26 Programme for open standards and open source software in government, ICTU, Pays-Bas, 2004, http: //www.ososs.nl/. 27 Les standards ouverts de l’informatique et l’espace public numérique, Michael Totschnig, Université du Québec à Montréal, Canada, 2001, http://commposite.uqam.ca/2001.1/articles/totsch. html. 28 Normes et standards ouverts, Annexe du rapport du projet Nouvelles Plateformes Technologiques, Pa- trick Genoud et Giorgio Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève, Juin 2003, http://www.geneve.ch/ot/. Observatoire Technologique, CTI 13
  • 14. Standards ouverts et logiciel libre Clarification des notions Un standard de facto est introduit par un acteur du marché et s’établit de lui-même comme le ou l’un des standards dominants sans l’aval d’un organisme officiel de standardisation. Un standard de jure est établi par un organisme officiel de standardisation. Un standard de jure est habituellement le résultat d’un consensus entre les différents membres d’un orga- nisme officiel de standardisation qui est la plupart du temps composé à la fois de membres provenant d’ins- titutions publiques et d’acteurs du marché. Les processus de standardisation de ce type peuvent prendre un temps jugé excessif par certains mais ils ont le grand mérite de présenter un agenda très prévisible. Lorsque l’on parle de standard ouvert, c’est souvent par opposition au standard propriétaire. Il est alors question de savoir dans quelle mesure les restrictions d’usage placées par le propriétaire du standard sont importantes. Dans ce cas les propriétaires du standard sont ceux qui, au travers de leur savoir-faire et/ou de la mise en application de brevets et de droits de propriété intellectuelle sont à même de décider qui peut utiliser le standard et à quel prix. L’évolution du standard est également de leur ressort. Un standard propriétaire est caractérisé par le fait qu’il est la propriété de quelqu’un qui y met (ou peut y mettre) des restrictions d’usage et d’accès. Il est important de noter qu’un standard n’est en général jamais complètement fermé, ce qui irait à l’encontre de sa diffusion. Le propriétaire choisit en fait le degré d’ouverture qu’il accorde à son standard afin d’optima- liser ses bénéfices. Plus le standard est diffusé et plus il est attractif pour l’utilisateur, mais plus le revenu par utilisateur (en terme de licences) a tendance à baisser. Dans cette logique d’opposition au standard propriétaire, le gouvernement français, au travers de la LCEN29 définit un standard ouvert comme suit : « On entend par standard ouvert tout protocole de communication, d’interconnexion ou d’échange et tout format de données interopérable et dont les spécifications techniques sont publiques et sans restriction d’accès ni de mise en œuvre. » En France on fait souvent référence à cette définition, même si elle manque selon nous de précision car elle n’aborde qu’une partie seulement des caractéristiques importantes liées à l’ouverture des standards. On y élude en effet les aspects liés au processus de validation par un organisme officiel de standardisation qui prennent une dimension essentielle lorsque l’on raisonne en termes d’indépendance et d’évolution du standard. Une définition beaucoup plus complète des standards ouverts à laquelle on se réfère fréquemment est celle de Bruce Perens30 qui propose une perspective axée utilisateur et basée sur les six principes ci-dessous. Pour concrétiser la mise en œuvre de chacun de ces principes, une liste de meilleures pratiques (dont certaines sont mentionnées ici) est proposée par l’auteur. 1. Disponibilité : l’accès et l’implémentation des standards sont ouverts à tous. – Le bon usage veut que la description et l’implémentation de référence d’un standard ouvert soient disponibles gratuitement en téléchargement sur Internet. – Chaque projet devrait être capable de fournir une copie sans frais excessifs. – Les licences attachées à la documentation des standards ne doivent restreindre aucune partie d’implémenter ce standard en utilisant quelque type de licence que ce soit. 29 LCEN — Loi pour la confiance dans l’économie numérique, Loi 2004-575 du 21 juin 2004, article 4, chap. Ier, titre Ier, http://www.foruminternet.org/documents/lois/lire.phtml?id=733. 30 Open Standards Principles and Practice, Bruce Perens, http://perens.com/OpenStandards/ Definition.html. Observatoire Technologique, CTI 14
  • 15. Standards ouverts et logiciel libre Clarification des notions – Le bon usage veut que les licences des plateformes de référence d’une application soient com- patibles avec toutes les formes de licences, libres ou propriétaires. 2. Maximiser le choix de l’utilisateur final : les standards ouverts créent un marché équitable et compétitif pour l’implémentation des standards. Ils ne lient pas les clients à un vendeur (ou un groupe de vendeurs) particulier. – Les standards ouverts doivent donc permettre une large gamme d’implémentations, que ce soit dans des projets métiers, académiques ou publiques. – Ils doivent supporter des solutions couvrant une large gamme de prix. 3. Pas de droits d’auteur : les standards ouverts sont libres de frais et de droits d’auteur. Seule l’émis- sion d’un certificat de conformité par l’organisme de standardisation peut impliquer des frais. – La licence des brevets contenus dans des standards doit être libre de droits et non discrimina- toire. 4. Pas de discrimination : les standards ouverts et les organismes qui les administrent ne doivent pas favoriser une implémentation plutôt qu’une autre pour une raison autre que la conformité technique de l’implémentation. Les organismes de certification doivent fournir le moyen de faire valider des implémentations à coût nul. Ils doivent également fournir des services de certification étendus. 5. Extension ou sous-ensemble : les implémentations de standards ouverts peuvent être étendues ou proposées sous forme de sous-ensembles. Cependant les organismes de certification peuvent refuser de certifier des sous-ensembles d’implémentations et peuvent imposer des exigences sur des extensions (voir Pratiques de prédateurs). 6. Pratiques de prédateurs : les standards ouverts peuvent recourir à des termes de licence qui les protègent contre des tactiques du type « englober / étendre ». Les licences attachées au standard peuvent exiger la publication d’informations de référence pour les extensions, et une licence pour la création, la distribution et la vente de software qui est compatible avec ces extensions. Un standard ouvert ne peut cependant pas interdire des extensions. Selon Ken Krechmer31 , la notion de standard ouvert peut être appréhendée en combinant les trois perspec- tives différentes que l’on peut en avoir, selon que l’on se place du point de vue du créateur du standard, de celui qui l’implémente ou de celui qui l’utilise. Chaque perspective est naturellement guidée par des consi- dérations très différentes. 1. Les organismes de standardisation qui représentent les créateurs de standards considèrent que ces derniers sont ouverts si leur élaboration suit les principes de séances ouvertes, de décisions par consensus et de processus clairement définis. 2. Les organismes qui implémentent un standard le considèrent comme ouvert lorsqu’il sert leurs marchés, lorsque son coût est nul, lorsqu’il n’empêche pas une innovation future, lorsqu’il ne rend pas obsolètes leurs implémentations précédentes et lorsqu’il ne favorise pas un concurrent. 3. Les utilisateurs de l’implémentation d’un standard le considèrent comme ouvert lorsque plusieurs implémentations (provenant de différentes sources) de ce standard sont disponibles, lorsque les im- plémentations de ce standard fonctionnent partout où nécessaire, lorsqu’elles sont supportées durant tout le cycle de vie des services utilisés et lorsque de nouvelles implémentations souhaitées par les utilisateurs sont compatibles avec les plus anciennes. Il est important de considérer ces trois points de vue afin de bien comprendre les attentes des différents acteurs concernés. La combinaison de ces trois perspectives se traduit selon Krechmer dans dix droits associés à la notion de standard ouvert : 1. Séance ouverte : le processus de développement des standards est ouvert à tous. 2. Consensus : les intérêts de chacun sont discutés et pris en compte de manière équivalente. 3. Processus clairement définis : des processus de vote et de recours peuvent être utilisés pour résoudre un problème. 4. Droits de propriété intellectuelle ouverts : ils sont disponibles pour tous les implémenteurs. 5. Diffusion mondiale : pour des capacités données, un standard unique au niveau mondial. 31 The Meaning of Open Standards, Ken Krechmer, Hawaii International Conference on System Sciences, Janvier 2005, http://www.csrstds.com/openstds.html. Observatoire Technologique, CTI 15
  • 16. Standards ouverts et logiciel libre Clarification des notions 6. Modifications ouvertes : toutes les modifications sont présentées et approuvées par un forum fonc- tionnant selon les cinq droits précédents. 7. Documentation ouverte : la documentation des standards comme de leurs avant-projets sont faci- lement accessibles, que ce soit pour leur implémentation ou pour leur utilisation. 8. Interfaces ouvertes : les interfaces doivent supporter des migrations et permettre un avantage pro- priétaire mais les interfaces standardisées ne doivent être ni cachées ni contrôlées. 9. Usage ouvert : les implémenteurs doivent pouvoir s’assurer objectivement de la conformité de leur implémentation. De leur côté les utilisateurs doivent avoir la garantie qu’elle répond à leurs besoins. 10. Suivi du support : les standards sont supportés jusqu’à ce que l’intérêt des utilisateurs cesse, et non jusqu’à ce que l’intérêt des implémenteurs diminue. On retrouve un certain nombre des critères énoncés par Perens. Mais le fait de tenir compte des points de vue des créateurs et des implémenteurs de standards en donne une vision plus pragmatique. Krechmer y introduit également la notion de processus d’élaboration ouvert. Il a ainsi comparé les principaux orga- nismes de standardisation selon ces dix critères. Aucun n’obtient la note maximale. Selon lui, jusqu’à ce que chaque organisme de standardisation indique clairement lesquels de ces dix critères il soutient et dans quelle mesure, la notion de standard ouvert ne restera qu’un slogan publicitaire. Entre la définition succincte de la LCEN française et celles relativement complexes mais plus complètes proposées par Perens ou Krechmer il y a donc de la place pour des propositions intermédiaires, à la fois plus simples à mettre en œuvre et à communiquer. On citera ici deux définitions qui nous semblent pertinentes et qui vont dans ce sens. Celle proposée par le service gouvernemental belge Fedict32 , et celle de l’EIF, le cadre commun d’interopérabilité33 de la Commission Européenne. La définition de Fedict s’appuie sur les notions de spécification ouverte et de spécification libre pour définir un standard ouvert. Une spécification ouverte doit être gratuite, disponible en ligne et suffisante pour développer une implémentation complète. Une spécification libre doit être ouverte et ne doit pas comprendre de restrictions juridiques (à l’exception de « licences open source ») qui compliquent la diffusion et l’utilisation. Un standard ouvert est une spécification libre et doit être approuvé par une organisation de standardisation indépendante. Comme schématisé à la figure 2, cette définition permet de distinguer très directement les différents cas. Le standard PDF par exemple, qui est parfois présenté (à tort) comme un standard ouvert, y apparaît comme une spécification ouverte mais propriétaire. Elle est en effet la propriété de la société Adobe qui en contrôle l’évolution. On y retrouve les éléments clés liés à la notion d’ouverture comme l’accès gratuit à la spéci- fication, la liberté d’usage et l’adoption par une organisation indépendante et ouverte. Cette définition se concentre sur les aspects jugés comme essentiels liés à l’ouverture du standard mais n’est pas aussi com- plète que celles proposées par Perens ou Krechmer. Avec le même souci de simplification, la Commission Européenne énonce une définition très similaire ins- pirée de celle en vigueur aux Pays-Bas (voir la section 7). Ainsi, selon l’EIF, un standard peut être qualifié d’ouvert si : 32 Directives et recommandations pour l’usage de standards ouverts et/ou spécifications ouvertes dans les administrations fédérales, Jean Jochmans et Peter Strickx, Gouvernement fédéral de Belgique, 2003, http://www.belgium.be. 33 EIF — European Interoperability Framework for Pan-European eGovernment Services, IDABC, Com- mission Européenne, 2004, http://europa.eu.int. Observatoire Technologique, CTI 16
  • 17. Standards ouverts et logiciel libre Clarification des notions Figure 2 – Des standards propriétaires aux standards ouverts (selon Fedict). 1. Il est adopté et maintenu par une organisation à but non lucratif. Son développement se fait sur la base d’une procédure décisionnaire ouverte disponible à toutes les parties inté- ressées (par consensus ou à la majorité par exemple). 2. Il a été publié et sa spécification est disponible soit gratuitement, soit à un coût nominal. Il doit être permis à chacun de le copier, de le distribuer et de l’utiliser soit gratuitement, soit à un coût nominal. 3. La propriété intellectuelle, c’est-à-dire les brevets éventuels, de tout ou partie du standard est cédée irrévocablement sur une base libre de royalties. 4. Il n’y a aucune contrainte à sa réutilisation. On y voit apparaître la notion de réutilisation du standard. Par contre la référence au fait que la spécifi- cation soit suffisante pour développer une implémentation complète n’y apparaît pas. On y introduit enfin la notion de coût nominal (synonyme de faible) qui peut prêter à interprétation et donc à confusion. Cette dernière notion est en effet relativement floue et n’entre d’ailleurs pas dans les critères proposés par Bruce Perens. Lorsqu’un gouvernement ou une administration propose l’utilisation d’un standard ouvert à quelques dizaines ou centaines de milliers de ses citoyens, cette notion de coût nominal peut amener des contraintes financières fortes selon l’interprétation qu’on lui donne. La simplicité de la définition de l’EIF a par contre le mérite de faciliter sa mise en œuvre et sa communication. Dans la mesure ou elle a été émise au niveau européen et qu’on s’y réfère dans plusieurs pays (la Norvège et les Pays-Bas notamment, voir la section 7), on peut supposer qu’elle constituera, en Europe du moins, une définition de référence de la notion de standard ouvert. 4.2 Degré d’ouverture Plusieurs standards se situent dans une zone grise entre standards propriétaires et standards ouverts. Ainsi les définitions proposées ci-dessus ne devraient pas être vues comme une exigence stricte pour qu’un Observatoire Technologique, CTI 17
  • 18. Standards ouverts et logiciel libre Clarification des notions standard puisse être qualifié d’ouvert. Dans la pratique ces définitions devraient plutôt fournir les paramètres d’évaluation à utiliser pour qualifier le degré d’ouverture du standard étudié. La figure 3 illustre cette notion de zone grise. Quelques standards y sont sommairement positionnés en fonc- tion d’une part de la facilité d’accès à leurs spécifications et d’autre part du degré d’ouverture de l’organisme qui l’a validé. Le schéma ne présente que deux des critères liés à la notion de standard ouvert. Si l’on s’en tenait à ces deux critères uniquement, le standard ouvert idéal se situerait dans la zone en haut à droite du graphique. Figure 3 – Degré d’ouverture d’un standard. L’exemple du coût nominal introduit dans la définition de l’EIF est illustratif. Le développement et la mainte- nance d’un standard efficace impliquent souvent des frais importants de la part du sponsor de ce standard. Ces coûts ne sont pas couverts si le standard peut être utilisé gratuitement, sauf au travers de la vente de produits ou de services dérivés. La gratuité est donc une qualité idéale que l’on peut attendre d’un standard ouvert mais qui se heurte à une vision pragmatique des choses. Dans de nombreux cas, on ne peut ainsi pas s’attendre à ce que le standard ouvert idéal n’existe que parce qu’il correspond à un besoin exprimé. D’un autre côté, il est évident que la gratuité est un pré-requis nécessaire (mais pas suffisant) lorsque l’on considère des implémentations de logiciels libres qui doivent par essence pouvoir être redistribuées gratui- tement. On se trouve alors face à deux cas de figure. Soit l’on propose, comme l’EIF, une définition laissant une marge d’interprétation qui permet de prendre en compte la zone grise autour du standard ouvert idéal. Mais on y perd alors en terme de clarté de la définition puisque un certain nombre de termes peuvent être sujets à interprétation. Soit l’on suit une approche similaire à celle du gouvernement danois34 qui donne une définition du standard ouvert dans sa forme la plus pure (propriétés fondamentales que l’on désire promouvoir) et qui met en œuvre une politique de standardisation pragmatique. Cette approche laisse une certaine marge de manœuvre par rapport à cet idéal en incluant le degré d’ouverture du standard dans les critères d’évaluation. 34 Definition of open standards, National IT and Telecom Agency, Ministry of Science, Technology and Innovation, Danemark, Juin 2004, http://www.itst.dk/. Observatoire Technologique, CTI 18
  • 19. Standards ouverts et logiciel libre Clarification des notions Joel West35 a étudié cette notion de degré d’ouverture et propose un certain nombre de dimensions per- mettant d’apporter une métrique lors de l’évaluation d’un standard. On peut les résumer au travers des 3 questions suivantes. 1. QUI : Qui a accès au standard ? 2. QUOI : Dans quel(s) but(s) le standard est-il ouvert ? 3. COMMENT : Quel est l’accès donné au standard ? La figure 4 présente un tableau constituant un point de départ pour l’élaboration d’une telle métrique. Figure 4 – Questions permettant d’évaluer le degré d’ouverture d’un standard (selon West). 5 Organismes de normalisation Cette section recense les principaux consortiums et organismes de standardisation œuvrant dans le do- maine des nouvelles technologies de l’information et de la communication. Cette liste n’est naturellement pas exhaustive. Les consortiums et organismes recensés ici travaillent à l’élaboration de standards que l’on peut considérer à divers degrés comme ouverts. AFNOR Association Française de Normalisation. http://www.afnor.fr/ – Normalisation dans le domaine des technologies de l’information http://forum.afnor.fr/ ANSI American National Standards Institute. http://www.ansi.org/ ATIS Alliance for Telecommunications Industry Solutions. http://www.atis.org/ 35 What are Open Standards ? Implications for Adoption, Competition and Policy., J. West, Standards and Public Policy Conference, Chicago, USA, Mai 2004, http://www.cob.sjsu.edu/west_j. Observatoire Technologique, CTI 19
  • 20. Standards ouverts et logiciel libre Clarification des notions CEN Comité Européen de Normalisation. http://www.cenorm.be/ Dublin Core Dublin Core Metadata Initiative, Groupe engagé dans le développement de standards de mé- tadonnées. http://dublincore.org/ ECMA European association for standardizing information and communication systems. http://www. ecma-international.org/ ETSI European Telecommunications Standards Institute. http://www.etsi.org/ FreeStandards.org The Free Standards Group. http://www.freestandards.org/ ICTSB Information & Communications Technologies Standards Board. http://www.ictsb.org/ IEC International Electrotechnical Commission. http://www.iec.ch/ IEEE Institute of Electrical and Electronics Engineers. http://www.ieee.org/ IETF Internet Engineering Task Force. http://www.ietf.org/ ISO Organisation Internationale de Normalisation. http://www.iso.ch/ ITU The International Telecommunication Union. http://www.itu.int/ JCP Java Community Process. http://jcp.org Liberty Alliance Liberty Alliance Project. http://www.projectliberty.org LSB Linux Standard Base. http://www.linuxbase.org/ NIST National Institute of Standards and Technology. http://www.nist.gov/ – Le sous-domaine ITL : Information Technology Lab. http://www.itl.nist.gov/ OASIS Organization for the Advancement of Structured Information Standards. http://www.oasis-open. org/ – Liste de tous les standards de base associés aux technologies Markup Language. http:// xml.coverpages.org/coreStandards.html – Une introduction à ces standards. http://xml.coverpages.org/library.html ODMG Object Data Management Group. http://www.odmg.org/ OMA Open Mobile Alliance. http://www.openmobilealliance.org/ OMG Object Management Group. Organisation internationale dont le but est de produire et de maintenir des spécifications pour des applications interopérables. http://www.omg.org/, notamment : – CORBA (Common Object Request Broker Architecture). http://www.corba.org/ – UML (Unified Modeling Language). http://www.uml.org/ – MDA (Model Driven Architecture). http://www.omg.org/mda/ OpenGroup The Open Group. http://www.opengroup.org/ OSGi Open Services Gateway Initiative. http://www.osgi.org/ RosettaNet Open e-business process standards. http://www.rosettanet.org/ TCG Trusted Computing Group. https://www.trustedcomputinggroup.org/ UDDI.org Universal Description, Discovery, and Integration. http://www.uddi.org/ VoiceXML Voice XML Forum. http://www.voicexml.org/ W3C World Wide Web Consortium. http://www.w3.org/ – La liste de la cinquantaine de recommandations émises par le W3C. http://www.w3.org/ TR/#Recommendations – Ainsi que les domaines d’activités correspondants. http://www.w3.org/Consortium/Activities – Méthodes de travail du W3C par Alain Michard (en français). http://www.editions-eyrolles. com/livres/michard/w3c-present.asp WS-I Web Services Interoperability Organization. http://www.ws-i.org/ Observatoire Technologique, CTI 20
  • 21. Standards ouverts et logiciel libre Clarification des notions 6 Standard ouvert vs logiciel libre Les chapitres précédents montrent combien les fondements des standards ouverts et des logiciels libres sont basés sur des objectifs et des modes de fonctionnement similaires. Mais ces deux concepts différent malgré tout : schématiquement, les standards ouverts concernent le contenu et l’échange d’information alors que le logiciel libre ne relève que de l’accès au code source. Comme le souligne Jack Verhoosel36 , les développeurs de logiciels libres implémentent volontiers des stan- dards ouverts pour deux raisons. La première est que l’utilisation de standards propriétaires va à l’encontre des principes d’ouvertures et d’interopérabilité qui sont prônés par la communauté du libre et qu’ils n’ont aucun intérêt à lier les utilisateurs à leurs développements. La seconde concerne les coûts et les licences d’utilisation éventuels des standards propriétaires qui vont à l’encontre de certaines licences open source. Il n’y a d’ailleurs pas toujours incompatibilité entre logiciel libre et standards propriétaires, pour autant que ceux-ci soient publiquement accessibles, gratuits et libres d’utilisation. A l’inverse il est possible et même souhaitable qu’un logiciel propriétaire implémente sans aucune restriction des standards ouverts. Ceci dé- pend fortement des conditions concurrentielles prévalant sur le marché. En principe la communauté open source préconise l’usage des standards ouverts. Mais ce n’est pas for- cément la règle. Cela peut provenir du fait qu’un standard ouvert potentiellement utilisable est incomplet, immature, de qualité insuffisante ou simplement qu’il n’existe pas. C’est parfois aussi tout bonnement lié au manque de maturité de la communauté de développeurs concernée par rapport à l’utilisation des stan- dards ouverts. Les spécialistes réunis lors de la conférence de Scottsdale37 tenue récemment sur le sujet, estiment qu’il y a encore un travail de sensibilisation à effectuer auprès de la communauté open source afin de la pousser à mieux implémenter les standards ouverts. « Le logiciel libre fait face à des défis importants, mais non insurmontables, dans son évolution actuelle. En tête de liste on retrouve les préoccupations liées à la propriété intellectuelle, à la nécessité de fournir des options de support et d’intégration aux usagers (et de les convaincre qu’ils sont fiables) et de gérer le risque tout en maximisant l’utilité des logiciels. Les standards (ouverts) proposent un outil efficace pour apporter une réponse à plusieurs de ces préoccupations. » Les logiciels libres auraient alors le double mérite d’implémenter des standards ouverts et de constituer une métrique pour la qualité de ces standards. En effet un standard devrait de manière générale être pensé et conçu en considérant son implémentation future. Mais quel que soit son degré d’ouverture, il ne démontre sa réelle utilité que dans la mesure où l’on peut se référer à des implémentations certifiées et accessibles. A ce niveau le lien entre logiciel libre et standards ouverts est manifeste car il est difficile de cacher l’implé- mentation d’un standard lorsque le code source est ouvert. Comme la communauté open source implémente généralement des solutions interopérables aussi conformes que possible aux standards ouverts, les logiciels libres de bonne qualité peuvent alors constituer des implémentations de référence accessibles. L’Union Européenne38 présente à cet égard le logiciel libre comme un modèle de développement idéal pour s’assurer que les standards ouverts peuvent être correctement mis en œuvre et intégrés. Le cadre com- mun d’interopérabilité européen relève que : « Les logiciels libres sont, par leur nature, des spécifications publiquement accessibles et l’ouverture de leur code source, promeut un débat ouvert et démocratique sur les spécifications, ce qui les rend à la fois plus robustes et interopérables. En tant que tels, le logiciel libre correspond aux objectifs du présent programme et devrait être évalué et considéré favorablement aux côtés d’alternatives propriétaires. » D’un autre côté, il est essentiel que les organismes de standardisation comprennent et acceptent les prin- cipes du logiciel libre. Le monde du libre aurait alors tout à y gagner. Certains comme Lawrence Rosen39 36 Open Standards and Open Source Software : Similarities and Differences, J. Verhoosel, Entschede, Pays-Bas, http://www-i4.informatik.rwth-aachen.de/~jakobs/Interop/Verhoosel.pdf. 37 Conference « Open Source, Open Standards : Maximizing Utility While Managing Exposure », 12-14 Septembre 2004, Scottsdale, USA, http://www.thebolingroup.com/OSOSAnalysis.pdf 38 EIF — European Interoperability Framework for Pan-European eGovernment Services, IDABC, Com- mission Européenne, 2004, http://europa.eu.int. 39 Lawrence Rosen, http://www.rosenlaw.com/. Observatoire Technologique, CTI 21
  • 22. Standards ouverts et logiciel libre Clarification des notions proposent même une redéfinition de la notion de standard ouvert afin de faciliter l’alignement des deux communautés. C’est principalement au niveau des droits de propriété intellectuelle et de gratuité que les définitions actuelles peuvent en effet poser problème. 7 Politiques gouvernementales Plusieurs gouvernements ont déjà pris position sur l’adoption des standards ouverts et du logiciel libre. Ces positions sont parfois très différentes et couvrent une large palette allant d’une non entrée en matière, à une volonté politique très affirmée en passant par une attitude agnostique. La section suivante résume les prises de position gouvernementales qui nous paraissent les plus intéres- santes dans ce domaine. Cette liste n’est bien entendu pas exhaustive et évolue continuellement. Un recueil de liens est également disponible sur le site de l’IDABC40 . Le Center for Strategic and International Studies produit un document41 qui recense dans un tableau sy- noptique les politiques, les recommandations et les textes de loi considérés au niveau des administrations nationales, régionales et locales sur la planète. Voici notre analyse en date du mois de juillet 2005. 7.1 Belgique Le Conseil des Ministres du 25 juin 2004 a approuvé les directives et recommandations aux services publics fédéraux pour l’usage de standards, de logiciels d’application et de logiciels libres, faits sur mesure42 : « Pour les nouveaux systèmes informatiques, les services publics fédéraux utiliseront désormais exclusive- ment des standards ouverts et/ou spécifications ouvertes pour les formats de données et les protocoles de communication lors de l’archivage, de l’échange et de la communication de données électroniques. Pour les applications existantes qui, lors de l’archivage, de l’échange ou de la communication de données électro- niques à des parties externes, n’utilisent pas encore de standards ouverts et/ou de spécifications ouvertes, pour les formats de données et les protocoles de communication, les services publics fédéraux lanceront et achèveront une migration conformément à un planning convenu lors de la fixation de chaque standard ou- vert et/ou spécification ouverte. Les administrations fédérales disposeront des droits de propriété pour tout logiciel fait sur mesure. Ce logiciel sera fourni en code source et sans droit de licence. Les services publics fédéraux pourront mettre ce logiciel à la disposition d’autres services publics en tant que logiciel libre. » La stratégie 2005 du gouvernement belge est décrite par Peter Vanvelthoven, Secrétaire d’État à l’Informa- tisation de l’État43 . Le point 3.4 stipule clairement que toute nouvelle application informatique utilisera des standards ouverts et que les applications existantes devront être migrées progressivement vers ceux-ci. La liste des standards ouverts utilisés par l’État sera rassemblée au sein du Cadre Fédéral Belge d’Interopera- bilité en concertation avec les Communautés et Régions. De plus, le texte continue sur la position face au logiciel libre : « Les logiciels libres doivent être sérieusement pris en compte au sein de l’administration fédérale. Quelques services publics ont déjà commencé à migrer d’un environnement de logiciels propriétaires vers un environnement de logiciels libres. Fedict suivra ces projets pilotes et évaluera les résultats et formulera des recommandations pour l’ensemble de l’administra- tion. » Le service gouvernemental Fedict44 définit la notion de standard ouvert comme : « une spécification gratuite, 40 Section du site Web du programme IDABC consacrée au logiciel libre : http://europa.eu.int/ idabc/en/document/1677/471. 41 CSIS — Center for Strategic and International Studies, 13 décembre 2004, http://www.csis.org/ tech/OpenSource/0408_ospolicies.pdf. 42 Standards et Logiciels, Chancellerie du Premier Ministre — Conseil des Ministres, Belgique, 2004, http://www.belgium.be/eportal/application?pageid=contentPage&docId=35409. 43 Note stratégique 2005, Secrétaire d’État à l’Informatisation de l’État, Peter Vanvelthoven, Belgique, 2005, http://www.belgium.be/eportal/application?pageid=contentPage&docId=36796. 44 Fedict a pour tâche d’initier, d’élaborer et d’accompagner des projets d’e-government pour l’administra- Observatoire Technologique, CTI 22
  • 23. Standards ouverts et logiciel libre Clarification des notions disponible en ligne, suffisante pour développer une implémentation complète, qui ne doit pas comprendre de restrictions juridiques (à l’exception de « licences open source ») qui compliquent la diffusion et l’utilisation et qui doit être approuvée par une organisation de standardisation indépendante45 . » Cette définition est similaire à celle de la Commission Européenne, mais ne fait notamment pas intervenir les notions d’organisation de standardisation indépendante à but non lucratif, avec des procédures de décision ouvertes et la mise à disposition gratuite et irrévocable des droits de propriété intellectuelle contenus dans le standard. En revanche, elle précise bien que l’implémentation doit être possible ce qui ne ressort pas clairement de la définition européenne. Le gouvernement belge a défini un cadre commun d’interopérabilité46 dans lequel il concrétise sa vision relative au logiciel libre et aux standards ouverts. La consultation de ce référentiel est largement ouverte (même aux contributions externes) dans le but de définir les standards techniques à travers un wiki 47 qui en permet la mise à jour continue. 7.2 Brésil Le président brésilien, Luís Inácio Lula da Silva, a donné le mandat le 29 octobre 2003 à l’Institut Natio- nal de Technologie Informatique (ITI) de planifier, coordonner et implémenter les projets du gouvernement concernant le logiciel libre48 (article 1). Le ITI intègre le Comité Exécutif du Gouvernement Électronique, lequel coordonne le Comité Technique d’Implémentation du Logiciel Libre du Gouvernement Fédéral49 . Dans son plan stratégique de mai 2004, le comité Exécutif du Gouvernement Électronique précise d’entrée que « le logiciel libre doit être utilisé comme une ressource stratégique » (page 8). La position du gouvernement brésilien face aux technologies de l’information est clairement une vision très large de développement économique et social, ainsi que de diminution de la fracture numérique. Le 18 juin 2004 Sérgio Amadeu da Silveira, directeur de l’ITI, déclarait : « Nous n’optons pas pour un produit, nous optons pour un modèle de développement et d’utilisation de logiciel. C’est une décision politique, et j’insiste sur ce point, fondée sur une raison économique — une réduction du paiement de royalties. Cette décision augmente aussi l’autonomie technologique du Brésil et renforce notre intelligence collective. » La plupart des sites web gouvernementaux brésiliens utilisent des composants libres et le gouvernement impose aux organismes d’état ou aux compagnies privées bénéficiant de financements gouvernementaux de développer et d’éditer leurs logiciels sous licence libre GNU/GPL50 . Un autre point intéressant est que le gouvernement préfère le logiciel libre pour éviter la gestion coûteuse les licences de produits propriétaires ou le risque de piratage qui le mettrait également face à des coûts et des poursuites judiciaires possibles. Microsoft a proposé une version moins coûteuse, mais amputée de plusieurs fonctionnalités de Windows XP (baptisée Windows Starter Edition) au Brésil. Toutefois, cette option a été finalement écartée par le gouver- nement brésilien. La décision a été très largement influencée par le rapport commandé par le gouvernement à Walter Blender, directeur exécutif du MIT MediaLab (Massachussets Institute of Technology), qui a chau- dement recommandé l’usage des logiciels libres de bonne qualité qui sont, selon lui, plus intéressants que tion fédérale. Il dépend des services publics fédéraux et de programmation dans le cadre des technologies de l’information et de la communication http://www.belgium.be/eportal/application?pageid= indexPage&navId=9513. 45 Directives et recommandations pour l’usage de standards ouverts et/ou spécifications ouvertes dans les administrations fédérales, Jean Jochmans et Peter Strickx, Gouvernement fédéral de Belgique, 2003, http://www.belgium.be. 46 BELGIF — BELgian Governement Interoperability Framework, http://www.belgif.be. 47 Un wiki est un site web dynamique dont tout visiteur peut modifier les pages à volonté. Pour plus d’infor- mation voir http://fr.wikipedia.org/wiki/Wiki. 48 Voir le site du Gouvernement brésilien, http://www.governoeletronico.gov.br/ governoeletronico/index.html. 49 Software Livre, Gouvernement du Brésil, http://www.softwarelivre.gov.br/. 50 Brazil : Free Software’s Biggest and Best Friend, Todd Benson, The New-York Times, 29 mars 2005, http://www.nytimes.com/2005/03/29/technology/29computer.html. Observatoire Technologique, CTI 23
  • 24. Standards ouverts et logiciel libre Clarification des notions les versions propriétaires limitées. 7.3 Danemark Le gouvernement danois (Ministère des sciences et technologies, et de l’innovation) a adopté le 13 juin 2003 une stratégie relative à l’utilisation de logiciels dans le but d’accroître la concurrence du marché du logiciel et d’augmenter la qualité et la cohérence des produits logiciels déployés dans le secteur public51 . Cette stratégie est déclinée selon une série de principes : 1. Valeur monétaire : Le principe gouvernant le choix, l’approvisionnement et l’utilisation de logiciels dans le secteur public est la recherche de la valeur maximale, fondée sur une approche coûts/bénéfices, indépendamment du fait d’utiliser du logiciel propriétaire ou libre. 2. Concurrence, indépendance et liberté de choix : Une concurrence effective est un pré-requis es- sentiel pour un marché du logiciel compétitif et diversifié. Les distributeurs de logiciel doivent pouvoir se concurrencer à « armes égales » et les barrières d’entrée doivent être éliminées. 3. Interopérabilité et flexibilité : La priorité doit être donnée aux logiciels qui sont construits de façon modulaire et qui peuvent s’interconnecter avec d’autres types de programmes et de systèmes. Ceci permet d’assurer que les modules du système logiciel peuvent être changés ou modifiés indépen- damment et ainsi augmenter la flexibilité et permettre la réutilisation. 4. Développement et innovation : Le secteur public doit être ouvert aux nouvelles méthodes d’approvi- sionnement et de développement de logiciel. En particulier, il existe un besoin de tester de nouvelles méthodes comme celles de développement du logiciel libre afin de les évaluer et d’en mesurer les avantages et les inconvénients à large échelle dans le cadre des administrations publiques. Pour soutenir ces objectifs stratégiques, les activités suivantes sont lancées : – Développer une signature numérique publique basée sur une solution open source. – Développer une analyse du coût total de possession (Total Cost of Ownership). – Démarrer des projets pilotes dans les administrations centrales, régionales et locales. – Suivre l’usage de standards ouverts et la définition d’un format de document ouvert. – Élargir le marché du logiciel pour le secteur public. – Favoriser la collecte et la dissémination de l’information. Un travail conséquent de standardisation des informations est entrepris. Ces résultats enrichissent un ré- férentiel XML afin de soutenir l’ensemble de la démarche. Le projet est nommé Infostructurebase52 et son objectif est de déterminer des standards pour l’échange de données en interne ainsi qu’entre les autorités gouvernementales, le public et les entreprises. La standardisation est une étape nécessaire vers l’utilisation et la réutilisation des données sur le long terme en s’assurant de l’absence de blocage (lock-in) dans des outils propriétaires ou des formats non documentés. La méthodologie de standardisation adoptée est très intéressante. Elle laisse des groupes d’utilisateurs, appelés communautés de pratique, définir les standards relatifs à leurs métiers en collaboration avec les informaticiens. Le rôle de ces communautés de pratique est de classifier et clarifier les termes et concepts utilisés lors d’échanges d’informations ainsi que leurs besoins d’interopérabilité en créant des définitions standard d’objets informationnels. Ces standards sont ensuite proposés à un comité XML qui revoit, accepte et publie les résultats. Ces résultats forment une base de référence pour le groupe de travail technique qui est ensuite chargé de rédiger les schémas XML correspondants. Ceci permet de réconcilier les architectures métier et technique. D’une part, les communautés de pratique définissent les concepts, la terminologie, les significations et les associations ainsi que les manières de travailler avec l’information. D’autre part, ces inputs sont intégrés dans les schémas par les informaticiens qui, eux, n’ont pas toujours une compréhension complète du domaine ou un ressenti exact de l’importance des relations spécifiques au métier. 51 ICA Country Report, Danemark, 2003, http://e.gov.dk/english/results/2003/ benchmarking_ica_country_report_denmark_2003/index.html. 52 OIO — Infostructurebase, Danemark, http://isb.oio.dk/Info/Standardization/ Standardization.htm. Observatoire Technologique, CTI 24
  • 25. Standards ouverts et logiciel libre Clarification des notions 7.4 États-Unis, Massachusetts Le gouvernement de l’État du Massachusetts a publié le 13 janvier 2003 deux documents concernant sa position vis-à-vis des standards ouverts et du logiciel libre. Le premier53 exige l’utilisation de standards ouverts comme critère sélectif lors de la création, de l’acquisition ou de la refonte d’applications informatiques afin d’assurer que les investissements dans les technologies de l’information soient consacrés à des solutions suffisamment interopérables pour satisfaire aux exigences métier de ses départements et servir au mieux le public. L’État du Massachusetts propose la définition suivante du standard ouvert : « Une spécification qui est dis- ponible publiquement, développée par une communauté ouverte et confirmée par un organisme de norma- lisation. » Le second document54 concerne l’acquisition de logiciels et stipule que les solutions doivent être sélection- nées selon la valeur mesurée au-delà du pur aspect financier. Il est nécessaire de considérer au minimum : le coût total de possession sur la durée de vie de la solution, l’adéquation aux besoins métier, la stabilité, la performance, la scalabilité, la sécurité, les exigences de maintenance, les risques légaux, la facilité de d’adaptation et la facilité de migration. Toutes les alternatives incluant en particulier, les logiciels propriétaires, les logiciels libres ainsi que les logiciels dont le code est partagé entre les administrations doivent être examinées. La position de cet état a eu une grande visibilité médiatique. Les déclarations de ses représentants, le CIO Peter J. Quinn et le Secrétaire d’État Eric Kriss55 ont poussé Microsoft à négocier et à proposer une version « moins fermée » du format XML des fichiers MS Office. L’état du Massachussets a pris position sur les formats de données et identifie le OASIS Open Document Format comme le standard choisi pour les applications bureautiques56 . Depuis le 21 septembre 2005, le format OpenDocument est l’un des standards de données référencés par leur modèle de référence technique qui catalogue les standards officellement adoptés57 . Au niveau fédéral américain, l’Office of Management and Budget recommande que les agences gouver- nementales aient des politiques d’acquisition de logiciels « neutres quant aux technologies et aux fournis- seurs. » 7.5 France L’Agence pour le Développement de l’Administration Électronique58 (ADAE) met à disposition des ministères et des services un guide de choix et d’usage des licences de logiciels libres pour les administrations. Ce guide recommande de privilégier l’utilisation de la licence GNU GPL pour les développements en logiciels libres réalisés par ou pour les administrations. Il préconise également une démarche qui s’appuie sur le code des marchés publics. L’ADAE a aussi largement soutenu l’information sur les solutions de logiciel libre 53 Enterprise Open Standards Policy, Commonwealth of Massachusetts, Massachusetts, USA, 13 janvier 2004, http://www.mass.gov/Aitd/docs/policies_standards/openstandards.pdf. 54 Enterprise Information Technology Acquisition Policy, Commonwealth of Massachusetts, Mas- sachusetts, USA, 13 janvier 2004, http://www.mass.gov/Aitd/docs/policies_standards/ itacquisitionpolicy.pdf. 55 Une retranscription officielle des commentaires informels donnés lors de la confé- rence de presse http://www.mass.gov/eoaf/open_formats_comments.html et leur traduction en français http://formats-ouverts.org/blog/2005/01/21/ 255-traduction-du-texte-officiel-du-massachussets-sur-les-formats-ouverts. 56 Déclaration de Peter Quinn du 29 août 2005 sur le site du http://www.mass.gov/Aitd/ et in- formations sur le site de News.com Massachusetts to adopt ’open’ desktop http://news.com.com/ 2102-1012_3-5845451.html. 57 Voir le document Enterprise Technical Reference Model Version 3.5 http://www.mass.gov/Aitd/ docs/policies_standards/etrm3dot5/etrmv3dot5informationdomain.pdf page 18. 58 ADAE - Agence pour le Développement de l’Administration Électronique, http://www.adae.gouv. fr/. Observatoire Technologique, CTI 25
  • 26. Standards ouverts et logiciel libre Clarification des notions à travers ses publications et colloques59 . Notons également que depuis la rédaction du guide du choix de licences, le CEA, le CNRS et l’INRIA ont élaboré CeCILL60 , la première licence reprenant les principes de la GNU GPL et qui définit les principes d’utilisation et de diffusion des logiciels libres en conformité avec le droit français. A travers l’ADAE, le gouvernement propose de créer et développer une plate-forme de services destinée aux organismes publics, visant le développement des technologies de l’information et de la communication. L’un des objectifs est de mettre en place un entrepôt d’informations pour la diffusion de la connaissance relative notamment aux méthodes, aux chartes et aux guides et d’en assurer la gestion. Il s’agit par ailleurs de pro- poser un espace de développement collaboratif qui sera également un point d’entrée pour le référencement des logiciels et des composants réutilisables. L’un des résultats de cette démarche est AdmiSource61 , une plate-forme collaborative proposée à l’ensemble des administrations françaises pour leurs développements de logiciels libres. Chacun est le bienvenu pour utiliser, participer et contribuer à la hauteur de ses intérêts. Ce portail permet de fédérer et partager les développements réalisés par les administrations françaises en leur offrant un outil de gestion de projet ouvert et collaboratif. Un démarche très similaire est proposée par l’ADULLACT62 , une association sans but lucratif, dont l’objectif est de soutenir et coordonner l’action des administrations et des collectivités territoriales pour promouvoir, développer, mutualiser et maintenir un patrimoine commun de logiciels libres utiles aux missions de service public63 . On peut également citer la loi 2004-575 du 21 juin 2004 pour la confiance dans l’économie numérique (LCEN), qui précise une définition de standard ouvert dans son article 4 : « On entend par standard ouvert tout protocole de communication, d’interconnexion ou d’échange et tout format de données interopérable et dont les spécifications techniques sont publiques et sans restriction d’accès ni de mise en œuvre. » Au cours d’une interview dans l’émission de Stéphane Paoli sur France Inter le 26 mai 2004, l’ancien premier ministre Jean-Pierre Raffarin a brièvement évoqué l’idée que l’administration française pourrait utiliser des logiciels libres au lieu d’acheter des logiciels propriétaires. Seul l’aspect économique a été invoqué : M. Raf- farin veut « faire en sorte que les communications inter-administrations passent par internet et l’utilisation des logiciels libres. » Il juge ainsi qu’il y aurait plus de 100 millions d’euros à économiser. 7.6 Norvège Dans son plan stratégique pour le gouvernement électronique eNorway200964 le ministre norvégien de la modernisation, Morten Andreas Meyer, a annoncé que le secteur public devra utiliser des standards ou- verts dans ses systèmes informatiques : « Les formats propriétaires ne seront plus acceptables dans les communications entre les citoyens et le gouvernement. » Le calendrier suivant est proposé65 : – D’ici 2006, un ensemble de standards administratifs et de gestion devront être établis pour les échanges de données et de documents. – D’ici 2006, tous les services du secteur public devront avoir établi des plans pour l’introduction de standards ouverts, d’architecture orientée services et de logiciels libres. – D’ici 2008, tous les échanges de données et de documents du secteur public devront satisfaire les standards administratifs et de gestion. 59 Réutilisation des logiciels et bouquet du libre, http://www.adae.gouv.fr/spip/rubrique.php3? id_rubrique=33. 60 Voir le site Web dédié à CeCILL, http://www.cecill.info/. 61 Voir le site Web http://admisource.gouv.fr/. 62 ADULLACT — Association des Développeurs et des Utilisateurs de Logiciels Libres pour les Adminis- trations et les Collectivités Territoriales, http://adullact.net/. 63 AdmiSource et ADULLACT.net utilisent d’ailleurs le même outil libre GForge http://www.gforge. org/. 64 Voir http://europa.eu.int/idabc/en/document/4415/194 et http://www.odin.dep.no/ mod/english/bn.html. 65 Voir http://europa.eu.int/idabc/en/document/4403/469. Observatoire Technologique, CTI 26