Guide to Open Source Software for Australian Government Agencies

Version 2 of the Australian Government Guide to Open Source Software, has been released by the Australian Government Information Management Office (AGIMO). The Australian Government's Open Source Software Policy requires agencies to consider open source software. The guide is available in PDF (1.09 MB), Microsoft Word (537 KB) and RTF (941 KB) formats. It is a shame the report was not released in the more open HTML format. Here are some excerpts:

Contents

Foreword 3

Contents 4

1. Introduction 5
2. What is open source software? 6
3. Australian Government Open Source Software Policy 11
4. Procurement of open source software 15
5. Comparing open source and proprietary software 19

Appendix 1: Australian Government Open Source Software Licensing Risk Framework 25

Appendix 2: Links to other resources 55

Appendix 3: Acronyms and definitions 60

Introduction

The Guide to Open Source Software for Australian Government Agencies provides an introduction to open source software. It includes background information on the benefits and risks of using, modifying, distributing and developing open source software and guidance to assist agencies understand, analyse, plan for and deploy open source software.

1.1 Intent

The guide is a stand-alone reference document on open source software; however, agencies are encouraged to read it alongside A Guide to ICT Sourcing for Australian Government Agencies ¹ (Guide to ICT Sourcing). This guide is not a substitute for legal or procurement advice. Any decisions on the use of software, including open source software, or associated services should be made according to the Commonwealth Procurement Guideline s ² and the Australian Government's Open Source Software Policy ³ .

Agencies should be aware that this guide is focused on open source software. It does not provide a complete picture of the benefits and risks of using proprietary software solutions.

1.2 Audience

Although this guide can be considered general background reading for anybody who is inte rested in open source software within government, the primary audiences for this guide are project managers and procurement teams who are sourcing software to meet business requirements. Agency personnel who influence the selection of software may also find this guide useful.

The Australian Government Open Source Software Licensing Risk Framework is designed for ICT specialists.

What is open source software?

Open source software is a popular term in the information and communications technology (ICT) industry, but it can mean different things to different people. This section defines open source software and highlights its benefits.

Agencies should keep in mind that open source software is not intrinsically of higher or lower quality than proprietary software. It is not inherently more or less secure, and it does not necessarily have a higher or lower total cost of ownership.

2.1 Definition of open source software

The Open Source Initiative (OSI) ⁴ , an organisation established to promote open source software, has developed an Open Source Definition (OSD) as follows:

The 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 licence 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 licence 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-publicized 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 preprocessor or translator are not allowed.

3. Derived Works: The licence must allow modifications and derived works, and must allow them to be distributed under the same terms as the licence of the original software.

4. Integrity of The Author's Source Code: The licence may restrict source-code from being distributed in modified form only if the licence allows the distribution of "patch file" with the source code for the purpose of modifying the program at build time. The licence must explicitly permit distribution of software built from modified source code. The licence may require derived works to carry a different name or version number from the original software.

5. No Discrimination Against Persons or Groups: The licence must not discriminate against any person or group of persons.

6. No Discrimination Against Fields of Endeavour:The licence 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 Licence: The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional licence by those parties.

8. Licence 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 licence, 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. Licence Must Not Restrict Other Software: The licence must not place restrictions on other software that is distributed along with the licensed software. For example, the licence must not insist that all other programs distributed on the same medium must be open-source software.

10. Licence Must Be Technology-Neutral: No provision of the licence may be predicated on any individual technology or style of interface.

Misconceptions

Although open source software often involves a distinctive development and distribution model, it may also be bundled and sold as part of a package with proprietary software. Software can be offered under both open source and proprietary licences. Where software is dual-licenced, agencies should choose the arrangement that best matches their requirements and provides value for money.

Open source software is sometimes confused with public domain software, shareware, community source software and freeware ⁵ . In addition, open source software is often linked with open standards; however, not all open source software products use open standards.

Another common misconception about open source software is that it can always be obtained free of financial cost. When open source software is labelled as 'free', that word refers to the ability of people to read, modify and redistribute the source code of the software, not the cost of the software ⁶ . The definition of open source software does not preclude people from selling the software. However, despite this, open source software is usually available free of upfront costs, although agencies still need to be aware of the total cost of ownership (TCO).

2.2 Development and support of open source software

There are three broad models for open source software development and support:

• Volunteer community. A large proportion of open source software is developed by a community of skilled people who usually communicate online. In this model, there is no specific corporation managing the development process. Support is available through the members of the community, who have forums and other feedback mechanisms to receive requests from users. There is generally no service level agreement available from the community. Popular packages such as the Apache web server and the Linux operating system have been developed using this model.

• Corporate-backed community. Some commercial organisations provide support for open source software. The commercial organisation may choose to create its own community to develop the open source software or they may choose to leverage off an existing product created by a volunteer community. The commercial organisation usually provides support to a defined service level agreement. More than one organisation can provide support for a product, leading to competition based on the quality and price of the service. For example, Oracle's and IBM's web servers are both based on the community-developed Apache.

• Commercial open source. Some open source software is developed or supported by a single corporation. Sun Microsystems (now owned by Oracle) provides the OpenSolaris operating system under this model.

2.3 Benefits of open source software

Open source software has a number of potential benefits. These benefits are not applicable in every instance; however, they can be seen as general characteristics of open source software. Some of these benefits can be realised only when agencies contribute back to the community. In some cases there are risks associated with the benefits, as discussed in Section 4: Procurement of open source software.

Open source software:

• Usually has no upfront payment. The lack of upfront payment may seem to benefit agencies financially; however, as with all software, agencies should consider the total cost of ownership, including all support services that will be required to operate the software over its lifespan.

• Encourages a competitive market for support services. Because the source code is available, it is possible for any software organisation to provide support for an open source product. In addition, customers are able to support the software themselves.

• Encourages a collaborative approach. Open source software encourages an open exchange of ideas, where any user of the software can contribute ideas to improve it. This tends to promote a collaborative approach that may foster innovation.

• Places fewer restrictions on the users of the software. Most open source software licences place fewer restrictions on the users of the software and emphasise respect for the privacy of the users. However, agencies should ensure that they understand the obligation for reciprocity that is included in many open source licences.

• Provides the opportunity for users to take direct control of the maintenance and support of the software. This may be a benefit to agencies that possess the appropriate skill base.

• Allows the opportunity to try the software before committing to it. This will enable agencies to test the viability of the software before fully committing to it.

• May reduce vendor lock-in. As the source code is publicly available, most licences will allow any individual or group to further develop the software without the obligation to support other users, even if the original community discontinues development. Commercial organisations may provide support for an open source package, if there are enough users willing to pay for that service.

• Allows users to view and modify the source code. The ability of users to scrutinise and change the source code of open source software may lead to increased stability and security. It also allows agencies to tailor the software to their own needs.

• Allows users to take advantage of the improved functionality of new releases more rapidly. Many new open source software communities follow the maxim of ‘release early, release often', meaning that users can quickly gain extra functionality for the software.

• Increases interoperability. Many open source software packages use open standards, which tend to lower the costs of integration and improve interoperability ⁷ .

• Usually is modular. Open source software packages are generally modular, which means that changes to one part of the source code is less likely to affect the rest of the software package.

Australian Government Open Source Software Policy

This section describes the principles that underpin the Australian Government's policy in regard to the procurement of open source software and suggests ways that consideration of open source software can be incorporated into procurement processes.

In January 2011, the Australian Government released a policy requiring agencies to consider open source software for all software procurements. The Open Source Sof tware Policy ⁸ , which is available from the Department of Finance and Deregulation website, will apply to any ICT procurement activity initiated after 1 March 2011.

3.1 Principles

The policy directs agencies to comply with three core principles.

Principle 1: Australian Government ICT procurement processes must actively and fairly consider all types of available software.

Australian Government agencies must actively and fairly consider all types of available software (including but not limited to open source software and proprietary software) through their ICT procurement processes. It is recognised there may be areas where open source software is not yet available for consideration. Procurement decisions must be made based on value for money. Procurement decisions should take into account whole-of-life costs, capability, security, scalability, transferability, support and manageabilty requirements.

For a covered procurement (over $80K), agencies are required to include in their procurement plan that open source software will be considered equally alongside proprietary software. Agencies will be required to insert a statement into any Request for Tender that they will consider open source software equally alongside proprietary software. Tender responses will be evaluated under the normal requirements of the Commonwealth Procurement Guidelines. For a non-covered procurement (below $80K), agencies are required to document all key decisions, as required by the Commonwealth Procurement Guidelines. This includes how they considered open source software suppliers when selecting suppliers to respond to the Select Tender or Request for Quotation.

Principle 2: Suppliers must consider all types of available software when dealing with Australian Government agencies.

Australian Government agencies will require suppliers to consider all types of available software (including but not limited to open source software and proprietary software) when responding to agencies' procurement requests.

Agencies are required to insert this requirement into their tender documentation. Suppliers will need to provide justification outlining their consideration and/or exclusion of open source software in their response to the tender. Agencies will determine compliance with this requirement when assessing tender responses.

Principle 3: Australian Government agencies will actively participate in open source sof tware communities and contribute back where appropriate.

The Australian Government, through AGIMO, will actively seek to keep up-to-date with international best practice in the open source software arena, through engaging with other countries and organisations. Australian Government agencies should also actively participate in open source software communities and contribute back where appropriate.

3.2 Compliance

The policy suggests sample draft clauses designed to assist agencies in complying with the policy. Agencies may choose to draft their own clauses.

The policy provides the following sample clauses:

• for inclusion in procurement plan/procurement documentation

[Agency Name] will actively and fairly consider all types of available software for ICT software procurements. Open source software will be considered equally alongside proprietary software.

• for inclusion in request for quote/select tender checklists

Have you considered all types of available software (including but not limited to open source software and proprietary software)?

• for inclusion in requests for tenders for covered procurements

[Agency Name] encourages suppliers to submit and/or develop open source software for this tender. When responding to this tender, suppliers must demonstrate a willingness to actively consider open source software throughout all stages of procurement, solution design and implementation in order to produce a product that demonstrates value for money and is fit for purpose. This may include incorporating open source software components together with proprietary software components.

In evaluating the tender, [Agency Name] will consider open source software equally alongside proprietary software.

• for inclusion in request for tender assessment checklists

Has the supplier sufficiently demonstrated that they have considered all types of available software (including but not limited to open source and proprietary software)?

Agencies are also encouraged to include a definition of open source software in their procurement documentation.

Procurement of open source software

This section uses the Department of Finance and Deregulation's four-phase ICT sourcing lifecycle to identify issues that agencies should consider when procuring open source software. Further details on the four-phase ICT sourcing lifecycle can be found in A Guide to ICT Sourcing for Australian Government Agencies ⁹ (Guide to ICT Sourcing).

The following sub-sections identify the common issues in software procurement and the specific issues that should be considered when procuring open source software. It is important for agencies to understand the range of different software options available. Agencies need to ensure that they comply with the procurement procedures outlined in the Commonwealth Procurement Guidelines, any relevant agency Chief Executive Instructions and any relevant whole-of-government ICT policies.

4.1 Common issues in software procurement

In many aspects, procuring open source software is similar to procuring proprietary software. Agencies must consider the following when procuring either open source software or proprietary software:

• Applicability of the Commonwealth Procurement Guidelines . Agencies must always follow the Commonwealth Procurement Guidelines when selecting a software solution.

• Total cost of ownership. When considering value for money, agencies need to take into account the total cost of ownership (TCO), also known as the whole-of-life costs, for use of the software. Even software that can be downloaded and used without cost may have downstream support, maintenance and exit costs. Agencies may need to purchase services for maintenance, support and deployment, and they may also have costs involved with installation, system integration, data conversion and testing. Agencies may also need to pay a developer to modify or integrate the software. Refer to the Guide to ICT Sourcing for more information.

• Matching support and maintenance arrangements to the agency's requirements. Agencies should ensure that the risk profile of their service level agreement for support and maintenance is appropriate for the business criticality of the software. Most agencies will incur some combination of internal staff charges and external support and maintenance charges for either proprietary or open source software.

• Matching product innovation, maturity and roadmap to the agency's requirements. There are variations in the stability, innovation and maturity of both open source and proprietary software packages. Agencies need to take these differences into account when procuring software.

• Aligning with the agency's strategy and architectures. The strategy and architectures of an agency may dictate certain principles, standards and technologies that need to be taken into account when considering new software. Consistent application of an agency's strategy and architectures helps to reduce staff training and ICT support costs.

4.2 Four-phase ICT sourcing lifecycle

The Guide to ICT Sourcing divides the sourcing lifecycle into four phases. The key issues to consider for open source software in each phase are:

• Phase I: Case for change

• Agencies should clarify their business need using their strategy and architectures to define their business case for change. This may include identifying any need for innovation, maturity, support, and integration with existing sof tware or systems.

• Phase II: Decide sourcing strategy

• • Agencies should decide whether there is any justification for limiting their software s election to specific technologies, packages or software models. It should be noted that an approach to an open market will provide the most objective evidence of available options. Agencies should consider the market conditions and TCO, especially support and transition costs.

• Agencies should also consider any whole-of-government ICT policies that may influence their decision making, for example, the ICT Customisation and Bespoke Development Policy ¹⁰ .

• Agencies should be aware that open source software can be sourced 'in house' by downloading open source software from various online repositories. The benefits and risks of 'in house' sourcing should be assessed, including the TCO.

• Phase III: Undertake procurement

• Agencies' procurement processes must be compliance with the Open Source Software Policy .

• Agencies should ensure that there is a software licence management framework, especially if they choose to procure open source software. See Appendix 1: Australian Government Open Source Software Licensing Risk Framework for more information.

• Agencies should be aware that it may be necessary to procure support services separately for open source software.

• Phase IV: Transition and manage

• Agencies should continue to manage their software against the licence cond itions.

• Agencies should also keep up to date on the changing software industry landscape.

Comparing open source and proprietary software

This section highlights some of the key issues that agencies should consider when comparing open source software to proprietary software.

Agencies need to understand the opportunities and risks associated with the different software options. Implementing open source software does not necessarily expose an agency to greater risk than implementing proprietary software; however, there may be a change in the risk profile. Some of the factors that will affect the risk profile are:

• How the agency is using the software. An agency may use the software as supplied, modify it, distribute it or use it as a component of another software implementation.

• The business alignment of the initiative. The Guide to ICT Sourcing provides a framework for assessing initiatives as vital, duty-bound, or discretionary and support. This is based on the relevance of the initiative to the agency's core business.

5.1 Key issues

Agencies need to consider the following when procuring open source or proprietary software solutions.

• Access to source code. By definition, open source software makes the source code available to anyone for viewing, vetting and modification. Proprietary software generally restricts access to and modification of its source code.

• Capital expenditure. Although open source software usually has no upfront cost, the TCO is unlikely to be nil, even if an agency provides in-house support. ¹¹ Proprietary software generally includes an upfront fee, unless the proprietary software is provided as a service ¹² . Agencies should consider the TCO for both proprietary and open source solutions. Considerations include acquisition, deployment, integration, support and maintenance, training and exit costs. However, there may be an opportunity to leverage an agency's existing software investments, for example, if an agency's software uses a particular standard, the cost of integration may be reduced by integrating software that supports the same standard.

• Customisation. Agencies should consider whether they need to customise the software and whether there are any applicable whole-of-government ICT policies (for example, the ICT Customisation and Bespo ke Development Policy ¹³ ). Customisation of open source software can be undertaken either by the agency or by a third party. If agencies choose to customise the software, they should consider the cost of future support, maintenance and upgrades. Agencies should also consider any licensing obligations. If agencies customise open source software and do not contribute the modified product back to the open source software community, this is called code forking. Code forking is discussed in further detail in the next section.

• Development/Governance. Open source software is generally developed by communities of developers who work together online ¹⁴ . These communities may also be supported by commercial organisations. An open source software community with an active and diverse membership, a broad user base, a good governance structure and regular updates is more likely to be responsive to user requests. The corporate history and product roadmap of proprietary software vendors may give agencies an indication of the quality of the vendor. Before an agency commits to using any software package, it should carefully assess the credentials and resources of the developers. The agency should consider whether appropriate development of the software will continue during the expected lifespan of its use by the agency.

• End user. The training necessary for end users should be considered whenever a new software purchase is made or an upgrade is obtained. ¹⁵

• Innovation. The nature of open source software allows agencies to contribute back to the product, which can aid innovation. However, this may affect the TCO of the product, as agencies will need to factor in the cost of contributing back (i.e. staff costs). Historically, proprietary software relies on the vendor to drive innovation.

• Intellectual property. There is a specific exemption for software governed by open source licences in the Australian Government's Statement of Intellectual Property Principles for Australian Government Agencies . This exemption allows the Commonwealth to retain intellectual property in products governed by open source licences. ¹⁶

• Liability . Agencies need to be aware of any liability they may face when modifying and distributing software. Any liability that agencies may face is generally listed in the software licence conditions under disclaimer of liability or disclaimer of warranty.

• Licence obligations. Agencies should be aware of their licensing obligations, including the possibility of the software being dual licensed. Some open source software licences may oblige agencies that modify and distribute the software to contribute all changes back to the open source software community. Proprietary software also comes with its own set of licensing obligations.

• Lock-in. Agencies should be aware of the risks of being locked-in to one type of software. Open source software may align to open industry standards, which can improve interoperability and reduce vendor lock-in. A Guide to ICT Sourcing for Australian Government Agencies ¹⁷ provides a detailed review of this topic. Agencies should also consider the possibility of being locked in due to a lack of support options.

• Maturity and portability. Agencies should ensure that they evaluate the maturity of any software product they are procuring. This includes considering the risks of having to change to a different product in the future.

• Release management. Open source software generally has an increased number of new releases that may have a negative impact in terms of greater requirements for integration testing, release management, bug fixes, and the associated risk management and support tasks.

• Reliability. Agencies should evaluate the reliability of any software product they are procuring. Commonly used open source software products may be more reliable as the community works to select the best improvements and offer them in the next release.

• Restrictions on use. There are typically few or no restrictions on the use of open source software. However, agencies should ensure that they understand the licence conditions before modifying the software. Agencies should also check the support arrangements. Proprietary software will usually have some restrictions on its use, which may include the requirement to pay additional licensing or support costs if there is a change in how the software is to be used.

• Re-Use. Open source software may encourage re-use through the community creation of solutions specifically for government use. However, agencies need to ensure that they have the appropriate governance structures in place for any shared solutions. The ICT Customisation and Be spoke Development Policy provides governance principles for cross-agency solution sharing.

• Security. Open source software allows agencies the opportunity to examine the source code, which may assist in assessing security risks. All software should be scrutinised for its security, governance and deployment arrangements, particularly if it will be used in a high-security area. The Defence Signals Directorate's Evaluated Products List provides a list of products that are certified for specific purposes and specific security levels. ¹⁸

• Support and maintenance. Open source software offers the following options for support and maintenance:

• In-house: Support and maintenance can be provided in-house by the agency.

• Community: Free support can be provided from the open source software community.

• Commercial: Support can be procured from a commercial organisation.

When an agency acquires an open source software solution through an external service provider, it is generally purchasing services and receiving the related software free of charge. There is usually a competitive market for commercial support services for open source software. However, agencies need to assure themselves of the capacity and capability of any organisation claiming to offer support services. Some open source software products may depend on key individuals within a community or a specific vendor to support the product. Open source software that is in widespread use is likely to have more competitive support services. Support and maintenance for proprietary software is generally provided by the vendor or authorised partners, with a certain amount of first level support usually being provided in-house.

• Warranties. Open source software that is downloaded free generally does not offer warranties. However, open source software that is procured from a commercial vendor will generally come with similar warranties to proprietary software.

5.2 Beyond use: code forking and reciprocity

This section gives further information on two issues that apply when modifying or developing open source software.

Code forking

Code forking occurs when agencies make changes to the code of open source software without publishing the code back to the software's development community. The fork is the split between the agency's version of the software and the version published by the community. Any further changes made by either the agency or the community will increase the fork. This can make it difficult for the agency to upgrade to a new published version, as the agency would have to reapply all its changes. This risk may be mitigated by contributing modified source code back to the open source software community.

Code forking is similar to customising proprietary software packages. Customising commercial products can also create a future liability for the agency, as upgrading to the next supported version of the package may be more expensive and time consuming due to the customisation.

• The benefits, costs and risks of customising should be included in the business case for any software initiative. Agencies should be aware of whole-of-government ICT policies that may govern their ability to customise software, such as the ICT Customisation and Bespoke Development Policy ¹⁹ . Agencies should also ensure that they have the appropriate skill base to manage the development and ongoing maintenance of the forked software.

Agencies working with open source software have the option to publish changes back to the development community. Depending on the licence, they may also be obligated to publish any changes that have been distributed. Should these changes be accepted by the community and integrated into the base product, alignment is maintained with the published version. Agencies need to consider the implications of contributing ...

From: Australian Government Guide to Open Source Software, Australian Government Information Management Office , Version 2.0, June 2011