From the browser on a smartphone, to word processing software, to an entire operating system, Open Source Software (Open Source) is so ubiquitous that you’re likely using it without even realising. So, what is it and why do we care about it in the context of an M&A transaction?

As opposed to proprietary or ‘closed source’ software, where the source code and usage rights are privately owned and controlled, Open Source is a form of publicly-accessible software source code that is subject to ‘open source’ licence conditions, generally allowing the licensee to use, view, modify, and redistribute the Open Source’s source code, at no cost. Open Source’s ease of access, flexibility and constant updates have made it extremely popular in software development, as it can be used to fast-track development of software and expand the functionality and capability of software quickly and inexpensively.

However, as a quid pro quo, Open Source licenses also require any development work done on that Open Source to be made available on an open source basis, and that requirement can also extend to and ‘infect’ other proprietary, previously ‘closed source’, software.

In the context of an M&A transaction where a key asset the subject of that transaction is the seller’s proprietary software, Open Source’s ubiquity means that Open Source will likely form part of that software. Organisations looking to undertake such transactions, on both the ‘buy’ and ‘sell’ side, should therefore be careful to understand the extent to which Open Source is being used in key software assets, as well as the risks and issues that generally arise due to its use.

If not used correctly, or indeed, if used pursuant to a particular type of licence, the use of Open Source and the corresponding obligations that attach to a particular Open Source licence, can potentially undermine the extent to which a piece of software can be considered to be proprietary and can have an adverse effect on the underlying value of the software. This could have disastrous effects for the seller in the context of an M&A transaction, where the transaction value is linked to the value of the software ‘owned’ by that seller.

Open Source licensing and the risk of ‘copyleft’ licenses

Open Source licences generally fall into two categories: permissive licences and ‘copyleft’ licences.

Permissive Licenses

Permissive licences (for example, Apache 2.0, MIT, BSD and CDDL) are generous licences, which allow a user to use, adapt and modify or otherwise exploit the relevant Open Source. Importantly, permissive licenses do not impose requirements on users (which exist in many ‘copyleft’ licenses – see below) to republish the modified source code of the Open Source, or the source code of the user’s software in which the relevant Open Source was used. Accordingly, this form of licensing allows Open Source to be used without the user having to compromise the proprietary nature of the software.

As permissive Open Source licences grant such broad rights, using permissively-licensed Open Source as part of software development, or acquiring intellectual property assets that contain Open Source components subject to permissive licensing, generally presents a lower risk when compared to using Open Source licensed under ‘copyleft’ terms.

‘Copyleft’ Licenses

Most Open Source is in fact licensed under stricter and significantly higher risk terms, referred to as ‘copyleft’ terms, of which there are two main classes: ‘weak’ copyleft licenses, and ‘strong’ copyleft licenses. Copyleft-licensed Open Source is the most commonly-used form of Open Source – it is estimated that over 75% of Open Source use is licensed on copyleft (either GNU General Public Licence (GPL) or Lesser GPL (LGPL)) terms. However, it is this form of Open Source licensing that can generally have a more dramatic effect on the value of proprietary software, and so we examine that in more detail in this article.

Under a weak copyleft licence (for example, EPL and LGPL), users may simply be required to publish any modifications made to the relevant Open Source. Under a strong copyleft licence however (for example, GPL and Mozilla Public Licence), users are not only required to make modifications publicly available, but, if and to the extent that the relevant proprietary software constitutes a derivative work of that Open Source, must also make available the entire piece of proprietary software in which that Open Source was used (on the same licensing terms as the Open Source itself) and release all rights to use the source code for that software to the public. Accordingly, such copyleft licenses can effectively make software that makes use of the Open Source, also Open Source itself.

Where an organisation purports to own a piece of software, the existence of strong copyleft-licensed Open Source in its code base can compromise the proprietary nature of the original source code. Because copyleft licenses render software that uses the Open Source on those terms, also Open Source, the owner of the original, proprietary software may not be able to adequately assert ownership of the intellectual property rights in and to that proprietary software.

This can be a disastrous result for a seller in the context of an M&A transaction centred around a piece of software which was thought to be proprietary. If the software becomes Open Source of itself and loses its intrinsic value (as its code must be published in the public domain), then the business case or value proposition underpinning the transaction itself is likely to be compromised.

Open Source and its interaction with third party software

A relevant consideration when using Open Source to develop software, is whether, within that software, there are any third party-licensed software components that may interact with Open Source. This is important because often, the licence terms for that third party software will contain prohibitions as to the use of that software in conjunction with Open Source components. This is effectively a risk mitigation strategy for those third party software providers, who are seeking to cover-off the risk of loss of ownership of the underlying software due to copyleft Open Source licensing.

Accordingly, it is important that organisations understand the interaction between third party software and Open Source within its proprietary software (if any), as well as any relevant prohibitions in respect of such interaction. Further, this understanding is important in the context of an M&A transaction, as it is vital for a prospective purchaser to understand how the seller’s proprietary software could give rise to liability to third parties, if the integration of third party and Open Source components has not been managed properly by the seller.

How can organisations mitigate the risk of copyleft Open Source?

Despite the risks, there are steps that organisations can take to de-risk the use of Open Source, particularly strong copyleft-licensed Open Source. In the context of an M&A transaction where proprietary software forms a key part of the seller’s asset package, these de-risking strategies will help a seller ensure that the value of the proprietary software is retained and will not compromise the value of the asset package.

Prospective purchasers may also implement certain de-risking strategies, to ensure that the value of the proprietary software is as represented by the seller and its purchase, use and exploitation will not give rise to liability, in respect of third party claims for intellectual property infringement or otherwise.

Select Open Source carefully

As noted above, not all copyleft licences are created equal, and the specific rights and obligations under the various licences exist on a continuum from ‘weak’ to ‘strong’. Accordingly, before using or modifying Open Source, or incorporating Open Source into proprietary software, organisations should consider carefully the types of Open Source it intends to use, as well as how that Open Source is licensed.

Understand the licensing terms

In addition to an appreciation of the implications of using a certain Open Source type in respect of the requirement to publish derivative works, organisations should be careful to understand the additional terms and conditions that attach to the relevant Open Source licence. For example, some Open Source licences may require a user to publish a copy of the original Open Source licence terms with any publication of the modified code (for example, MsPL and MIT) or retain all copyright notices and trade marks (for example, CDDL).

Organisations should also seek to understand the circumstances where obligations to publish modified code or derivative works may not apply. For example, under some circumstances, the use of Open Source licensed under GPL terms may not give rise to such obligations.

Think about how Open Source interactions are structured

Another way to incorporate Open Source code into a piece of proprietary software, while still managing copyleft licensing risk, is to consider how that software is structured technically. For example, an organisation may choose to use only Open Source components that do not require modification, which could mean that the publication obligations under the relevant licence can be avoided, which may help to ensure that the relevant Open Source code will not undermine the proprietary nature of the software – though this may not always be the case.

Establishing clear Open Source governance policies

Regardless of whether an organisation is using Open Source under a copyleft or permissive licence, clear policies and procedures for the use of Open Source should be established and adhered to, and should set out, at a minimum:

  • the broad in-house position in respect of the use of Open Source and the circumstances under which Open Source may/may not be used in software development;
  • the roles, responsibilities and key personnel in respect of the use and management of Open Source use within the organisation, in respect of including paths of escalation and legal sign-off; and
  • the procedures for compliance with licence terms, including the release and publication of source code (if required).

In addition, organisations should maintain a register of all Open Source used in its software development activities, which should detail the specific Open Source licence types used and note any material obligations that attach to such use.

In the context of an M&A transaction, a seller’s Open Source policies and procedures and Open Source registers are a key deal artefact that a prospective purchaser should review thoroughly during the due diligence process, in order to obtain the full picture of the relevant software and assess the risk that may attach to its purchase.

Transaction due diligence

Where a prospective purchaser is undertaking due diligence in respect of a possible acquisition of a business or assets containing proprietary software, the key issue that is likely to arise in respect of that software is whether the seller (or its broader corporate group) owns the intellectual property rights in and to that software.

An understanding of the seller’s use of Open Source in connection with the development of that software will be a large piece of the puzzle, which will assist the prospective purchaser in understanding the true value of the business or assets the subject of the transaction. To that end, prospective purchasers should ensure that their due diligence investigations into the seller’s business cover:

  • the seller’s use of Open Source in the development of its software, including how it is licensed, what Open Source components are used and for what purpose;
  • the seller’s compliance with the terms of the relevant Open Source licenses and whether any legal or regulatory issues have arisen as a result of the use of Open Source, or any claims have been made or threatened against the seller. This will be particularly important to understand where the proprietary software of the seller is licensed/sold to customers;
  • the seller’s policies and procedures surrounding the use of Open Source;
  • whether any Open Source is used in conjunction with any third party-owned software and whether the terms governing the licensing of that third party software prohibit the interaction of that software with Open Source components; and
  • whether any technical audits have been undertaken in respect of the relevant software and the results of such audits.
Problem mitigation

If any issues in respect of the seller’s use of Open Source are identified in a prospective purchaser’s due diligence exercise, then the purchaser may seek to resolve those issues in the following ways:

  • removal of problematic Open Source code from the proprietary software, provided that the functionality of the proprietary software can be preserved;
  • the use of different Open Source code that may have a weaker copyleft, or permissive licence that will achieve the same result from a technical perspective;
  • re-writing problematic code, if practicable – the prospective purchaser should seek to assess the viability of this option based on the anticipated level of effort; and
  • purchasing a licence for code that is the same as or similar to the problematic Open Source component(s).
Contractual protections under development agreements

If any third parties have been engaged by an organisation to develop software for and on its behalf, then that organisation may employ strategies in order to de-risk the use of Open Source via its contracts with those third party developers. Principally, the organisation might ensure that no Open Source is used in the development of the relevant software without the consent of that organisation. The organisation should also include in those contracts, appropriate indemnities and warranties that relate to the use of that Open Source.

Contractual protections under sale documentation

In the context of an M&A transaction, a purchaser may also require the seller to provide certain warranties as to the proprietary software and the Open Source used therein, including in relation to the seller’s ownership of the underlying intellectual property rights in and to that software, as well as the seller’s compliance with Open Source licence terms. The purchaser may also seek an indemnity for breach of any such warranties. .

Conclusion

Open Source is a powerful tool for building software. However, the verbiage ‘open source’ often misguides users into believing they have broad scope to do whatever they wish with the source code of the Open Source. This is not the case, and accordingly organisations should be acutely aware of the licences they are interacting with when building software or acquiring assets containing proprietary software, and how they can take steps to mitigate legal and commercial risk, and ensure compliance.

How can DLA Piper assist?

DLA Piper is well-placed to assist you in navigating the nuances of Open Source licensing and understanding the risks and mitigation strategies outlined in this article. We have extensive, market-leading experience in M&A transactions and we understand the issues when it comes to Open Source. Among other things, we can assist with the review of Open Source licence terms, participate in risk assessments, perform transactional due diligence to assess use of Open Source and ownership of proprietary software, and provide advice in relation to prohibitions in third party software licence terms as they relate to the use of Open Source.