European Commission. Open Source Strategy. Date: 18/06/2003 Version: Benoit Mercier & Herman Brand

Transcription

1 EUROPEAN COMMISSION DIRECTORATE-GENERAL PERSONNEL AND ADMINISTRATION Informatics Directorate Office systems and technical support European Commission Open Source Strategy Date: 18/06/2003 Version: Authors: Benoit Mercier & Herman Brand Revised by: Monique Limbos Approved by: Jose Marin Navarro Public: Reference Number: Commission européenne, L-2920 Luxembourg. Telephone: (352) Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) Office: IMCO 3/8. Telephone: direct line (32-2) Fax: (32-2) herman.brand@cec.eu.int

2 Document History Version Date Comment Modified Pages /06/2003 Document created by Herman Brand & Benoit Mercier all Contacts: Benoit Mercier, Telephone:(32-2) , Herman Brand, Telephone:(32-2) , Open Source Strategy - Page i

3 PREFACE PART I - OPEN SOURCE SOFTWARE - STRATEGY 1. OPEN SOURCE STRATEGY - INTRODUCTION STRATEGY JUSTIFICATION IMPLEMENTATION OF THE STRATEGY: WORKING PLAN OPEN SOURCE Evaluate current use of OSS in the Commission Consolidate Linux as a server platform Improve OSS product management and use Promote Internal OSS community Evaluate OSS products and solutions... 8 PART II - OPEN SOURCE SOFTWARE - STRATEGY - SUPPORTING DOCUMENT 1. OPEN SOURCE SOFTWARE - INTRODUCTION OPEN SOURCE SOFTWARE DOMAIN CLASSIFICATION Operating System Technical infrastructure Server tools Development tools Desktop tools "Out of the box" tools USE OF OSS AT THE COMMISSION Operating systems Server Desktop Technical infrastructure Server tools File and print servers Web Servers Application servers Database servers Other tools related to technical infrastructure... 5 Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) Office: IMCO 3/19. Telephone: direct line (32-2) Commission européenne, L-2920 Luxembourg. Telephone: (352) benoit.mercier@cec.eu.int

4 3.4. Development tools Desktop tools "Out of the box" tools DOCUMENT MANAGEMENT AND ARCHIVING IMPLICATIONS Product management Resources Support Security Development process Training WORKING PLAN OPEN SOURCE Evaluate current use of OSS in the Commission Perform a detailed survey on the OSS used in the DGs Consolidate Linux as a server platform Linux/Unix and ETP platform interoperability study Definition of a Linux Single Application Host Reference Configuration Migration of Circa from Unix and deployment on Linux Consider classification of Linux as a Class B product Evaluate clustering and scalability functionality available under Linux Improve OSS product management and use Adaption of product management guidelines to allow for the particularities of Open Source Software solutions Clearly indicate that OSS solutions will be admissible when publishing calls for tender Promote Internal OSS community Creation and leading of the Commission OSS community Definition of development best practices for applications based on OSS (continuous integration) Evaluate OSS products and solutions Evaluate and test Application server solutions: Jboss, Tomcat Evaluate and test OSS Database solutions: MySQL and PostGreSQL Evaluate scripting and development languages: PHP, Python Based on evaluations compose a "deployment OSS package" for external deployment and re-use (especially web applications) by external parties like Member States Monitor the OSS Desktop evolution... 9 ANNEXE I - OPEN SOURCE DEFINITION

5 Preface This document contains two parts. Part I has been devoted to the description of the proposed Open Source strategy. Part II contains background information related to Open Source Software and the various tools that exist. Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) Office: IMCO 3/19. Telephone: direct line (32-2) Commission européenne, L-2920 Luxembourg. Telephone: (352) benoit.mercier@cec.eu.int

6 PART I Open Source Software - Strategy Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) Office: IMCO 3/19. Telephone: direct line (32-2) Commission européenne, L-2920 Luxembourg. Telephone: (352) benoit.mercier@cec.eu.int

7 1. OPEN SOURCE STRATEGY - INTRODUCTION Open Source Software (OSS) is software which source code is openly published, which is usually available at no (license) charge, and which is often developed by voluntary efforts. A full definition has been built up by the Open Source Initiative. Their Open Source definition can be found in Annexe 1. Important to point out is that although many OSS packages are available for free, OSS is not necessarily free, and they are not zero cost software either. OSS is starting to bring fundamental changes to the software marketplace, it is proven not to be just hype, and this is recognised by the European Commission Informatics Directorate. Internally, the Commission's response to OSS to date has been the establishment of an opportunistic strategy (December 2000) that notably produced the recommendation of Apache Web Server as the preferred choice in the domain of Web Servers on Unix and Linux. As a result of that strategy, Systran a translation application has been running in the Data center on Linux for some years now and Linux has been integrated in the Call for tenders for server hardware. In addition, it implemented the mandatory consideration of OSS alternatives for all software and hardware acquisition procedures. Commission developers are also using OSS tools such as Ant, CVS or JUnit that help to significantly improve the software development process and constitute the technical basis of the OSS development model. Now, it is considered necessary to define and implement a more explicit internal policy on the use of OSS within the Commission I.T. infrastructure and this document will layout that policy. 2. STRATEGY The key items of this policy are as follows: The Commission will formalise the use of OSS where a clear benefit can be expected. The Commission will continue to consider OSS solutions alongside proprietary ones in IT procurements. Contracts will be awarded on a "value for money" 1 basis. For all future IT developments, the Commission shall promote the use of products that support recognised, well-documented standards. Inter-operability is a critical issue for the Commission, and usage of well-established open standards is a key factor to achieve and endorse it. For all new development, where deployment and usage is foreseen by parties outside of the Commission Infrastructure, Open Source software will be the preferred development and deployment platform. 1 Not only licence costs but also setup, maintenance, support and training costs should be considered Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) Office: IMCO 3/19. Telephone: direct line (32-2) Commission européenne, L-2920 Luxembourg. Telephone: (352) benoit.mercier@cec.eu.int

8 3. JUSTIFICATION The justification for adopting this policy is that every effort should be made to reduce the cost and risk to Commission systems. Adopting this policy helps to achieve this by: Always procuring the solution that gives the best value for money. Oss solutions will always be included in the evaluation of the software. The software that will be selected may be an OSS solution, a proprietary one, or a mixture of both. Decisions should be made on a case by case basis. Ensuring that inter-operability of systems is provided and maintained by always implementing well-established open standards, a guarantee of perennial investment. OSS is particularly meaningful in this field. Reducing or removing the dependency on individual IT suppliers Providing more flexibility in the development, enhancement and integration of systems. In this respect, access to the source code is clearly an improving factor. Maintaining the security and integrity of Commission systems. Properly configured OSS can be at least as secure as mainstream proprietary systems. 4. IMPLEMENTATION OF THE STRATEGY: The following permanent actions will be taken to implement this policy: This policy will be made available to all those involved and interested in areas of the software infrastructure, application development and procurement. The procurement procedure will be adapted so that OSS solutions can be purchased. The technical file of product selection procedures for a certain infrastructure or application domain will describe what OSS alternative was available and how it has been evaluated. The decision whether or not to include OSS solutions in the selection procedure will have to be justified, just like it would be for any other product. 5. WORKING PLAN OPEN SOURCE The following objectives have been associated to the Open Source Software working plan for the next two years Evaluate current use of OSS in the Commission Perform a detailed survey on the OSS used in the DGs 5.2. Consolidate Linux as a server platform Linux/Unix and ETP platform interoperability study Definition of a Linux Single Application Host Reference Configuration Migration of Circa from Unix and deployment on Linux Consider classification of Linux as a Class B product Evaluate clustering and scalability functionality available under Linux 5.3. Improve OSS product management and use Adaption of product management guidelines to allow for the particularities of Open Source Software solutions. Clearly indicate that OSS solutions will be admissible when publishing calls for tender. 7

9 5.4. Promote Internal OSS community Creation and leading of the Commission OSS community Creation of infrastructure to support the community (like an intranet site amongst other things). Definition of development best practices for applications based on OSS (continuous integration) 5.5. Evaluate OSS products and solutions Evaluate and test Application server solutions: Jboss, Tomcat Evaluate and test OSS Database solutions: MySQL and PostGreSQL. Evaluate scripting and development languages: PHP, Python. Based on evaluations compose a "deployment OSS package" for external deployment and re-use (especially web applications) by external parties like Member States Monitor the OSS Desktop evolution 8

10 PART II Open Source Software Strategy - Supporting Document Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) Office: IMCO 3/19. Telephone: direct line (32-2) Commission européenne, L-2920 Luxembourg. Telephone: (352) benoit.mercier@cec.eu.int

11 1. OPEN SOURCE SOFTWARE - INTRODUCTION Open Source Software (OSS) is software of which the source code is openly published, which is usually available at no license charge, and which is often developed by voluntary efforts. A full definition has been built up by the Open Source Initiative. Their Open Source definition can be found in Annexe 1. In December 2000, the Commission defined an opportunistic strategy concerning this software. It allowed, for instance, the recognition and the use of the Apache Web Server as a recommended solution on Unix systems. It was also recommended to further investigate Linux. Now, the Linux Intermediate report opens new doors in the operating system field by comparing Linux to other Unix' flavours. It has lead to the consideration of Linux as the preferred platform for Apache and as the possible base software for single application host machines. OSS' credibility has been publicly established when market giants such as HP, IBM and Sun threw their weight behind it. More and more government administrations and Universities in the World, and, particularly in Europe, are using or moving to OSS solutions to satisfy their needs. OSS is currently widely used in DG's but it is difficult to appraise the exact situation as it is often considered an underground activity mainly due to the lack of official acknowledgement. There is no time like the present to update the strategy for the internal use of Open Source Software in the I.T. infrastructure of the Commission. 2. OPEN SOURCE SOFTWARE DOMAIN CLASSIFICATION In this section a software classification is used in order to highlight domains where OSS solutions are available and viable Operating System Linux is the flagship in the range of operating systems available for free on the Internet. Programmers from around the world teamed up to develop the original kernel, and then private companies and others adapted the work to create their own unique Linux flavours called distributions. These distributions go by a variety of names, including Red Hat, SuSE, Mandrake, Debian, etc. Currently, Red Hat and Suse have been eveluated as the best solutions, closely followed by Mandrake (Linux Evaluation study intermediate report). Today, some major distributors joined together to create UnitedLinux. UnitedLinux is a standards-based, worldwide Linux solution targeted at the business user and developed by Conectiva, The SCO Group, SuSE, and Turbolinux. It is designed to be an enterprise-class, industry-standard Linux operating system. This should allow hardware and software vendors (amongst others) to support a single high value Linux offering rather than many different versions. Distributions inside the union will survive but they will share a common basis and will be allowed to bear the label "UnitedLinux". The current situation can be summarised like this: volunteers maintain one common Linux kernel and two major distribution flavours are proposed: UnitedLinux and RedHat. The Linux operating system can be used with a wide variety of hardware, from workstations to multi-processors clustered servers and mainframes. Open Source Strategy - Page 1 / 11

12 2.2. Technical infrastructure OSS related to technical infrastructure are numerous: 2.3. Server tools network: DNS Server (e.g. BIND is used on the vast majority of name serving machines on the Internet), etc. connectivity: Remote Access Services (e.g. Radius), etc. security: firewall (Suse Firewall, OpenRouter, etc.), proxy (e.g. Squid), etc. various protocol implementations: Samba allows connectivity between "Unix like" systems and Windows, etc. monitoring, etc. OSS server tools are broadly used today in a variety of fields: Web server: Apache J2EE application server: JBoss, JonAS, Tomcat Other application servers like PHP server and Zope Directory server: OpenLDAP Database servers (MySQL, PostgreSQL, FireBird, etc.) Mail Server, FTP server, News server, etc. Most of these tools can be used on all major operating systems (Windows, Unix, Linux, etc.). Examples: Apache, PHP, JBoss, MySQL, Firebird, etc Development tools This class contains software allowing developers and communities to work efficiently: Language specific IDE (Integrated Development Environments): Eclipse (Java), etc. Source code/project deliverables repository: CVS Server-side scripting tools: Perl, TCL, Python, etc. And a lot of de-facto standard tools that facilitate the developer's work and improve the overall quality of a project development: Ant, JUnit, etc. Most of these tools can be used on all major operating systems (Windows, Unix, Linux, etc.). Examples: Eclipse, CVS, Ant, etc. Libraries of reusable code are also an important part of the developer's tools. OSS code libraries are numerous and often become de-facto standards like the one for playing with XML (Xerces, Xalan, etc.), managing log statement in Java code (log4j), adopting an MVC framework in JSP driven websites (Struts, etc.) 2.5. Desktop tools A great many OSS applications, covering the need of almost all technical and non technical workstation users are available: Internet browsers, Office suites, editing and publishing tools, image manipulation programs, etc. Open Source Strategy - Page 2 / 11

13 Most of these tools can be used on all major operating systems (Windows, Unix, Linux, etc.). Examples: the Mozilla web browser ("Netscape"), OpenOffice office tool suite or The Gimp (image manipulation). Linux distributions come with powerful Graphical User Interfaces build on top of the original Linux kernel: KDE and Gnome are the best known free and easy-to-use desktop environments for the user, as well as powerful application frameworks for the software developer. More and more "traditional" proprietary products exist for these environments "Out of the box" tools This category of software grows continuously. Viable OSS solutions exist in various fields: Web Content Management: Zope, Plone, PostNuke, etc. Developer Community: GForge Bug tracking systems: Bugzilla, Scarab, Jira, GNATS, etc. Meta data repository: RIB 3. USE OF OSS AT THE COMMISSION The rationale behind the strategy is to formalise the use of Open Source Software where a clear benefit can be expected. Benefits can be financial, technical or tactical. Evidently, the strategy will have to be applied in accordance with the product management procedures that have brought harmonisation in the products used at the Commission today. The previous strategy has lead to the wide adoption of the Apache Web Server and to the conclusion that Linux is a suitable operating system for web and application servers. The next priority step is to consolidate Linux as a server platform including reference configuration, that supports web applications and can be used as dedicated server for specific purposes (Single Application Host). It means that at least the following products must be running: Apache web server and ColdFusion server. Oracle and BEA server should also be considered. Full OSS boxes should be considered for specific problems (e.g. CIRCA). It could be a possible answer to delegations and agencies requirements. And a solution for interaction with other Member States, including the new Member States of Eastern Europe. The following sections describe the areas where OSS could play an important role and whether it is relevant or not for the Commission Operating systems Server Linux is a suitable operating system for web and application servers and is a convenient answer to the current need of small web application "black box" servers. The Commission will continue considering Linux as viable alternative for Unix operating system on server machines. In addition, the actions resulting from the Linux evaluation intermediate report are underway Desktop To be in a comparable situation to the one we have today, we would have to rebuild a reference configuration based on an Open Source operating system. This would bring the necessity to evaluate functionally and technically the 40 software elements composing it, and supporting more than 10 different hardware configurations. Moreover, the applications currently deployed Open Source Strategy - Page 3 / 11

14 under the client-server model, such as the SICs or other local information systems would have to be rewritten. The Web model is recommended for the application development, allowing a better independence from the client operating system. The recommendation is to continue to monitor the evolution of Linux and associated management and Office tools, but to keep the situation as it is today for the standard office workstation. DG Infso are currently evaluating Linux desktops (about 70) to appraise the feasibility of their use in the Commission environment Technical infrastructure OSS are particularly complete and reliable in this field. BIND (DNS) and Samba are de-facto standards for integrating heterogeneous systems. OpenLDAP is already used at the Data Centre as a proxy server. The use of tools such as Amanda should be envisaged for the backup of local Linux systems. The Commission will continue monitoring and promote the use of OSS that may be useful in the infrastructure fields: network services, security, backup, web logs analysis (ex. Analogue), etc Server tools File and print servers "File and print" facilities are essentials to every operating system since almost any type of applications uses those features. Linux and Samba allow connectivity with the existing Windows based systems (file and print sharing). However, the different security models and the need of specific drivers do not allow a global support or a recommendation as the general model for the Commission infrastructure. Nevertheless, major companies (HP, IBM, etc) begin to sell Linux File & Print server black boxes. Some of these very conveniently update desktop printer drivers automatically. The Commission should stay alert: the option exists and is valid Web Servers The Apache web server is recognised and use widely and is on the Commission product list. The Commission will continue using Apache as the preferred Web server on Unix and Linux systems and will study its potential recommendation on Windows NT/W2K systems Application servers The Commission currently uses two proprietary application servers: BEA WebLogic (J2EE applications) and Macromedia ColdFusion. The needs are well covered and these services are widely available for use at the Data Centre. Competitive OSS solutions exists in J2EE and web scripting fields. J2EE applications server like JBoss or JOnAS and servlet containers like Tomcat are some of them. PHP is a web scripting language/server offering comparable functionality to those of ColdFusion. The quality and support of standards of these servers are widely recognised. The Commission is satisfied with the current situation and benefits from using other application servers are not visible at this time. Nevertheless, some positioning and evaluating work will be done in this domain to assess the viability of OSS application servers in some circumstances (to be defined) where, for instance, the possibility of freely (re)distribution of the server and the application is needed or where the licence cost of the solution is crucial. Open Source Strategy - Page 4 / 11

15 The Commission has to stay open and pay attention to the available OSS solutions, particularly for wide diffusion of applications Database servers The need of database management systems is already covered by the Commission use of Oracle and there is no direct benefit to switch to OSS solutions. Nevertheless, some positioning and evaluating work will be done to assess the viability of OSS databases (MySQL, PostGres, FireBird, etc.) under certain conditions (to be defined). The Commission has to stay open and pay attention to the available OSS solutions, particularly for wide diffusion of applications Other tools related to technical infrastructure Any other OSS tool that could be useful in monitoring or administering systems should be considered, particularly for web application "black box" servers previously described. The availability of OSS products must be carefully checked for system services like backup, clustering and monitoring as well the way to integrate it in the architecture and with tools currently in place Development tools Tools such Ant, JUnit and CVS are de-facto standards that facilitate the developer's work and improve the overall quality of a project development. The Commission will promote the use of such tools for achieving continuous integration during development cycle. In the field of reusable code libraries, the use of the Xerces OSS parser is now a DI recommendation. The use of such libraries (Xalan, log4j, JUnit, etc.) will be studied and eventually recommended wherever a clear benefit can be expected. At the Commission, the need for a Java IDE is already covered by JBuilder and does not deserve a move to OSS solutions. A study into the Java IDE market has been performed and has been published Desktop tools Depending on local needs, as always, specific products can be used to cover specific needs, without globally organised support. If the OASIS initiative of defining a common open document model succeed, the Commission should carefully evaluate this format and assess the gain that adopting it might bring in terms of independence and perennial investment (see 4). This includes the evaluation of OpenOffice suite for instance "Out of the box" tools Tools like Plone, GForge, Bugzilla, etc. could be used to support collaborative work around developer and/or user communities. The Commission will consider using such tools leveraging teamwork. Zope (and Plone again) are very interesting solutions in the field of Web Content Management. Evaluation and positioning work could be envisaged in this domain. 4. DOCUMENT MANAGEMENT AND ARCHIVING Documents are the kernel and memory of an organisation such as the Commission. Tools used to create these documents have been changing over time and, of course, the technical format has been changing too. When it comes to archiving and managing document-centric content, a Open Source Strategy - Page 5 / 11

16 common format is needed. To solve this kind of problem, the use of standards, non-proprietary formats to save documents, is a key factor. OSS can definitely help in this area. Notably, the Organisation for the Advancement of Structured Information Standards, or OASIS, has created a technical committee that will attempt to conform data stored in office documents to a standard file format based on XML ( One of the goals of the group, called the Open Office XML Format Technical Committee, is to free corporate data from proprietary file formats so they can be accessed for years to come no matter what office software a company is using. Proponents contend that companies are currently saving data in proprietary file formats, such as those written in Microsoft's Word software, and locking themselves into using that software indefinitely ( Matt Berger, 20 th November 2002). Choosing a common office document format and tools allowing to work with it may help to lower the dependency on individual IT suppliers. A choice has to be made for the past (conversion) and future (conversion or new tools) documents. 5. IMPLICATIONS 5.1. Product management The Commission will pursue the current product management strategy that takes into account OSS when selecting any product, evaluating its community as a virtual vendor Resources The use of OSS "as is" requires in general the same resources as proprietary products and varies per product. However, if the Commission wants to modify/adapt some OSS to their needs or participate actively to the OSS development community, they will have to devote appropriate resources Support The OSS support model is quite different from what we are used to. The Open Source community generally assures support via the Internet, through mailing lists, newsgroups, etc. The person encountering the problem is responsible for it until the solution is found. The support offered is known to be very effective and of a high quality, at least for major projects (Samba, Apache). Furthermore, a lot of "traditional" companies have started to sell services and support covering OSS products (Apache, PHP, JBoss, MySQL, etc.). Our current support model for the proprietary development products is centralised, with different levels of intervention depending on the urgency or importance of the problem, allowing us to have a global overview of the open problems for each product and the issues pending. We may need to organise the support for OSS in such a way that we take advantage of both models. Another kind of support should be provided: an Intranet (IntraComm) access to resources related to OSS. List of selected OSS tools in each category, forum, guidelines, etc. This is the responsibility of the "Commission OSS Community". We might have to contract "integrator" companies to supply the necessary support Security Just like for any other product, OSS must be included in security projects like DAVID (Deployment of an enhanced AntiVIrus Defence) and HOLMES (put in place a security bulletin service for the DGs). Subscription to sources dedicated to the diffusion of security related information will be implemented, in line with the current product management policies. Open Source Strategy - Page 6 / 11

17 5.5. Development process OSS is developed by communities. These communities had to learn working in team in a very structured and organised way. Therefore they developed powerful techniques that helps to manage development process. The independence offered by the use of such tools is a guarantee for a secure investment. The Commission will recommend the use of OSS techniques (continuous integration) for improving the quality of internal development processes. This could bring major enhancements in our development project management. The "Commission OSS Community" will provide the means to take advantages of the community development approach Training The "FormTech" call for tender covers Open Source Software training, and provides the necessary to cover potential demands and requests for training. 6. WORKING PLAN OPEN SOURCE The following objectives have been associated to the Open Source Software working plan for the next two years Evaluate current use of OSS in the Commission Perform a detailed survey on the OSS used in the DGs The goal of this survey is to get a complete and detailed inventory of OSS that are currently in use (or planned to be used) in DG's production systems Consolidate Linux as a server platform Linux/Unix and ETP platform interoperability study This project is aimed at establishing Unix'like systems configuration parameters to ensure interoperability between Unix, Linux and ETP configurations (security, file and print sharing, etc.). The study is now (15/05/2003) in the final review phase Definition of a Linux Single Application Host Reference Configuration The goal is to describe and evaluate Oracle and Coldfusion deployment on Linux servers in order to establish a Linux Single Application Host Reference Configuration. This should help to build a more flexible IS deployment architecture. This project may also lead to positionning Linux as an alternative to Unix for internal DG use Migration of Circa from Unix and deployment on Linux Circa migration project consists in the description and evaluation of the hardware and software related issues for moving Circa to Linux platform. The selection of the hardware configuration using the new Dell Contract is the main issue, taking into account the 24*7 and full failsafe deployment implications Consider classification of Linux as a Class B product As the use of Linux is now formalised, the classification as a Class B product seems to be the natural following step in the process. The way to achieve this classification is the goal of this action that encompasses several others described in this chapter. Classification supposes support, training and evolution follow-up. Open Source Strategy - Page 7 / 11

18 Evaluate clustering and scalability functionality available under Linux This action will answer the following question: is it possible to configure Linux machines and clusters to achieve high level of reliability and scalability without entailing special hardware? 6.3. Improve OSS product management and use Adaption of product management guidelines to allow for the particularities of Open Source Software solutions Current product management and procurement procedures are going to be adapted to avoid excluding OSS solution offers because they do not fit into the traditionnal economic model. The action will consist of a first study phase followed by the appropriate adaptation of the procedures Clearly indicate that OSS solutions will be admissible when publishing calls for tender The tenderers should be informed that the Commission is ready to evaluate and use OSS. This may encourage integrator companies to reply to Call for Tenders with OSS solution based offers. The way to do it has to be defined and implemented Promote Internal OSS community Creation and leading of the Commission OSS community The goal is to create and animate a place to share experiences related to OSS practuces and products in the Commission and guarantee their promotion and visibility througouht all distribution bodies. The OSS working model will be promoted within the community also for non OSS solutions/products/projects. Several DI units are involved in this action: STB, ISIQ and SSI are the principal ones. This action implies the creation of an infrastructure to support the community (like an intranet site amongst other things) Definition of development best practices for applications based on OSS (continuous integration) They are many things to learn from the collaborative development model inherent to OSS that can be extremely valuable for any development projects. The objective of this action is to propose a way to manage development projects from the technical point of view based on tools and methods that made the success of numerous OSS projects. This will essentially provide DGs with guidelines for the development of applications that will propose a set of products and a way of working to develop Java/J2EE applications based on the recommended Java IDE (Jbuilder) and a set of open source products or technologies (CVS, Ant, JUnit...) Evaluate OSS products and solutions These actions are part of the continuous work of the DI unit in charge of technology watch. Evaluating and testing OSS application servers, databases or languages will help to better understand their particularities and may lead onto some recommandation use in some specific situations. Open Source Strategy - Page 8 / 11

19 Evaluate and test Application server solutions: Jboss, Tomcat Evaluate and test OSS Database solutions: MySQL and PostGreSQL Evaluate scripting and development languages: PHP, Python Based on evaluations compose a "deployment OSS package" for external deployment and re-use (especially web applications) by external parties like Member States Monitor the OSS Desktop evolution Open Source Strategy - Page 9 / 11

20 ANNEXE I - OPEN SOURCE DEFINITION Introduction Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: (1) Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. (2) Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicised means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a pre-processor or translator are not allowed. (3) Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. (4) Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (5) No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. (6) No Discrimination Against Fields of Endeavour The license must not restrict anyone from making use of the program in a specific field of endeavour. For example, it may not restrict the program from being used in a business, or from being used for genetic research. (7) Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. (8) License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. (9) The License Must Not Restrict Other Software Open Source Strategy - Page 10 / 11

21 The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. (10) *The License must be technology-neutral No provision of the license may be predicated on any individual technology or style of interface. Origins: Bruce Perens wrote the first draft of this document as "The Debian Free Software Guidelines", and refined it using the comments of the Debian developers in a month-long conference in June, He removed the Debian-specific references from the document to create the "Open Source Definition." Copyright 2003 by the Open Source Initiative A list of Open Source Initiative approved licenses can be found at: Open Source Strategy - Page 11 / 11