Background

Key Features of Open Source Licences

10 For the purposes of this guide, the term "open source" describes software licensing arrangements that share the following features:

• Modification permitted and source code provided: Open source licences let licensees use and modify the software's source code.

• Distribution permitted: Open source licences allow licensees to distribute the software, whether in its original form, as part of another software program, or as modified by the licensee.

11 Open source licences commonly include a number of additional features that are relevant to this guide, including:

• "Infectious" nature: Many open source licences are "infectious", meaning that the original open source licence may apply to:

(a) the original software if re-distributed

(b) any modification of the original software if redistributed

(c) software containing or integrated with the original software, if redistributed

(d) software used in conjunction with the original software to provide a web based service.

We prefer to use the descriptive term "infectious", in a similar manner to Greg Vetter's widely referenced paper on open source licenses: http://opensource.mit.edu/papers/vetter2.pdf.

• No warranties: Open source software is generally provided "as is", without any warranties as to its fitness for a purpose, performance, title or infringement, and without any indemnities against third party claims of intellectual property infringement.

12 The Open Source Initiative (OSI) has currently approved over 55 open source licences, including what they describe as the "classic" GPL, LGPL, BSD and MIT licences. As each open source licence is written on different terms, each licence may have different legal effect. As OSI points out, "be sure that you read and understand the license terms completely".

back to top

Understanding the Infectious Effects of Open Source Licences

13 A key to understanding the legal risks of open source is understanding the extent to which open source licences are infectious.

Shading illustrates the components subject to an open source licence.

There are three broad levels of infection

14 Open source licences can be grouped into three broad levels of infectiousness, illustrated below:

Strongly infectious licences

15 A "strongly infectious" open source licence will infect any redistributed piece of software that contains or is derived from software licensed under it. It is generally very difficult to modify or integrate software licensed under a strongly infectious open source licence without the resulting product, when redistributed, becoming "open source" on the same terms as the original. The GPL is an example of a strongly infectious open source licence.

16 Software may also be infected by a strongly infectious licence in the following circumstances:

• Infected software output: It can be argued that any output from a piece of open source software is "derived" from that software, and accordingly is infected. Open source compiler programs are an interesting case in point. A compiler translates source code into object code that can be executed on a computer. The object code is the output, and derivative, of the compiler. So any application that has been compiled by a strongly infectious open source compiler may itself be infected. The GPL expressly provides that software compiled with the GNU Compiler Collection (GCC) is not infected by the GPL. Presumably the Free Software Foundation considers other GPL compilers will infect the compiled software.

• Libraries: A library is a collection of subprograms, which 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). It is not settled whether static or dynamic linking of a strongly infectious open source library will infect the resulting application. But the GPL assumes they do. Most operating systems include libraries used by the applications that run on them. An exception to the GPL provides that the distributed source code need not include anything normally distributed with the major components of an operating system, i.e. the libraries that come with the operating system.

• 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. 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. 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. A client is a program that accesses a service on another computer, via a network. 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. It has been argued that if these programs are written with specific open source software in mind, they will be infected by the relevant open source licence, but if they were written generally, without knowledge of the internal working of the open source software, then they aren't infected. The legal position is unsettled.

• ASPs and web services: An application service provider (ASP) is a business that provides computer-based services to customers over a network. A web service is a software system designed to support interoperable machine-to-machine interaction over a network. In both cases, the software itself is never distributed. For that reason, open source licences that require distribution in order to become infectious, will have no effect. To counter this, many strongly infectious open source licences include a "network use" clause deeming use over a network to be a distribution. A network use clause may be included in the next version of GPL.

Weakly infectious licences

17 A "weakly infectious" open source licence will infect only itself and modified or augmented versions of itself; that is, versions which have been added to or changed. Where a developer takes components licensed under a weakly infectious open source licence and integrates them into other software, that other software is not infected, 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 weakly infectious licence, and a non-open source component is added to it, more often than not the resulting product will be infected. Again, it all depends on how the licence is worded. The CAL is an example of a weakly infectious open source licence.

Permissive licences

18 A "permissive" open source licence is not infectious. A permissive licence does not apply to the original software itself, modifications of the software, or to other software that is integrated with it. The MIT Licence is an example of a permissive open source licence.

Infectious licences can be quarantined by various integration techniques

19 The infectious effects of open source licences can be "quarantined" by keeping open source components sufficiently separate from the rest of the software. Take for example an application, which utilises a component licensed under the GPL (a strongly infectious licence). If this component is integrated with the rest of the application in such a manner that the application as a whole cannot be said to "contain" the component, the package is not infected by the GPL. The developer of the package would have to distribute the component itself under the GPL, but could treat the rest of the package as its own proprietary product.

20 The infectious impact of various integration techniques is illustrated below.

21 However, the diagram above should be taken as a guide only. There will often be considerable uncertainty over what degree of separation is sufficient to avoid infection by a particular open source licence, because of the following:

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

• 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. These issues can be complicated, and legal advice from lawyers in the governing jurisdiction may be needed.

• Many open source licences are drafted in language which is ambiguous or even downright vague - 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 - US courts have determined that to be a "derivative", software must be substantially similar to and in some form include a portion of the original work. Derivative may or may not have the same meaning under NZ law.

• To compound the problem, there are virtually no judicial precedents on this point, even in relation to common licences like the GPL. 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.

22 As a rule of thumb:

• There is no infection for "mere use" of open source software. This includes running a standalone open source word processing or spreadsheet package.

• But there is likely to be infection where open source software is modified or integrated into other software. "Integrated" can mean anything from data-sharing between applications to transplanting code from one piece of software to another.

23 Because of the uncertainty surrounding this issue, if the consequences of infection are severe for any intended use of a software application, then the approach taken should be conservative and seek to avoid any possibility of infection. There is no substitute here for case-by-case analysis and building up a body of precedents as risk assessments are done.

back to top

Legal Risks in Using Open Source Software

24 This section describes the key legal risks of using open source software, and whether these risks are substantial in practice.

There are a number of legal risks

Exposure to faults and intellectual property claims

25 There is a risk that open source software contains functional defects, or breaches a third party's intellectual property rights (e.g. where it contains code misappropriated from proprietary software or functionality in breach of a patent). The absence of warranties and indemnities in most open source licences means the licensee bears this risk. This can be contrasted with the protection usually available under commercial software licences.

26 Although patents only protect against unlicensed use in the country in which the patent was granted, patents can create particularly severe intellectual property infringement risks. This is because patents take precedence over an otherwise valid open source licence. In addition, the impact of patents is constantly increasing as the number of software patents increases. Many multinational software corporations maintain large patent portfolios in a range of countries which they can enforce against software developers and users in those countries.

27 It is worth noting that 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 still apply to open source software that was not acquired for the purposes of a business.

Disclosure of confidential code

28 Agencies will want to keep some software strictly confidential. Security related software may be an example. There are several circumstances in which confidential software infected by an open source licence might become openly available against the agency's wishes, for example:

• If software is infected by an open source licence, an agency may have no right to distribute the infected software unless it does so on open source terms. The agency is in an unenviable position. It must either breach the open source licence or make the confidential source code open.

• Because an agency may simply choose not to distribute the confidential, infected software, perhaps a more likely risk is that someone receiving an inadvertently disclosed copy of infected software will have an implied licence to use it on the terms of the infecting open source licence. Because of that implied licence, the agency may be unable to obtain an injunction to stop the recipient using the infected software.

• Further, while most open source licences do not require redistribution of the source code or any modifications to it, it is conceivable that an open source licence might require distribution of modifications as a condition of the right to modify and use the original software.

No rights to distribute infected software

29 An agency will have no right to distribute:

• infected software on non-open source terms

• software that is infected by more than one open source licence, if the open source licences are not compatible (i.e. each open source licence may require the infected software to be used or distributed under its licence terms and not the other/s).

30 Apart from not meeting its legal obligations, in these situations the agency faces an increased risk that it may need to protect its licensees against third party claims they can't validly use the infected software. This obligation would normally arise under the "IP Warranty" clause in the distribution agreement.

Inability to commercialise

31 The above risks can obviously make it difficult to commercialise infected software . As this is not usually an issue for government agencies, commercialisation issues are not dealt with directly in this guide.

Other risks

32 Because most open source licences deal only with licensing issues, many important provisions such as taxation, confidentiality and dispute resolution may be missing. There is also the risk, when using open source software under an obscure open source licence, of unusual licence provisions that have not been considered in this guide.

Risks are affected by the software's intended use

33 The risks described above do not apply equally to all intended uses of open source software. For example:

• The risks are high if an agency is using open source software in confidential software intended only for internal use.

• The risks are low if the agency is using an open source component in an application that is itself intended for release on open source terms.

And the licence terms may never be enforced

34 Apart from the risks of exposure to faults and third party intellectual property claims, the other risks described above will only eventuate if a third party enforces the open source licence against the licensee. So who would do that?

Legal proceedings can only be taken by certain people

35 The only parties entitled to take legal proceedings in relation to open source software 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 likely to be little incentive on the direct licensor or the owner of the code to enforce their rights legally - after all they must have been happy for their code to be freely used and modified or they would not have released it on open source terms.

36 Enforcement is complicated further by the fact that open source software can have multiple owners, as the author of each part of the software may own that part. To address this issue, some open source organisations encourage authors to assign ownership of any new open source code to the open source organisation. This concentrates ownership in one organisation and simplifies any enforcement of the open source licence by that organisation.

Who might enforce a claim?

37 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:

• Defence from unlicensed user: If software is infected by an open source licence (because it contains open source code), the terms of the open source licence could legitimise use that would otherwise be unauthorised. In other words, an unauthorised user might claim as a defence that the owner should have licensed the software on open source terms.

• Claim by interest group: In some circumstances, an open source interest group, such as the Free Software Foundation, may fund a claim on behalf of the code owners, or take a claim itself where it is the owner or direct licensor. It has been reported that, in 2003, the Free Software Foundation took out-of-court action against some 50 GPL infringers.

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

back to top