NATO UNCLASSIFIED

Enclosure 1AC/322(SC/1)N(2007)0011AC/322(SC/4)N(2007)0014AC/322(SC/5)N(2007)0016

STRATEGYFOR THE USE OF

OPEN SOURCE SOFTWARE (OSS) IN NATO SYSTEMS

(07 JULY 2007)

NATO UNCLASSIFIED(i)

NATO UNCLASSIFIED

TABLE OF CONTENTS

REFERENCE DOCUMENTS

EXECUTIVE SUMMARY

1. INTRODUCTION1.1 Background1.2 Need for OSS Strategy1.3 Open Source Software (OSS)1.4 OSS versus Proprietary Software1.5 OSS Usage Model

2. TARGET GROUPS2.1 System Acquisition Managers2.2 Budget Managers2.3 Policy Makers

3. SCOPE

4. PURPOSE

5. OBJECTIVES FOR USING OSS5.1 Objectives5.2 Conditions for meeting Objectives

6. KEY AREAS AND CRITERIA6.1 Architectures and Standards6.2 Migration and Integration6.3 Management, Support and Maintenance6.4 Repository and Licensing6.5 Security6.6 Training6.7 Funding6.8 Distribution6.9 Total Cost of ownership

7. WAY AHEAD7.1 Short Term (1-2 years)7.2 Medium Term (3-4 years)

8. GOVERNANCE8.1 Approval Authority of Strategy8.2 Execution Authorities of Strategy

NATO UNCLASSIFIED(ii)

NATO UNCLASSIFIED

REFERENCE DOCUMENTS

(a) NATO Software Management Guidance, EAPC(NC3-B)D(2003)007, 2 October 2003

(b) NATO C3 System Architecture Framework, AC/322-D(2004)002(INV), dated 7 January 2004

(c) NATO C3 Technical Architecture (NC3TA), EAPC(AC/322-SC/5)N(2006)0021, dated 12 April 2006

(d) NATO Interoperability Standards and Profiles (NISP) EAPC(AC/322-SC/1-WG/4)N(2007)0001, dated 5 April 2007

(e) NATO CIS Configuration Management Policy and Directive, AC/322-D(2006)0052, dated 28 August 2006

(f) Security Implications of Using Open Source Software (OSS) in NATO, AC/322(SC/4)WP(2004)0012, 7 July 2004

(f) INFOSEC Technical and Implementation directive for computer and Local Area Network (LAN) Security, AC/322-D/0048, 29 April 2002

NATO UNCLASSIFIED(iii)

NATO UNCLASSIFIED

EXECUTIVE SUMMARY

The Military Budget Committee (MBC) requested the NATO C3 Board (NC3B) to conduct a study into non-proprietary software solutions such as Open Source Software (OSS) for use in NATO systems. These other solutions could be considered as alternatives to single source enterprise agreements when screening budgets for IT-systems. In response to the MBC study request, the NC3B tasked the former Information Systems Sub-Committee to develop a strategy for the use of OSS and other software for NATO funded systems.An explicit strategy on the use of OSS within NATO is required to ensure that NATO exploits the benefits that OSS can offer in a systematic and balanced way when selecting software for NATO systems. The target group of this strategy is NATO system managers (including acquisition managers), budget managers and policy makers.

OSS has initiated a fundamental change in the software infrastructure marketplace. The model of the OSS market is based upon the concept of users getting ‘free’ software and paying for ‘value added’ services where required. The potential application of OSS in NATO covers a wide spectrum, ranging from its use as a commodity, provided and supported by commercial providers, to NATO’s active involvement and leadership in developing, supporting and distributing Open Source code.

The purpose of this strategy is to enable a structured approach to the adoption of OSS in NATO systems through the identification of key areas, with their associated criteria, required for the objective selection of OSS or proprietary software to meet specific user requirements. The objectives for using OSS are: Less dependency on single vendors and proprietary technology, Cost reduction, and Improvement of interoperability of systems through the use of Open Standards.

The following key areas to be considered for selection of OSS are addressed in the strategy, with their associated criteria: Architectures and standards, Migration and Integration, Management, Support and Maintenance, Repository and Licensing, Security, Training, Funding, Distribution, and Total Cost of Ownership.

NATO UNCLASSIFIED(iv)

NATO UNCLASSIFIED

The strategy provides the following recommended way ahead for the short term (1-2 years):

(a) Use of OSS and Proprietary Software: NATO project and program offices are to consider OSS and proprietary solutions equally for IT procurements for NATO systems, based on value for money and fit for purpose principles by applying the criteria in this strategy.

(b) OSS Pilot projects: In order to fully exploit the benefits of OSS in NATO programs, program managers should establish feasibility studies and pilot projects to study and test the viability of the OSS approach in their respective programs.

(c) Open Standards: Adherence to the use of Open Standards in OSS for the exchange of information in a mixed environment of proprietary software systems and OSS based systems should be mandatory for NATO systems.

(d) INFOSEC Operational Procedures: Operational security guidance , developed under the lead of Information Assurance Sub-Committee, concerning the INFOSEC aspects of deploying, operating and managing OSS are the same as in proprietary software and shall be followed.

(e) Legal Aspects of OSS Licenses: NATO legal authorities should investigate the legal aspects of OSS licensing and provide clear guidelines concerning the use of different OSS license types in NATO systems.

The strategy provides the recommended way ahead for the longer term (3-4 years) as follows:

(a) Implementation plan for the use of OSS in NATO: Based on NATO and nations experience, results of feasibility studies and pilot projects, the possibility of expanding the deployment of OSS components should be investigated for the longer-term, including its consideration as the default exploitation route for NATO funded software where practical and cost-effective.

(b) Open Standards strategy: The NOSWG should develop a strategy to encourage cooperation between users of Open Standards and OSS and help ensure the use of common Open Standards within OSS.

NATO UNCLASSIFIED(v)

NATO UNCLASSIFIED

1.1. INTRODUCTION

1.1 Background

1.1.1 In October 2002, the Military Budget Committee (MBC) voiced concerns over the software license agreements acquired via Select and Enterprise agreements under sole source procurement rules. It requested the NATO C3 Board (NC3B) to conduct a study of other software solutions such as the use of Open Source Software (OSS) to report in time for the post-2005 selection process. The NC3B tasked its former Information Systems Sub-Committee (ISSC) to develop a NATO strategy for the use of OSS to allow software alternatives for NATO funded systems. This document is intended to meet this requirement.

1.2 Need for OSS Strategy

1.2.1 OSS is already in significant use in a growing number of NATO systems, both large and small. However, in order to ensure that NATO fully exploits the benefits of such use, it is necessary to adopt a more systematic and balanced approach to the selection of software for NATO systems. An explicit strategy on the use of OSS within NATO is required to ensure consideration of OSS for NATO systems based upon an objective assessment of relevant selection criteria.

1.3 Open Source Software (OSS)

1.3.1 OSS is software whose source code is developed, tested and enhanced in an open exchange of information environment, often through the voluntary efforts of business and academic software experts. It is usually made freely available without a license fee under an open software development process to prevent it being subsequently redistributed under a more restricted license. This innovative approach of OSS has had a significant impact upon the software infrastructure marketplace.

1.4 OSS versus Proprietary Software

1.4.1 OSS is characterised by the openness of code and the absence of a single controlling entity. In contrast, the workings of proprietary software are usually kept hidden, protected under the terms of the license the owner of the software has laid down.

1.4.2 In switching from proprietary software to OSS direct savings can be made in license payments. On the other hand, there will be increased costs for services such as software management, training and building up expertise among system managers. The model of the OSS market is based upon the concept of users getting ‘free’ software and paying for ‘value added’ services, where required.

1.4.3 The principal question is: to what extent can and should OSS supplement or replace proprietary software? OSS offers opportunities to provide product diversity in the

NATO UNCLASSIFIED- 1 -

NATO UNCLASSIFIED

acquisition of NATO systems, which will reduce the costs and risks of being wholly dependent upon a single software supplier. In addition, OSS is based on Open Standards, which makes it independent of proprietary solutions and relatively easy to replace or to integrate with other Open Standards based products. However, other factors must also be considered, such as the cost of change and the overhead of having to maintain both OSS and proprietary software simultaneously.

1.5 OSS Usage Model

1.5.1 The potential application of OSS in NATO covers a wide spectrum, ranging from its use as an out-of-the-box commodity provided and supported by commercial providers, to NATO’s active involvement and leadership in developing, supporting and distributing OSS code.

1.5.2 The gradations of OSS usage in NATO are as follows:

(a) Using unchanged common available OSS packages obtained from a commercial provider responsible for packaging, distribution, support, training, etc.

(b) Using a commercial provider to adjust OSS to meet specific NATO purposes, for example by changing configuration settings and files and supplying additional integrating OSS packages to provide a NATO OSS desktop suite.

(c) Using OSS from approved sources without commercial support. In this case, NATO would be responsible for obtaining OSS source code from the OSS community (for example by downloading from the Internet) and compiling, packaging, configuring, distributing and supporting the product internally.

(d) Using and modifying OSS, typically by changing source code, to provide functionality to meet NATO specific needs. In such circumstances, NATO Organisations might contribute to the OSS community through participation in the improvement of the OSS published baseline by proposing improvements, requiring critical updates, etc.

(e) Using OSS to create new applications. In this case, NATO would develop, publish, and sponsor OSS and share it with the OSS community in order to solicit feedback and contributions to improve its functionally and quality. Use of such software would be open to the entire OSS community.

1.5.3 The type of OSS usage will largely determine the way in which the life-cycle of a particular system component is managed and hence its impact on the “Total Cost of Ownership” of the OSS component.

NATO UNCLASSIFIED- 2 -

NATO UNCLASSIFIED

2.2. TARGET GROUPS

2.1.1 System Acquisition ManagersThis strategy is primarily aimed at those responsible for NATO systems acquisition, offering guidance in software selection during the planning, design and maintenance phases of new projects and when updating existing systems.

2.1.2 Budget ManagersThis strategy is also aimed at the NATO budget managers, in support of the screening of software choices on a value for money principle within NATO projects.

2.1.3 Policy MakersThis strategy is also aimed at alerting NATO policy and decision makers to the potential benefits of OSS when setting other strategies for ensuring interoperable systems.

3.3. SCOPE

This strategy shall be used for the planning of all new and updates to existing NATO systems which require the acquisition or development of software.

4.4. PURPOSE

The purpose of this strategy is to enable a structured approach to the adoption of OSS in NATO, by identifying key areas and criteria against which the selection of OSS to meet NATO requirements can be objectively determined.

5.5. OBJECTIVES FOR USING OSS

5.1 Objectives

The overall objectives of using OSS are as follows:

5.1.1 Less dependency on Single Vendors and Proprietary Technology NATO software selection procedures shall seek to remove or to minimize reliance on ‘vendor lock-in’ to proprietary products and services. OSS can provide for a significant reduction of vendor dependency and can increase flexibility of choice. Because the source code is freely available, any suitable company can be selected to integrate, update or maintain the software.

5.1.2 Cost reduction Every effort shall be made to select a software solution that reduces total cost of ownership for a system and gives value for money to NATO. This may be an OSS solution, a proprietary one, or a mixture of both. Decisions shall be made on the basis of the key areas and associated criteria provided in this strategy.

NATO UNCLASSIFIED- 3 -

NATO UNCLASSIFIED

5.1.3 Improvement of interoperability of systems In order to ensure interoperability among NATO systems and between NATO and national systems, products that support open standards shall be used to the maximum extent possible in all future NATO System acquisition and developments.

5.2 Conditions for meeting Objectives

The following conditions must be met in order to achieve the above objectives:

5.2.1 Retain or improve quality of Software The quality of software must be assured. Experiences with OSS in large civilian projects demonstrate that it can be reliable and stable. The availability of the software source code enables regular software quality checks which help ensure that software quality can be retained and improved.

5.2.2 Retain or improve security Security must be maintained. Studies in the civilian and military domain demonstrate that properly configured and patched OSS can be as secure as proprietary software and as immune against malicious software attacks. Appropriate security checks should be conducted to retain or improve the required level of security.

5.2.3 Retain or improve usability of systems Existing system facilities must be maintained. When introducing new OSS components to a system, it essential that existing levels of usability are retained and disruption of users kept to a minimum.

5.2.4 Assess life-cycle costs A full assessment of life-cycle costs is necessary. Before selecting OSS for a NATO system, it must be demonstrated that support will be available and that the use of OSS will provide additional value over the projected life-cycle, taking into account all new system and infrastructure support costs.

6.6. KEY AREAS AND CRITERIA

6.1 Architectures and standards

6.1.1 A well-structured architecture is essential for a modern, complex information system whatever software it is based upon. Open standards provide flexibility in adopting new or replacement OSS and proprietary software components from different sources. However, integrating large numbers of small components from different sources can become complex. It is, therefore, necessary to balance the level of software integration complexity caused by granular component modularity and the level of flexibility and openness to ensure and maintain a manageable level of architectural and support complexity.

NATO UNCLASSIFIED- 4 -

NATO UNCLASSIFIED

In order to achieve a stable open standards and OSS-based architecture, the principles and guidelines below should be applied by system managers in selecting and integrating these components.

6.1.2 Principle 1: Adopt Open Standards and Technologies

(a) Only adopt products adhering to open standards and an open architecture.(b) Follow mandatory open standards in the NATO Interoperability Standards

and Profiles (NISP).(c) Ensure long-term readability of data. OSS Office Tools can read/write most

current COTS document formats successfully, but digital durability of information can only be assured through the adoption of open standards-based document exchange, groupware, email, media, database storage and file system formats.

6.1.3 Principle 2: Select OSS Products Carefully

(a) Only adopt OSS products with a proven track record – (e.g. have external community support and market share, or have been certified for use in other NATO projects);

(b) Ensure that representative pilot projects have been undertaken to provide extensive “proof of concept” before undertaking major architectural changes;

(c) Ensure that all security and technical issues have been fully investigated before adoption;

(d) Ensure that selection of OSS products is undertaken using objective criteria;(e) Consider the use of experienced OSS System Integration Contractors to

reduce and manage the risk of malfunction or lack of functionality.

6.1.4 Principle 3: Control and Manage Integration Complexity

(a) Re-engineer application systems using modules with open APIs in order to ease integration and allow more re-use of components;

(b) Before commitment to any change, ensure that the support required for a complex mix of OSS components linked through open standard interfaces is properly understood and considered against that required for less highly integrated alternative OSS or proprietary systems;

(c) Ensure that the Systems’ Target Architecture addresses in sufficient detail the Technical and Software Configurations (ref. (a) and (b)) that define the different software components, their underlying standards and interfaces;

(d) Select components that closely match user requirements or that are customisable to add or remove required or surplus functionality;

(e) Plan to allow the use on servers of both OSS and proprietary software, in order to facilitate smooth transition;

(f) Leave existing applications which cannot be readily ported to a new OSS platform to continue to run in their legacy environment. Concentrate on

NATO UNCLASSIFIED- 5 -

NATO UNCLASSIFIED

linking them with the rest of the new architecture and plan to replace them when the existing platform is renewed;

(g) Consider the use of application virtualisation on servers while running thin clients. Although introducing a risk of single point of failure, it offers improved management control, scalability and economies in the resources needed for software and hardware configuration management.

6.2 Migration and Integration

6.2.1 Full or partial migration of an architecture based on proprietary software to one based on OSS requires extensive planning efforts. For a large-scale migration exercise, (as opposed to extension of the existing infrastructure with a single OSS component or system) an outline migration roadmap should be prepared that addresses as a minimum the following aspects:

(a) Migration principles;(b) The migration scenario or approach; and(c) Specific integration issues to be addressed.

6.2.2 Migration Principles

In a complex CIS enterprise environment such as the NATO CIS infrastructure the following two high-level principles are advised as a starting point for a migration roadmap:

(a) Assume a heterogeneous environment comprising components from multiple sources, both OSS and proprietary software based. Most (complex) large-sized NATO systems can be so described and there are no indications that emerging OSS technologies are likely to change this architectural reality;

(b) The migration roadmap should be based on progressive migration and integration of OSS components (no BIG BANG approach).

6.2.3 Migration scenario:

A step-wise approach should be followed that addresses the risk and impact of migrating from non-OSS components. A migration roadmap focused on migrating to a full OSS environment (bearing in mind the first migration principle) should include the following steps:

(a) Assessment of feasibility and opportunities for OSS components. This includes undertaking quick investigations and feasibility studies to investigate migration opportunities. It may also include implementation of a small pilot project to assess the merits and provide lessons learned before starting the larger migration project;

NATO UNCLASSIFIED- 6 -

NATO UNCLASSIFIED

(b) Select and implement a low “user and data services” impact migration activity first. Infrastructure servers are prime candidates here. Examples are proxy, web server, DNS, DHCP server;

(c) Use Test and Integration Facilities, if available, to conduct trials before implementation;

(d) After having built up experience in implementing and managing the services as migrated in step (b) above, the level of data and user orientation may rise by selecting specific servers in a next step, for example file and print servers;

(e) After this step more user services oriented components (or services in SOA) might be migrated such as Core User applications, Middleware, and Application Servers as well as Core enterprise services (in SOA) and COI services (in SOA);

(f) Finally, migrate users’ desktops and desktop oriented applications;

(g) Apply Authentication and Security Services.

An alternative approach would be to develop a parallel OSS based infrastructure and migrate user and server data to the new environment. Activation of user and infrastructure services in the new environment could again be based on a stepwise approach. Such an alternative OSS based environment would provide opportunities for administration familiarisation. Successful OSS implementations would also help the position of NATO in negotiations with vendors of competing proprietary software.

6.2.4 OSS integration issues to be addressed

As in any migration there are common pitfalls and/or issues. Whilst not confined to the use of OSS, they are mentioned here as points requiring attention when integrating OSS based solutions into the evolving CIS infrastructure:

(a) For OSS provided by a commercial supplier, it should be checked that component and system interfaces (API’s) as well as service interfaces that support information exchange are based on Open Standards;

(b) For OSS modified or customised for NATO applications Open Standards conformance of system interfaces should be ensured;

(c) File systems and formats need to be mapped. There are many significant differences between Windows and POSIX file system features, including access control handles, file attributes and meta information;

(d) Selection of data and information formats is key to ensuring present and future system interoperability. For example, the continued use of the

NATO UNCLASSIFIED- 7 -

NATO UNCLASSIFIED

proprietary .document format (e.g. DOC) might be the best short term choice because all related applications (word processing, document management, presentation, etc) can handle it. Other longer term options which should also be considered include open or common standards such as RTF, OASIS XML or PDF formats;

(e) If it is decided to change formats it is essential to ensure that full analysis and testing is undertaken to ensure that:

Users do not lose critical functionality,

The costs of porting files and documents to a new format does not exceed the benefits,

The ability to retrieve and read old formats is addressed in the event of a large legacy of archival documents;

(f) Hardware compatibility needs to be assured and software drivers may not be readily available, especially for very old or very new hardware. It may be necessary to acquire expertise in preparing such drivers when dealing with military device interfaces;

(g) Software compatibility also needs to be assured. Following a change of workstation operating system, all user application software running on that platform must be fully (re)tested for compatibility with the new system. This would also be the case when the web browser product is changed;

(h) Rather than migrating every application, it may be more cost-effective to leave a rarely-used legacy application running in its original environment, and provide the services to the user through a terminal service or web based interface;

(i) While migrating the infrastructure platform services it is important to assess the impact on requirements for middleware and application level frameworks. For example, if applications have been developed on the Microsoft .NET framework and this framework service is not (fully) available on the migrated infrastructure platform this could have adverse consequences;

(j) Systems and components should be integrated into the common available authentication, PKI and directory services that are, or will be, installed for common NATO use, and should not have their own (new) entries.

6.3 Management, Support and Maintenance

6.3.1 In general, the control and management of OSS should follow all the existing established procedures for software as described in Ref. (a). The fact that OSS source code is readily available and easily modifiable makes it essential that rigorous security and configuration controls are applied to prevent unauthorised access or changes being made to installed software. Care should be taken to ensure that

NATO UNCLASSIFIED- 8 -

NATO UNCLASSIFIED

inexpensive OSS packages are not viewed as being less valuable or requiring less protection than their possibly more expensive proprietary software counterparts.

6.3.2 Initial Installation

6.3.2.1 Large off-the-shelf OSS packages, such as office automation suites, should be obtained from approved suppliers in accordance with the procedures, described in Ref. (a) or in local guideline documents. Such suppliers can ensure quality control of supplied code and provide ongoing support for subsequent security patches and bug fixes. They should also be able provide similar support for earlier versions of software after it is no longer readily available elsewhere. This will help avoid the need for frequent upgrades.

6.3.2.2 Small OSS applications such as anti-spam-ware may be obtained from the originating author sites as with similar proprietary software products. However such code should be scrutinised before installation, which should only be undertaken with security approval as appropriate for the system concerned in accordance with the instructions and guidelines in Ref. (f). OSS distributions generally have cryptographic hash to verify the integrity of the downloaded code, and these should be verified and logged. NATO modified OSS packages should be obtained from approved NATO repositories or agencies, which will also be responsible for providing subsequent support.

6.3.2.3 OSS source code should be compiled and installed using an approved compiler, after which the source code and compiler should be removed and secured separately. Details of version numbers and patch levels of all installed software should be recorded in accordance with standard configuration control procedures.

6.3.3 Patches and Fixes Security patches and bug fixes should be obtained from the original supplier under support arrangements or from NATO repositories. Authorised repository and system managers may also download the source code of such software directly from recognised Internet sites. As with proprietary software, OSS updates should be assessed for applicability and only those considered necessary should be installed. All such installations should be undertaken and recorded as for similar proprietary software updates.

6.3.4 Modification of Source Code In most NATO software development environments there should be no requirement to modify OSS source code. Where essential modification is undertaken, however, the modified, tested and operational source code must be passed to a NATO repository. Personnel there will be responsible for ensuring that the modified code is published to the OSS development community for verification. This will ensure that the modifications, once confirmed as benign and acceptable to the wider community will be incorporated in subsequent version updates. It will also help avoid possible legal problems, which could arise if modified code needs to be distributed to third

NATO UNCLASSIFIED- 9 -

NATO UNCLASSIFIED

parties such as national users. In the interest of configuration control, NATO OSS code may not be changed by user sites without the specific agreement of the appropriate NATO repository.

6.4 Repository and Licensing

6.4.1 Repository

6.4.1.1 Traditional OSS development uses source code downloaded from community web sites or procured from an OSS supplier. The issue for NATO development will be tracking and maintaining the integrity of OSS code developed and/or used in NATO applications.

6.4.1.2 It is foreseen that no additional measures to the existing NATO Software Configuration Management (CM) (Ref. (d)) and Licence Management (LM) procedures will be required for OSS which is provided by a commercial supplier, and to which no modifications are made prior to deployment. New versions of such software will be tracked and controlled as for proprietary software.

6.4.1.3 A limited number of NATO repositories (managed by NCSA, NPC and NC3A) should be established to record all OSS code used in NATO systems or systems under development. NCSA would be responsible for Bi-SC fielded AIS, NPC for ACCS and air-related applications, whilst NC3A would be the focal point repository for commercially developed applications under NSIP projects. Other Agencies/Organisations may either use one of these repositories, or establish one of their own. Each agency would draw on the other NATO repositories as required. NC3A would pass on control and management of new code segments to either NCSA or NPC as projects passed from ‘procurement’ to in-service.

6.4.1.4 These NATO repositories will control, under full CM, the evolution of OSS inside NATO and be responsible for co-ordination and coherence with the external OSS communities. Such an arrangement would allay concerns of the security authorities over the uncontrolled development of software subsequently used for critical or classified applications and systems. The use of the repository process to release code on behalf of NATO, rather than individuals, is designed to protect NATO’s Intellectual Property Rights in the code. Furthermore, the incorporation of formal quality management processes into the code modification process would be essential to minimise any possible legal action against NATO for damages caused by defective code issued by a NATO employee. NC3A would provide existing NATO-developed OSS applications to commercial suppliers on request when delivering systems as part of a contract; similar to the existing purchaser-furmished equipment (PFE) provisions. Similarly, any OSS identified for use by a contractor in fulfilment of a project or application should be provided only from a NATO Repository. The Repository should obtain the required OSS from a reputable source and release it to the contractor after it has been subjected to Quality Assurance (QA), CM and LM scrutiny.

NATO UNCLASSIFIED- 10 -

NATO UNCLASSIFIED

6.4.2 Licensing

6.4.2.1 There are many types of OSS licences in circulation, although most are based on either the GNU General Public Licence (GPL), the Berkeley Software Distribution (BSD) or the Library (or Lesser) GPL (LGPL). These are briefly described below:

(a) GPL . The GPL is the most popular, but restrictive, open source license. The GPL explicitly forbids any activity that could lead to the inclusion of source code licensed under the GPL in proprietary software. The GPL allows modifications to the source code without restrictions, but such modifications must be released back to the OSS community. Integration of software licensed under the GPL can only happen with other software licensed under the GPL, or GPL-compatible licences. All software maintained by the GNU project is licensed under the GPL, as are a lot of non-GNU software projects (such as the Linux kernel).

(b) LGPL . The LGPL is a derivative of the GPL. Its purpose is to allow the integration with proprietary software. An example of this is the GNU C library. If the GNU C library would be licensed under the GPL, all programs linked against it would also have to be GPL.

(c) BSD . BSD-type licenses impose few constraints to the user and allow a software developer to include BSD style licensed source code in proprietary software. The BSDtype licenses cover some of the most commonly used software, such as the Apache web server and Mozilla.

6.4.2.2 Licence control will be exercised by the existing authourities, which would be the NATO bodies authorised to issue new licences for NATO-modified OSS code used within their area of responsibility. They would also be responsible for releasing modified and quality-assured code back to the external communities.

6.4.2.3 It is the responsibility of Programme and Project Managers to ensure that any OSS used or distributed by NATO is covered under the appropriate licence(s). There are currently over 50 types of licence, or derivatives of licence types, in use world-wide, and considerable care must be taken on the selection of products. Managers should seek specialist legal advice on the conditions of use of licences from the relevant NATO authority during the initial planning of a project to avoid legal issues with operational use and distribution of OSS.

6.4.2.4 Further in-depth analysis of the legal aspects of OSS licenses is required and this should be undertaken by NATO legal authorities.

6.5 Security

6.5.1 The Information Assurance Sub-Committee (reference (e)) has conducted an initial investigation into the impact of open source on information security and has

NATO UNCLASSIFIED- 11 -

NATO UNCLASSIFIED

concluded that “the availability of the source code of OSS products does not pose a significant higher risk regarding discovery and exploitation of security vulnerabilities than major closed proprietary software products used by NATO”.

6.5.2 The main threat of usage of OSS components is related to the integrity of the source code. The following steps are recommended to mitigate the risk of breach of OSS components’ integrity:

6.5.2.1 All OSS components, independently of the OSS usage model (see section 1.5) should met these major criteria:

(a) It must have reliable and trustworthy support available (possibly from commercial sources) to provide security updates, patches and second line troubleshooting support;

(b) It must have a proven track record of security and reliability.

6.5.2.2 NATO organisations should require security certification and/or independent quality auditing for OSS components used in NATO projects. Requirements for certification and/or audit criteria are to be determined on a case by case basis. Requirements will follow standard NATO guidelines to cover risk profiles related to the usage of the OSS components (operational impact) and the type of OSS component (reference OSS usage model). Trusted bodies should be assigned the task of certification and/or audits.

6.5.2.3 In moving towards the usage of OSS, the Information Assurance Sub-Committee will continue to develop Technical & Implementation IA directives and guidance that address the IA aspects on deploying, operating and managing software solutions in NATO environments.

6.6 Training

6.6.1 One of the key points to address when adopting OSS in NATO software systems is to study training requirements for system administrators and end users. Currently NATO software systems are largely based on proprietary software products and in considering the use of OSS it is necessary to consider what training will be required for system administrators and end users to become proficient in the new or upgraded software. The level and duration of such training will vary between establishments, depending upon the skill and experience of those concerned and the complexity and range of tasks required in a particular environment. The following issues will need to be considered.

6.6.2 Any major upgrade of server operating system software requires system administrators to undertake refresher training. An upgrade to a new version of Windows typically requires about two weeks training. Windows system administrators required to transfer to a new server environment such as proprietary UNIX or OSS LINUX would

NATO UNCLASSIFIED- 12 -

NATO UNCLASSIFIED

normally need between three and four weeks conversion and familiarisation training to achieve a basic administrator skill level.

6.6.3 Introduction of OSS will normally result in a mixed operating environment for an indeterminate period, during which time it will be necessary to ensure that system administration staff continue to undertake periodic refresher training on both systems in order to maintain expertise in both types of software.

6.6.4 Users will require training following replacement of an office suite of programs, whether to OSS or to a different proprietary packages. Skilled users transferring between packages with a similar look and feel may require only one day’s training. Training of less skilled users, or for anyone moving between packages with significantly different interfaces, may require several days. The provision of suitable training courses (whether classroom-based or via e-learning packages) and the scheduling of users to attend classes or undertake individual training must be addressed.

6.7 Funding

6.7.1 The funding arrangement for purchasing fully supported OSS from commercial sources should mirror those in place for buying proprietary software. Procurement agencies should seek to achieve ‘Enterprise Agreements” (EA) with the suppliers of commercialised OSS to ensure that NATO maximises the cost benefits available from the fielding of OSS. As NATO gains experience with OSS the pattern of usage defined in section 1.5 could change and this could affect the costing model compared to that of proprietary software. Initial licence purchase costs for OSS could reduce, possibly to zero, but subsequent costs for service and implementation could become significant.

6.7.2 The creation of a Service Level Agreement (SLA) or Memorandum of Understanding (MOU) should be considered when a NATO entity is reliant upon another NATO organisation for the support and update of NATO-modified OSS code. Such agreements may include payment schedules for the supply of those services.

6.7.3 NATO organisations must take into account the requirement for downstream operational support of OSS, and incorporate appropriate funding requirements for licence payments or contractor support in their annual O&M budgets. Such information must also be included when making evaluations of a potential OSS project.

6.7.4 Procurement terms and conditions and NATO Software EA contract limitations must be taken into consideration when planning migration to OSS products. EA contracts are typically for a fixed term with a declared minimum purchase of products/licences as a contractual baseline. Payment for products declared in the baseline count must continue to be made for the duration of the contract, irrespective of actual use; there is normally little or no possibility of reducing the baseline or breaking the contract without incurring substantial financial penalties. All migrations to OSS products

NATO UNCLASSIFIED- 13 -

NATO UNCLASSIFIED

should, therefore, be planned and synchronised with existing contractual breakpoints to avoid incurring unnecessary additional costs to NATO.

6.8 Distribution

6.8.1 OSS will normally be delivered to end-users either through the implementation of an infrastructure project by selected contractors, or through the release of updates to fielded systems by the responsible NATO support provider.

6.8.2 Notwithstanding the general provisions of OSS licences, the issuing NATO authority should normally be regarded as the “user” and there should be no requirement to further distribute the source code to the end-user during release or installation. Where it is necessary to issue source code to an end user, however, it must be accompanied by clear and unambiguous documentation, preferably in the form of an electronic End-User Licence Agreement (EULA), clearly indicating under what conditions and limitations the code has been distributed. A copy of this certificate, together with the list of the recipients of the code, must be logged in the relevant NATO repository and be updated as necessary.

6.9 Total Cost of Ownership

6.9.1 A number of independent studies have indicated that there can be considerable Total Cost of Ownership (TCO) savings when using OSS in place of proprietary software. However, such costs and savings depend on the type of usage defined in section 1.5, and these may vary within the NATO environment. Projects must therefore be assessed on an individual basis, considering each of the following cost areas:

6.9.1.1 Software License Costs for Initial Procurement and Maintenance In order to compare the license and maintenance costs of OSS with proprietary software within their particular environment, project managers should first establish with NCSA if any NATO-wide EAs exist for the proposed OSS and/or the equivalent proprietary software package. They should then ascertain the licensing and maintenance costs over three years. For end-user organisations using OSS or OSS-customised packages distributed and maintained by NATO distribution centres, the licensing and maintenance costs will be minimal. However, for NATO organisations with responsibility for downloading, in-service maintenance, problem-solving and/or distribution, there will be support implications. For smaller OSS packages these may again be small. However, more complex software such as operating system or office automation software may require NATO to establish an in-house integration and maintenance facility with support engineers.

6.9.1.2 Migration Costs Independent of the usage model, as with any software migration to a new platform, there is a cost for migrating proprietary software to an OSS environment. These are likely to be greater if existing applications are not (fully) supported on the chosen OSS platform. These costs should be estimated using standard migration guidelines,

NATO UNCLASSIFIED- 14 -

NATO UNCLASSIFIED

taking into account the size and complexity of the exercise and whether it is to be done in-house or by contractors.

6.9.1.3 Implementation and Integration Costs There may be one-off costs for implementing and integrating different OSS components such as upgrading hardware peripherals for which no driver software is available for OSS platforms and re-developing scripts, macros and office templates. Where an OSS component lacks essential features, it may be necessary to install additional OSS or proprietary software components to provide these. On the other hand, OSS may contain required features such as file server backup, that would otherwise require to be procured separately in a proprietary software environment. All required elements of implementation and integration must be included to ensure that the total extra costs are considered versus the savings in license fees. Such costs may be incurred either directly, or indirectly if OSS has been procured from a commercial vendor. In this case, the vendor would take responsibility for ensuring integration into the OSS platform of the NATO system, and the savings would offset against the higher license procurement and maintenance costs.

6.9.1.4 Management and Support Costs In assessing the cost of server management support for an OSS environment within NATO, it will be necessary to take into account the availability of personnel having the appropriate skills and experience. Many NATO organisations rely on military personnel having little or no experience of OSS server environments. This skill shortage may require the hiring of external expertise. However, other factors, such as the reduced vulnerability to virus attacks compared to proprietary software environments may reduce the level of support required.

6.9.1.5 Training Costs More training will be required for conversion from a proprietary solution, both for administrators and end-users, than would be the case for a normal software upgrade or refreshment. There will also be a need to continue training on both OSS and proprietary software packages for an indeterminate period, where both types of software continue to co-exist. It may be necessary to procure or develop new e-learning packages to train users in OSS. The cost of subsequent introductory or refresher training courses for users and administrators should be similar to those for equivalent proprietary package training.

6.9.1.6 Hardware Costs Studies have shown that servers using OSS such as LINUX can be more efficient and handle more traffic than equivalent Windows servers. This could save money through the use of lower specification servers or by delaying hardware replacement.

NATO UNCLASSIFIED- 15 -

NATO UNCLASSIFIED

7.7. WAY AHEAD

7.1 Short Term (1-2 years)

7.1.1 Give full consideration to OSS in all software procurements NATO project and program managers are to give equal consideration to both OSS and proprietary solutions when undertaking software procurements for NATO systems. Where OSS is fit for purpose and provides value for money in accordance with the criteria in this strategy, its use should be encouraged.

7.1.2 OSS Pilot projects In order to fully exploit the benefits of OSS in NATO programs, program managers should be encouraged to establish feasibility studies and pilot projects to assess the viability of applying OSS to NATO systems being acquired by the program. Pilot projects will provide experience in software quality, user- friendliness and user-training as well as identifying means of achieving interoperability with existing NATO and national systems.

7.1.3 Open Standards Adherence to the use of Open Standards when using OSS, or when exchanging information in a mixed environment of proprietary software systems and OSS based systems, should be mandatory. Software specialists in NATO organisations are encouraged to cooperate and contribute to these lists in order to facilitate closer alignment between the use of OSS and Open Standards.

7.1.4 INFOSEC Operational Procedures Operational security guidance, developed under the lead of Information Assurance Sub-Committee, concerning the INFOSEC aspects of deploying, operating and managing OSS are the same as in proprietary software and shall be followed.

7.1.5 Legal Aspects of OSS Licenses The legal aspects of licenses should be further investigated by NATO legal authorities with the aim of developing clear guidelines for using different types of OSS licenses in NATO systems. Until such guidelines are available, use of OSS should only be undertaken with the approval of the Legal Advisor of the appropriate NATO organisation, to ensure that there is no legal risk.

NATO UNCLASSIFIED- 16 -

NATO UNCLASSIFIED

7.2 Medium Term (3-4 years)

7.2.1 Implementation plan for the use of OSS in NATO Based on NATO experience, results of feasibility studies and pilot projects, the long-term viability of migrating towards a greater deployment of OSS components should be explored. The option of making OSS the default exploitation route for NATO-funded software, except where it is less cost-effective than a proprietary alternative or too difficult to integrate, should be further investigated and reflected in an implementation plan outlining the strategic options. Such a plan should also reflect the distribution of OSS in NATO and in particular the roles of NATO organisations, like NPC, NC3A and NCSA. The NC3B should task the ISSC with the development of this plan.

7.2.2 Open Standards strategy The NOSWG should develop an Open Standards strategy in which they are mandated and in which the cooperation between users of Open Standards and OSS is strengthened. This cooperation should not be limited to NATO users but should also include national users of OSS to maximize the benefits of using Open Standards and OSS both in NATO and national systems.

8.8. GOVERNANCE

8.1 Approval Authority of Strategy

This strategy has been developed and agreed, by the Information Services Sub-Committee (ISSC) in coordination with the Information Assurance Sub-Committee (IASC) and the C3 Coherence Sub-Committee (C3CCSC) . Before approving this OSS strategy on behalf of the NATO Council, the NC3B will coordinate with the Council Committee level executive authorities in para 8.2 below. The ISSC will maintain the strategy on behalf of the NC3B.

8.2 Execution Authorities of Strategy

The execution authorities of this NATO strategy are the NATO budget authorities, which are Senior Resource Board, Infrastructure Committee and Civil and Military Budget Committee, which are responsible for ensuring that the selected software solution meets the criteria of this strategy in NATO projects. The NATO C3 Board and its Sub-Committees are responsible for providing standards and policy consistent with and supporting this strategy.

NATO UNCLASSIFIED- 17 -