Invested in Client Success

Icon

Secret Source (or not) – Open Source Software and M&A Transactions

Banner
Rebecca Dooley
Rebecca Dooley
Partner
Max Jamieson
Max Jamieson
Senior Associate

In M&A transactions involving technology or software companies, the key asset of the target or seller entity is often a proprietary software platform or product. The source code of these kinds of platforms or products may include “open source software”, which can present certain risks for buyers.

What is Open Source Software?

Source code is code that programmers can manipulate to change how a software program or application works. The source code of some software is “closed source” software, meaning that only the person that owns it may modify it. Users of closed source software need a licence to use it. Examples of closed source software include Microsoft Office and Adobe Photoshop.

On the other hand, Open Source Software (“OSS”) is source code that is made available by its creators to the public who would like to view, copy, alter and share the code. In doing so, OSS promotes collaboration as it permits programmers to make modifications to source code and incorporate those changes into their own projects. Examples of OSS include LibreOffice and the GNU Image Manipulation Program. OSS users will still need a licence to use the OSS, and types of OSS licences are discussed in further detail below.

The Linux Foundation – a non-profit organisation established with the partial goal of supporting OSS projects – has reported that OSS comprises 70-90% of ‘any given piece of modern software solutions.’[1]

Software engineers can commercially exploit OSS for profit by using them as ‘building blocks’ to develop new applications. This may include the use of open source libraries that may, for example, encrypt data using industry standards or deal with dates and time zones. The availability of OSS enables software to be developed quicker and at a lower cost, as developers focus on writing code for the core function of the product.

Types of and risks associated with OSS Licences

Buyers need to be conscious of the different OSS licences that exist and may be present in software assets owned by seller or target companies. OSS has either ‘permissive’ or ‘copyleft’ licences, which differ in the restrictions they place on the software.

Permissive licences have very few restrictions on use of the relevant OSS. The MIT open source licence (being a permissive licence) provides that any person may ‘deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicence, and/or sell copies of the Software.’ The only restrictions under a MIT licence are that the code must contain the original copyright notice, and a copy of the licence itself.

Other examples of permissive software licences include Apache 2.0, BSL licences and BSD licences.

On the other hand, copyleft licenses impose a reciprocity requirement. Developers using OSS with a copyleft license must make their modified software available to the public with the same licence as the original OSS. This means that anybody can use the software derived from the OSS with the copyleft licence, and any derivative works must be distributed under the same licence terms (i.e. a free, copyleft licence). This obligation applies to the entire product or platform even if it only contains a few lines of code subject to a copyleft licence.

Examples of copyleft licences include GNU General Public License, GNU Affero General Public License and the Creative Commons Attribution-Share Alike License.

Accordingly, if a seller or target company owns a platform containing copyleft licences, this can have significant repercussions on a buyer’s ability to control and profit from the relevant platform (or other software assets) following completion of the transaction, as any software containing an OSS copyleft licence must make its entire source code available for free, along with the rights to modify and distribute it, even if it only incorporates a few lines of OSS code.

In addition to the above, a buyer may face various other risks because of a seller or target entity’s use of OSS, including:

  • Certain legal obligations if the buyer or target commercially distributes software containing OSS, such as defending or indemnifying any future users or developers against any claims brought by a third party for acts in relation to the commercial distribution of the OSS-containing software by the buyer or target; and
  • Increased compliance obligations under certain OSS licences requiring the buyer or target to preserve copyright notices and licence information, provide notices identifying copyright holders and specify the modifications made to the software by the seller or target.

Practical Steps for Minimising OSS Risks

A buyer may take various steps to mitigate the risk of the use of OSS. These include:

  • Prior to the transaction, engaging a third-party auditor or using a scanning tool to undertake an audit of the codebase to identify any problematic OSS components and consider any potential issues with licence compliance.
  • Ensuring the transaction documents contain warranties that:
    • Each OSS item and the relevant licence has been disclosed to the buyer;
    • The seller or target is fully compliant with and has not breached any applicable licences;
    • The code is not subject to any licences requiring any of the software to be disclosed or distributed or be licensed for modification or derivative works; and
    • There are no limitations or conditions on the right or ability to use or distribute the software or enforce the intellectual property rights in the software.
  • Ensuring the transaction documents contain indemnities protecting the buyer against any losses that arise from breaches of OSS licences in relation to the codebase, including for any claims brought by third parties.
  • After the transaction, developing a policy to govern how its staff are to use or contribute to the OSS components in its codebase, which should set out:
    • All the OSS components and relevant licences as well as how these components are used in the codebase;
    • An approval process for licensing, distributing or using the identified OSS components;
    • Compliance processes for ensuring compliance with the relevant OSS licences;
    • How OSS components are to be handled in third party dealings, like agreements, acquisitions and other transactions; and
    • Intellectual property considerations.

Liability limited by a scheme approved under Professional Standards Legislation.


© ADDISONS. No part of this document may in any form or by any means be reproduced, stored in a retrieval system or transmitted without prior written consent. This document is for general information only and cannot be relied upon as legal advice.

Related Insights