Recommendations

34 To help manage the specific risks of open source software, SSC makes the following general recommendations to agencies:

Using Stand-Alone Open Source Applications

35 There is usually no significant legal risk from mere use of open source software. But before using the software agencies should consider the following, in the same way they should with any commercial software:

35.1 Read and understand the open source licence. This is a fundamental precaution for ensuring the software is appropriate for the intended use. And it is good practice to have the terms of any contract, including an open source licence, legally reviewed. The GPLv2, LGPLv2.1, CAL, MBSD and MIT licences are appropriate for stand-alone use.

35.2 Obtain performance and intellectual property protection from the supplier of the open source software, where appropriate and available. These include warranties that:

35.2.1 the software conforms to the supplier's specification and the agency's requirements. Suppliers will generally be unwilling to provide a more open-ended "fitness for purpose" warranty

35.2.2 the agency's use of the software in accordance with the agreement will not breach the intellectual property rights of any third party, backed by an intellectual property indemnity.

35.3 Negotiate any other appropriate contractual terms. These include implementation, support, payment, taxation, dispute resolution, confidentiality, etc.

36 Where the open source software is provided free of charge, it will generally be inappropriate to seek warranties/indemnities or other contractual additional terms. Because commercial software is usually chargeable, most agencies are able to negotiate warranties when licensing significant items of commercial software.

37 Open source operating systems are usually used on a stand-alone basis, and pose no risks. However, if commercial code exposes the internal data structures of a strongly propagating operating system, or statically links to the operating system's libraries, it may be encumbered. These situations should be dealt with in accordance with the following section, as integration with open source software.

In-House Modification or Integration of Open Source Software

38 In these situations a deeper understanding of the implications of the source code licence is necessary. This is because modification or integration may cause the open source licence to propagate. The agency should:

38.1 Use freely any open source software that is licensed under a non-propagating licence. This includes the MBSD and MIT licences.

38.2 For other open source licences, choose a distribution strategy. If using software licensed under a propagating open source licence, including the GPLv2, LGPLv2.1 and CAL, choose one of the following distribution strategies for the resulting software:

38.2.1 Closed distribution, i.e. distribution only within the agency's legal entity.

38.2.2 Limited distribution, i.e. distribution to other legal entities on non-open source terms.

38.2.3 Open distribution, i.e. distribution on open source terms. This does notmean that the agency must distribute the software, only that if it did, it would do so on open source terms.

Agencies should be aware of the scope of their legal entity. As government departments are part of the Crown, a single legal entity, provision of open source software between them would not constitute distribution. But non-departmental agencies, such as Offices of Parliament, Crown Entities and State Owned Enterprises, are distinct legal entities and provision of open source software between them will amount to distribution.

An agency must also consider its obligations under the Official Information Act 1982 if it receives a request to disclose software it owns or has licensed.

38.3 And implement the software appropriately. For the GPLv2, LGPLv2.1 and CAL this means:

Using Third Party Developers

39 When using third party developers, agencies have less control over whether open source software is included in the developed software. Accordingly, there can be a higher risk of propagation. Agencies should:

39.1 Ensure developers have obtained the agency's consent to the licence terms before providing the licensed software. This applies whether the developer is providing open source or commercial software. Requiring consent, means the agency has an opportunity to apply these recommendations appropriately. As developers may not know in advance what open source software will be used in a project, consent can be given during the project.

39.2 Include appropriate provisions in development contracts. Appropriate provisions include the following:

Distributing Software

40 It is usually only when open source software is distributed that the key obligations under its open source licence start to apply. When distributing software, the agency should:

40.1 Confirm whether open source licences apply. It is not always an easy task. One approach is to search the source code for copyright notices, to identify if any open source code can be found.

40.2 Meet all relevant distribution requirements. The distribution requirements are likely to include providing copies of source code and including copyright notices. The licences approved under this guide require the following copyright notices and disclaimers with any encumbered software:

41 Although an open source licence may purport to disclaim all warranties, by virtue of the Consumer Guarantees Act 1993 certain warranties, including warranties governing quality and fitness for purpose, may apply to open source software distributed by agencies.