Buying A Business With Software At Its Core: Key Issues In Australia

In this article we do a deep dive on key legal issues when buying a software business in Australia. Whether the business offers 'traditional' (on-premise) software, software as a service (SaaS, or other as-a-service models) or an app to the market, there are a number of things to make sure you do your homework on (in addition to the usual things to diligence in an acquisition). This is against a dynamic backdrop of increasing and evolving tech-regulation, masses of data, ever-present (and sophisticated) cyber threats and fast paced technological development.

1 Intellectual property - do you own it (or have a right to use it)?

Intellectual property (IP), and understanding and confirming that the target clearly owns or has sufficient rights to use all IP needed for its business, is fundamental to the value, competitive advantage and operation of any software business. This includes copyright, trade marks and patents. This article focuses on copyright, particularly as it protects the software itself, however deal teams also need to carefully consider other types of relevant IP, as well as domain names and business names (as you typically would in any acquisition).

A key asset of a software business will be source code - the human readable code of a software program, often described as a software company's 'crown jewels'. Manuals, user guides, programming notes, specifications and other documentation required to understand, maintain and develop the software are also critical, and need to be sufficiently detailed and clear for reasonably skilled computer programmers to pick up and understand the program logic of the software and enable future maintenance and development.

Copyright protection:

Source code, related source code documentation and other key materials such as policy documents and marketing materials are protected by copyright. Copyright is the key legal protection to safeguard proprietary software and allow the owner to control the distribution and licensing of its products.

Copyright is not registerable in Australia, so it is not possible to conduct searches to identify what copyright is owned by the target. This means that deal teams need to investigate how the software (and other important copyright material) was developed, and whether there have been any assignments of copyright / IP rights, in order to determine if the target owns the rights in the software / materials. This can be complex because software development often involves multiple contributors, including employees, contractors and third-party service providers. This can make it challenging to establish clear authorship and ownership of the software.

As a general principle in Australia, where an employee creates a copyright work in the course of their employment with the target, the target will own the copyright in that work (unless the parties have expressly agreed otherwise in writing). On the other hand, where a third party, like an independent contractor, consultant or service provider, creates copyright works, that third party will own the copyright in those works - even if the target has paid for the works. This is also the case for material created by founders before incorporation of the target or directors who are not employees. In order for the target to own the copyright in works (such as source code) created by a third party, the third party needs to have validly assigned those rights in writing to the target. Deal teams should investigate the chain of software (or other) development and ownership to validate whether the target owns the copyright in the software / materials.

Authors of copyright works (whether employees or third parties) also have personal rights, called moral rights, in relation to attribution and integrity in the works they create (for example, to prevent works being subjected to derogatory treatment). These personal rights cannot be assigned, however the author can give consent for acts that would otherwise infringe their moral rights, so deal teams should confirm that such consents have been provided to the target. This may require a risk based assessment depending on the number, duration and nature of the authors and works.

Potential gaps in ownership:

If there are gaps in copyright ownership, then this needs to be addressed either by:

• requiring the target to obtain an IP assignment deed (or other contractual documentation) from the owner of the copyright works (eg developer of the software) under which the IP rights are validly assigned to the target (if the target needs to own the software); or
• ensuring there is a sufficiently broad licence in place for the target to use the relevant copyright works as it needs for the purposes of the business.

Given the criticality of software ownership to the value of a software business, any assignments in relation to the software should happen before signing or completion of the transaction or be a condition precedent in the sale documentation.

Collaborations:

Collaboration arrangements also need careful consideration – if there are two or more parties collaboratively developing software (or other copyright material), the ownership can be very unclear (and arrangements under which parties 'jointly' own IP can be complicated and have potentially problematic implications). Collaboration agreements should be reviewed to determine who owns the copyright works and the scope of any cross licensing (or other licensing).

Third party functionality or components:

Deal teams should also interrogate whether any third party functionality, components or products (Third Party Products) are incorporated into, or integrated with, the target's software product or platform. Where that is the case, then careful review of the contractual terms between the target and third party will be required to check (amongst other things) that the target has a sufficient licence to use that Third Party Product in the way that it does (or may wish to in the future), whether the licence is exclusive (if the Third Party Product, for example, provides the target a competitive advantage) and that it does not give rise to operational risks (eg termination rights triggered on change of control or for convenience, short licence terms etc). If the Third Party Products are open source – see section 2 below.

Customer licences:

Typically, licenses to customers of standard software products should be granted on a non-exclusive basis and not impact the ownership of software, but this should be carefully checked to identify if there are any rights granted to customers that could impact the target's ability to deal with that software, such as an exclusive or sole licence or right to acquire. If customer agreements include any software development work, then this should also be carefully examined because in many cases customers will seek to own developments they have paid to create. If that new development is then incorporated back into the main software product or platform, there are potential issues. For example, the customer that owns the new development may not allow others to use it, or it may demand a licence fee for the target to re-licence to other customers. A related issue to assess is whether the target is required to provide copies of the source code to the customer, because this increases the risks of a disclosure of the proprietary source code.

Other issues:
Examining risks to IP ownership, and of third-party IP infringement, as part of due diligence is critical. These are examples of key IP issues to consider in that process. However, as mentioned above, deal teams will also need to consider other types of relevant IP, such as trade marks and patents (which could also apply to software although quite difficult and rare in Australia), as well as domain names and business names. IP rights, chains of title and commercial arrangements involving IP can be complicated and nuanced, so this is not exhaustive and should be carefully considered in light of the exact nature of the target company and software to be acquired.

2 Open source software

Open source software (OSS) is source code that is made available by the owners to anyone to use, modify and distribute (generally, but not always, for free). It is widely used by software developers and incorporated into software products, but often not well enough understood in due diligence.

Types of OSS licences:

OSS is governed under different types of OSS licence terms (there are many!), but they generally range from less restrictive or 'permissive' licences to more restrictive or 'copyleft' licenses. OSS has many benefits including saving time and costs in development, but used unchecked or inappropriately can give rise to risks.

Highest risks and copyleft:

The highest legal risks are around 'copyleft' OSS that is incorporated into a target's software products, as that can (depending on the licence terms and how the OSS is used or the software product is distributed) require the target to disclose some or the whole of the source code base for its product (or in some limited cases even contain prohibitions on commercialisation of source code that incorporates OSS). In other words, there can be an obligation to disclose proprietary source code in its entirety just because one part of that source code incorporated OSS. Risks include potential loss of competitive advantage if the target's source code is disclosed (potentially to competitors) as required by copyleft obligations, OSS licensors / industry groups seeking to enforce licence terms to require the disclosure or potentially make royalty claims, or costs of remedial action to re-code/remove the OSS from the code base.

Understanding how the target uses OSS:

Deal teams should get an understanding of whether the target uses OSS (it probably does) and if so what, where and how. Ask how the target governs use and incorporation of OSS into its software products (including awareness, policies and procedures to assess, control and approve the use of OSS). To get clarity on what OSS is used (whether because the target does not have a good understanding of what OSS has been incorporated into its software products over the years, if required or recommended by a W&I insurer or simply to be prudent), consider an OSS audit to scan the code base of the target's software product(s) to identify any OSS components. If undertaking an audit, engage with the seller on it early, as you will need to agree what source code will be scanned, consider the scope of the audit required, engage the auditor, allow time for the audit and then digest and address the findings.

3 Artificial intelligence

Software companies are increasingly using artificial intelligence (AI) in their businesses. This can take many forms, for example:

• using AI in the software development process and to create source code;
• using AI to help run and optimise parts of their business;
• licensing AI from AI vendors to embed AI functionality or tools into their software products; and
• in some cases, developing their own AI products.

Each of these uses gives rise to different risks and considerations, including in relation to privacy, intellectual property, bias, misinformation / inaccuracy and information security. This is a complex and continuously evolving area that deal teams should consider if the target is using or developing AI, and seek expert advice where needed.

4 Data and privacy

Data should be carefully considered from all angles in an acquisition – including from privacy, commercial and information security perspectives, particularly if the target handles customer data.

What is the data?

Deal teams should seek to understand:

• what data is used and generated by the target and what will be acquired as part of the deal, the nature of that data, where that data 'flows' and how the data is accessed and protected
• where the data is stored
• what data is structured vs unstructured
• the target's approach to data governance, including policies, procedures, consents and Privacy Impact Assessments
• any material contractual arrangements the target might have, for example to source data, share data with others for analytics or commercialisation purposes or under which the target receives or is 'licensed' to use certain data
• current and historical regulatory and compliance issues

Future changes in use:

Deal teams may also want to have an eye to the future on data – for example, do you have plans to use the data in different ways to create more value in the future? If so, it may pay to start considering early if there could be any roadblocks to such future use cases – in terms of regulation or contractual restrictions that may apply to the target. Such issues could dampen the value of the data to you.

Privacy:

Where the target deals with customer or other personal information, getting comfort on the target's privacy posture will be essential. This is even moreso in the current environment of regulatory focus and reform around privacy in Australia (and of course considering whether any international regulations, like GDPR, might also apply to the target remain important). Privacy reform in Australia over recent years has generally increased regulatory risk by increasing potential penalties and exposing administrative breaches and non-serious interferences to tiered civil penalties – and further reform is on the horizon¹.

Additional privacy considerations apply to asset sales, as these are more likely to involve collection and disclosure of personal information as part of the deal itself (i.e. the buyer collects personal information disclosed by the target). That said, there can still be movement of personal information that should be considered in share sale scenarios, in particular where there is going to be greater integration of the target into the buyer's group.

5 Cyber and information security

Cyber risk is everywhere and continues to increase, so understanding the security posture and cyber resilience of a target and its software products is crucial.

Cyber security posture:

Due diligence should be conducted to assess the cybersecurity practices, posture and risks associated with the target and its software products – because these may be inherited with the acquisition (e.g. a buyer will inherit latent security issues in the software products, and in a share sale the buyer will inherit liability for past security problems). From a legal perspective, deal teams should ask, for example:

• What technical, organisational and governance measures does the target have to manage its cyber risk?
• Have any cyber incidents occurred over the last number of years (and if so, dig into the details, including any actual or anticipated litigation associated with the incident)?
• How does the target company manage cyber risk with its third party suppliers and within its supply chain (this is an area of growing complexity and cyber vulnerability – and too often a blind spot for risk)?
• Does the target have cyber insurance? What (if any) cyber security or risk management standards or frameworks does the target comply with (eg ACSC Essential Eight, ISO/IEC 27001 and 27002, NIST Cybersecurity Framework, SOC2) etc?
• Do the software products regularly undergo security testing and audits (including by independent auditors)?
• Have any security vulnerabilities been identified in the software products (and if so, have they been remediated)?
• When did the target last conduct penetration testing and were any material issues identified?

Technical and operational (as well as legal) due diligence:

Importantly, cyber due diligence should be conducted from a technical and operational perspective, as well as a legal perspective. This includes diligence that you would generally do for an acquisition around the target's cyber maturity, culture, policies, procedures, risk management frameworks, controls, audits / assessments, incident response plans and testing, among other things, as well as more particular diligence for a software business to understand the security (and vulnerabilities) in the target's software products.

The criticality of cyber security due diligence has recently been highlighted by the landmark decision of the Federal Court to impose the first civil penalty (being $5.8 million) under the Privacy Act on Australian Clinical Labs (ACL) in relation to a data breach that occurred on systems of a company shortly after it was acquired by ACL. The data breach occurred not long after ACL had acquired Medlab without identifying or remediating serious cybersecurity vulnerabilities. The penalty is broadly considered to be the ultimate consequence of inadequate cybersecurity diligence review as part of the acquisition, and consequent failures to remediate cybersecurity readiness and resilience (for more details on the case and practical tips for cyber due diligence, see our article: The ACL case: A $5.8M reminder to get cyber due diligence right). Although this case didn't involve a software business, the lessons are just as relevant.

Security issues in the target or its software products can have huge ramifications, including impacts to the business, customers, regulatory compliance, fines, remediation costs, cyber or privacy related claims and long-term reputational damage. Security diligence is critical to understand and mitigate risks and help protect the investment in the intellectual property, value and reputation of the target and software being acquired.

Footnotes

1. https://www.hsfkramer.com/insights/2024-06/navigating-australian-privacy-reform-your-guide-to-the-changes-ahead.