Australia: The Open Source siren song - or an alternative to proprietary software?
Government Affairs Alert

Government Affairs Alert

With Government Agencies trying to implement savings in innovative ICT procurement, the increased utilisation of Open Source, or indeed, replacing proprietary software with Open Source, is a significant opportunity for customers.

The opportunity to use Open Source software also offers leverage in the context of technology procurement.

In November 2003, the Brazilian government issued a policy encouraging the use of Open Source. By 2005, 300,000 government computers had switched from Microsoft to the Open Source operating system: Linux. Three years later, 73% of large companies in Brazil were using Open Source.¹

The UK caught on in 2004, when the UK's Office of Government Commerce described Open Source Software as "a viable and credible alternative to proprietary software for infrastructure implementations and for meeting the requirements of the majority of desktop users...". ² Now, in 2013, British Government CTO Liam Maxwell expressed the Government's preference for the use of Open Source. ³

In Brussels, similar to the Brazilian government, Open Source is already being relied upon for essential IT functions. For instance, the EU Commission runs IT solutions on more than 350 Linux servers, and uses Open Source based solutions for authentication, performing more than 1 million authentications on a yearly basis with more than 17,000 different users every day. ⁴

Following this trend, the Australian Government Information Management Office (AGIMO), in its 2011 Open Source Guide, suggested that Open Source software can "improve[e] interoperability and possible cost savings." ⁵ Under current federal government Open Source procurement policy all FMA Agencies need to consider Open Source as a future solution to preventing ICT Lock-In. ⁶ More recently, the Commonwealth's CTO John Sheridan has been quoted as stating that in many cases, Open Source is better value to the government than proprietary software thanks to, in large part, the better tech-support now available for mature Open Source solutions. ⁷

But is this a case of succumbing to a siren's song? What are the risks associated with Open Source software and what mitigation strategies can government agencies use to mitigate or avoid risks?

This article examines the risks and mitigation strategies from a Government ICT procurement perspective where an agency is considering procuring pure Open Source software.

WHAT IS OPEN SOURCE?

Open Source software (or to the initiated, OSS) is computer software where the source code ⁸ is freely available to the community to view, modify, copy and distribute, subject to certain licensing conditions. ⁹ Not be confused with "Public Domain Software" (PDS), Open Source is always released under a licence (unlike PDS, which can be used by anyone without restriction). ¹⁰

Judge Jeffrey S White, in the US Federal Appeals Court decision of Jacobsen v Katzer ¹¹ described how Open Source is developed in his judgment and it is worthwhile revisiting his description here. Open Source software is software that is developed through online community Open Source "projects". These projects invite programmers from around the world to view the publicly available software code, and make changes/improvements. This communal group work makes the development much faster and cheaper. In exchange for the help received, the copyright holder permits users to copy modify and distribute the software code provided that the users keep the code accessible. ¹² This accessibility requires users, in some instances (depending on the licence type), to make their improvements to the code publicly accessible through Open Source licensing. This can make commercial exploitation of the modifications difficult, but is an advantage to licensees who gain free access to the improvements.

Open Source is an alternative to "proprietary software" and is touted as a technology solution that can drive efficiency and can improve an agency's economic and strategic chances in procurement. ¹³

TYPES OF OPEN SOURCE SOFTWARE

AGIMO describes Open Source in its 2011 Open Source Guide as software falling into particular categories: (see bottom left hand corner).

Examples of Open Source include the Mozilla Firefox web browser, the Linux operating system, the Apache HTTP Server, the Android platform (used in Samsung's Galaxy Tab 10.1) and the MySQL relational database system. ¹⁵

Open Source software is available for many everyday applications for which agencies often use proprietary software.

OPEN SOURCE SOFTWARE LICENCES

Open Source does not simply mean that access to the source code is provided. Additional criteria must be complied with in order for software to meet the definition of "Open Source". ¹⁶ The Open Source Initiative ¹⁷ (a not-for-profit advocacy group dedicated to promoting open source software) puts forward the following 10 points in an attempt to define Open Source:

Licences such as the GNU GPLv2 and GPLv3, the Modified BSD licence , the Apache 2.0 licence and the Mozilla Public Licence 2.0 have been certified as compliant with the Open Source Initiative definition and are good examples of Open Source licences. 19

Points taken from AGIMO's "Guide to Open Source Software for Australian Government Agencies" v.2.0 of June 2011 available online

WHAT ARE THE RISKS?

Adopting Open Source solutions is not without risk. While these risks are, in many cases, not fundamentally different from the risks posed by proprietary software, agencies should adhere to the risk management framework for Open Source highlighted by AGIMO (see the side bar for a snapshot version and link to the Guide on page 4). ²⁰

In a scenario where an agency is considering procuring an Open Source solution, the most common risks are:

1. lack of legal and technical protection for failure of the software and risks of compatibility;
2. risk of third party infringement;
3. general licence term infringement; and
4. total cost of ownership exceeding the amount estimated, because of extra costs of support.

NO PROTECTION

With proprietary software, the licence usually provides a minimal degree of protection. Open Source licences generally contain provisions that license the product on an "as is" basis without any warranties or indemnity. Open Source licences usually expressly exclude (at least to the "extent permitted by law") implied warranties, such as warranties that the software:

• will perform to any particular level or scope of functionality; and
• will not infringe the intellectual property rights of other persons (third party infringement is discussed further below).

This approach may be unsuitable for government agencies because federal government policy on accepting liability for risk is quite strict. The policy generally requires that risks should be borne by the party in the best position to manage them. ²¹ Of course, the policy is not unfettered. In instances where the risks outweigh the benefits, agencies are able to accept risks according to Commonwealth Procurement Rules and the ICT capping policy. A lot of trust therefore, is placed in an agency conducting a careful risk assessment.

Certainly, business continuity is critical for government. If software does not perform as required, the consequences, not only for the government but possibly also for the general public, can be catastrophic.

Suggestions

When considering using Open Source software, independent from an ICT supplier, agencies should:

• conduct thorough due diligence into the Open Source software and licence to ensure the product is mature, tried and tested and has a low risk of failure i.e. the software components should be comprehensively assessed before being implemented;
• consider software where issues and bugs are managed by bug tracking²² and a resolution system that is transparent and publicly available.²³ An Open Source project that has a bug tracking system in place may be more reliable than one which does not; and
• develop governance policies that track changes of Open Source applications. Monitoring can protect the agency from becoming vulnerable to software defects i.e. ensuring regular updating to components from community Open Source code forums and monitor code usage across the applications. onitoring will also provide access to information improvements.

THIRD PARTY INFRINGEMENT CLAIMS

The risk of third party IP infringement claims arising is not unique to Open Source, but the risk can be greater. This is because it allows users to freely modify and distribute the software. If a user modifies the source code by including third party proprietary code without obtaining the owner's permission, the modified software will infringe third party rights. This infringement will carry through subsequent versions of the software which contain the infringing code. ²⁴

Open Source licences do not indemnify the end-user, and the innocent end-user is likely to have no idea whether the source code contains proprietary code until the user receives a strongly worded letter claiming third party infringement.

Suggestions

In order to minimise the risk of third party infringement claims, agencies should conduct due diligence into the software to ensure that the software is, at the very least, developed and documented in a well-controlled manner to provide confidence with respect to incorporated code from third parties. ²⁵ A thorough investigation can help to highlight whether third party code has been incorporated and agencies will then need to consider if the risk outweighs the benefit.

INFRINGEMENT OF LICENCE OBLIGATIONS

While many Open Source licence models allow the modification of the source code for internal use without requiring the user to make the modified code publicly available, other licences (such as the GNU General Public Licence) do in fact oblige the user to distribute the modified code by making it publicly accessible. ²⁶ If an agency's in-house developer or contractor used Open Source software to design an agency specific program, and that Open Source software was subject to the GNU General Public Licence, then the agency is required to upload the modified source code.

This could be undesirable if the agency did not wish to make the program publicly available, or if the agency wanted to exploit the program commercially.

If agencies fail to comply with the terms and conditions of a software licence, they risk being liable for infringement. While Open Source licences have not been tested in Australian Courts, in the EU and the US, legal action has been successful in prosecuting breaches of Open Source licences. ²⁷ It is therefore very important that agencies fully understand the terms of a licence, and that agencies ensure continuous monitoring to avoid breaches of licence terms.

Suggestions

• Ensure that agencies have comprehensive governance procedures in place to track, monitor and evaluate all instances of Open Source software.²⁸
• Educate agency staff about the licensing obligations associated with Open Source solutions.
• Undertake risk assessments to determine the agency's individual "risk appetite" for programs that involve Open Source software.²⁹

A related issue is that any customisation or modification of Open Source software in-house may become subject to Open Source licensing terms. Suggestions to avoid this include:

• ensuring the licence conditions allow for derivation, and if they don't, agencies should have mechanisms in place to avoid customising the software and breaching the licence inadvertently by not making the customisation publicly available (in breach of the requirement for reciprocity);
• ensure in-house developers and end-users are aware of the legal boundaries of the agency and the software's intended use;³⁰ and
• consider the obligation of reciprocity i.e. the possibility of being required to republish all the newly developed source code to maintain compliance with Open Source licensing terms.

COMPATIBILITY AND INTEROPERABILITY

Open Source software packages frequently (although not always) use open standards, so they are generally more interoperable than proprietary software. ³¹ However, while proprietary software is generally certified to be compatible with specified operating systems, often there is no similar guarantee for Open Source software. There is, therefore, a risk that a particular Open Source product will not be compatible with Australian Government Agency systems.

Suggestions

• Perform due diligence. Agencies should be careful to ensure that the proposed Open Source solution has a track record of compatibility for constituent software (i.e. there may be real world examples of the software in use by other agencies or by private corporations).
• Investigate any publicly available information relating to performance and test configuration. Ideally, these tests should be repeatable with publicly available results for analysis.³²

TOTAL COST OF OWNERSHIP

Proprietary software often comes with expert support, updates and usually, a helpdesk for end users who experience difficulties with the software. Open Source solutions are often criticised for being dependent on the general development community for support for software problems. While in many cases, the initial outlay of purchasing Open Source and keeping it updated is zero or low, ³³ when problems arise, critics of Open Source adoption suggest that expenditure on repairing the problems can start to outweigh the initial benefit of obtaining an Open Source solution for free.

Total Cost of Ownership ( ^TCO ) is therefore an important consideration when agencies are looking towards Open Source as a cheaper alternative. The Open Source TCO could end up requiring tailored support, maintenance, exit costs, installation, system integration, data conversion, testing, and even employing an in-house developer.

However, in a data analysis ³⁴ investigating Open Source adoption by US Fortune-1000 companies conducted by Diomidis Spinellis and Vaggelis Giannikas in 2012, TCO was not seen as a financial disincentive for Open Source adoption. In fact, the study found ³⁵ that companies using Open Source operating systems had "higher gross margins and profits than those using proprietary alternatives." ³⁶ The conclusion was that the long term adoption of Open Source by private enterprise was driven by its lower cost and higher operating efficiencies. ³⁷ While cost analyses should be conducted on a case-by-case basis, the risk of TCO being greater in Open Source as compared to proprietary software may not be as significant as once thought. ³⁸

Suggestions

• Agencies should consider using a mature, tried and tested Open Source product where "Value Added Resellers" (VARs) and independent support vendors offer services for external support.³⁹
• When investigating Open Source solutions, agencies should ensure that the exit costs from the software are known and minimal and that the software does not impose additional costs by creating or forcing dependencies on other software or technologies.⁴⁰

OPEN SOURCE IN THE SOFTWARE SUPPLY CONTRACT

In situations where agencies are procuring IT solutions and a tenderer purports to include Open Source code as one component of the total solution, it is essential to have appropriate liability arrangements.

Whilst Open Source comes with no warranties regarding performance, if a tenderer offers a combined Open Source and proprietary software solution, agencies should try to get the supplier to warrant, or take some responsibility, for the Open Source software's performance. In this way, the supplier takes this risk, rather than the Commonwealth. However, the tenderer may not also be prepared to take the risk of third party IP infringement.

Suggestions

In ICT purchase contracts that involve the use of Open Source, agencies should:

• require the tenderer to take some responsibility for the fitness for purpose and the performance of the Open Source software as part of the total offered solution;
• be prepared with a set of minimum required service levels that focus on agency specific risks and are measurable and enforceable, and which cover all components of the solution. If the tenderer refuses to include any service levels or performance warranties in the contract, at the very least agencies should ensure that the software is rigorously tested before being accepted and deployed into the agency's operating environment;

• do a risk assessment of the total solution;
• ensure that any limits of liability are acceptable in the context;
• ensure the tenderer will also be obliged to comply with the Open Source licences;
• ensure that any technical support offerings extend to support for the Open Source components;
• require the Open Source solution to identify licences used, and require the developer to disclose when it does use third-party code;
• obtain an indemnity for third party breaches and IP;
• ensure that any limitations on remedies and/or liability under the licence are consistent with all relevant Commonwealth policies. In particular, agencies should ensure that any limitation on the developer's liability under the contract does not represent an unacceptable risk to the agency based on the agency's risk assessment.

CONCLUSION

Open Source is an excellent solution for reducing ICT spend and encouraging more competition in the ICT market. As Spinellis and Giannikas rightly point out: "[Open Source] is not an all or nothing proposition; it can be adopted in a gradual fashion testing the waters for benefits and unknown risks." ⁴¹ Government agencies are required to consider Open Source as an ICT solution according to federal IT procurement policy. Through comprehensive investigation and risk analysis, the financial benefits of Open Source may result in substantial ICT savings and economic efficiencies. Agencies can capitalise on the opportunities that Open Source software presents if they understand the advantages and risks (and the value for money) of using that software.

Footnotes

¹ Sir Peter Gershon, Review of the Australian Government's Use of Information and Communication Technology (Department of Finance and Deregulation, 2008) 43 available online: < htt://www.finance.gov.au/publications/ict-review/ >.

² HMG, Office of Government Commerce, Open Source Software Trials in Government: Final Report (October 2004) also cited in Will Scrimshaw and Matthew Harris "Open Source Software – an overview of the main legal and commercial implications of its use" (2005) 11(7) Computer and Telecommunications Law Review 222.

³ Liam Maxwell quoted by Brian Glick, "Government mandates 'preference' for open source" ComputerWe ekly.com (online) Friday, 15 March 2013: < http://www.computerweekly.com/ news/2240179643/Government-mandates-preference-for-open- source > (last accessed 1/10/2013).

⁴ European Commission, Strategy for Internal Use of OSS at the EC , (01/08/2013) < http://ec.europa.eu/dgs/informatics/oss_tech/index_ en.htm > (last accessed 5/09/2013).

⁵ Australian Commonwealth Government, Department of Finance and Deregulation – AGIMO, A Guide to Open Source Software for Australian Government Agencies (version 2.0, 2011) 2.

⁶ Australian Commonwealth Government, Department of Finance and Deregulation – AGIMO, "Open Source Software Policy", Australian Government Information Management Office (AGIMO) Circular , (No. 2010/004) 13 January 2011.

⁷ See Josh Taylor, "Australian government can't recruit fast enough for open source", ZDNet (online) 27 August 2013: < http://www. zdnet.com/australian-government-cant-recruit-fast-enough- for-open-source-7000019868/?s_cid=e551&ttag=e551 >; and "Australian Government Switching To Open Source" EFYTimes.com (online) 27 August 2013, < http://www.efytimes.com/e1/fullnews. a s p ? e d i d =114 42 0 >; and Stuart Corner, "Open-source platform gains popularity in government" The Sydney Morning Herald (Sydney, Australia) 24 September 2013 available online: < http://www.smh. com.au/it-pro/government-it/opensource-platform-gains-popularity- in-government-20130924-hv1sj.html >.

⁸ " Source Code refers to the human readable instructions that comprise a computer program. Modification to software cannot be done without access to the software's source code." Definition cited in Brian Fitzgerald & Nic Suzor, "Legal Issues for the Use of Free and Open Source Software in Government" (2005) 29 Melbourne University Law Review 412, 413.

⁹ Australian Commonwealth Government, Department of Finance and Deregulation – AGIMO, above n 5.

10 Andrew Katz, "Open Source Software: An Opening Resource" (2006) Computers and the Law 10 , 11.

11 Robert Jacobson v. Matthew Katzer and Kamind Assoc.s Inc 535 F. 3d 1373 (Fed. Cir. 2008).

¹² I bid . 1379

¹³ See the Open Source Initiative, About the Open Source Initiative , (16 July 2013) Open Source Initiative < http://opensource.org/about >.

¹⁴ AGIMO, above n 5, 16.

¹⁵ See further Diomidis Spinellis and Vaggelis Giannikas "Organizational adoption of open source software" (2012) 85(3) The Journal of Systems and Software, 666 – 682; also available online: < http://www.dmst.aueb. gr/dds/pubs/jrnl/2012-JSS-OSS-Industry-Use/html/SG11.html >.

¹⁶ Open Source Initiative, above n 13.

¹⁷ Ibid.

¹⁸ Ibid.

¹⁹ Matthew Baldwin, "Open source software – what to look out for" (2011) 14 Internet Law Bulletin , 150.

²⁰ See AGIMO, above n 5 at Appendix 1: Australian Government Open Source Software Licensing Risk Framework; and Federal Financial Institutions Examination Council, Risk Management of Free and Open Source Software (13 September 2010) FFIEC < http://www.ffiec. gov/press/pr102104.htm >.

²¹ Department of Finance and Administration, Guidelines for Issuing and Managing Indemnities, Guarantees, Warranties and Letters of Comfort. Financial Management Guidance No. 6, (Department of Finance and Administration, 2003), 7 < http://www.finance.gov.au/publications/finance- circulars/2003/docs/Contingent_Liabilities_Finance_Circular.pdf > .

²² Bug tracking: is software attached to an Open Source project which allows the community to file defects ("Bugs") in the software for repair. An example is "Bugzilla" where the bug tracking software assigns all bugs to a "gatekeeper" which then assigns bugs to a developer for repair. See Bugzilla (22 May 2013) http://www.bugzilla. org/ and (2 October 2013) Wikipedia < http://en.wikipedia.org/wiki/ Bugzilla > for more information.

²³ UK Cabinet Office, Assessment of Software for Government (V 1.0, April 2012) 9 < https://www.gov.uk/government/uploads/system/ uploads/attachment_data/file/78974/Assessment_of_Software_for_ Government_v1_0.pdf >.

²⁴ Amanda McBratney and Malcolm McBratney, "Source of concern for IT purchasing decisions" (2010) 23 Australian Intellectual Property Law Bulletin 101, 103.

²⁵ UK Cabinet Office, above n 23, 9.

26 HMG Procurement Service, ICT Advice Note – Procurement of Open Source , (November 2011, v1.1) 5, available online: < https://www.gov. uk/government/publications/open-source-procurement-toolkit > (last accessed 26/09/2013).

⁷ See eg in the USA Jacobsen v Katzer , above n 12, and a list of successful enforcement actions (including both lawsuits and settlements) at News of the Gpl-violations.org Progect at < http://gpl- violations.org/news/ > cited in Heather Meeker. Meeker also discusses several other successful Open Source licence enforcement disputes in her article "Open Source and the Age of Enforcement" (2012) 4(2) Hastings Science and Technology Law Journal 267.

²⁸ AGIMO, above n 14, 26.

²⁹ Ibid. 27.

30 Ibid. 29.

31 Ibid. 7.

32 See further UK Cabinet Office, above n 23, 6.

33 Diomidis Spinellis and Vaggelis Giannikas, above n 15, 669-670.

34 Examining web server logs (278 million entries) and using network probes.

35 The study obtained its data by examining specific Open Source software systems t-tests analyses.

36 Diomidis Spinellis and Vaggelis Giannikas, above n 15, 677.

37 Ibid. 682.

³⁸ See further David A. Wheeler Why Open Source Software/ Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! (16 April 2007) David A. Wheeler's personal homepage < www. dwheeler.com/oss_fs_why.html > (reviewing thirty studies or other data points concerning the total cost of ownership of free software systems as compared to their proprietary counterparts) cited in Justin Colann, "Free and open source software in municipal procurement: the challenges and benefits of cooperation" Fordham Urban Law Journal (2012) 39(4), 903.

³⁹ Federal Financial Institutions Examination Council, Risk Management of Free and Open Source Software , < www.ffiec.gov >

⁴⁰ UK Cabinet Office, above n 32, 11.

⁴¹ Diomidis Spinellis and Vaggelis Giannikas, above n 15, 682.

© DLA Piper

This publication is intended as a general overview and discussion of the subjects dealt with. It is not intended to be, and should not used as, a substitute for taking legal advice in any specific situation. DLA Piper Australia will accept no responsibility for any actions taken or not taken on the basis of this publication.

DLA Piper Australia is part of DLA Piper, a global law firm, operating through various separate and distinct legal entities. For further information, please refer to www.dlapiper.com