Source files of fsfe.org, pdfreaders.org, freeyourandroid.org, ilovefs.org, drm.info, and test.fsfe.org. Contribute: https://fsfe.org/contribute/web/ https://fsfe.org
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.

644 lines
28KB

  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <html>
  3. <version>1</version>
  4. <head>
  5. <title>FSFE - EIFv2: Tracking the loss of interoperability</title>
  6. </head>
  7. <body class="full-width" id="eifv2-track">
  8. <p id="category"><a href="/activities/os/os.html">Open Standards</a></p>
  9. <h1>EIFv2: Tracking the loss of interoperability</h1>
  10. <div id="introduction">
  11. <p>This document provides a comparative analysis of the evolution of the
  12. European Interoperability Framework. Based on <a
  13. href="http://ec.europa.eu/idabc/en/document/7732">consultations</a>
  14. submitted on <a href="http://ec.europa.eu/idabc/en/document/7733">the
  15. second version of the European Interoperability Framework</a> (EIF version
  16. 2), it emphasizes the different transformations the draft has undergone
  17. since 2008.</p>
  18. </div>
  19. <p>From our analysis, we can conclude that in key places, the European
  20. Commission has taken on board only the comments <a
  21. href="http://ec.europa.eu/idabc/servlets/Doc?id=31903">made</a> by the <a
  22. href="http://www.bsa.org">Business Software Alliance</a>, a lobby group
  23. working on behalf of proprietary software vendors. At the same time,
  24. comments by groups working in favour of Free Software and Open Standards
  25. were neglected, e.g. those made by <a
  26. href="http://openforumeurope.org/">Open Forum Europe</a>. </p>
  27. <p>Looking back to the consultation draft, it is obvious that during the
  28. development of EIFv2, the European Commission has abandoned the concept of
  29. Open Standards as a key enabler for interoperability. This is a central
  30. reason why the current draft would see the European Interoperability
  31. Framework become a shadow of its former self.</p>
  32. <p>Table of Contents</p>
  33. <ul>
  34. <li><a href="#about">What is the European Interoperability Framework?</a></li>
  35. <li><a href="#one">1. Standards are key to interoperability</a></li>
  36. <li><a href="#two">2. Eliminating the use of proprietary standards</a></li>
  37. <li><a href="#three">3. The Openness Continuum</a></li>
  38. </ul>
  39. <h2 id="about">What is the European Interoperability Framework?</h2>
  40. <p>The EIF is a set of interoperability guidelines documents and initiatives
  41. conducted under the auspices of the ISA (Interoperability Solutions for
  42. European Public Administrations) programme. The EIF supplements the various
  43. National Interoperability Frameworks in the pan-European dimension.</p>
  44. <ul>
  45. <li>November 2004: <a href="http://ec.europa.eu/idabc/en/document/3473/5585#finalEIF">European Interoperability Framework (EIF) version 1</a></li>
  46. <li>July 2008: EIF version 2, <a href="http://ec.europa.eu/idabc/servlets/Doc?id=31597">draft for consultation</a> (<a href="http://ec.europa.eu/idabc/en/document/7732">comments</a>)</li>
  47. <li>November 2009: EIF version 2, <a href="http://blog.webwereld.nl/wp-content/uploads/2009/11/European-Interoperability-Framework-for-European-Public-Services-draft.pdf">leaked draft</a></li>
  48. <li>March 2010: EIF version 2, <a href="#">leaked draft (release candidate)</a>
  49. <p>If there are any improvements to be found over the November 2009
  50. draft, they are cosmetic at best. Between then and now, the European
  51. Commission has merely removed the formulations that attracted the most
  52. criticism.</p>
  53. </li>
  54. </ul>
  55. <h2 id="one">1. “Standards are key to interoperability”</h2>
  56. <div class="compare">
  57. <div class="clear">
  58. <div class="grid-50 left">
  59. <h3>A. EIFv2 Consultation Draft</h3>
  60. <blockquote>
  61. <p>"<span style="background:#ffff00">Standards are key to
  62. interoperability.</span> In the EU strategy for Growth and Jobs,
  63. strong and dynamic standardisation has been identified as one of
  64. the key instruments to foster innovation. Standardisation has a
  65. dimension of public interest, in particular whenever issues of
  66. safety, health, environment and performance are at stake." (p.35)</p>
  67. <p>"The role of national administrations in this process is to
  68. <span style="background:#1e90ff">choose the appropriate
  69. standard</span>"</p>
  70. </blockquote>
  71. <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>
  72. </div>
  73. <div class="grid-50 left">
  74. <h3>B. The Business Software Alliance's comments</h3>
  75. <blockquote>
  76. <p>"<span style="background:#ffff00">while open standards are
  77. critical to achieving interoperability</span>, <span style="background:#ffa500">often a number of complementary mechanisms
  78. work together to achieve the overall interoperability
  79. goal.</span>"</p>
  80. </blockquote>
  81. <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>
  82. <blockquote>
  83. <p>"Finally, the EIFv2.0 should refrain from recommending that
  84. procurement be used to promote open standards. Instead, the EIF
  85. v2.0 should endorse applicable principles and rules as expressed in
  86. Directives 2004/18 and 98/34, and should encourage Member States to
  87. make procurement decisions on the merits."</p>
  88. </blockquote>
  89. <p>While the Consultation Draft argued that national administrations' role is
  90. to choose appropriate and Open Standards, the BSA clearly advocates against such decisions,
  91. which should be based exclusively "on the merits."</p>
  92. <blockquote>
  93. <p>"Fourth, the <span style="background:#1e90ff">draft EIFv2.0
  94. mistakenly suggests</span> that convergence toward a single set of
  95. standards is better for public authorities than the use of
  96. multiple, competing standards.
  97. <span style="background:#1e90ff">Indeed, the draft concludes that the use of
  98. multiple, equivalent standards may lead to a lack of
  99. interoperability. Converging toward a single set of standards is,
  100. in most cases, a highly risky approach</span>. Because it is
  101. impossible to predict how any specific solution will fare in the
  102. marketplace "</p>
  103. </blockquote>
  104. </div>
  105. </div>
  106. <div class="clear">
  107. <div class="grid-50 left">
  108. <h3>C. EIFv2 Leaked Draft 11/2009</h3>
  109. <blockquote>
  110. <p>"<span style="background:#ffff00">While there is a correlation
  111. between openness and interoperability</span>, <span style="background:#ffa500">it is also true that interoperability can be
  112. obtained without openness, for example via
  113. <strong>homogeneity</strong> of the ICT systems, which implies that
  114. all partners use, or agree to use, the same solution to implement a
  115. European Public Service.</span>"</p>
  116. </blockquote>
  117. <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>
  118. </div>
  119. <div class="grid-50 left">
  120. <h3>D. EIFv2 Leaked Draft 03/2010</h3>
  121. <blockquote>
  122. <p>Therefore, European public administrations should strive towards
  123. openness taking into account needs, priorities, legacy, budget, market
  124. situation and a number of other factors.</p>
  125. </blockquote>
  126. <p>The unfortunate reference to homogeneity has been dropped out, in favour of openness.</p>
  127. <p>This part has become even less meaningful than
  128. the draft from November 2009. Given the vendor lock-in which proprietary
  129. software and standards produce, the language in this section does not
  130. provide any reasons for public administrations to consider moving to
  131. Open Standards, let alone actually make the switch.</p>
  132. </div>
  133. </div><!--end .clear-->
  134. <hr />
  135. <p>The current draft says that in making their decision about whether to use
  136. Open Standards, public bodies should consider "priorities, legacy, budget,
  137. market situation" and other factors. This non-conclusive lists is easy to
  138. decrypt:</p>
  139. <ul>
  140. <li><p>Like any strategic consideration, looking into Open Standards does
  141. often take an initial extra effort. IT is not usually a mission priority
  142. in public administrations. Therefore, explicitely naming "priorities" here
  143. preserves the status quo.</p></li>
  144. <li><p>"Legacy" implies that public administrations should look at the
  145. format of the existing data they have, and consider the cost of switching
  146. to a storage format based on Open Standards. Exit costs from proprietary
  147. solutions can be substantial. But these costs always accrue eventually,
  148. either now (when they can be calculated) or at a later time, when the
  149. public body needs to switch to a new format (whether open or proprietary)
  150. for some reason. In the latter case, the future costs are both higher and
  151. harder to calculate.</p>
  152. <p>The reference to "legacy" therefore asks public bodies to put off the
  153. inevitable exit costs to some distant future day. Organisations following
  154. this advice are in effect skirting their responsibility towards
  155. citizens.</p></li>
  156. <li><p>"market situation" is an invitation to public bodies to prefer the
  157. dominant solution. On the desktop as well as in many other areas, the most
  158. widespread solutions are usually proprietary, thanks to the long-standing
  159. effects of vendor lock-in and the way in which some proprietary companies
  160. have abused their dominant position.</p></li>
  161. </ul>
  162. <p>
  163. With this reference to "market situation", the EC is asking Europe's
  164. public bodies to further entrench current monopolies by choosing solutions
  165. based simply on their market share, rather than on a full assessment of
  166. their capabilities, long-term benefits and sustainability.
  167. </p>
  168. <h2 id="two">2. “Eliminating the use of proprietary standards”</h2>
  169. <div class="clear">
  170. <div class="grid-50 left">
  171. <h3>A. EIFv2 Consultation Draft</h3>
  172. <blockquote>
  173. <p>"Public administrations and European Institutions such as the
  174. European Commission should actively <span
  175. style="background:#90ee90">support efforts at eliminating the use of
  176. proprietary standards</span> and solutions within public administrations
  177. by actively supporting and participating in standardization efforts,
  178. particularly by formulating and communicating needs and requirements,
  179. according to the new approach."</p>
  180. <p>"make access to public services as affordable as possible."</p>
  181. <p>"Administrations should ensure that <span
  182. style="background:#ffc0cb">solutions and/or products
  183. are chosen via a process in which competition between vendors is
  184. fair. [...] do not lock them in</span> as regards future choices."</p>
  185. <p>"This section advocates a <span
  186. style="background:#90ee90">systematic migration towards the use
  187. of open standards</span> or technical specifications [...] to guarantee
  188. interoperability, to facilitate future reuse and long-term
  189. sustainability while minimizing constraints. After contextualising
  190. the definition of open standards or technical specifications, this
  191. section addresses the assessment and selection of standards or
  192. technical specifications and finally presents a set of
  193. recommendations. (p 51)"</p>
  194. <p>"<span
  195. style="background:#ffc0cb">Access to the standards or technical specifications has to be
  196. inexpensive and easy and there should be no (cost) barriers related
  197. to their implementation</span> so that a wide variety of products will be
  198. available on the market;"</p>
  199. </blockquote>
  200. <p>These extracts shows the original intention of the Framework. Besides promoting standards,
  201. choosing Open Standards instead of proprietary ones was regarded as the best way to ensure
  202. interoperability's success along with economic competition. <a href="#not1" id="anc1">[1]</a></p>
  203. <blockquote>
  204. <p>"considered an open standard under the EIF v1 definition:</p>
  205. <ol>
  206. <li>The open standard is adopted and will be maintained by a
  207. not-for-profit organisation, and its ongoing development occurs on
  208. the basis of an <span
  209. style="background:#ffc0cb">open decision-making procedure available to all
  210. interested parties (consensus or majority decision etc.)</span>.</li>
  211. <li>The open standard has been published and the standard
  212. specification document is available either <span
  213. style="background:#ffc0cb">freely or at a nominal
  214. charge. It must be permissible to all to copy, distribute and use
  215. it for no fee or at a nominal fee</span>.</li>
  216. <li>The intellectual property - i.e. <span
  217. style="background:#ffc0cb">patents possibly present - of
  218. (parts of) the open standard is made irrevocably available on a
  219. royalty free basis</span>.</li>
  220. <li>There are <span
  221. style="background:#ffc0cb">no constraints on the re-use</span> of the standard."</li>
  222. </ol>
  223. </blockquote>
  224. <p>This definition of an open standard was already approved in the first version of the European Interoperability Framework.</p>
  225. </div>
  226. <div class="grid-50 left">
  227. <h3>B. The BSA's comments</h3>
  228. <blockquote>
  229. <p>"Second, both the EIF v2.0 and CAMSS <span
  230. style="background:#ffc0cb">should either not define
  231. open standards</span>, or should endorse a definition that is consistent
  232. with common usage of the term. (...)
  233. "open":</p>
  234. <p>(1) the specification is publicly available <span
  235. style="background:#ffc0cb">without cost or for
  236. a reasonable fee</span> to any interested party;</p>
  237. </blockquote>
  238. <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>
  239. <blockquote>
  240. <p>(2) any patent rights necessary to implement the standard are
  241. available to all implementers on <span
  242. style="background:#ffc0cb">RAND terms, either with or without
  243. payment of a reasonable royalty or fee</span>; and</p>
  244. </blockquote>
  245. <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>
  246. <blockquote>
  247. <p>(3) the specification should be in sufficient detail to enable a
  248. complete understanding of its scope and purpose and to enable
  249. competing implementations by multiple vendors.</p>
  250. </blockquote>
  251. </div>
  252. </div><!--end .clear-->
  253. <div class="clear">
  254. <div class="grid-50 left">
  255. <h3>C. EIFv2 Leaked Draft 11/2009</h3>
  256. <blockquote>
  257. <p>"<span style="background:#90ee90">It is up to the creators of any
  258. particular specification to decide how open they want their
  259. specification to be</span>."</p>
  260. <p>"If the principle of openness is applied in full:</p>
  261. <ul>
  262. <li><span
  263. style="background:#ffc0cb">All stakeholders can contribute to the elaboration of the
  264. specification and public review is organised</span>;</li>
  265. <li>The specification document is freely available for everybody to
  266. study and to share with others;</li>
  267. <li>The specification can be implemented under the different
  268. software development approaches19.</li>
  269. </ul>
  270. <p>[19] For example using Open Source or proprietary software and
  271. technologies. This also allows providers under various business
  272. models to deliver products, technologies and services based on such
  273. kind of formalised specifications."</p>
  274. </blockquote>
  275. <p>The definition of Open Standards from the first version of the EIF was present in
  276. the consultation document, which also said that "[p]ublic administrations in Europe [...]
  277. should actively support efforts at eliminating proprietary standards". In reaction to the
  278. BSA's comments, the leaked draft totally reverses that position, offering only an extremely
  279. vague description of a "principle of openness", which can either be applied in full or not.</p>
  280. </div>
  281. <div class="grid-50 left">
  282. <h3>D. EIFv2 Leaked Draft 03/2010</h3>
  283. <blockquote>
  284. <p>The possibility of sharing and re-using components based on formalised specifications depends on the openness of the specifications. If the principle of openness is applied in full:</p>
  285. <ul><li>All stakeholders have the same possibility of contributing to the elaboration of the specification and public review thereof is organised;</li><li>The specification document is freely available for everybody to copy, distribute and use;</li><li>The specification can be freely implemented and shared under different software development approaches (18).</li>
  286. </ul>
  287. <p>[18] For instance, Open Source or proprietary software and technologies. This fosters competition since providers working under various business models may compete to deliver products, technologies and services based on such kind of formalised specifications.</p>
  288. </blockquote>
  289. <p>The current draft does not reflect any improvement over the version of the Document made public on November.</p>
  290. </div>
  291. </div><!--end .clear-->
  292. <hr />
  293. <p>
  294. The 2008 consultation draft spoke of "eliminating the use of proprietary
  295. standards". This provided a clear direction to Member States, showing them
  296. the way to achieve interoperability in their public services
  297. </p>
  298. <p>
  299. At this point, the consultation draft provided a workable definition of
  300. what is considered to be an Open Standard. In the current draft, this
  301. section is stripped down to a factual statement that is so generic as to
  302. be meaningless. This section provides no guidance whatsoever to Member
  303. States.
  304. </p>
  305. <p>
  306. Meanwhile, Free Software ("open source") as a key driver of
  307. interoperability is relegated to a footnote, which is the only occurence
  308. of the term in the entire document. The elimination of Free Software from
  309. the text could not have been more systematic.
  310. </p>
  311. <h2 id="three">3. The Openness Continuum</h2>
  312. <div class="clear">
  313. <div class="grid-50 left">
  314. <h3>A. Consultation Draft</h3>
  315. <blockquote>
  316. <p>"The difficulty in limiting the selection of standards or
  317. technical specifications only to <span style="background:#d09cf0">the "most
  318. open</span>"<br />
  319. The definition of open standards presented above should be
  320. considered as part of <span style="background:#d09cf0">a broader approach</span>, as openness touches upon
  321. many aspects of the definition, adoption and use of standards or
  322. technical specifications. First of all, openness might address
  323. additional process-related characteristics such as being subject to
  324. a non-discriminatory conformance process.</p>
  325. <p>On the other hand, the characteristics of an open standard or
  326. technical specification, as presented in the previous section,
  327. might be fulfilled by some technical specifications only in part.
  328. It is useful to consider some specific
  329. "shadings" of openness such as
  330. technical specifications that are:</p>
  331. <ul>
  332. <li>"freely available" (meaning that their contents are not
  333. secret),</li>
  334. <li>"available for free" (without charge), or</li>
  335. <li>"free of use restrictions" (i.e., of legal restrictions on
  336. their use).</li>
  337. </ul>
  338. <p>The interest in such additional categorisations is
  339. straightforward: <span style="background:#d09cf0">Open standards or technical specifications are
  340. preferred (for all the reasons given above), but if there is no
  341. suitable, feasible open standard or technical specification, one
  342. can investigate some of the "less
  343. open" alternatives</span>. Whereas the goal is to ensure real
  344. and fair competition through the selection of open standards or
  345. technical specification, it is however <span style="background:#d09cf0">difficult at this time to
  346. limit the selection of standards or technical specifications only
  347. to the "most open"</span> as prevailing
  348. conditions must be taken into account, including the current market
  349. conditions.</p>
  350. <p>However, <span style="background:#d09cf0">such choices must be revisited on a regular basis in
  351. order to ensure that a systematic migration towards the use of open
  352. standards</span> or technical specifications takes place, as quickly as is
  353. practical."</p>
  354. </blockquote>
  355. </div>
  356. <div class="grid-50 left">
  357. <h3>B. BSA</h3>
  358. <blockquote>
  359. <p>"In defining openness in a manner that is inconsistent with
  360. common industry practice, the EIF v2.0 excludes many <span style="background:#d09cf0">leading
  361. standards</span> widely recognised as open from its scope
  362. including such well-known standards as DVB,
  363. GSM and MP3. (We have attached a list of excluded standards to our
  364. comments at Appendix A). If Member States implement this
  365. definition, they will effectively be restricted from utilizing a
  366. wide range of <span style="background:#d09cf0">leading technologies that implement these popular
  367. standards</span>. This would represent a dramatic shift at national level,
  368. given that virtually every single Member State now has policies
  369. that are far more flexible."</p>
  370. </blockquote>
  371. <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>
  372. </div>
  373. </div>
  374. <div class="clear">
  375. <div class="grid-50 left">
  376. <h3>C. EIFv2 Leaked Draft 11/2009</h3>
  377. <blockquote>
  378. <p>"Specifications, software and software development methods that
  379. promote collaboration and the results of which can freely be
  380. accessed, reused and shared are considered open and lie at one end
  381. of the spectrum while <span style="background:#d09cf0">non-documented, proprietary specifications,
  382. proprietary software and the reluctance or resistance to reuse
  383. solutions, i.e. the "not invented here" syndrome, lie at the other
  384. end</span>.</p>
  385. <p>The spectrum of approaches that lies between these two extremes
  386. can be called the openness continuum."</p>
  387. </blockquote>
  388. <p> The consultation document already included the idea of an "openness continuum".
  389. This continuum, however, only covered a range from "open" to "most open". In the leaked draft,
  390. the continuum suddenly includes proprietary standards and specifications.
  391. </p>
  392. <blockquote>
  393. <p>"Within the context of the EIF, openness is the willingness of
  394. persons, organisations or other members of a community of interest
  395. to share knowledge and to stimulate debate within that community of
  396. interest, having as ultimate goal the advancement of knowledge and
  397. the use thereof to solve relevant problems. In that sense, openness
  398. leads to considerable gains in efficiency."</p>
  399. </blockquote>
  400. </div>
  401. <div class="grid-50 left">
  402. <h3>D. EIFv2 Leaked Draft 03/2010</h3>
  403. <blockquote>
  404. <p>Specifications, software and software development methods that promote
  405. collaboration and the results of which can freely be accessed, reused and
  406. shared are considered open and may lead to gains in efficiency, while
  407. non-documented, proprietary specifications, proprietary software and the
  408. reluctance or resistance to reuse solutions, i.e. the "not invented here"
  409. syndrome, are considered closed.</p>
  410. </blockquote>
  411. <blockquote>
  412. <p>Within the context of the EIF, openness is the willingness of persons,
  413. organisations or other members of a community of interest <strong>to freely
  414. share knowledge</strong> and to stimulate debate within that community of
  415. interest, having as ultimate goal the advancement of knowledge and the use
  416. thereof to solve relevant problems. Interoperability involves the sharing of
  417. information and knowledge between interacting organisations, hence implies
  418. openness.</p>
  419. </blockquote>
  420. <p>
  421. The terms "open" and "closed" are used in a manner that is so vague as to
  422. render them essentially meaningless.
  423. </p>
  424. <p>
  425. However, the current draft makes no attempt to highlight that an "open"
  426. approach is preferable to a "closed" one. Even if it did, both terms are
  427. used in a manner that is so vague as to render them essentially
  428. meaningless.
  429. </p>
  430. </div>
  431. </div><!--end .clear-->
  432. <hr />
  433. <p>
  434. By the time the draft of November 2009 became public, this had morphed
  435. into the concept of an "openness continuum", which met with heavy
  436. criticism. As a result, the expression is no longer present in the current
  437. draft, which instead uses simply "open" and "closed".
  438. </p>
  439. <p>
  440. Looking back to the consultation draft, it is obvious that during the
  441. development of EIFv2, the EC has abandoned the concept of Open Standards
  442. as a key enabler for interoperability. This is a central reason why the
  443. current draft would see the European Interoperability Framework become a
  444. shadow of its former self.
  445. </p>
  446. <p><strong>Conclusion:</strong> Based on the above analysis, we can only
  447. conclude that the European Commission is giving strong preference to the
  448. viewpoint of a single lobby group. Regarding interoperability and open
  449. standards, key places of the consultation document were modified to comply
  450. with the demands of the BSA. Input given by other groups was not considered
  451. on this issue. Beyond ignoring this input, the Commission has apparently
  452. decided to ignore the success of the first version of the EIF, and to
  453. abandon its efforts towards actually achieving interoperability in
  454. eGovernment services.</p>
  455. <hr />
  456. <p><a id="not1" href="#anc1">[1]</a>. This is a stark contrast with the
  457. European Commission's policy on this subject. See
  458. <a href="http://europa.eu/rapid/pressReleasesAction.do?reference=SPEECH/08/317&amp;format=HTML&amp;aged=0&amp;language=EN&amp;guiLanguage=en">
  459. this speech by European Commissioner for Competition, Ms. Neelie Kroes</a>:</p>
  460. <blockquote>“I know a smart business decision when I see one - choosing
  461. open standards is a very smart business decision indeed.”</blockquote>
  462. <p>
  463. <a id="not2" href="#anc2">[2]</a>. Indeed, instead of the vague notion of
  464. "reasonable fee," a nominal one-time fee permits Free Software projects to
  465. implement standards. See as a similar case the
  466. <a href="http://www.samba.org/samba/PFIF/">agreement between Samba and Microsoft</a>.
  467. </p>
  468. </div><!--end .compare-->
  469. </body>
  470. <author id="roy" />
  471. <author id="gerloff" />
  472. <date>
  473. <revision content="2010-03-24" />
  474. <original content="2009-11-27" />
  475. </date>
  476. <!--<download type="pdf" content="eifv2-02.pdf" />-->
  477. </html>
  478. <!--
  479. Local Variables: ***
  480. mode: xml ***
  481. End: ***
  482. -->