IDABC OSS event. Implementing Open Source Software in Public Administrations: Problems and Solutions

Transcription

1 IDABC OSS event Implementing Open Source Software in Public Administrations: Problems and Solutions ABSTRACT EU public administrations are increasingly interested in OSS use and development as it has several characteristics well-suited to public sector needs, allowing or enhancing knowledgesharing and software re-use. To achieve the full potential of OSS, public administrations need to work together towards more interoperability, security and cost efficiency. The Third OSS IDABC Annual Conference took place in Prague on 11 April It was organised with the support of the Czech IT Ministry to coincide with the Czech Linuxexpo The workshop agenda put forward two major issues related to working with OSS in public administration: OSS legal status: the workshop examined licensing issues encountered during development of custom OSS in public administration. It also investigated good practice for OSS procurement and discussed a newly-published Dutch manual summarising the main issues and solutions in OSS procurement for administrations. How best to organise cooperation? Problems and solutions were presented to organise crossborder and national cooperation schemes for OSS knowledge-sharing by public administrations. The IDABC presented a new idea to develop a common OSS cooperation platform: an Open Source Repository for egovernment. A call for ideas was launched on the needs and potential functions of these possible cooperation instruments. Page 1/10

2 Abbreviations EC DG ENTR EUPL GPL ICT IDABC OSS OSOR European Commission Directorate General of the Enterprise and Industry European Union Public Licence General Public Licence Information & Communication Technologies European Community programme for Interoperable Delivery of European egovernment Services to public Administrations, Businesses and Citizens Open Source Software Open Source Repository for egovernment Page 2/10

3 Table of contents Abbreviations 2 Table of contents 3 Introduction 4 Welcome: Karel De Vriendt (Head of Unit, IDABC, European Commission) 4 Keynote speech: Dana Bérová, Czech IT Minister 4 Morning Session: OSS legal questions 5 Licences, patents and similar issues 5 Presentation: Open Source licensing of software developed by public administrations (Carsten Gerlach) 5 Discussion: Copyleft and dual licensing for public funded software (Rishab Gosh) 7 Public procurement and OSS 8 Presentation: The Dutch manual on Open Standards and Open Source Software in the procurement process (Bart Knubben) 8 Discussion: By law, by chance, by passion politicians? (Flavia Marzano) 9 Afternoon Session: Organising European Collaboration 11 Implementing multinational projects 11 Presentation: Models for cross-border collaboration (Patrice-Emmanuel Schmitz) 11 Discussion: Cross-border collaboration - There are no Issues only Solutions (maybe) (Patrick Sinz) 12 Discussion: The Swedish example (Mats Östling) 12 Building a platform for pan-european collaboration 13 Presentation: The European Open Source Repository OSOR (Barbara Held ) 13 Discussion: OSS is not about money (Jan-Willem Broekema) 13 Conclusions (Karel De Vriendt) 14 Page 3/10

4 Introduction Welcome: Karel De Vriendt (Head of Unit, IDABC, European Commission) Karel De Vriendt welcomed the participants and thanked them for participating in the event. He introduced the workshop highlighting the importance of OSS in public administration which enables software provision for egovernment services. Mr. De Vriendt introduced the work of the IDABC Programme and its objective of supporting tools assisting administrations to develop and share new solutions. Mr. De Vriendt distinguished packaged from customised OSS. Packaged OSS means that public administrations are passive software users. They should take the next step to become part of the OSS development community. For custom software, public administration is becoming a growing market for the IT development sector. Interoperability is a major OSS challenge in terms of enabling public administrations, citizens and companies to share basic modules without compatibility issues. Implementing public administration OSS has a huge potential. However, problems remaining are: the choice of licences public software procurement handling the creation of new cooperation models The aim of the workshop was to propose potential solutions to these problems. Keynote speech: Dana Bérová, Czech IT Minister Mr. De Vriendt s introduction was followed by a keynote speech by the Czech IT Minister, Dana Bérová presenting Open Standards and OSS in public administration within the framework of the Czech Information and Communication Policy introduced by the Government in March According to the Minister, the Czech Government encourages primarily the validated international Open Standards use, in order to facilitate interoperability within and between administrations and also with the consumers of public services. Vendor lock-in is also avoided. The Czech understanding of Open Standards is based on the 2004 Open Forum Europe definition 1. Open Standards are a prerequisite for using OSS and OSS conforms well to the requirements of Open Standards. Therefore, the Czech IT Ministry aims to enhance the information provision, methodological support and substantial solutions for OSS use by administrations. To this end, the OSS Alliance 2, a not-for-profit organisation managed by the Czech Technical University, has been granted patronage of the Czech IT Ministry. The Alliance functions as a consultancy, advice centre and meeting point for public administrations on OSS matters. It seeks to enhance cooperation between public administrations and the Open Source community. The organisation is also working on the development of a Czech Open Source Repository. After one year of existence, several successful OSS implementation examples in small public administrations have proven the effectiveness of the Alliance and its mission to share information. The Alliance found that users were satisfied, unlike previous experiences showing user Page 4/10

5 resistance to OSS. Establishing internal IT helpdesks proved to be very effective, smoothly solving user problems. However, challenges remain which mainly relate to systems interoperability, specifically the closed systems used by central government. Mrs. Bérová highlighted the need to clearly define Open Standards to minimise the burden of compliance with administrative regulations for the OSS users relative to the users of proprietary software. She also questioned whether it would be useful to recommend certain document formats in preference to others. The Minister proposed the next steps to improve public administration OSS utilisation. She presented the Czech Open Government 2006 Initiative 3 as a platform for discussion of OSS potential and the role of public administration, which may act not only as a user, but also as an OSS producer. The Ministry is therefore committed to adopt a twin top-down and bottom-up approach, by both promoting OSS in IT departments and exchanging views with the public administration top management,. Mrs Bérová insisted on the need to create legal exchange platforms to resolve issues relating to OSS licenses and their incompatibility with the Czech copyright, civil and contractual law. With regards to potential IDABC activities, the Minister called for measures to ensure legal certainty in European OSS use. While she explicitly praised the IDABC project of establishing a European Open Source Software Repository, she also pointed to the need for more information on interoperability between OSS and proprietary software products and solutions. Morning Session: OSS legal questions Licences, patents and similar issues Presentation: Open Source licensing of software developed by public administrations (Carsten Gerlach) The first part of the session focussed on how to license OSS developed for public administrative purposes. Carsten Gerlach from Wendler & Tremml Lawyers (Berlin) opened the session with a description of licensing issues that public administrations might encounter when producing OSS solutions for their own use and possible dissemination. The development of a public administration procurement platform served as an example from real life. Mr Gerlach identified three main issues for public administration using OSS for e-procurement platforms. Firstly, the conformity of OSS licences to general legal requirements or to the specificities of e-procurement law might be questioned. Secondly, the choice or adaptation of a specific licence should be considered and thirdly, the liability question should be taken into account. One might consider that confidentiality requirements of e-procurement platforms may prevent administrations from using OSS if these provisions forbid a disclosure of the source code. Moreover, a public administration acting as a software distributor could cause possible competition problems, as it might be competing with the private sector. In addition, budget regulations and procurement law might also hinder administrations implementing OSS in public procurement solutions or to give assets away for free. This does, by no means, prevent OSS implementation but legal aspects must be considered. 3 Page 5/10

6 The licence choice is of paramount importance, when implementing OSS in public administration. This choice must be based on a thorough consideration of the administration's technical and organisational needs and the legal framework. It is a key determinant in attracting a collaborative Open Source community and has consequences for the product application. Apart from the dominating GPL, OSS producers can today chose between more than 100 licence texts or even create a new one, like IDABC s draft European Union Public Licence (EUPL V1.0). However, there are basically two OSS licence styles: The copyleft licence (such as the GPL or EUPL licences) which mandates that all modifications to or works derived from the original software should be redistributed under the same licence terms. The permissive licences allow redistribution under any licence term. Both types have advantages and disadvantages according to the specific scenario. OSS components might need to be integrated with proprietary software for technical reasons. The individual component licences must then permit integration. This means that there are cases when two copyleft licensed components or a copyleft and commercially licensed component cannot be integrated. The permissive licences do not pose integration problems. Legal solutions to this copyleft licence incompatibility have been developed. Compatibility clauses can be integrated into licences, implying that some versions are compatible with each other and components can therefore be integrated. (As an illustration, the draft GPLv3 licence is compatible with the draft EuPL V 1.0 licence). Dual licensing is another legal solution to ensure compatibility. Specific software can then be released under two licences. The OSS licence terms in public administration have an important impact on the future commercial exploitation by 3 rd parties of the developed OSS software. Packaged OSS cannot be used for commercial purposes as licences do not allow discrimination against users or uses. Different licence terms, allowing commercial use, would change the open source characteristic of the software. However, depending on the licence style, modifications of the original OSS can be commercially appropriated by third parties. Copyleft-style licences prevent this appropriation, as they ensure that all future versions are available under the same licence. Permissive licences, however, allow third parties to own future modifications or derived works. Consequently, the licensor (public administration, in this particular case) could be required to purchase new versions of the platform under the terms of a proprietary (non-os) licence. National legal requirements need to be taken into account when licensing software. Most existing licences are written under US law, in the English language. This means that translated versions are non-binding. Moreover, due to different national copyright laws, the validity of existing (US) licence terms is often disputed. Due to the different legal systems in the US and Europe, liability issues are a source of legal uncertainty. Warranty and liability clauses are usually excluded in OSS licenses, which is incompatible with national law in many European countries. The draft EUPL licence provides a solution to these national requirements as it includes these and compatibility clauses. It also guarantees that copyright is licensor-owned and assumes liability for misconduct, personal injury and includes statutory product liability law. However, as with commercial software, liability risks can never be completely excluded. Page 6/10

7 Discussion: Copyleft and dual licensing for public funded software (Rishab Gosh) The general discussion with the audience focussed on: The IDABC fields of actions for work on legal issues. Is there a checklist for public administration OSS licensing? Dual licensing as the best option for public authorities to drive community acceptance; The status of EUPL translations and their compatibility with the widely used GPL licence. Rishab Ghosh of the Maastricht Economic Research Institute (MERIT) started the discussion by remarking that the OSS success comes from the developers, not from the lawyers. Developers are concerned with software, not with legal issues. Legal issues arise from OSS use in administrations and commercial use by third parties. He pointed out that license readability and user-friendliness is crucial to achieve OSS community acceptance and cooperation. Clearlywritten advice on existing licences could be a path for IDABC to follow. He commented on the commercial use of publicly-funded OSS by third parties, stating that public administrations do not have an obligation to make their OSS accessible to all. He also underlined the growing need to legally define OSS modifications or re-use in order to be able to control commercial exploitation. He also presented possible public policy goals for OSS licensing. Public administrations OSS should make available to the public, presently and in perpetuity including further modifications; and also for commercial exploitation by the contractor and by third parties who seek software improvements. By testing these policy goals on the three different types of software licence (copyleft, permissive and private), he concluded that dual licensing under copyleft and private licence is the best policy option as it allows the OSS, including future modifications in perpetuity, to be made available to all: Specifically: Community developers who can modify the software under the copyleft licence; Contractors or funders who retain copyright over original software and can exploit it commercially; Third-party developers who can get a private licence from the funder enabling exploitation without copyleft restrictions. Questions and a discussion followed on the EUPL licence. Mr. De Vriendt clarified that the EUPL licence was made primarily for EU use and translations are to be provided for this use. The EUPL translations can be used as such or even adapted for national public administration. Miguel Amutio from the Spanish Public Administration Ministry stressed the importance of making the EUPL and the GPL compatible in order to drive community acceptance when licensing OSS. Mr. De Vriendt explained that today the EUPL licence has not been officially declared compatible with the GPL licence v0.3 as it had to be tested amongst community developers first. The outcome of the public consultation on the first draft has been published on the IDABC website Page 7/10

8 Public procurement and OSS Presentation: The Dutch manual on Open Standards and Open Source Software in the procurement process (Bart Knubben) Bart Knubben from the Dutch ICTU started the second part of the morning session by presenting the work of his government which initiated the OSOSS Programme several years ago to support Open Standards and OSS implementation in Dutch public administration. Since January 2006, the OSOSS concentrates on Open Source only, as the promotion and the management of Open Standards have been transferred to a permanent unit, the GBO.OVERHEID. The OSOSS programme s mission now is to inform and provide guidance for public administrations through an OSS development process. In this context, a manual has been drafted to explore the possibilities of using OSS and Open Standards in conformity with Dutch procurement laws. It aims to guide administrations through the process of procuring customised OSS software. Dutch procurement law applies the principles of transparency, objectivity, non-discrimination and justification of choice. Therefore, public administrations must reflect on the extent to which they may state in tender specifications that OSS and Open Standard are a requirement (a must ) or a preferred solution (a should ). The manual provides, as a starting point, a definition and differentiation of Open Standards and OSS according to the IDABC (EIF V1.0) and OSI 5 definitions. In addition to the manual, the OSOSS programme has developed a Dutch catalogue of Open Standards 6. Mr. Knubben elaborated all these matters by presenting specific examples of guidance featured in the manual: Following the justification of choice principle, Open Standards or OSS should be required in a tender procedure only if all definition features are of importance for the service/support contract. If only some features of the definitions are of importance, then an Open Standard or OSS can be preferred. Justification for tendering OSS may derive from other legal requirements, for example from the availability of the source code or the adaptability of software for security reasons. The Dutch archiving law, for example, imposes the use of XML standard. Specific laws can also require that document formats should not be dependent on the use of specific software. Referring to specific Open Standards in a call for tender document is allowed only when the standard is approved by a Dutch or European standardisation body. If not recognised by a public standardisation body, it should not be referred to unless there is no other way to indicate the technical specification than referring to the standard. Following the nondiscriminatory principle of procurement law, it is recommended to use the phrase or the equivalent thereof when referring to specific standards. It is not an obligation but the authority has to demonstrate that no other tender met the specification. To conclude, Mr. Knubben suggested future steps at European level such as not only compiling best - but also worst-practices in public procurement and the creation of standard templates for procurement documents. As procurement law is mainly of European origin, it is important that these issues are addressed at EU level Page 8/10

9 Discussion: By law, by chance, by passion politicians? (Flavia Marzano) Flavia Marzano from the University of Bologna started the discussion on procurement of OSS by acknowledging that cross-fertilization of ideas at EU level is vital. She put forward the idea of publishing a manual for politicians, providing practical advice on how to create a proper legal environment in support of just and ethical choices when procuring ICT. She reflected on justification and non-discrimination as concepts used in the procurement discussion. She highlighted that better spending of public finances through the use of OSS did not need justification, since the procurement of proprietary software de facto does not require justification: Many tenders simply request proprietary products by their brand name. Moreover, OSS is, by definition, non-discriminatory as vendors of proprietary software could adapt their licences. Conditions for software procurement should rather be based on concepts such as quality, security, interoperability and software re-use. She further pointed out that existing regulations favouring OSS implementation should be exploited to a greater extent. As an example, the Italian Central Public Administration requires that all software source code used must be freely available. In addition, any administration buying OSS must give it free to other administrations. Administrations cannot force taxpayers to buy a certain type of software to be able to read public documents. She concluded by raising the question whether the real and only difference between OSS and proprietary software is the licence. Further discussions and comments raised the following points: Several participants, mainly representing proprietary software vendors, insisted that the principle of neutrality should be the guiding criterion for public administrations in a procurement process: The best technical solution should be the criterion for justification of software procurement, regardless of its licence characteristics. Mrs. Marzano pointed out that the licence is not the main criterion for public authorities but a choice between open or closed software. In many cases, characteristics of OSS can be important for the delivery of the service. The neutrality argument was also countered by Rishab Ghosh s worst practice examples of tenders just requesting proprietary products thus excluding OSS bids. Questions were raised on the legality of referring to existing software products in tender specifications. Bart Knubben insisted that tenders should mention the objectives or specifications of a solution rather than the product itself. Cases have been brought to court because specific software products had been cited. Karel De Vriendt brought up the lock-in problem in ICT, which might force you and your successors to buy one specific product over and over again to safeguard compatibility with legacy components. In principle, said Mr. De Vriendt, administrations should not be limited to buying a specific software in perpetuum, because they have made an initial choice. Open Standards are a prerequisite to avoid lock-in. Mr. Ghosh highlighted the fact that proprietary de facto standards with no official recognition of standardisation bodies (CEN, ISO ) can be specified in tenders. He regretted that this is not the case for non-official Open Standards produced by industry consortia such as OASIS. In addition, comments were made on the perceived risk factors for public administration when implementing OSS. Proprietary software might be often preferred by project officers procuring software as they wish to avoid failure risks. Public administrations often do not Page 9/10

10 have the capacity or knowledge to technically implement OSS themselves. Tendering OSS is very often about tendering services instead of products, which makes the comparison between OSS offers and proprietary bids overly complicated. Barbara Held concluded that the morning session had clearly documented the existence of two different spheres of influence with respect to public administration OSS implementation: - an operational level of project implementation where practical questions call for substantial and legally-based considerations and solutions. The speakers have identified problems but also shown that there are solutions. - a political level, where policy considerations sometimes from different sectors - set the frame of action within defining principles. Promoting Open Source means working at both levels. Page 10/10

11 Afternoon Session: Organising European Collaboration Implementing multinational projects Presentation: Models for cross-border collaboration (Patrice-Emmanuel Schmitz) The topics addressed in the second session sought to identify and analyse models for crossborder cooperation between public administrations for further OSS developments. In his introductory comments, Patrice-Emmanuel Schmitz from Unisys pointed out the growing political awareness and high-level commitment towards egovernment services have become a necessity in the EU and can help meeting the Lisbon objectives. Implementing platforms for European e-procurement procedures is a typical example, since e-procurement has high political priority by promising immediate benefits to all interested partners. On the other hand, the complexity of the service renders the project too expensive for small administrations and even small countries. Pooling public OSS developments between national administrations, in this context, is a logical step and should be given priority. The shared use of public financial resources seems desirable. Solutions could be built upon, common standards shared, without neglecting the adaptability of software to local contexts such as languages, culture etc. However, can multinational egovernment projects such as an eprocurement platform be implemented? How can a consortium be formed? How is it possible to handle budget questions and procurement issues between the Member States concerned? These were among the questions researched by an IDABC study. As a result, Patrice-Emmanuel Schmitz proposed several models from which some things can be learnt, but a viable model for egovernment seems to be out of reach for the moment: One model can be drawn from the defence cooperation model in the EU (presently about 25 international projects). These are managed through ad-hoc organisations based on the founding principle of juste retour aiming to ensure work-share benefits for each participating state. However: they are based on high-level international treaties. A second model delegates cooperation to a specific agency such as the newly established European Defence Agency, which mobilises participating states resources to optimise the European Defence Equipment market. In 2006, defence procurement was implemented in an electronic market place to register products, suppliers and customers... However: the establishment of such an institution requires considerable political and organisational effort with uncertain prospects. The public market approach is a plausible approach to foster cross-border OSS cooperation. However, it raises many questions such as budget shares for countries which are not equal in size, sovereignty of states, market holders and possible mandates to be obtained. Therefore: this implies international agreements to issue common tenders etc. At this point in time, the solution to set-up a European funded research project seems to be the most realistic one. However, conditions are linked to R&D projects such as the minimum requirement of three participating countries, a maximum funding of 30%-50% and the need for a very solid proposal with an experienced coordinator. This also remains subject to the publication of calls which need to include the right priorities. Moreover, Consortium agreements, bureaucracy and administrative processes remain long and results uncertain. And: it does not produce a viable model for other cross-border projects. Page 11/10

12 Apart from the organisational and legal questions derived from the cooperation of independent administrations, there also remains the question on how to collaborate with the OSS community: should the projects try to associate themselves with existing communities or should they create their own community? As a result of his analysis Patrice-Emmanuel Schmitz stated that a central EU egovernment software repository could become the essential infrastructure for the sharing of applications at the European level and the solution for organisational as well as legal problems. Mr. Schmitz proposed as the creation of a European egovernment Interoperability Agency which would identify the needs, mobilise the funds for OSS cooperation and act as a central meeting point for existing national agencies. It could contract in any market and implement a strategy together with incentives voluntary contributions. Discussion: Cross-border collaboration - There are no Issues only Solutions (maybe) (Patrick Sinz) Patrick Sinz from Adullact (Association des Développeurs et des Utilisateurs de Logiciels Libres pour l'administration et les Collectivités Territoriales) stated that cross-border cooperation is not an OSS problem, as the community is international. He started the discussion by underlining the lack of information flow between Member States. Public authorities have many common activities but are not always aware of the benefits they could obtain from cross-border cooperation. However, he admitted from the ADULLACT cooperation platform experience, not only are multinational projects extremely complex, but even inter-regional ones. As there are different cooperation levels - between governments, (sub)contractors, OSS communities, etc., there are also different cooperation models government to government, PPPs, community- based grassroot projects etc. Cooperation at all levels is precisely the aim of ADULLACT ( which connects many different actors from the public and private sectors as well as from the OSS community. The experiences with this Government-Forge are very positive: it generates cooperation. A spin-off is now the ADULLACT project, a public-private partnership company, which will deliver consultancy projects. Discussion: The Swedish example (Mats Östling) Mats Östling from SKL emphasised that sharing resources is the priority; cooperation will then follow spontaneously. He explained that 80% of public administrations software developments can be used in other administrations. The focus should lie on the remaining 20% which cannot be used due to different regulations and national standards; these must be adapted to local needs. Sweden has cooperated with Finland and Norway to develop a repository. In Sweden, OSS is developed by professional vendors rather than by volunteers. Cooperation is undertaken essentially on small scale as there is no national ICT policy. Serious discussions are continuing about OSS business models. It is crucial that these models are well-understood by public authorities and that OSS vendors are part of the business model definition and the process by which it is formed. Therefore, central regulation is not needed but cooperation should be community driven. Mr. Ghosh remarked that OSS software development was started by individuals to meet their own needs. Public authorities have different needs and should seek incentives and encouragement for public OSS software development by knowledge sharing, advertisement campaigns, etc. Page 12/10

13 Building a platform for pan-european collaboration Presentation: The European Open Source Repository OSOR (Barbara Held ) The second part of the afternoon session was devoted to the planned IDABC project for an Open Source repository for European egovernment (OSOR). Barbara Held from the IDABC Programme explained the OSS promotion policy framework, as part of the IDABC mission 7 and high-level Commission policy papers such as the eeurope Action Plan 2005 and the more recent i2010 initiative, which puts the emphasis on sharing egovernment applications and experiences. The OSOR intends to go further than the existing Open Source Observatory (OSO) which focuses on the dissemination of good practice: The OSO currently consists of a website containing general information and international news on OSS developments. With the OSOR, IDABC intends to create a cooperation platform for the EU and Member States services. Initial steps have already been taken with a study on Pooling Open Source Infrastructure Software, defining requirements and success factors. Furthermore, the 'software taxonomy for public administrations OSS application has already been developed for the current OSS observatory and has been adapted for the Andalusian adminstration s repository. The related call for tender is on-going. Barbara Held differentiated several functions for the OSOR. The OSOR could function as a spider web connecting existing platforms, thus promoting pan-european synergies and cooperation. Secondly, the OSOR could also operate as a public registry and repository for up- and down-load of OSS applications. A third function would be a cooperation platform with technical and organisational support. Several needs are arise from these functions, such as a state-of-the-art website with adequate tools, management and governance procedures, common policies on publishing, guidelines and licences and support for cooperation. Mrs. Held opened the debate by raising several issues (which are also to be dealt with in a feasibility study) related to the OSOR functions and she also launched a call for ideas: Which functionalities are really needed? Who should take part in the cooperation? Public administrations, vendors, etc. Within which areas should common policies be developed? Compliance certifications, etc. Who should manage the OSOR and how best can its sustainability be ensured beyond the IDABC programme? Are there other services to be provided such as compatibility tests, certifications, and who should provide operational support? Discussion: OSS is not about money (Jan-Willem Broekema) Jan-Willem Broekema representing both, the Dutch OeGov Overheid and the OSOSS Programme presented the Dutch government's OSS policy context. The government acted prior to 2006 as information provider. It is now committed through the OSOSS Programma to consider OSS as a solution for specific needs of the administration. Arguments on why to use OSS do not focus merely on financial resources but also on transparency, security and innovation. He underlined the importance of differentiating OSS from Open Standards. Open Standards ensure interoperability between governments. Specific standards should be promoted to enhance exchange and interoperability. 7 Page 13/10

14 He identified some practical issues to be considered when creating a repository such as the OSOR: Developers do not wish to share solutions until finalised. Developers input and community building should be one focus of cooperation; Legal aspects should be clarified and better communicated as there is a certain fear of the legal implications for public administrations if they share OSS; As development costs are a burden, cost sharing should be given priority in a cooperation platform. The following points were made by the speakers panel: Patrice-Emmanuel Schmitz and other participants acknowledged the need to create a central communication platform: administrations too often reinvent the wheel was the phrase used. The planned OSOR was generally welcomed. The EU should coordinate the OSOR activities. There is a need for actions at the European level to coordinate and support cooperation between the EU and members states. Patrice-Emmanuel Schmitz added that the EU should not impose specific software products. Bart Knubben recommended IDABC taking OSOR step by step starting with connecting existing networks and see if it is necessary to add another layer such as a central repository or collaboration functionalities. In regard to the partners to be involved, Jan-Willem Broekema stated that the success of the Dutch platform was due to the involvement of businesses. Conclusions (Karel De Vriendt) Karel De Vriendt, IDABC Head of Unit, closed the workshop and highlighted some of the day's conclusions: Public authorities need to think about software requirements before choosing a licence. Several parameters need to be taken into account when choosing a licence such as the integration and licence compatibility of different software components, national legal framework and a potential commercial appropriation of the software. Efforts need to be made to educate and inform public authorities about the treatment of OSS licenses. When procuring ICT, public administration should put forward transparency, security and reliability as main criteria. Administrations should be able to justify their choices when evaluating software procurement tenders and aim to mention their requirements and objectives in the tenders rather than specifying software products. The Dutch experience in the framework of the OSOSS programme shows that common standards are paramount to interoperability. This applies also to OSS software. The OSOR will have to further promote the use and the establishment of standards. The Czech IT Minister, Dana Bérová rightfully identified the use of the Open Standards as one of the main challenges when implementing interoperability for public administrations. There is a need to link existing initiatives and build communities composed of administrations with similar problems. Not only administrations should be part of this cooperation, but also businesses and the OSS community, with the aim of developing a European Open Source competence centre. Further ideas and suggestions on OSOR should be sent to Barbara Held Barbara.Held@ec.europa.eu. Page 14/10