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.

20141215.FSFE.EC_OSS_Strategy.en.xhtml 39KB

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <html>
  3. <head>
  4. <title>Considerations on Updating the European Commission's Open
  5. Source Strategy - Public Bodies - FSFE</title>
  6. </head>
  7. <body class="article" microformats="h-entry">
  8. <p id="category"><a href="/activities/policy/eu/policy-goals.html">
  9. Policy goals 2014 - 2019</a></p>
  10. <h1>Considerations on Updating the European Commission's Open Source
  11. Strategy</h1>
  12. <div id="introduction">
  13. <p>
  14. The European Commission has a published <a
  15. href="">"Open
  16. Source Strategy"</a>, describing the use it makes of
  17. Free Software internally. In November
  18. 2014, the Commission asked FSFE for input to an
  19. upcoming revision of this "strategy". In response to
  20. this request, we produced the document below.
  21. </p>
  22. <p>
  23. The EC's current "strategy" is rather limited in
  24. scope and ambition, and the Commission has
  25. indicated that future versions of the strategy will
  26. remain within similar constraints. Accordingly, we
  27. have opted to focus our input on achieving the
  28. maximum possible amount of progress within those
  29. limits. In parallel, we are continuing our efforts
  30. to set the Commission, and other European
  31. institutions, on a course for software freedom in
  32. both policy and practice.
  33. </p>
  34. </div>
  35. <!-- Table of contents -->
  36. <!--<h2>Table of Contents</h2>
  37. <ul>
  38. <li><a href="#sec-1">1. Introduction</a></li>
  39. <li><a href="#sec-2">2. Contributing to external Free Software
  40. projects</a>
  41. <ul>
  42. <li><a href="#sec-2-1">2.1. Clarify copyright ownership among EC and
  43. agencies</a></li>
  44. <li><a href="#sec-2-2">2.2. Create a policy</a></li>
  45. <li><a href="#sec-2-3">2.3. Make contributing simple</a></li>
  46. <li><a href="#sec-2-4">2.4. Incentivise developers to
  47. contribute</a></li>
  48. <li><a href="#sec-2-5">2.5. Under which licenses should the
  49. European Commission release contributions to Free Software
  50. projects?</a></li>
  51. <li><a href="#sec-2-6">2.6. Contributor agreements</a></li>
  52. </ul></li>
  53. <li><a href="#sec-3">3. Distributing software developed by or for
  54. the EC</a>
  55. <ul>
  56. <li><a href="#sec-3-1">3.1. Why should the European Commission
  57. release its own programs as Free Software?</a></li>
  58. <li><a href="#sec-3-2">3.2. Current Free Software releases by the
  59. European Commission</a></li>
  60. <li><a href="#sec-3-3">3.3. Making releasing software under a Free
  61. Software license easy</a></li>
  62. </ul></li>
  63. <li><a href="#sec-4">4. Further considerations</a>
  64. <ul>
  65. <li><a href="#sec-4-1">4.1. Liability</a>
  66. <ul>
  67. <li><a href="#sec-4-1-1">4.1.1. Outbound liability</a></li>
  68. <li><a href="#sec-4-1-2">4.1.2. Inbound liability</a></li>
  69. </ul></li>
  70. <li><a href="#sec-4-2">4.2. Remarks on software
  71. procurement</a></li>
  72. </ul></li>
  73. <li><a href="#sec-5">5. Conclusions</a></li>
  74. </ul>-->
  75. <!-- Introduction -->
  76. <div><h2 id="sec-1">1. Introduction</h2>
  77. <div>
  78. <p>The purpose of this document is to provide input on a number of
  79. specific questions to the team tasked with updating the EC's Open
  80. Source Strategy, which is meant to guide the decisions of those in
  81. charge of the Commission's IT systems and IT procurement, with respect
  82. to contributing and releasing software under a Free Software license.<sup>
  83. <a id="fnr.1" name="fnr.1" href="#fn.1">1</a></sup> The ultimate goal
  84. of this paper is to enable the European Commission to maximise the
  85. value for money it obtains from its IT systems, by leveraging the
  86. advantages of Free Software and open file formats.</p>
  87. <p>This document does not constitute legal advice. If legal advice from a
  88. specialist is required, FSFE will be honoured to facilitate contacts
  89. with competent lawyers.</p>
  90. <p>While in this document we focus on the European Commission, the
  91. information contained herein applies equally to other EU institutions,
  92. as well as to public bodies more generally.</p>
  93. <p>The terms "Free Software" and "open source software" both refer to
  94. computer programs which recipients may <a href="">
  95. use, study, share, and improve</a>. In this document, the term "Free
  96. Software" is preferred. Both terms cover the same set of programs<sup>
  97. <a id="fnr.2" name="fnr.2" href="#fn.2">2</a></sup>.</p>
  98. </div>
  99. </div>
  100. <!-- Contributing to external Free Software projects -->
  101. <div><h2 id="sec-2">2. Contributing to external Free Software projects</h2>
  102. <div>
  103. <p>The Commission, and other European institutions, are currently
  104. making use of numerous Free Software programs and applications
  105. <sup><a id="fnr.3" name="fnr.3" href="#fn.3">3</a></sup>.
  106. At the same time, the Commission admits that it is "in a situation
  107. of effective captivity with Microsoft as regards its desktop
  108. operating systems and office productivity tools"<sup><a id="fnr.4"
  109. name="fnr.4" class="footref" href="#fn.4">4</a></sup>. Making
  110. greater use of Free Software tools is an essential step in loosening
  111. the bonds of this captivity. In addition, the Commission's IT
  112. services are adapting, patching and improving Free Software
  113. programs for their own use. If the European Commission contributes
  114. to outside Free Software tools which it uses itself, those
  115. contributions will help to make those tools more useful, quickly
  116. and in a cost-effective manner.</p>
  117. <p>Permitting such contributions is the most cost-effective way of
  118. improving the tools that the Commission is using. Ideally, these
  119. contributions will become part of the mainline project; this would
  120. eliminate the need for the Commission's developers to repeatedly apply
  121. Commission-specific patches to subsequent versions of the programs in
  122. question, freeing up their time for more useful tasks. (It should be
  123. noted that such improvements are out of the question with non-free
  124. software; here, the Commission is fully dependent on the vendor of the
  125. program for any fixes or improvements.</p>
  126. <p>Already in 2005, the Commission published a "Guideline for Public
  127. Administrations on Partnering with Free Software Developers"
  128. <sup><a id="fnr.5" name="fnr.5" href="#fn.5">5</a></sup>, which
  129. remains a useful resource.</p>
  130. <p>It is useful to distinguish between contributing to an external
  131. project as a way to improve it (e.g. by providing upstream patches and
  132. modules), and releasing an internally-developed program to the public
  133. under a Free Software license.</p>
  134. <p>Contributions to an existing project are only a matter of internal
  135. organization of the Commission. Contrary to what happens if the public
  136. entity distributes software under a closed or "proprietary" license
  137. software which may compete with existing applications in the same
  138. market, contributing to a public Free Software project does not put
  139. the Commission in a situation of competition with commercial actors.</p></div>
  140. </div>
  141. <div><h3 id="sec-2-1">2.1. Clarify copyright ownership among EC and agencies</h3>
  142. <div>
  143. <p>Currently, the copyright on code and documentation created
  144. by Commission staff is held by the Commission. The contracts
  145. with service suppliers normally state that all software
  146. developed for the Commission in the context of the contract
  147. is owned by the Commission. The relevant director-general
  148. decides on issues related to copyright and trademarks, after
  149. having consulted the legal service and the Joint Research
  150. Centre.</p>
  151. <p>When contributions are created by contractors external to
  152. the Commission, copyright ownership will depend on the terms
  153. of the contract in question. Where the Commission holds
  154. copyright on the work created under these contracts, it may
  155. decide to distribute the work in question under a Free
  156. Software license of its choice.</p>
  157. <p>Alternatively, the EC could choose to let copyright in
  158. the newly created code and documentation remain with the
  159. contractor, and impose a contractual obligation for the
  160. contractor to publish these assets in a suitable manner under
  161. a Free Software license (and perhaps participate in their
  162. maintenance for a specified period of time).</p>
  163. <p>As the expert on the specific project, the contractor is
  164. in a much better position to handle the distribution of the
  165. software and documentation in a productive and sustainable
  166. way, by bringing the necessary technical and legal expertise
  167. to bear. At the same time, it is important to recognise that
  168. distributing software is not among the Commission's primary
  169. responsibilities; this task should therefore be handled in
  170. the most efficient manner possible. For this approach to work,
  171. the Commission however needs to set the right requirements
  172. and incentives. (This is an approach adopted in Sweden, for
  173. example.)</p>
  174. </div>
  175. </div>
  176. <div><h3 id="sec-2-2">2.2. Create a policy</h3>
  177. <div>
  178. <p>Contributions to outside Free Software projects by
  179. developers working for the Commission could be enabled
  180. through a simple policy signed by the relevant Director
  181. General. This policy could be approved after consultation
  182. with the legal service and the joint research centre.</p>
  183. <p>As an important first step, the EC should state publicly
  184. that developers working on Commission software projects and
  185. using or implementing Free Software solutions can contribute
  186. to the upstream projects any bug fixes and new functionality.</p>
  187. <p>Where a more explicit policy is required, it should be as
  188. simple as possible, both in administrative and linguistic
  189. terms. The policy should contain the following elements:</p>
  190. <ul>
  191. <li>Rationale for the policy
  192. <ul>
  193. <li>e.g. Free Software serves to avoid lock-in,
  194. and enables a more effective IT strategies in
  195. the public sector.</li>
  196. </ul>
  197. </li>
  198. <li>Operational part, describing steps that developers
  199. should follow:
  200. <ul>
  201. <li>Identification of the Free Software project
  202. to which developers will contribute (the "target
  203. project")</li>
  204. <li>Identification of copyright and trademark
  205. ownership regime for potential contributions from
  206. the EC</li>
  207. <li>Identification of the target project's license
  208. and contribution policy</li>
  209. <li>Identification of person(s) involved in the
  210. process, and their approval (if required)</li>
  211. <li>Identification of required documentation</li>
  212. <li>Example header files</li>
  213. </ul>
  214. </li>
  215. </ul>
  216. <p>For cases where explicit approval is required, the policy
  217. should stipulate a clear approval path, a time period during
  218. which the developer can expect to receive approval, e.g. one
  219. week.</p>
  220. </div>
  221. </div>
  222. <div><h3 id="sec-2-3">2.3. Make contributing simple</h3>
  223. <div>
  224. <p>If useful adaptations of software tools to the Commission's
  225. needs are actually to occur, making such improvements simple
  226. is the first step. In order to ensure that these improvements
  227. will be contained in future versions of the outside project,
  228. it is important to simplify the process for developers to
  229. contribute these improvements "upstream" to the outside project
  230. <sup><a id="fnr.6" name="fnr.6" href="#fn.6">6</a></sup>.</p>
  231. <p>We recommend to use the above-mentioned policy to give
  232. developers working for the Commission and other European
  233. institutions blanket permissions for small contributions
  234. that are directly related to Free Software projects which
  235. are currently in use within the institution in question.</p>
  236. <p>For more substantial contributions, or in cases where the
  237. usefulness of the contribution requires further explanation,
  238. we suggest that the Commission Free Software policy should
  239. outline and set up a simple, efficient approval process.
  240. This process should provide developers with a clear decision
  241. path, and a clear timeline indicating how long after their
  242. inquiry they can expect to receive a decision.</p>
  243. <p>In order to make the process efficient, we recommend to
  244. apply the Commission's rules on public statements by its
  245. employees in a sensible manner. As a rule, source code does
  246. not serve to convey views or opinions. Concerns that
  247. developers through their contributions might make statements
  248. that would be potentially damaging to the Commission are in
  249. our view largely unwarranted. While it is theoretically
  250. conceivable that a developer might choose to make damaging
  251. statements as part of his or her contribution, current
  252. Commission employment rules and policies provide ample means
  253. to handle any such incidents, in the very unlikely case that
  254. they were to occur at all.</p>
  255. <p>Theoretically, one could argue that while the
  256. contributions will not convey views or opinions, the fact
  257. that the Commission contributes to a particular Free Software
  258. product may be conceived as a statement of support/approval
  259. of this product. While the author has never once encountered
  260. this sort of problem in practice during the past 10 years,
  261. such concerns could be addressed with a public disclaimer
  262. posted alongside an explanation of the Commission's contribution
  263. policy, or even alongside the updated Open Source Strategy.</p>
  264. </div>
  265. </div>
  266. <div><h3 id="sec-2-3">2.4. Incentivise developers to contribute</h3>
  267. <div>
  268. <p>If useful adaptations of software tools to the Commission's
  269. needs are actually to occur, making such improvements simple
  270. is only the first step. In addition, we recommend a few simple
  271. measures to incentivise developers in this regard.</p>
  272. <p>The first measure is to set up efficient and painless
  273. processes for contribution. Not only should contributing to
  274. the mainline project not require additional effort; doing so
  275. should ideally be <i>easier</i> for a developer than applying
  276. a patch only to the copy of the software that is being used
  277. within the Commission.</p>
  278. <p>The second measure is to permit developers to attach their name to
  279. their contributions, while the copyright remains with the European
  280. Commission or another EU institution. Contributions to Free Software
  281. projects are an important and valued component of a developer's
  282. experience and resume, since they permit future employers to get a
  283. realistic impression of a potential hire's skills. Permitting
  284. developers to attach their name to the contributions they make would
  285. allow them to build up a portfolio of demonstrable work experience
  286. during their time with the Commission, and would make the Commission
  287. a more attractive employer.</p>
  288. <p>In practice, the best path would be to allow developers to write the
  289. copyright notices on their contribution in roughly the following way:</p>
  290. <blockquote><p>This code contributed by Jane Smith
  291. &lt;;. &#169; 2014 European
  292. Commission.</p></blockquote>
  293. <p>It should be noted that both measures are simple steps
  294. to take, and require little more than an administrative
  295. decision. They also do not add costs; on the contrary, they
  296. may well contribute to reducing costs for maintenance and
  297. adaptions in the medium term.</p>
  298. </div>
  299. </div>
  300. <div><h3 id="sec-2-5">2.5. Under which licenses should the European
  301. Commission release contributions to Free Software projects?</h3>
  302. <div>
  303. <p>When developers associated with the Commission contribute
  304. to existing Free Software projects, such contributions will
  305. as a rule need to be made under the same Free Software license
  306. as the main project. In fact, most projects would refuse
  307. contributions under any other license, because mixing different
  308. licenses in the same project would quickly lead to conflicting
  309. sets of copyright rules, creating problems that are difficult
  310. or impossible to resolve.</p>
  311. </div>
  312. </div>
  313. <div><h3 id="sec-2-6">2.6. Contributor agreements</h3>
  314. <div>
  315. <p>Some Free Software projects demand that contributors
  316. assign the copyright in their contributions to an organisation,
  317. usually either a company or a foundation acting as a fiduciary.
  318. These agreements have the purpose of making projects with a
  319. large number of contributors easier to manage on the legal
  320. level.</p>
  321. <p>If developers, or the organisations where they work, are required to
  322. sign a contribution agreement in order to contribute to a project, we
  323. recommend to submit the proposed agreement to a competent lawyer for
  324. consideration. Most likely, such questions will need to be decided by
  325. the Director General after having consulted the Commission's Legal
  326. Service and the relevant department in the Joint Research Centre. A
  327. repository of approved contribution agreements could be maintained, to
  328. avoide repeated legal review. The required effort should be weighed
  329. against the benefit of having the software in question adapted to the
  330. Commission's needs<sup><a id="fnr.7" name="fnr.7" href="#fn.7">7</a></sup>.</p>
  331. </div>
  332. </div>
  333. <!-- Distributing software developed by or for the EC -->
  334. <div><h2 id="sec-3">3 Distributing software developed by or for the EC</h2>
  335. <div>
  336. <p>Public administrations are always at liberty to develop software for
  337. their own purposes, or contract out such work to third parties. Once
  338. this software has been developed, the public administration may decide
  339. to make the program available to others as well.</p>
  340. </div>
  341. </div>
  342. <div><h3 id="sec-3-1">3.1. Why should the European Commission release
  343. its own programs as Free Software?</h3>
  344. <div>
  345. <p>Software is a <a href="">non-rival</a>
  346. good: If a citizen or company makes use of a computer program
  347. paid for by the European Commission, this use does not in any
  348. way interfere with the Commission's own use of that program<sup><a id="fnr.8" name="fnr.8" href="#fn.8">8</a></sup>.
  349. Quite to the contrary: The program might actually generate
  350. additional value for the citizen or company which was not
  351. previously available. According to a study by Carlo Daffara, Free
  352. Software contributes 450 billion Euro each year to Europe's economy,
  353. in direct savings and increased productivity and efficiency<sup><a id="fnr.9" name="fnr.9" href="#fn.9">9</a></sup>.</p>
  354. <p>It is important to understand that the value of any software released
  355. by the Commission under a Free Software license is in the eye of the
  356. beholder, i.e. the external user. As with Open Data, external users
  357. may put these programs to useful purposes that the Commission could
  358. not predict ahead of time, thus generating added value for Europe's
  359. economy at no additional cost to the taxpayer<sup><a id="fnr.10" name="fnr.10" href="#fn.10">10</a></sup>.
  360. Since distributing software is not among the primary responsibilities
  361. of the European Commission, it is important that this process
  362. should be designed to be as efficient as possible.</p>
  363. <p>The European Commission is ultimately funded through the taxes of
  364. European citizens. It is only logical that wherever possible, the
  365. assets created with public funds should be made available to the
  366. public. On its Joinup portal<sup><a id="fnr.11" name="fnr.11" href="#fn.11">11</a></sup>,
  367. the Commission offers a platform for public administrations
  368. to make their software available for re-use. Some European
  369. regions, such as Andalusia and the Basque Country in Spain,
  370. are requiring all programs developed with public funds to be
  371. made available as Free Software. These policies follow an
  372. economic logic of stimulating the development of competent IT
  373. companies in those regions, and we consider them an example which the
  374. European Commission might wish to follow.</p>
  375. </div>
  376. </div>
  377. <div><h3 id="sec-3-2">3.2. Current Free Software releases by the
  378. European Commission</h3>
  379. <div>
  380. <p>The European Commission has developed a Free Software license of its
  381. own explicitely for this purpose: The European Union Public License
  382. (EUPL)<sup><a id="fnr.12" name="fnr.12" href="#fn.12">12</a></sup>.</p>
  383. <p>Already now, the The European Commission is making numerous Free
  384. Software solutions publicly available through the <a href="">Joinup</a> repository
  385. and collaborative platform, a project by DG DIGIT's ISA
  386. Programme. Examples include:</p>
  387. <ul>
  388. <li>Open ePrior (now being implemented by the Belgian Federal and the
  389. government of the Flemish region)</li>
  390. <li>Open eTrustEX</li>
  391. <li>ECI Validation Tool for Statements of Support (VTECI)</li>
  392. <li>ECI Online Collection Software (OCS)</li>
  393. <li>SPOCS-Simple Procedures Online for Crossborder Services</li>
  394. <li>Tarîqa</li>
  395. <li>Multilingual Electronic Dossier</li>
  396. <li>Inspire Registry</li>
  397. <li>Inspire Geoportal</li>
  398. <li>Inspire validator</li>
  399. <li>mAggregator</li>
  400. <li>mDownloader</li>
  401. <li>ePetition (renamed euSurvey)</li>
  402. <li>Stork</li>
  403. <li>Joinup (now reused by the government of Vietnam,
  404. South Australia and Australia and New Zealand)</li>
  405. <li>OS toolbox</li>
  406. <li>Echo Offline eSingle form</li>
  407. </ul>
  408. <p>These examples indicate that the EC already has substantial practical
  409. experience in sharing software. We recommend to systematically review
  410. the lessons learned, identify potential improvements to the process,
  411. and implement them.</p>
  412. </div>
  413. </div>
  414. <div><h3 id="sec-3-3">3.3. Making releasing software under a Free Software license easy</h3>
  415. <div>
  416. <p>As discussed in relation to contributions to existing projects
  417. discussed above, the decision procedure within the Commission is the
  418. same in both cases: the relevant Director General consult the Legal
  419. Service and the Joint Research Centre and takes a decision.</p>
  420. <p>When releasing software, we recommend that the Commission should
  421. follow accepted best practices of the Free Software
  422. community. Projects should have a modular structure, and should
  423. ideally be hosted on a public version control platform that makes it
  424. easy for both in-house and outside developers to contribute to the
  425. project.</p>
  426. <p>Before distributing or publishing newly developed software, the
  427. Commission should carefully check that the finished program complies
  428. with all license requirements on inbound code (i.e. existing Free
  429. Software components used in the project). The EC should also select a
  430. Free Software license under which to distribute the project. In the
  431. past, the Commission has given preference to the
  432. <a href="">European Union Public
  433. License</a> (EUPL). Depending on the inbound code being reused, it may be
  434. necessary to distribute the project under another license, such as the
  435. <a href="">GNU General Public License</a>.</p>
  436. </div>
  437. </div>
  438. <!-- Further considerations -->
  439. <div><h2 id="sec-4">4. Further considerations</h2></div>
  440. <div><h3 id="sec-4-1">4.1. Liability</h3></div>
  441. <div><h4 id="sec-4-1-1">4.1.1. Outbound liability</h4>
  442. <div>
  443. <p>The question of liability is sometimes raised in connection with
  444. oublic bodies releasing Free Software, or to contribute to external
  445. Free Software projects. While this is a prudent consideration to
  446. undertake, it does not present an obstacle to such releases or
  447. contributions in practice.</p>
  448. <p>This section is based on a legal opinion published by Dr
  449. Till Jaeger and Dr Carsten Schulz, which in addition to being the
  450. leading document in this field can be considered to have stood the
  451. test of time<sup><a id="fnr.13" name="fnr.13" href="#fn.13">13</a></sup>.
  452. The opinion is based on German liability law, which carries
  453. perhaps the most stringent liability rules in the EU.</p>
  454. <p>According to Jaeger and Schulz, software that is distributed free of
  455. charge has the legal status of a gift. This means that the
  456. institution providing the software (in this case, the Commission or
  457. another European institution) will only be liable for defects which
  458. it has maliciously concealed<sup><a id="fnr.14" name="fnr.14" href="#fn.14">14</a></sup>.</p>
  459. <p>Should the program turn out to infringe any third-party rights (such
  460. as copyright, patents or trademarks held by others), the Commission
  461. would only be liable if it had introduced such infringements knowingly
  462. and willingly.<sup><a id="fnr.15" name="fnr.15" href="#fn.15">15</a></sup>.</p>
  463. <p>In addition to these considerations, it is worth pointing out that
  464. neither the author of this document (despite a decade of personal
  465. experience in the field) nor any of the experts that have contributed
  466. to this text are aware of a single successful liability complaint
  467. brought against a person or institution who has distributed Free
  468. Software free of charge.</p>
  469. </div>
  470. </div>
  471. <div><h4 id="sec-4-1-2">4.1.2. Inbound liability</h4>
  472. <div>
  473. <p>Where the Commission uses Free Software produced externally, the
  474. developers and distributors of the programs in question normally
  475. cannot be held liable for any problems or malfunctions. Where the
  476. Commission deems it necessary to have an external party to hold liable
  477. for problems, it may enter into a service contract with a suitable
  478. company.</p>
  479. <p>It is worth noting that in practice, there is little or no difference
  480. between Free and non-free software in this regard. The makers of
  481. non-free programs typically design their end-user license agreements
  482. to exclude liability to the maximum extent possible under the
  483. law. This means that even in extreme circumstances, software makers
  484. can only be held liable for defects which they have maliciously
  485. concealed.</p>
  486. </div>
  487. </div>
  488. <div><h3 id="sec-4-2">4.2. Remarks on software procurement</h3>
  489. <div>
  490. <p>Free Software represents only a part of the software used by the
  491. Commission. Significant benefits are available from updates to the
  492. Commission's approach to software procurement.</p>
  493. <p>IT procurement is a complex and dynamic field. It would therefore be
  494. prudent for the Commission to stay abreast with the rapid development
  495. of best practices in the field. A particularly valuable example are
  496. the "Red Lines for IT procurement" announced by the UK Government in
  497. January 2014<sup><a id="fnr.16" name="fnr.16" href="#fn.16">16</a></sup>.</p>
  498. <p>Besides putting an explicit limit on the size of individual contracts,
  499. these rules state that:</p>
  500. <blockquote><ul>
  501. <li>companies with a contract for service provision will not be
  502. allowed to provide system integration in the same part of
  503. government</li>
  504. <li>there will be no automatic contract extensions; the government
  505. won’t extend existing contracts unless there is a compelling
  506. case</li>
  507. <li>new hosting contracts will not last for more than 2 years</li>
  508. </ul></blockquote>
  509. <div>
  510. <p><img src="/graphics/UKGsuppliers2010.png" alt="UKGsuppliers2010.png" /></p>
  511. <p>Figure 1: Geographical distribution of the UK Government's IT supply chain, 2010</p>
  512. </div>
  513. <p>Pointing out that "[s]marter purchasing realised savings of £3.8
  514. billion in 2012 to 2013 alone", the government's chief procurement
  515. officer said that these steps were intended to counter monopolistic or
  516. oligopolistic behaviour among suppliers<sup><a id="fnr.17" name="fnr.17" href="#fn.17">17</a></sup>
  517. of precisely the sort that have lead the Commission into its
  518. current "effective captivity" to Microsoft in particular.</p>
  519. <p>When procuring new solutions, the Commission should consider future
  520. exit costs during the process of assessing new solutions, along the
  521. lines of the UK Government's Technology Code of Practice:</p>
  522. <blockquote>
  523. <p>"Ensure a level-playing field for open source software. Demonstrate
  524. an active and fair consideration of using open source software –
  525. taking account of the total lifetime cost of ownership of the
  526. solution, including exit and transition costs."<sup><a id="fnr.18" name="fnr.18" href="#fn.18">18</a></sup></p>
  527. </blockquote>
  528. <div>
  529. <p><img src="/graphics/UKGsuppliers2014.png" alt="UKGsuppliers2014.png" /></p>
  530. <p>Figure 2: Geographical distribution of the UK Government's IT supply chain, 2014</p>
  531. </div>
  532. <p>In addition, the UK Government's Open Standards principles deal with
  533. the issue of exit costs:</p>
  534. <blockquote>
  535. <p>"As part of examining the total cost of ownership of a
  536. government IT solution, the costs of exit for a component should be
  537. estimated at the start of implementation. As unlocking costs are
  538. identified, these must be associated with the incumbent
  539. supplier/system and not be associated with cost of new IT projects."<sup><a id="fnr.19" name="fnr.19" href="#fn.19">19</a></sup></p>
  540. </blockquote>
  541. <p>Taken together, the UK Government's Open Standards policy and the
  542. changes made to IT procurement have already resulted in a significant
  543. diversification of the government's IT supply chain, as indicated by
  544. the changed geographical distribution of the government's IT
  545. suppliers (see Figures 1 and 2).</p>
  546. <p>Concerning framework agreements, Sweden's central procurement agency
  547. Kammarkollegiet offers a useful example. The agency has recently
  548. published a set of framework agreements for software and
  549. services. Each agreement covers Free Software, non-free software, and
  550. cloud services at the same level, making it possible to directly
  551. compare value for money for each particular use case.</p>
  552. </div>
  553. </div>
  554. <!-- Conclusions -->
  555. <div><h2 id="sec-5">5. Conclusions</h2>
  556. <div>
  557. <p>The European Commission stands to gain significant advantages from
  558. allowing its developers and contractors to contribute to outside Free
  559. Software projects. By distributing its own programs as Free Software,
  560. the Commission can enable the interoperability gains and efficiency
  561. savings that come with reuse. Such releases also make valuable assets
  562. available to the taxpayers who paid for them, enabling further
  563. economic exploitation. Provided that appropriate policies and
  564. processes are put in place, neither contributions to outside projects
  565. nor the release of programs as Free Software carries any significant
  566. risks or downsides for the Commission.</p>
  567. <p>Main considerations related to contributing to external
  568. Free Software projects:</p>
  569. <ul>
  570. <li>Allowing the EC's developers and contractors to contribute to
  571. upstream projects currently in use at the Commission is an
  572. effective way of ensuring that these programs fill suit the
  573. Commission's needs in future. Such contributions will not, as a
  574. rule, put the Commission in competition with commercial actors.</li>
  575. <li>The first step in enabling developers and contractors to contribute
  576. to upstream projects is to clarify who holds copyright in their
  577. contributions, and therefore is in a position to decide on the
  578. license conditions under which the contribution shall be distributed.</li>
  579. <li>To actually enable contributions to outside upstream projects, the
  580. EC should publish a statement clarifying that such contributions by
  581. Commission staff and contractors are permitted and desired.</li>
  582. <li>As a next step, the Commission should create a simple policy for
  583. more substantial contributions and other cases where explicit
  584. approval is required. This policy should state a clear approval
  585. path for contribution requests, along with the maximum time that
  586. the requesting developer will have to wait for an answer.</li>
  587. <li>Besides making the process of contributing to outside projects as
  588. simple as possible, the Commission can incentivise its developers
  589. to engage in such contributions by allowing them to include their
  590. name in the copyright notice (while copyright remains with the EC).</li>
  591. </ul>
  592. <p>Main considerations related to the EC releasing programs developed by
  593. the EC as Free Software:</p>
  594. <ul>
  595. <li>Software created by or for the European Commission is ultimately
  596. funded by European taxpayers. The Commission should make such
  597. software available for reuse by default; Free Software licenses
  598. provide an efficient mechanism for this.</li>
  599. <li>Already now, the EC distributes numerous programs under Free
  600. Software licenses, and has gained significant experience in this
  601. regard.</li>
  602. <li>When distributing its own programs as Free Software, the Commission
  603. is free to choosing a license which it considers suitable. If
  604. pre-existing Free Software components were used in the project, the
  605. EC's choice of license will have to fulfil the license requirements
  606. of those inbound components.</li>
  607. <li>The EC would only be liable for defects in programs it distributes
  608. if it has maliciously concealed those defects. In practice, it is
  609. extremely unlikely that such programs will present a source of
  610. liability claims against the Commission.</li>
  611. </ul>
  612. <p>In addition to these considerations, we recommend that the EC should
  613. review its approach to software procurement to take into account best
  614. practices that were recently developed, such as the standards and
  615. procurement policies issued by the UK government in 2013-14.</p>
  616. </div>
  617. </div>
  618. <!-- Footnotes -->
  619. <blockquote>
  620. <h2>Footnotes: </h2>
  621. <p><sup><a id="fn.1" name="fn.1" href="#fnr.1">1</a></sup>
  622. The author wishes to express his gratitude to the following
  623. experts who contributed to this document: Karel de Vriendt, Carlo
  624. Piana, Malcolm Bain, Gijs Hillenius, Daniel Melin, Mirko Böhm. Any mistakes are
  625. the author's own.
  626. </p>
  627. <p><sup><a id="fn.2" name="fn.2" href="#fnr.2">2</a></sup>
  628. A detailed explanation is available at
  629. <a href=""></a>
  630. </p>
  631. <p><sup><a id="fn.3" name="fn.3" href="#fnr.3">3</a></sup>
  632. <a href=""></a>
  633. </p>
  634. <p><sup><a id="fn.4" name="fn.4" href="#fnr.4">4</a></sup>
  635. European Commission, "Future Office Automation Environment",
  636. p.1. Document released by Secretary General Catherine Day in response
  637. to questions from MEP Andersdotter on January 31, 2014.
  638. </p>
  639. <p><sup><a id="fn.5" name="fn.5" href="#fnr.5">5</a></sup>
  640. <a href=""></a>
  641. </p>
  642. <p><sup><a id="fn.6" name="fn.6" href="#fnr.6">6</a></sup>
  643. An important resource in this regard is the
  644. <a href="">Report on policies
  645. and initiatives on sharing and re-use</a> published
  646. by the ISA programme in February 2013.
  647. </p>
  648. <p><sup><a id="fn.7" name="fn.7" href="#fnr.7">7</a></sup>
  649. FSFE offers a <a href="">Fiduciary Licensing Agreement</a>
  650. as a legal tool for Free Software projects that wish
  651. to centralise their copyright in a single legal entity.
  652. </p>
  653. <p><sup><a id="fn.8" name="fn.8" ref="#fnr.8">8</a></sup>
  654. The opposite would be the case
  655. for an office chair or desk: It could not reasonably
  656. be used by a Commission official at the same time
  657. as it is being used by a citizen or company.
  658. </p>
  659. <p><sup><a id="fn.9" name="fn.9" href="#fnr.9">9</a></sup>
  660. Daffara, Carlo (2012): Estimating
  661. the Economic Contribution of Open Source Software to
  662. the European Economy. In: Shane Coughlan (ed.):
  663. First OpenForum Academy Conference Proceedings. Available at
  664. <a href=""></a>
  665. </p>
  666. <p><sup><a id="fn.10" name="fn.10" href="#fnr.10">10</a></sup>
  667. See <a href=""></a>
  668. </p>
  669. <p><sup><a id="fn.11" name="fn.11" href="#fnr.11">11</a></sup>
  670. <a href=""></a>
  671. </p>
  672. <p><sup><a id="fn.12" name="fn.12" href="#fnr.12">12</a></sup>
  673. See <a href=""></a>
  674. </p>
  675. <p><sup><a id="fn.13" name="fn.13" href="#fnr.13">13</a></sup>
  676. Dr Till Jaeger, Dr Carsten Schulz:
  677. Gutachten zu ausgewählten rechtlichen Aspekten der
  678. Open Source Software. JBB Rechtsanwälte, 2005.
  679. Available at <i>\_html/art47.pdf</i>.
  680. </p>
  681. <p><sup><a id="fn.14" name="fn.14" href="#fnr.14">14</a></sup>
  682. Jaeger/Schulz 2005, p.67
  683. </p>
  684. <p><sup><a id="fn.15" name="fn.15" href="#fnr.15">15</a></sup>
  685. Jaeger/Schulz 2005, p.69
  686. </p>
  687. <p><sup><a id="fn.16" name="fn.16" href="#fnr.16">16</a></sup>
  688. <a href=""></a>
  689. </p>
  690. <p><sup><a id="fn.17" name="fn.17" href="#fnr.17">17</a></sup>
  691. See <a href=""></a>
  692. </p>
  693. <p><sup><a id="fn.18" name="fn.18" href="#fnr.18">18</a></sup>
  694. <a href=""></a>
  695. </p>
  696. <p><sup><a id="fn.19" name="fn.19" href="#fnr.19">19</a></sup>
  697. <a href=""> Open Standards Principle 4</a>
  698. </p>
  699. </blockquote>
  700. </body>
  701. <sidebar promo="our-work">
  702. <h2>Table of Contents</h2>
  703. <ul>
  704. <li><a href="#sec-1">1. Introduction</a></li>
  705. <li><a href="#sec-2">2. Contributing to external Free Software
  706. projects</a></li>
  707. <li><a href="#sec-3">3. Distributing software developed by or for
  708. the EC</a></li>
  709. <li><a href="#sec-4">4. Further considerations</a></li>
  710. <li><a href="#sec-5">5. Conclusions</a></li>
  711. </ul>
  712. <h2>Our policy goals</h2>
  713. <ul>
  714. <li><a href="/activities/policy/eu/policy-goals/consumer-rights.html">Consumer rights and device sovereignty</a></li>
  715. <li><a href="/activities/policy/eu/policy-goals/privacy.html">Privacy, surveillance and cryptography</a></li>
  716. <li><a href="/activities/policy/eu/policy-goals/distributed-systems.html">Distributed systems</a></li>
  717. </ul>
  718. </sidebar>
  719. <author id="gerloff" />
  720. <date>
  721. <original content="2014-12-15" />
  722. </date>
  723. <download type="pdf" content="/activities/policy/eu/20141215.FSFE.EC_OSS_Strategy-input.pdf"/>
  724. </html>
  725. <!--
  726. Local Variables: ***
  727. mode: xml ***
  728. End: ***
  729. -->