Source files of,,,,, and Contribute:
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

eifv2-01.en.xhtml 20KB

  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <html>
  3. <head>
  4. <meta name="author-name-1" content="Hugo Roy" />
  5. <meta name="author-link-1" content="/about/roy/roy.html" />
  6. <meta name="publication-date" content="2009" />
  7. <title>FSFE - EIFv2: Tracking the loss of interoperability</title>
  8. <style type="text/css">
  9. .colonne {
  10. margin-top:20px;
  11. font-size:0.9em;
  12. max-width:30%;
  13. min-width:25%;
  14. border:0;
  15. float:left;
  16. padding:0px 10px;
  17. }
  18. .nettoyeur { clear: both; height: 0; margin: 0; padding: 0; border: 0; line-height: 1px; font-size: 1px; }
  19. .frame {
  20. min-width:800px;
  21. overflow-x:scroll;
  22. }
  23. </style>
  24. </head>
  25. <body>
  26. <p align="right">[ <a href="eifv2.en.pdf">PDF version (76k)</a> <em>Outdated</em> ]</p>
  27. <h1 align="center">EIFv2: Tracking the loss of interoperability</h1>
  28. <p class="indent"><em>This document provides a comparative analysis of the
  29. evolution of the European Interoperability Framework. Based on <a
  30. href="">consultations</a> submitted on
  31. <a href="">the second version of the
  32. European Interoperability Framework</a> (EIF version 2), it emphasizes the different
  33. transformations the draft has undergone from <a
  34. href="">the original draft</a> on
  35. which a public consultation was held in the summer of 2008, to <a
  36. href="">the
  37. leaked draft</a>.
  38. </em></p>
  39. <p>Table of Contents</p>
  40. <ul>
  41. <li><a href="#about">What is the European Interoperability Framework?</a></li>
  42. <li><a href="#one">1. Standards are key to interoperability</a></li>
  43. <li><a href="#two">2. Eliminating the use of proprietary standards</a></li>
  44. <li><a href="#three">3. The Openness Continuum</a></li>
  45. </ul>
  46. <h2 id="about">What is the European Interoperability Framework?</h2>
  47. <blockquote>
  48. <p>The EIF is a set of interoperability guidelines documents and initiatives conducted under the auspices of the IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens) Programme. The EIF supplements the various National Interoperability Frameworks in the pan-European dimension.</p>
  49. </blockquote>
  50. <p><em><a href="">From the Consultation Draft, Section 2/3.</a></em></p>
  51. <p>The analysis below highlights some changes the draft has undergone between the public consultation in the summer of 2008 and the draft which leaked in November 2009. During the public consultation, numerous groups and individuals submitted <a href="">comments</a>. From our analysis, we can conclude that in key places, the European Commission has taken on board only the comments <a href="">made</a> by the <a href="">Business Software Alliance</a>, a lobby group working on behalf of proprietary software vendors. At the same time, comments by groups working in favour of Free Software and Open Standards were neglected, e.g. those made by <a href="">Open Forum Europe</a>.
  52. </p>
  53. <h2 id="one">1. “Standards are key to interoperability”</h2>
  54. <div class="frame">
  55. <div class="colonne">
  56. <h3>A. EIFv2 Consultation Draft</h3>
  57. <blockquote>
  58. <p>"<span style="background:#ffff00">Standards are key to
  59. interoperability.</span> In the EU strategy for Growth and Jobs,
  60. strong and dynamic standardisation has been identified as one of
  61. the key instruments to foster innovation. Standardisation has a
  62. dimension of public interest, in particular whenever issues of
  63. safety, health, environment and performance are at stake." (p.35)</p>
  64. <p>"The role of national administrations in this process is to
  65. <span style="background:#1e90ff">choose the appropriate
  66. standard</span>"</p>
  67. </blockquote>
  68. <p>The Consultation Draft highlights the fact that standards are among the best tools to achieve interoperability without harming competition or innovation. Besides, it refers to "appropriate standard," which means that if several standards exist for the same purpose, then a choice should be made. This choice, as later explained, should give a preference to Open Standards.</p>
  69. </div>
  70. <div class="colonne">
  71. <h3>B. The Business Software Alliance's comments</h3>
  72. <blockquote>
  73. <p>"<span style="background:#ffff00">while open standards are
  74. critical to achieving interoperability</span>, <span style="background:#ffa500">often a number of complementary mechanisms
  75. work together to achieve the overall interoperability
  76. goal.</span>"</p>
  77. </blockquote>
  78. <p>In this sentence, BSA refers explicitly to Open Standards while the assessment that is made suggests that standards themselves are not a key to interoperability.</p>
  79. <blockquote>
  80. <p>"Finally, the EIFv2.0 should refrain from recommending that
  81. procurement be used to promote open standards. Instead, the EIF
  82. v2.0 should endorse applicable principles and rules as expressed in
  83. Directives 2004/18 and 98/34, and should encourage Member States to
  84. make procurement decisions on the merits."</p>
  85. </blockquote>
  86. <p>While the Consultation Draft argued that national administrations' role is to choose appropriate and Open Standards, the BSA clearly advocates against such decisions, which should be based exclusively "on the merits."</p>
  87. <blockquote>
  88. <p>"Fourth, the <span style="background:#1e90ff">draft EIFv2.0
  89. mistakenly suggests</span> that convergence toward a single set of
  90. standards is better for public authorities than the use of
  91. multiple, competing standards.
  92. <span style="background:#1e90ff">Indeed, the draft concludes that the use of
  93. multiple, equivalent standards may lead to a lack of
  94. interoperability. Converging toward a single set of standards is,
  95. in most cases, a highly risky approach</span>. Because it is
  96. impossible to predict how any specific solution will fare in the
  97. marketplace "</p>
  98. </blockquote>
  99. </div>
  100. <div class="colonne">
  101. <h3>C. EIFv2 Leaked Draft</h3>
  102. <blockquote>
  103. <p>"<span style="background:#ffff00">While there is a correlation
  104. between openness and interoperability</span>, <span style="background:#ffa500">it is also true that interoperability can be
  105. obtained without openness, for example via
  106. <strong>homogeneity</strong> of the ICT systems, which implies that
  107. all partners use, or agree to use, the same solution to implement a
  108. European Public Service.</span>"</p>
  109. </blockquote>
  110. <p>Referring to BSA's "complementary mechanisms," the leaked draft argues that interoperability can also be achieved without standards, e.g. if everyone uses the same proprietary solution.</p>
  111. </div>
  112. <div class="nettoyeur"></div>
  113. </div>
  114. <p><strong>Conclusion:</strong> The original draft argued that standards are a crucial component of interoperability, and that the framework must provide guidelines to promote those standards that are the most likely to achieve interoperability. This resulted in a strong preference for Open Standards. However, the leaked draft, following recommendations from the BSA, undermines the importance of standards. On the other hand, it suggests that all concerned "agree to use the same solution to implement a European Public Service."</p>
  115. <p>This will hinder competition and strengthen the status quo in favour of proprietary business models.</p>
  116. <h2 id="two">2. “Eliminating the use of proprietary standards”</h2>
  117. <div class="frame">
  118. <div class="colonne">
  119. <h3>A. EIFv2 Consultation Draft</h3>
  120. <blockquote>
  121. <p>"Public administrations and European Institutions such as the
  122. European Commission should actively <span
  123. style="background:#90ee90">support efforts at eliminating the use of
  124. proprietary standards</span> and solutions within public administrations
  125. by actively supporting and participating in standardization efforts,
  126. particularly by formulating and communicating needs and requirements,
  127. according to the new approach."</p>
  128. <p>"make access to public services as affordable as possible."</p>
  129. <p>"Administrations should ensure that <span
  130. style="background:#ffc0cb">solutions and/or products
  131. are chosen via a process in which competition between vendors is
  132. fair. [...] do not lock them in</span> as regards future choices."</p>
  133. <p>"This section advocates a <span
  134. style="background:#90ee90">systematic migration towards the use
  135. of open standards</span> or technical specifications [...] to guarantee
  136. interoperability, to facilitate future reuse and long-term
  137. sustainability while minimizing constraints. After contextualising
  138. the definition of open standards or technical specifications, this
  139. section addresses the assessment and selection of standards or
  140. technical specifications and finally presents a set of
  141. recommendations. (p 51)"</p>
  142. <p>"<span
  143. style="background:#ffc0cb">Access to the standards or technical specifications has to be
  144. inexpensive and easy and there should be no (cost) barriers related
  145. to their implementation</span> so that a wide variety of products will be
  146. available on the market;"</p>
  147. </blockquote>
  148. <p>These extracts shows the original intention of the Framework. Besides promoting standards, choosing Open Standards instead of proprietary ones was regarded as the best way to ensure interoperability's success along with economic competition. <a href="#not1" id="anc1">[1]</a></p>
  149. <blockquote>
  150. <p>"considered an open standard under the EIF v1 definition:</p>
  151. <ol>
  152. <li>The open standard is adopted and will be maintained by a
  153. not-for-profit organisation, and its ongoing development occurs on
  154. the basis of an <span
  155. style="background:#ffc0cb">open decision-making procedure available to all
  156. interested parties (consensus or majority decision etc.)</span>.</li>
  157. <li>The open standard has been published and the standard
  158. specification document is available either <span
  159. style="background:#ffc0cb">freely or at a nominal
  160. charge. It must be permissible to all to copy, distribute and use
  161. it for no fee or at a nominal fee</span>.</li>
  162. <li>The intellectual property - i.e. <span
  163. style="background:#ffc0cb">patents possibly present - of
  164. (parts of) the open standard is made irrevocably available on a
  165. royalty free basis</span>.</li>
  166. <li>There are <span
  167. style="background:#ffc0cb">no constraints on the re-use</span> of the standard."</li>
  168. </ol>
  169. </blockquote>
  170. <p>This definition of an open standard was already approved in the first version of the European Interoperability Framework.</p>
  171. </div>
  172. <div class="colonne">
  173. <h3>B. The BSA's comments</h3>
  174. <blockquote>
  175. <p>"Second, both the EIF v2.0 and CAMSS <span
  176. style="background:#ffc0cb">should either not define
  177. open standards</span>, or should endorse a definition that is consistent
  178. with common usage of the term. (...)
  179. "open":</p>
  180. <p>(1) the specification is publicly available <span
  181. style="background:#ffc0cb">without cost or for
  182. a reasonable fee</span> to any interested party;</p>
  183. </blockquote>
  184. <p>This point is an equivalent of EIFv1 definition's 2nd criterion. However, there are substantial differences. While the EIFv1 advocated "free of charge or at a nominal fee," the BSA argues for "a reasonable fee," which implies that Free Software is prevented from making use of those standards. ("Reasonable" refers to so-called "Reasonable and Non-Discriminatory" terms, which are in fact neither reasonable nor non-discriminatory from the point of view of Free Software. Under such terms, the person implementing the standard usually has to pay the rightsholder a royalty <strong>per copy</strong> of the software which is distributed. This clashes with most common Free Software licenses, which forbid restrictions on distribution. <a href="#not2" id="anc2">[2]</a></p>
  185. <blockquote>
  186. <p>(2) any patent rights necessary to implement the standard are
  187. available to all implementers on <span
  188. style="background:#ffc0cb">RAND terms, either with or without
  189. payment of a reasonable royalty or fee</span>; and</p>
  190. </blockquote>
  191. <p>The EIFv1's definition required that patent rights made were irrevocably available for use without royalties. This is clearly against BSA's statement.</p>
  192. <blockquote>
  193. <p>(3) the specification should be in sufficient detail to enable a
  194. complete understanding of its scope and purpose and to enable
  195. competing implementations by multiple vendors.</p>
  196. </blockquote>
  197. </div>
  198. <div class="colonne">
  199. <h3>C. EIFv2 Leaked Draft</h3>
  200. <blockquote>
  201. <p>"<span style="background:#90ee90">It is up to the creators of any
  202. particular specification to decide how open they want their
  203. specification to be</span>."</p>
  204. <p>"If the principle of openness is applied in full:</p>
  205. <ul>
  206. <li><span
  207. style="background:#ffc0cb">All stakeholders can contribute to the elaboration of the
  208. specification and public review is organised</span>;</li>
  209. <li>The specification document is freely available for everybody to
  210. study and to share with others;</li>
  211. <li>The specification can be implemented under the different
  212. software development approaches19.</li>
  213. </ul>
  214. <p>[19] For example using Open Source or proprietary software and
  215. technologies. This also allows providers under various business
  216. models to deliver products, technologies and services based on such
  217. kind of formalised specifications."</p>
  218. </blockquote>
  219. <p>The definition of Open Standards from the first version of the EIF was present in the consultation document, which also said that "[p]ublic administrations in Europe [...] should actively support efforts at eliminating proprietary standards". In reaction to the BSA's comments, the leaked draft totally reverses that position, offering only an extremely vague description of a "principle of openness", which can either be applied in full or not.</p>
  220. </div>
  221. <div class="nettoyeur"></div>
  222. </div>
  223. <h2 id="three">3. The Openness Continuum</h2>
  224. <div class="frame">
  225. <div class="colonne">
  226. <h3>A. Consultation Draft</h3>
  227. <blockquote>
  228. <p>"The difficulty in limiting the selection of standards or
  229. technical specifications only to <span style="background:#d09cf0">the "most
  230. open</span>"<br />
  231. The definition of open standards presented above should be
  232. considered as part of <span style="background:#d09cf0">a broader approach</span>, as openness touches upon
  233. many aspects of the definition, adoption and use of standards or
  234. technical specifications. First of all, openness might address
  235. additional process-related characteristics such as being subject to
  236. a non-discriminatory conformance process.</p>
  237. <p>On the other hand, the characteristics of an open standard or
  238. technical specification, as presented in the previous section,
  239. might be fulfilled by some technical specifications only in part.
  240. It is useful to consider some specific
  241. "shadings" of openness such as
  242. technical specifications that are:</p>
  243. <ul>
  244. <li>"freely available" (meaning that their contents are not
  245. secret),</li>
  246. <li>"available for free" (without charge), or</li>
  247. <li>"free of use restrictions" (i.e., of legal restrictions on
  248. their use).</li>
  249. </ul>
  250. <p>The interest in such additional categorisations is
  251. straightforward: <span style="background:#d09cf0">Open standards or technical specifications are
  252. preferred (for all the reasons given above), but if there is no
  253. suitable, feasible open standard or technical specification, one
  254. can investigate some of the "less
  255. open" alternatives</span>. Whereas the goal is to ensure real
  256. and fair competition through the selection of open standards or
  257. technical specification, it is however <span style="background:#d09cf0">difficult at this time to
  258. limit the selection of standards or technical specifications only
  259. to the "most open"</span> as prevailing
  260. conditions must be taken into account, including the current market
  261. conditions.</p>
  262. <p>However, <span style="background:#d09cf0">such choices must be revisited on a regular basis in
  263. order to ensure that a systematic migration towards the use of open
  264. standards</span> or technical specifications takes place, as quickly as is
  265. practical."</p>
  266. </blockquote>
  267. </div>
  268. <div class="colonne">
  269. <h3>B. BSA</h3>
  270. <blockquote>
  271. <p>"In defining openness in a manner that is inconsistent with
  272. common industry practice, the EIF v2.0 excludes many <span style="background:#d09cf0">leading
  273. standards</span> widely recognised as open from its scope
  274. including such well-known standards as DVB,
  275. GSM and MP3. (We have attached a list of excluded standards to our
  276. comments at Appendix A). If Member States implement this
  277. definition, they will effectively be restricted from utilizing a
  278. wide range of <span style="background:#d09cf0">leading technologies that implement these popular
  279. standards</span>. This would represent a dramatic shift at national level,
  280. given that virtually every single Member State now has policies
  281. that are far more flexible. "</p>
  282. </blockquote>
  283. <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>
  284. </div>
  285. <div class="colonne">
  286. <h3>C. Leaked Draft</h3>
  287. <blockquote>
  288. <p>"Specifications, software and software development methods that
  289. promote collaboration and the results of which can freely be
  290. accessed, reused and shared are considered open and lie at one end
  291. of the spectrum while <span style="background:#d09cf0">non-documented, proprietary specifications,
  292. proprietary software and the reluctance or resistance to reuse
  293. solutions, i.e. the "not invented here" syndrome, lie at the other
  294. end</span>.</p>
  295. <p>The spectrum of approaches that lies between these two extremes
  296. can be called the openness continuum."</p>
  297. </blockquote>
  298. <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.
  299. </p>
  300. <blockquote>
  301. <p>"Within the context of the EIF, openness is the willingness of
  302. persons, organisations or other members of a community of interest
  303. to share knowledge and to stimulate debate within that community of
  304. interest, having as ultimate goal the advancement of knowledge and
  305. the use thereof to solve relevant problems. In that sense, openness
  306. leads to considerable gains in efficiency."</p>
  307. </blockquote>
  308. </div>
  309. <div class="nettoyeur"></div>
  310. </div>
  311. <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.
  312. </p>
  313. <hr />
  314. <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=";format=HTML&amp;aged=0&amp;language=EN&amp;guiLanguage=en">this speech by European Commissioner for Competition, Ms. Neelie Kroes</a>:</p>
  315. <blockquote>“I know a smart business decision when I see one - choosing open standards is a very smart business decision indeed.”</blockquote>
  316. <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="">agreement between Samba and Microsoft</a>.
  317. </p>
  318. </body>
  319. <timestamp>$Date: 2010-02-04 14:44:12 +0100 (jeu. 04 févr. 2010) $ $Author: hugo $</timestamp>
  320. </html>
  321. <!--
  322. Local Variables: ***
  323. mode: xml ***
  324. End: ***
  325. -->