Executive Summary

4 Software is generally considered to be "open source" when it is provided in source code (i.e. human readable) form, under a licence that allows it to be modified and redistributed. In addition, many open source licences are "infectious". This means that the requirement to provide source code and permit modification applies to any redistribution of the original software, and even to software that merely contains the original, integrates with the original, or simply uses the original in certain ways.

5 There are many different types of open source licence. Each is worded differently and can pose slightly different legal risks. But in general terms the legal risks of these licences can be summarised as follows:

6 It is the infectiousness of open source licences that leads to many of these risks. Unfortunately it is not always clear-cut when any piece of open source software will be infectious. In addition, the practical significance of these risks for any particular piece of software will depend on the intended use of the software and whether anyone is likely to seek to enforce the terms of the open source licence.

7 Managing open source software risks can be complicated. To help simplify matters, SSC makes the following general recommendations to cover most open source legal risks facing government agencies:

• Using stand-alone, open source applications:

(a) Only use open source licences that have been legally reviewed, including the GPL, LGPL, CAL, MBSD, MIT, which have been reviewed and are recommended by SSC for use in accordance with this guide.

(b) Obtain performance and intellectual property warranties from the supplier of the open source software, where appropriate and available.

• In-house modification or integration of open source software: In addition to the above recommendations:

(a) Choose one of the following distribution strategies for the resulting software:

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

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

(iii) Open distribution, i.e. on open source terms.

(b) Manage the chosen licence to match the chosen distribution strategy as follows:

(c) Avoid the conflict of licence terms that can occur when more than one open source licence infects the same piece of software.

• Using third party developers:

(a) As the standard contractual position, prohibit use of open source software in all development contracts.

(b) If the developer wishes to use open source software, consider all of the above recommendations before agreeing to remove the open source prohibition. Include specific contractual provisions in the development contract to ensure the proposed use of open source software is appropriate.

• Redistributing software: In addition to the above recommendations, meet the distribution requirements of any relevant open source licences.

8 Agencies should put in place policies and procedures to ensure that these recommendations are met. As the above recommendations won't always fit the situation at hand, agencies should allow for exceptions on a case-by-case basis.

9 SSC's recommended approach can be summarised as follows:

back to top