Background

Features of Open Source Licences

6 Software is generally considered to be "open source" when it is made available in source code (i.e. human readable) form, under a licence that allows it to be modified and redistributed.

7 Some open source licences are said to "propagate". This means that the original open source licence must be applied when:

7.1 redistributing the original open source code

7.2 distributing modifications of the original open source code

7.3 distributing software that incorporates, or is derived from, the original open source code.

8 Software affected by a propagating licence is said to be "encumbered" by that licence. But it is important to note that propagation generally has effect only on distribution.

9 As with many commercial software products, open source software is generally provided "as is", without any:

9.1 warranties as to its fitness for a purpose, its performance, or the licensor's title to the software

9.2 indemnities against third party claims of intellectual property infringement.

Types of Open Source Licence

10 There are many different varieties of open source licence, including the 58 that have currently been approved by the Open Source Initiative, see http://www.opensource.org/licenses/. The original owner of the software determines which open source licence (or licences) to release the software under.

11 For the purposes of illustration, the recommendations in this guide are applied to the following open source licences:

11.1 General Public Licence v2, June 1991 (GPLv2)
see http://www.opensource.org/licenses/gpl-license.php.

11.2 Lesser General Public Licence v2.1, February 1999 (LGPLv2.1)
see http://www.opensource.org/licenses/lgpl-license.php.

11.3 Clarified Artistic Licence (CAL)
see www.statistica.unimib.it/utenti/dellavedova/software/artistic2.html.

11.4 Modified BSD Licence (MBSD)
see www.opensource.org/licenses/bsd-license.php.

11.5 MIT Licence (MIT) also called the X Licence or X11 Licence,
see www.opensource.org/licenses/mit-license.php.

12 This document is not an exhaustive guide to all open source licences. Agencies are free to use other open source licences but, as the Open Source Initiative points out, agencies must be sure they read and understand the licence terms completely.

Risks of Open Source Licences

13 As each open source licence is worded differently, they can pose slightly different legal risks. But in general terms the legal risks of open source licences can be summarised as follows:

13.1 Exposure to faults and intellectual property claims. This risk arises because open source software is usually provided "as is" without warranties or indemnities. (This risk applies equally to many commercial software products, and some argue that commercial software is even more prone to faults and intellectual property claims because the source code is not open for third parties to fix.)

13.2 Disclosure of confidential proprietary code. This risk arises where proprietary code is encumbered by a propagating open source licence and then distributed, because under the propagating licence the agency cannot usually control what recipients do with the proprietary code. Not all agency software will be confidential, but examples of confidential software include software containing algorithms and processes, which must remain confidential to ensure they are not circumvented, such as methods of identifying fraud. Another example would be military software such as flight software which might reveal weaknesses if released as open source. However, a propagating open source licence will not encumber the data used by an encumbered application.

13.3 Loss of open source rights. An agency will lose its rights to use, modify and distribute an item of open source software if:

13.3.1 the agency distributes, on non-open source terms, any software that is encumbered by the original open source software

13.3.2 the distributed software is encumbered by more than one open source licence and each licence requires the encumbered software to be used or distributed under its licence terms and not the other/s.

13.4 Circumvention of proprietary licence terms. The recipient of an agency's proprietary application may be able to circumvent the agency's licence for the application, if the application contains a strongly propagating, open source component. This is because the strongly propagating component may mean that the agency should have licensed the software to the recipient on open source terms, which would permit the recipient to use the software without restriction.

14 The above risks are reasonably limited but, in some circumstances, may have significant consequences. Accordingly agencies should ensure they understand and take reasonable steps to mitigate these risk.

Understanding Open Source Licence Propagation

15 The first risk described above applies when open source software is licensed into an agency for its internal use. The other risks apply when the open source software encumbers software on redistribution. Accordingly, these other risks are referred to as the "propagation risks" and a more detailed understanding of propagation is needed to address them. As a rule of thumb:

15.1 There is no propagation for:

15.1.1 "mere use" of open source software. This includes running a standalone open source word processing or spreadsheet package

15.1.2 modification or integration of open source software with other software, if the resulting application is not distributed.

15.2 There maybe propagation where open source software is modified or integrated with other software and the combined application is distributed. "Integrated" can mean anything from data sharing between applications to transplanting code from one piece of software to another.

16 However not all open source software is propagating. Open source licences can be grouped into three broad levels of propagation, illustrated below:

Strong Propagation Licences

17 In general terms, a strong propagation licence will encumber any redistributed:

17.1 copy of the underlying software

17.2 modification of the underlying software

17.3 software that includes, or is sufficiently integrated with, the underlying software.

18 The GPLv2 is an example of a strong propagation open source licence. It applies to any distributed software that "in whole or part contains or is derived from" software that is licensed under the GPLv2. It is relatively easy to determine whether commercial software "contains" GPLv2 code by comparing the source code files word-for-word. Determining whether commercial software is "derivative" of GPLv2 code is less straightforward. The Free Software Foundation's frequently asked questions page for the GPLv2 states "we believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged)". They add "if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program".

19 Accordingly, software may be encumbered by the GPLv2 in the following circumstances:

19.1 Libraries . A library is a collection of subprograms that provide services to independent applications by way of "links". Linking allows library code and data to be shared and changed in a modular fashion between applications. Linking may be static (where the library data is copied into the application when it is compiled) or dynamic (where the library remains distinct from the application). Statically linking to an open source library under the GPLv2 will encumber the resulting application, as the application will "contain" part of the open source library. Dynamically linking to an open source library may also encumber the resulting application, if the library and the application are sufficiently intimately connected.

19.2 Programs that communicate with open source applications. Many programs send instructions to, or receive instructions from, open source applications, including plug-ins, device drivers, clients and GUIs (see definitions below). It has been argued that if these programs are written with specific open source software in mind, i.e. if they are derivative, then the relevant open source licence will encumber them, but if they were written generally, without knowledge of the internal working of the open source software and are not derivative, then they aren't encumbered.

19.2.1 A plug-in is usually a program that interacts with an operating system's user interface, to provide a specific function. Examples are plug-ins to display specific graphic formats (e.g. SVG if the browser doesn't support this format natively), to play multimedia files, to encrypt/decrypt email (e.g. PGP), or to filter images in graphic programs.

19.2.2 A device driver is usually a program that enables an operating system to interact with a hardware device by way of an abstraction layer built into the operating system.

19.2.3 A client is a program that accesses a service on another computer, via a network.

19.2.4 A GUI or graphical user interface is the means of interacting with a computer by graphic images, such as the windows, icons, menus and pointing devices of most modern operating systems.

19.3 ASPs and web services. Some strongly propagating licences may deem the use of open source software over a network to be distribution, although the software itself is never actually distributed. This can affect ASPs and web services:

19.3.1 An application service provider (ASP) is a business that provides computer-based services to customers over a network.

19.3.2 A web service is a software system designed to support interoperable machine-to-machine interaction over a network.

Weak Propagation Licences

20 In general terms, a weak propagation open source licence will only encumber a redistributed:

20.1 copy of the underlying software

20.2 modification of the underlying software.

21 But where a developer includes software under a weak propagation licence in a larger application, the larger application is not encumbered and does not become open source. Note however that this does not necessarily apply in reverse - where the parent application is open source under a weak propagation licence, and a non-open source component is added to it, more often than not, the resulting product will be encumbered.

22 The CAL is an example of a weak propagation open source licence, as it only applies to "derivatives...created through textual modification".

23 LGPLv2.1 software is weakly propagating, but only if the software that uses an LGPLv2.1 library:

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

23.2 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.

Non-Propagating Licences

24 Many open source licence will not propagate at all. They do not apply to redistributions of the original software itself, modifications of the software, or to other software that is integrated with it.

25 The MIT Licence is an example of a non-propagating open source licence as it permits a recipient "to deal in the Software without restriction".

26 The CAL, which is normally weakly propagating, will become non-propagating if the agency:

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

26.2 provides a separate manual page for each non-standard executable that clearly documents how it differs from the standard version.

Constraining Strong Propagating Open Source Software

27 In most cases, agencies will not be concerned if the original open source software, or minor modifications to the original, are encumbered. However, agencies are more likely to be concerned if an open source licence encumbers applications that are essentially separate. This means that the propagation risks described above lie mainly with strongly propagating licences, as these propagate to applications that include open source components or are sufficiently integrated with them. One way to avoid these licences propagating is to ensure that their method of integration is such that the open source licence does not propagate. We refer to this process as "constraining" the open source licence.

28 The impact of various integration techniques on the ability of a strong propagating open source to propagate is illustrated below.

Legal Interpretation of Propagating Licences

29 The above discussion of propagation and constraint should be taken as a guide only. There will often be considerable uncertainty over what degree of constraint is sufficient to avoid propagation of a particular open source licence, because of the following:

29.1 Differently worded open source licences require different degrees of separation for successful constraint. In each case it is a question of interpretation, often requiring legal advice.

29.2 The law that governs an open source licence will influence its interpretation. The governing law may be specified in the open source licence, or it may need to be inferred from the circumstances, including where the transaction took place and the country of residency of the parties. Legal advice from lawyers in the governing jurisdiction may be needed.

29.3 Many open source licences are drafted in ambiguous language - phrases such as "derivative" and "separate works" do not provide any clear indications as to which methods of integration (e.g. static linking, dynamic linking) will result in sufficient separation and which will not. "Derivative" is a term originating under US copyright law. It may not have the same meaning under NZ law.

29.4 To compound the problem, there are virtually no judicial precedents on this point, even in relation to common licences like the GPLv2. As a result, it is difficult to discern the legal view (as opposed to views of the open source community) on the various methods of integration. However, official commentary on the open source licence, such as the Free Software Foundation's "Frequently Asked Questions about the GNU GPL" (see www.gnu.org/licenses/gpl-faq.html), may be persuasive in interpreting open source licences.

30 Because of the uncertainty in interpretation, if the consequences of propagation are severe for any intended use of a software application, then the approach taken should be conservative and seek to avoid any possibility of propagation.

Enforcement of Open Source Licences

31 Some of the open source risks apply only to the extent that someone seeks to enforce the propagating open source licence. The only parties entitled to take legal proceedings to enforce an open source licence are the immediate licensor (for breach of the open source licence) and the owner of the code (for breach of copyright if the open source licence is not followed). Legal proceedings are expensive, and there is often little incentive on the direct licensor or owner to enforce their rights legally - after all they must have been happy for the code to be freely used and modified or they would not have released it on open source terms.

32 Legal enforcement can be complicated further by the fact that open source software can have multiple owners - generally, the author of each part of the software owns the part they wrote. To address this issue, some open source organisations encourage authors to assign ownership of any new open source code to the organisation. This concentrates ownership and simplifies any enforcement of the open source licence by the owning organisation.

33 So there are probably few situations in which anyone would enforce an open source licence. But there are some situations where they may, including the following:

33.1 Defence from unlicensed user. If a software user breaches a proprietary licence, for example by redistributing the licensed software without authorisation, they will seek any opportunity to justify their breach and circumvent the license. If the software includes a strongly propagating open source component, the user might claim as a defence that their distribution was permitted because the owner should have licensed the software on open source terms.

33.2 Legal claim by interest group. In some circumstances, an open source interest group, such as the Free Software Foundation, may fund a legal claim on behalf of the code owners, or take a claim itself where it is the owner or direct licensor.

33.3 Public pressure. Perhaps a more likely approach, although not a legal one, is that the open source community may put political pressure on the infringing organisation to comply with the open source licence. It has been reported that, in 2003, the Free Software Foundation took out-of-court action against some 50 GPLv2 infringers.