Recommendations

38 Dealing with the risks of open source software can be complicated, given the multitude of open source licences, the ways in which they can infect other software, and the numerous ways in which open source software may be used. To help simplify matters, this guide contains recommendations that SSC hopes will address the risks in most open source use by government agencies.

39 The recommendations cover the main situations in which government agencies might acquire and use open source software, namely:

• Licensing stand-alone open source applications for internal use.

• Internal development using open source software.

• Using contractors to develop software.

• Distributing software to third parties.

40 Government agencies should put in place policies and procedures to ensure that the recommendations are met. As the recommendations are necessarily general, and err on the side of caution, agencies should implement a process for granting appropriate exemptions to the recommendations on a case-by-case basis.

back to top

Using Stand Alone Open Source Applications

41 If an agency is merely using open source software, there is usually no risk of infection and the agency should follow the recommendations in this section.

42 However, as illustrated in the section headed "Understanding the Infectious Effects of Open Source Licences", it can be unclear what constitutes "mere use" without infection. In inherently risky situations (e.g. when using highly confidential software together with the open source application to provide web services) the agency may want legal advice on the likelihood of any open source infections.

Only use specific open source licences

43 Because of the complexities of the many different open source licences, SSC only recommends use of open source software under the following licences:

the GNU General Public Licence (GPL), a strongly infectious licence

the GNU Lesser General Public Licence (LGPL), a strongly infectious licence containing exceptions allowing it to act like a weakly infectious licence if certain criteria are met

the Clarified Artistic Licence (CAL), a weakly infectious licence

the Modified BSD Licence (MBSD), a permissive licence

the MIT Licence (MIT), a permissive licence.

44 If an agency proposes to use open source software under any other open source licence, it should seek approval under Part E - Exceptions.

Obtain warranties/indemnities if appropriate and available

45 The warranties and indemnities that an agency should seek from external suppliers, where appropriate and available, include the following:

A warranty that 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.

A warranty that the agency's use of the software in accordance with the agreement will not breach the intellectual property rights of any third party.

An indemnity from any third party's claim that its intellectual property rights have been infringed by the agency using the software in accordance with the agreement.

46 These warranties and indemnity should protect against patent claims in all jurisdictions in which the code may be used. Their effectiveness will depend on the precise terms of the warranties and the supplier's financial means. It is good practice to have the warranties legally reviewed.

47 It will be appropriate to obtain these warranties and indemnities if:

the agency is paying a significant amount of money for the software or a wider package which relies on it

the software is to be used in a "mission critical" application, i.e. where a failure would cause serious loss or disruption

the supplier of the software recommended the use of the open source software as an alternative to a proprietary product.

48 Whether the agency will be able to negotiate warranties and indemnities in respect of open source software will depend on its negotiating leverage with the supplier.

49 Where the agency is not able to obtain suitable warranties and indemnities, it should consider alternatives to the open source software in question. Proceeding without relevant warranties and indemnities does not require sign-off under Part E - Exemptions, but before proceeding the agency should weigh:

the benefits of using the particular open source software - for example, cost savings or the ability to customise

the likelihood and amount of loss which might be sustained by the agency, for example:

(a) lost productivity, data loss or repair costs, in the event of a technical failure

(b) negative publicity, legal expenses or damages for infringement, if the agency is accused by a third party of infringing its intellectual property rights.

back to top

Internal Modification and Integration

50 If an agency is modifying/integrating open source software, it should treat the open source licence as infectious and follow the recommendations in this section, in addition to the recommendations set out in the section above. If the open source licence is not infectious, only the recommendations in the section above need be followed.

Choose a distribution strategy

51 The government agency should first choose an appropriate distribution strategy for the finished product. There are three possible strategies:

Closed distribution: Because of the nature of the software, e.g. its strict confidentiality, it must never be distributed outside the legal entity in which it originates.

Limited distribution: The software may be distributed outside the legal entity in which it originates, now or in the future, but the agency will want to restrict distribution to a limited group of recipients and/or licence the software on non-open source terms, e.g. without providing the source code.

Open distribution: The agency is comfortable that:

(a) if it wished to distribute the software, it would do so on open source terms; and

(b) inadvertent release of the software would not unduly prejudice the agency.

52 It is important to note that government departments are part of the single legal entity, the Crown. Accordingly, a closed distribution strategy for one department would permit distribution amongst all departments. However Crown Entities (EQC or NZQA, for example) and SOEs are not part of the Crown and are distinct legal entities from each other. So distribution between these entities would require a limited distribution strategy rather than closed.

53 It should also be noted that an open distribution strategy does not mean that the agency must distribute the software. An agency must consider its obligations under the Official Information Act 1982 if it receives a request to disclose software it owns or has licensed.

Manage the chosen licence to match the chosen strategy

54 Once the government agency has chosen a distribution strategy and the open source licence it will use, it should manage its use of the open source code in accordance with the following table.

55 The requirements set out in the above table are explained in more detail in the following paragraphs.

Quarantining GPL code

56 Quarantining is necessary where the agency wants to develop or commission software utilising GPL code, but the software is intended for limited or closed distribution. In other words, quarantining is a method of avoiding the infectious terms of the GPL in order to guarantee limited or closed distribution.

57 It is a somewhat risky approach. The GPL is not entirely clear on the degree or methods of separation necessary to prevent the GPL from infecting software, which utilises code or components licensed under it. However, we believe it is safe for an agency to quarantine GPL code by confining the code to a separate executable or a plug-in invoked by a technique such as "fork-exec" (in Unix). Any other form of integration requires a risk assessment and legal sign-off on an exception basis as set out in Part E - Exceptions.

58 Where GPL code is successfully quarantined, the rest of the software can be distributed under proprietary terms, and without providing the source code. Note however that the quarantined code (for example, the plug-in) must still be distributed under the terms of the GPL.

Quarantining or meeting LGPL exception

59 Where the agency chooses a closed or limited distribution strategy, code licensed under the LGPL will be suitable for modification or incorporation into other software only if one of the following apply:

First, the LGPL code may be quarantined in the same manner as for GPL software, described above.

Secondly, under clause 6 of the LGPL, software that uses a LGPL library may be distributed without source code if the LGPL library is linked by a mechanism which:

(a) uses at run time a copy of the library already present on the user's computer system (i.e. a dynamically linked library)

(b) will operate properly with a modified version of the library if the user installs one, as long as the modified version is interface-compatible with the version that was originally linked to by the application.

Before utilising this exception to the LGPL, those responsible for the software should consult the text of the LGPL, particularly as clause 6 includes other distribution requirements such as permitting modification for the customer's own use (even though source code is not provided).

Quarantining or meeting the CAL exception

60 Where the agency chooses a closed or limited distribution strategy, code licensed under the Clarified Artistic Licence will be suitable for modification or incorporation into other software only if one of the following apply:

First, the CAL code may be quarantined. The CAL is weakly infectious as it only applies to the original files and derivatives of the original files "that are created through textual modification". Accordingly, it is safe to link to CAL software without risk of infection.

Secondly, clause 4.3 of the CAL provides a way to avoid such derivatives being infected. The clause requires the distributor to:

(a) renames any non-standard executables so the names do not conflict with names of the original executable

(b) document in a manual how each executable differs from its original version

(c) provide instructions on where to get the original version to anyone to whom it distributes the software.

61 Before utilising this exception, those responsible for the adaptation of the open source software should consult the Clarified Artistic Licence, particularly clauses 3 and 4 and its additional requirements for notice of modifications.

Avoid conflicts of open source licences

62 Care should be taken to avoid licence conflicts which may occur when a piece of software is infected by two or more different licences with incompatible requirements; that is, where complying with one licence would result in a breach of the other. The licences listed above are widely accepted as compatible with the GPL and each other.

back to top

Third Party Software Developments

63 When using third party developers, agencies have less control over whether open source software is included in the developed software, and hence there is often a higher risk of infection. To address these risks, the agency should follow the recommendations in this section.

Prohibit use of open source software without consent

64 As its standard position, all Development Agreements should prohibit the use of any open source code in the supplied software.

If open source used and approved, include specific contractual provisions

65 If the developer wishes to use open source software, the agency may remove the prohibition only after considering all of the recommendations above.

66 If the agency gives its consent for the third party to include open source code in the software, the following provisions should be included in the development contract, depending on the desired distribution strategy:

67 If the new code is owned by an agency that is part of the Crown, it will be subject to crown copyright. Otherwise it will be subject to ordinary copyright. There is little difference between the two types of copyright for the purposes of this guide.

back to top

Software Distribution

68 If an agency wishes to distribute any software, it should follow the recommendations in this section. The aim is to ensure that if the software has been infected, that the underlying open source licences are complied with.

Confirm whether any open source licence applies

69 The first step is to confirm what open source licences apply. It is not always an easy task. One approach is to identify who developed each module and determine on what basis the agency is using it (e.g. as owner or licensee and, if as licensee, then on what terms). Another approach is to read the End User License Agreement and/or search the source code for copyright notices, to identify if any open source code can be found.

70 The next step is to identify whether the open source code has infected any other software being distributed.

Meet the distribution requirements for all infected software

71 For any infected software, the distribution requirements of the relevant open source licence should be complied with. The agency should consult the relevant open source licences to confirm the distribution requirements. They are likely to include:

Providing copies of source code

Including copyright notices. The licences approved under this guide require the following copyright notices and disclaimers with any infected software: