Legal Issues Arising from Use of Open Source Software Components

What is open source software

The term “open source” refers to material that people are able to modify, access and share freely because its components/design/underlying elements are publicly accessible.

Open source software (OSS) is software that has its source code publicly released under the terms of a copyright licence that allow for the general use, inspection, modification and enhancement of source code by anyone. Such a licence is called an open source licence. Open source licensing is commonly associated with software, but its application is broader than this – the “Free Beer” open source beer project (being a beer recipe and brand that is freely available for use under an open source licence) provides an interesting non-software example (click here for further information).

OSS can be contrasted with proprietary (closed source) software, which is software whose source code is kept as proprietary by its owner, and is not publicly available for anyone to access, modify or further develop. The source code of proprietary software is only available to parties other than the software owner in limited circumstances, and any such entitlements are set out in a licence agreement entered into between the party wishing to use the software (and often involving remuneration in the form of a licence fee or royalty scheme) and the software owner licensor. Licence agreements relating to proprietary software also set out what (limited) use the licensee is permitted to make of the software (e.g. install the software for use on X number of machines for use by a maximum of Y users, for internal business purposes only). Anything that is not permitted by the terms of the licensing arrangement is an unauthorised use that the licensor is entitled to take legal action to prevent/obtain damages in respect of.

Open source licences

There are a range of open source licences that have achieved general popularity and are widely used. These include:

• Apache Licence 2.0;
• GNU General Public Licence 3.0;
• GNU Library or “Lesser” General Public Licence;
• MIT Licence;
• Mozilla Public Licence 2.2; and
• Common Development and Distribution Licence.

All of these licences vary in their terms and requirements, but they all have certain essential elements in common including:

• No royalties or fees are payable to the owner of the licensed software;
• There is no restriction on selling or giving away the licensed software as part of another software distribution;
• There are no restrictions on the applications of the software;
• Source code must be supplied with the software; and
• Creation of modifications and derivative works is permitted, and these can be freely distributed under the same open source licence terms as the original software.

The entire purpose of open source licensing is to limit restrictions and promote public availability; accordingly there is no restriction on OSS being used for commercial purposes. It is therefore increasingly common for OSS components to be utilised by software developers when creating proprietary software, proposed to be used for internal business use or commercialisation.

OSS and legal issues

Use of OSS components when creating proprietary software seems like an obvious choice – someone else has done all the work (hence a saving in development effort and costs), and the components are free to use. While there are obvious benefits associated with OSS, software owners are often unaware that by using OSS components in their proprietary software, they may be subject to a range of obligations depending on the licensing terms under which the utilised OSS components are made available.

One notable obligation imposed by various open source licences is a requirement to include certain copyright notices, and in some instances, to make available certain code.

The current version of the Apache Licence, for example, permits the creation of derivative works and free re-distribution of the original material, and any derivative works that may be created, in source or object code form, provided that:

• Recipients are provided with a copy of the Apache Licence terms;
• Any modified files must carry prominent notices stating that the files have been changed;
• Source code versions must retain any included attribution, copyright, patent or trade mark notices; and
• If the original work included a NOTICE text file, the derivative works that are distributed must include a readable copy of those notices.

There is no restriction on the inclusion of additional copyright/attribution notices for new additions, or the use of different licence terms for any developed modifications as a whole – provided the Apache Licence terms are complied with.

As another example, the GNU General Public Licence includes detailed notice requirements also, for original and derivative works, and is an open source licence that permits conveyance of a work in object code form provided that the corresponding source code is also made generally available, free of charge, in one of the stipulated ways.

Practical implications for businesses

Though use of OSS components when developing software for internal or commercial use is an initially attractive option, businesses that do so must take all necessary steps to comply with the terms of the licences under which the OSS components are made available to them. The time and effort that can go into ensuring compliance means that there are hidden costs associated with the use of OSS components. Given this, and coupled with the fact that compliance may require the source code of any developed derivatives to be made publicly available, businesses may wish to think twice about using OSS.

If OSS components have been used in proprietary software, businesses should undertake the necessary steps to review the licence terms and ensure that all necessary notices are included, and all source code is made available as needed. This may require the assistance of legal advisers, to confirm obligations under the relevant licence terms.

In a due diligence investigation, for example, if it is the case that OSS is used in the business being investigated, the party undertaking the due diligence will require confirmation that all applicable licence terms have been complied with.

Compliance can be a tricky and time consuming process – in one matter we assisted a client with, approximately 60 separate OSS components were utilised in software developed by the client, requiring us to individually consider the licence terms applicable to each and resulting in the client having to make adjustments to its software to comply with the notice requirements and make certain source code publicly available.

Failure to comply with OSS requirements can potentially result in legal action by the original licensors, as well as negative publicity and other reputational impacts. It is an important issue, and should not be overlooked by businesses. Due to the potential complexities associated with use of OSS, we recommend that the issue of licence term compliance be tackled concurrently with the software development process, so all notices can be included, and source code that is required to be made publicly available easily identified, as the development process is undertaken (rather than having to backtrack and re-work software to ensure compliance). If a business routinely uses OSS in its software development activities, an internal compliance protocol may be warranted.

We have extensive expertise in assisting clients with understanding their obligations arising from use of materials made available under open source licence terms. Please contact a member of our team for further information on how we can assist you.

This article was written by Luke Dale, Partner, and Niomi Abeywardena, Special Counsel.