Helping European PAs share applications

Pooling Open Source Software: An IDA Feasibility Study
Schmitz and Castiaux (IDA, 2002)

“the belief that any software can be given as open source, and then maintained and updated for free by an army of contributing volunteers is an illusion” [p18]

This is one of several European-funded projects investigating the role of open source software (OSS) in the public sector, and the appropriate policy response generally. The aim of this project was to establish what is needed to establish an effective pan-European software pooling service given that as it is argued “much of the software produced by or for administrations are not [standard packages] … as a consequence, the reuse of … software depends on the … adaptation its source code” [p7]

The conclusions were to define a system with similar functionality to Sourcefource.net, and to leave the choice of licensing (GPL, BSD etc) to individual projects. It is assumed that because the developed applications would be aimed at the PA market, the risk of impact on the private sector would be limited. I find this questionable: a query-routing application is just as applicable in a private sector context even if initially developed for the public sector.

The issue of pooling existing software is covered in some depth [pp16-19]. Since this is one of areas this thesis is exploring, the nine considerations a listed in full:

  1. Is there a common need across several administrations?
  2. What is the motivation for pooling it? To benefit the broader community, or to free-ride maintenance from others?
  3. What will the former owner’s future commitment be? Will a role as lead in development, support and documentation be maintained?
  4. Maturity of the software
  5. Readiness of the code for sharing, in terms of documentation and internal architecture. OSS favours modularised to monolithic code, leading to six or seven requirements for supporting a coding effort, including documentation (what language to be used), a clear road-map and clear decision-making structures
  6. An idea of the costs of adapting the software for other sites – ease of adding other languages, use of open standards for data interchange and storage
  7. Confirmation that the legal rights exist to release the software
  8. Choice of appropriate OSS license (GPL, BSD or a variation). A special license is not seen as a good idea due to conflicts with GPL and similar ‘copyleft’ licences [p141] *.
  9. Adequate user documentation

The paper also considers how the open source software development life-cycle (SDLC) could be supported. It is envisaged that the POSS process would work to ensure common standards between projects. The main mechanism would be an initial acceptance test [it is recognised that this might be expensive], which would verify both the opportunity that the code provided to other PAs and the quality of the supplied package. Access to the POSS repository would be restricted to paid-up members.

That is, the POSS is seen as more than a simple repository in the style of SourceForge: it is seen a service for European PAs, providing a mechanism for filtering and certifying the quality of the pooled software.

Funding of OSS development is implicitly assumed to come from PAs developing the code to suit their requirements and then contributing their work back to the pool. Funding marketing/dissemination expenses are assumed to come from existing government or EU funds. Only a need for central support of legal advice on licensing issues is foreseen. [p29]

Highlighting the fact that ‘free software’ does not come for free, the cost of the POSS service is estimated at €1m per annum. It is recommended that funded comes from European institutions, though it is noted that commercial software developments and also some OSS advocates, such as Raymond, argue that the market should decide on the outcome. [p137]

The questions is: what happened to its recommendations, given that four years later, FLOSSPOLS[1:p14] was making similar recommendations.

Note

* This is in contrast to the position subsequently taken in Schmitz, Ghosh et al (2005) [2] where it is stated that “none of the existing licensing responded to the requirements… to provide valid texts in many European languages”, avoid the necessity for compliance with US law of copyright and contract and establish a competant European jurisdiction. The EUPL is being developed in conjunction with GPL V3 however, with the aim of preventing incompatibilities if possible.

Referred documents

1. Ghosh R & R Glott. Free/Libre Open Source Software: Policy Support (FLOSSPOLS). MERIT (2006)

2. Schmitz P-E & R Ghosh et al Report on Outcomes of public consultation about the EUPL (European Union Public Licence) IDA/GPOSS (2005)

Advertisements

About Peter Cruickshank

Lecturer in the School of Computing and a member of the Centre for Social Informatics at Edinburgh Napier University, Scotland. Interested in information systems, learning, politics, society, security and where they intersect. My attempts at rounding out my character include food, cinema, running, history and, together with my lovely wife, bringing up a cat and a couple of kids.
This entry was posted in e-government, Europe, ipr, opensource, paper. Bookmark the permalink.

2 Responses to Helping European PAs share applications

  1. Pingback: Spartakan » Europe still doesn’t know what to do with OSS

  2. Pingback: L’uso dell’Open Source nelle PA europee « I numeri dell’innovazione

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s