fsfe-website/activities/os/eifv2-01.fr.xhtml

403 lines
22 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="UTF-8"?>
<html>
<version>1</version>
<author id="roy"/>
<date>
<original content="2009"/>
</date>
<head>
<title>FSFE - EIFv2 : Suivre et mesurer la perte d'interopérabilité</title>
<style type="text/css">
.colonne {
margin-top:20px;
font-size:0.9em;
max-width:30%;
min-width:25%;
border:0;
float:left;
padding:0px 10px;
}
.nettoyeur { clear: both; height: 0; margin: 0; padding: 0; border: 0; line-height: 1px; font-size: 1px; }
.frame {
min-width:800px;
overflow-x:scroll;
}
</style>
</head>
<body>
<p align="right">[ <a href="eifv2.en.pdf">version PDF (en anglais) (76k)</a> ]</p>
<h1 align="center">EIFv2&#160;: suivre et mesurer la perte d'interopérabilité</h1>
<p class="indent"><em>Note de traduction&#160;: les liens hypertextes conduisent généralement à des documents rédigés en anglais, comme c'est souvent le cas des documents de travail internationaux. Les traductions faites des extraits de ces textes ne proviennent pas du service de traduction de l'Union Europenne. De plus, nous faisons ici référence à la notion de <strong>norme</strong> lorsque nous parlons d'"Open Standards" en anglais.</em></p>
<p class="indent"><em>Ce document présente une analyse comparative de l'évolution du Cadre européen d'interopérabilité (EIF&#160;: European Interoperability Framework) basée sur les <a href="http://ec.europa.eu/idabc/en/document/7732">commentaires</a> formulés vis-à-vis de la <a href="http://ec.europa.eu/idabc/en/document/7733">deuxième version de l'EIF</a> (EIF v2). Il met en lumière les changements apportés entre la première mouture, sur laquelle une consultation publique avait été organisée durant l'été 2008, et <a
href="http://blog.webwereld.nl/wp-content/uploads/2009/11/European-Interoperability-Framework-for-European-Public-Services-draft.pdf">la version actuelle</a> du document de travail, qui a fui dans la presse.</em></p>
<p>Table des matières</p>
<ul>
<li><a href="#about">Qu'est-ce que le Cadre européen d'interopérabilité&#160;?</a></li>
<li><a href="#one">1.Les normes sont le cœur de l'intéropérabilité</a></li>
<li><a href="#two">2. S'affranchir de l'utilisation des standards propriétaires</a></li>
<li><a href="#three">3. Le continuum de l'Ouverture</a></li>
</ul>
<h2 id="about">Qu'est-ce que le Cadre européen d'interopérabilité&#160;? (EIF en anglais)</h2>
<blockquote>
<p>L'EIF est un ensemble de lignes directrices pour l'interopérabilité et d'initiatives menées sous les auspices du programme IDABC (<em>Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens</em>, livraison aux administrations publiques, aux entreprises et aux citoyens de services d'«&#160;e-gouvernement&#160;» européens interopérables). L'EIF complète les différents cadres nationaux d'interopérabilité au niveau paneuropéen.</p>
</blockquote>
<p><em><a href="http://ec.europa.eu/idabc/servlets/Doc?id=31597">Extrait du document de travail initial, section 2/3.</a></em></p>
<p> Le texte ci-dessous analyse certains changements que le texte a connus entre la consultation publique organisée durant l'été 2008 et le document de travail qui en résulta en novembre 2009. À l'occasion de cette consultation, de nombreux groupes et particuliers ont soumis <a href="http://ec.europa.eu/idabc/en/document/7732">leurs commentaires</a>. D'après notre analyse, nous pouvons conclure que la Commission Européenne, dans des domaines clés, n'a pris en compte que les <a href="http://ec.europa.eu/idabc/servlets/Doc?id=31903">commentaires proposés</a> par la <a href="http://www.bsa.org">«Business Software Alliance»</a>, un groupe de lobbying agissant pour le compte des entreprises de logiciels propriétaires. Quant aux commentaires proposés par les groupes travaillant en faveur du Logiciel Libre et des Standards Ouverts, ils ont été négligés. Parmi eux se trouvent ceux de l'<a href="http://openforumeurope.org/">Open Forum Europe</a>.
</p>
<h2 id="one">1. «&#160;Les normes sont le cœur de l'intéropérabilité&#160;»</h2>
<div class="frame">
<div class="colonne">
<h3>A. Document de consultation de l'EIFv2</h3>
<blockquote>
<p>«&#160;<span style="background:#ffff00">Les normes sont le cœur de l'interopérabilité.</span> La stratégie de l'Union Européenne pour la croissance et l'emploi a identifié une normalisation forte et dynamique comme un instrument crucial pour favoriser l'innovation. La normalisation a une dimension d'intérêt public, en particulier en matière de sécurité, de santé, d'environnement et de performance.&#160;» (p.35)</p>
<p>«&#160;Le rôle des administrations nationales dans ce processus est de
<span style="background:#1e90ff">choisir la norme appropriée.</span>&#160;»</p>
</blockquote>
<p>Le document de consultation souligne le fait que les normes sont parmi les outils les plus efficaces pour réaliser l'interopérabilité sans nuire à la compétition ou à l'innovation. De plus, en se référant à la «&#160;norme appropriée&#160;», il indique que si plusieurs normes existent pour un même usage, un choix doit être fait. Ce choix, comme expliqué ensuite, doit favoriser les Standards Ouverts.</p>
</div>
<div class="colonne">
<h3>B. Commentaires de la <em>Business Software Alliance</em></h3>
<blockquote>
<p>«&#160;<span style="background:#ffff00">S'il est vrai que les Standards Ouverts jouent un rôle critique pour permettre l'interopérabilité</span>, <span style="background:#ffa500">ce sont souvent nombre de mécanismes complémentaires qui, fonctionnant ensemble, concrétisent l'interopérabilité totale.</span>&#160;»</p>
</blockquote>
<p>Dans cette phrase, la BSA mentionne explicitement les Standards Ouverts, mais cette affirmation suggère de remettre en cause le rôle même que jouent les normes dans l'interopérabilité.</p>
<blockquote>
<p>«&#160;Finalement, l'EIFv2.0 devrait se retenir de recommander que les appels d'offres promeuvent les Standards Ouverts. À la place, l'EIF devrait adopter les principes et les règles exprimés dans les directives 2004/18 et 98/34, et encourager les États membres à baser leur décision d'appel d'offres sur le mérite.&#160;»</p>
</blockquote>
<p>Alors que le document de consultation arguait que le rôle des administrations nationales était de choisir des Standards Ouverts et appropriés, la BSA s'oppose clairement à ces décisions, qui devraient exclusivement être basées «&#160;sur le mérite&#160;».</p>
<blockquote>
<p>&#160;«Quatrièmement, le <span style="background:#1e90ff">brouillon de l'EIFv2.0 suggère à tort</span> que la convergence vers un unique ensemble de normes profite davantage aux autorités publiques qu'une utilisation de normes multiples se concurrençant l'une l'autre.
<span style="background:#1e90ff">En effet, le document conclut que l'utilisation de normes équivalentes et multiples pourrait mener à un manque d'interopérabilité. La convergence vers un ensemble unique de normes est, dans la plupart des cas, une approche très risquée</span> car il est impossible de prédire l'impact qu'une solution spécifique aura sur le marché.&#160;»</p>
</blockquote>
</div>
<div class="colonne">
<h3>C. Le document de l'EIFv2 non définitif (fuite)</h3>
<blockquote>
<p>&#160;«<span style="background:#ffff00">S'il existe une corrélation entre transparence et interopérabilité</span>, <span style="background:#ffa500">il est également vrai que l'interopérabilité peut être obtenue sans transparence, par exemple grâce à <strong>l'homogénéité</strong> des systèmes informatiques, ce qui implique que tous les partenaires utilisent et se mettent d'accord sur l'emploi de la même solution pour les services publics européens.</span>&#160;»</p>
</blockquote>
<p>En se référant au «&#160;mécanismes complémentaires&#160;» décrits par la BSA, le document qui a fui explique que l'interopérabilité peut aussi être obtenue sans normes, par exemple si tout le monde utilise la même solution propriétaire.</p>
</div>
<div class="nettoyeur"></div>
</div>
<p><strong>Conclusion&#160;:</strong> Le document de travail original défendait les normes comme élément fondamental de l'interopérabilité et requérait que le cadre définisse les lignes de conduite qui favoriseraient l'utilisation des normes et, ce faisant, permettrait l'interopérabilité des systèmes. En conséquence, il y aurait eu une forte préférence vis-à-vis des Standards Ouverts. Cependant, la version du document qui a fui, absorbant les recommandations du BSA, minimise l'importance des normes. En outre, elle suggère que tous les états «&#160;se mettent d'accord sur l'emploi de la même solution pour les services publics européens.&#160;»</p>
<p>Cela entraverait la concurrence et renforcerait le statu quo en faveur du modèle économique des solutions propriétaires.</p>
<h2 id="two">2. «&#160;Éradiquer l'utilisation de standards propriétaires&#160;»</h2>
<div class="frame">
<div class="colonne">
<h3>A. Document de consultation de l'EIFv2</h3>
<blockquote>
<p>«&#160;Les administrations publiques et les institutions européennes comme la Commission européenne devraient <span style="background:#90ee90">promouvoir activement les efforts envers l'éradication des standards et des solutions propriétaires</span> au sein des administrations publiques, en participant aux efforts de normalisation, particulièrement par la formulation et la communication des besoins et des nécessités, en accord avec la nouvelle approche.&#160;»</p>
<p>«&#160;rendre l'accès aux services publiques aussi abordable que possible.&#160;»</p>
<p>«&#160;Les administrations doivent faire en sorte que <span
style="background:#ffc0cb">les solutions et/ou les produits soient choisis par un processus dans lequel la concurrence entre les fournisseurs est juste. [...] sans les enfermer</span> et contraindre leurs choix ultérieurs.&#160;»</p>
<p>«&#160;Cette section préconise une <span
style="background:#90ee90">migration systématique vers l'utilisation des normes ouvertes</span> ou des spécifications techniques [...] qui garantissent l'interopérabilité, facilitent la réutilisation ultérieure à long terme tout en minimisant les contraintes. Après avoir précisé la définition des normes et standards ouverts ou des spécifications techniques, cette section aborde la sélection des normes ou spécifications techniques et présente un ensemble de recommandations.&#160;» (p. 51)</p>
<p>«&#160;<span
style="background:#ffc0cb">L'accès aux normes ou spécifications techniques doit être facile et à un coût raisonnable, sans barrières relatives à leur implémentations</span> de telle sorte qu'une grande variété de produits puissent être disponibles sur le marché&#160;;&#160;»</p>
</blockquote>
<p>Ces extraits mettent en lumière l'intention originale du cadre d'interopérabilité. En plus de promouvoir les normes, préférer les normes ouvertes aux standards propriétaires est perçu comme le meilleur moyen de garantir que l'interopérabilité soit un succès et contribue à la concurrence. <a href="#not1" id="anc1">[1]</a></p>
<blockquote>
<p>«&#160;considérant une norme ouverte selon la définition de l'EIF version 1&#160;:</p>
<ol>
<li>La norme ouverte sera adoptée et sera maintenue par une organisation sans but lucratif, et son développement se fera sur la base d'une <span
style="background:#ffc0cb">procédure de décision ouverte à toutes les parties intéressées (par consensus ou par voie de majorité, etc.)</span>.</li>
<li>La norme ouverte sera publiée et le document de spécifications sera disponible soit <span
style="background:#ffc0cb">gratuitement ou contre une redevance nominale. Il doit être permis de le copier, le distribuer et l'utiliser gratuitement ou en échange d'une redevance nominale</span>.</li>
<li>La propriété intellectuelle par exemple <span
style="background:#ffc0cb">la possible présence de brevets de la norme ouverte sera irrévocablement rendue disponible et libre de droits</span>.</li>
<li>Il n'y a <span
style="background:#ffc0cb">aucune contraite sur la réutilisation</span> de la norme.&#160;»</li>
</ol>
</blockquote>
<p>Cette définition d'une norme ouverte a déjà été approuvée avec la première version du Cadre européen d'interopérabilité (EIF).</p>
</div>
<div class="colonne">
<h3>B. Commentaires de la BSA</h3>
<blockquote>
<p>"Deuxièmement, l'EIF v2.0 ainsi que le CAMSS <span
style="background:#ffc0cb">ne devraient pas définir les normes ouvertes
</span>, ou devraient admettre une définition plus consistante avec
l'utilisation commune du terme [...] «&#160;ouvert&#160;»&#160;:</p>
<p>(1) la spécification est disponible publiquement <span
style="background:#ffc0cb">sans coût ou en échange d'une redevance
raisonnable</span> pour n'importe quelle [FIXME: interested party]</p>
</blockquote>
<p>Ce point équivaut au deuxième critère de la définition de l'EIFv1. Cependant,
il y a des différences substantielles. Alors que l'EIFv1 arguait en faveur de
conditions «&#160;libre de droit ou moyennant une redevance nominale&#160;», la
BSA défend des conditions «&#160;en échange d'une redevance raisonnable&#160;»,
ce qui a pour conséquence d'exclure les Logiciels Libres d'utiliser ces normes.
&#160;Raisonnable&#160;» fait référence aux termes RAND, <em>Reasonable and
Non-Discriminatory</em>, qui en fait ne sont pas raisonnables pour le Logiciel
Libre. En effet, avec de tels termes, la personne qui implémente la norme doit
habituellement payer l'ayant-droit une redevance <strong>par copie</strong> de
logiciel distribué. Cela est incompatible avec la plupart des licences de
Logiciel Libre, qui interdisent de telles restrictions à la distribution. <a
href="#not2" id="anc2">[2]</a></p>
<blockquote>
<p>(2) n'importe quel droit sur un brevet nécessaire à l'implémentation
du standard est mis à disposition de tous les participants à des
conditions <span style="background:#ffc0cb">raisonnable et
non-discriminante (RAND), avec ou sans le payement d'une charge
raisonnable ou d'une redevance</span>; et</p>
</blockquote>
<p>La définition de l'EIFv1 requiert que les ayant-droit d'un brevet mettent à
disposition irrévocablement leurs droits sans charges. Ceci allait clairement a
l'opposé de cette affirmation de la BSA.</p>
<blockquote>
<p>(3) la spécification doit être suffisamment détaillée pour permettre
une compréhension totale de son spectre d'application et de son but et
permettre des implémentations concurrentes par des fournisseurs
multiples.</p>
</blockquote>
</div>
<div class="colonne">
<h3>C. Le document de l'EIFv2 divulgué sans publication</h3>
<blockquote>
<p>«&#160;<span style="background:#90ee90">Il appartient aux créateurs d'une spécification particulière de décider du degré d'ouverte qu'ils souhaitent pour leur spécification.</span>&#160;»</p>
<p>«&#160;Si le principe d'ouverture s'applique en entier&#160;:</p>
<ul>
<li><span style="background:#ffc0cb">Tous les participants
peuvent contribuer à l'élaboration d'une spécification et une
revue publique est organisée</span>&#160;;</li>
<li>Le document de spécification est disponible librement à tous
pour être étudié et partagé avec d'autres&#160;;</li>
<li>La spécification peut être implémentée selon les approches
de développement du logiciel différentes [19].</li>
</ul>
<p>[19] Par exemple utilisant des technologies Open Source ou
propriétaire. Il s'agit aussi de permettre aux fournisseurs de pourvoir
selon divers modèles économiques, des technologies et services basé sur
de telle sorte de spécifications.&#160;»</p>
</blockquote>
<p>La définition des Normes Ouvertes de la première version de l'EIF qui était
présente dans le document de consultation indiquait aussi que «&#160;les
administrations publiques en Europe [...] doivent activement soutenir les
efforts d'élimination des standards propriétaires&#160;». En réaction aux
commentaires de la BSA, le document [FIXME: fuité] renverse totalement cette
position, notamment avec une description extrêmement vague du «&#160;principe
d'ouverture&#160;» qui peut être appliqué en entier ou non.</p>
</div>
<div class="nettoyeur"></div>
</div>
<h2 id="three">3. The Openness Continuum</h2>
<div class="frame">
<div class="colonne">
<h3>A. Consultation Draft</h3>
<blockquote>
<p>"The difficulty in limiting the selection of standards or
technical specifications only to <span style="background:#d09cf0">the "most
open</span>"<br />
The definition of open standards presented above should be
considered as part of <span style="background:#d09cf0">a broader approach</span>, as openness touches upon
many aspects of the definition, adoption and use of standards or
technical specifications. First of all, openness might address
additional process-related characteristics such as being subject to
a non-discriminatory conformance process.</p>
<p>On the other hand, the characteristics of an open standard or
technical specification, as presented in the previous section,
might be fulfilled by some technical specifications only in part.
It is useful to consider some specific
"shadings" of openness such as
technical specifications that are:</p>
<ul>
<li>"freely available" (meaning that their contents are not
secret),</li>
<li>"available for free" (without charge), or</li>
<li>"free of use restrictions" (i.e., of legal restrictions on
their use).</li>
</ul>
<p>The interest in such additional categorisations is
straightforward: <span style="background:#d09cf0">Open standards or technical specifications are
preferred (for all the reasons given above), but if there is no
suitable, feasible open standard or technical specification, one
can investigate some of the "less
open" alternatives</span>. Whereas the goal is to ensure real
and fair competition through the selection of open standards or
technical specification, it is however <span style="background:#d09cf0">difficult at this time to
limit the selection of standards or technical specifications only
to the "most open"</span> as prevailing
conditions must be taken into account, including the current market
conditions.</p>
<p>However, <span style="background:#d09cf0">such choices must be revisited on a regular basis in
order to ensure that a systematic migration towards the use of open
standards</span> or technical specifications takes place, as quickly as is
practical."</p>
</blockquote>
</div>
<div class="colonne">
<h3>B. BSA</h3>
<blockquote>
<p>"In defining openness in a manner that is inconsistent with
common industry practice, the EIF v2.0 excludes many <span style="background:#d09cf0">leading
standards</span> widely recognised as open from its scope
including such well-known standards as DVB,
GSM and MP3. (We have attached a list of excluded standards to our
comments at Appendix A). If Member States implement this
definition, they will effectively be restricted from utilizing a
wide range of <span style="background:#d09cf0">leading technologies that implement these popular
standards</span>. This would represent a dramatic shift at national level,
given that virtually every single Member State now has policies
that are far more flexible. "</p>
</blockquote>
<p>Against Open Standards and specifications, the BSA promotes "leading or popular standards." It seems difficult to have any relevant guideline or definition about what makes a "leading standard." Moreover, there are no connections in terms of interoperability and competition.</p>
</div>
<div class="colonne">
<h3>C. Leaked Draft</h3>
<blockquote>
<p>"Specifications, software and software development methods that
promote collaboration and the results of which can freely be
accessed, reused and shared are considered open and lie at one end
of the spectrum while <span style="background:#d09cf0">non-documented, proprietary specifications,
proprietary software and the reluctance or resistance to reuse
solutions, i.e. the "not invented here" syndrome, lie at the other
end</span>.</p>
<p>The spectrum of approaches that lies between these two extremes
can be called the openness continuum."</p>
</blockquote>
<p> The consultation document already included the idea of an "openness continuum". This continuum, however, only covered a range from "open" to "most open". In the leaked draft, the continuum suddenly includes proprietary standards and specifications.
</p>
<blockquote>
<p>"Within the context of the EIF, openness is the willingness of
persons, organisations or other members of a community of interest
to share knowledge and to stimulate debate within that community of
interest, having as ultimate goal the advancement of knowledge and
the use thereof to solve relevant problems. In that sense, openness
leads to considerable gains in efficiency."</p>
</blockquote>
</div>
<div class="nettoyeur"></div>
</div>
<p><strong>Conclusion:</strong> Based on the above analysis, we can only conclude that the European Commission is giving strong preference to the viewpoint of a single lobby group. Regarding interoperability and open standards, key places of the consultation document were modified to comply with the demands of the BSA. Input given by other groups was not considered on this issue. Beyond ignoring this input, the Commission has apparently decided to ignore the success of the first version of the EIF, and to abandon its efforts towards actually achieving interoperability in eGovernment services.
</p>
<hr />
<p><a id="not1" href="#anc1">[1]</a>. This is a stark contrast with the European Commission's policy on this subject. See <a href="http://europa.eu/rapid/pressReleasesAction.do?reference=SPEECH/08/317&amp;format=HTML&amp;aged=0&amp;language=EN&amp;guiLanguage=en">this speech by European Commissioner for Competition, Ms. Neelie Kroes</a>:</p>
<blockquote>“I know a smart business decision when I see one - choosing open standards is a very smart business decision indeed.”</blockquote>
<p><a id="not2" href="#anc2">[2]</a>. Indeed, instead of the vague notion of "reasonable fee," a nominal fee permits Free Software projects to implement standards. See as a similar case the <a href="http://www.samba.org/samba/PFIF/">agreement between Samba and Microsoft</a>.
</p>
</body>
<translator>Nicolas JEAN, Hugo Roy, Jil Larner (Mont Blanc, France)</translator>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->