Software beware: software development risks in the energy & resources sector

What you need to know

• Software is an increasingly important part of innovation in the energy & resources sector.
• The IP risks and opportunities associated with software are not always well understood, especially in relation to open source software.
• In this article we discuss some key copyright and confidentiality considerations, and highlight common issues which (1) arise for software development projects, (2) should be kept in mind when negotiating contracts, and (3) are relevant when buying or selling businesses with valuable software

What you need to do

• Become familiar with the IP risks and opportunities associated with software in the energy & resources sector.
• If your company is involved in any software development, ask whether your team properly manages the use of open source software and compliance with the associated licence terms.
• When buying or selling a business, consider whether its valuable software is properly protected, and whether it is subject to any problematic open source software licence terms.

IP protection for software

In this article, we address the two most relevant types of IP protection for software: copyright and rights in confidential information. We will address patents, and the challenges in obtaining patent protection for computer implemented inventions, in a subsequent article in this series.

Copyright

Copyright arises automatically on the creation of the relevant work. It prevents, among other things, copying or reproduction of the work or a substantial part of the work. This means copyright will stop others from copying your software source code, or give you a cause of action if they do so, but will not prevent others from independently writing their own software that works the same way or achieves the same outcome.

There may be a number of copyright works subsisting in a single software application, each falling within the category of "literary works", which expressly includes "computer programs", under the Copyright Act 1968 (Cth). It can be a complicated exercise to identify each copyright work in a software application. For example, each iterative version of a software application might be a separate copyright work (see, generally, JR Consulting v Cummings (2016) 329 ALR 625 at 675-676).

If you wish to assign, license or enforce copyright in your software application in the future, you should ensure that you clearly document who contributes to its development, and that you have the IP rights assigned or licensed from all contributors. Obtaining assignments from the group of people who may be authors is a practical way to side-step the forensic difficulties of identifying each separate copyright work and who created it.

Confidential information

As copyright doesn't prevent reverse engineering, or others from copying the way your software works, it can also be important to keep key aspects (eg, algorithms) confidential. For example, this may be achieved by storing such key components of a software application in a separate environment, which the software application interacts with by sending inputs and receiving outputs, without disclosing the key components to the end user.

Practical protections of confidentiality (in addition to contractual terms) are particularly important for software, which is often stored and developed on cloud based environments which may allow remote access. Risks can arise if these practical access restrictions are not carefully managed. For example, in Grow MF Pty Ltd v Parthy [2023] FCA 442, a senior software engineer resigned and allegedly removed other employees as owners and administrators of the company's GitHub (cloud based software development platform) and Figma (cloud based collaboration platform) accounts, and changed the passwords to the company's cloud-based development environment. Grow MF had to seek urgent court orders to compel the former employee to restore that access, pending the trial.

Open source software

What is it?

A particular area of IP risk is open source software. Open source software refers to software or software components that the owner has made available to the world subject to fixed licence terms. Open source software is very commonly used in software development, including by major players in the energy & resources industry.

What are the risks?

Companies and, in particular, their software development teams, often do not appreciate that using open source software amounts to entering into a contract with the owner of copyright in that software.

The terms of common open source software licences can vary significantly. There are generally two major categories: (a) "copyleft", which often can contain problematic conditions; and (b) "permissive", which generally contain fewer restrictions and, importantly, allow proprietary derivative software (being software developed from or including the open source components).

"Copyleft" (ie, the opposite of copyright) licences typically require any derivative software to be made open source on the same licence terms. While there is a global trend in "copyleft" licences becoming less popular over time, they are still very commonly used. For example, the GNU's family of General Public Licenses (GPL), an example of a "copyleft" licence, is reportedly the most popular open source licence type (as at 19 January 2023 - source).

The risk which often arises is that an open source software component is a small part of a much larger program. However, depending on the terms of the licence, the entire larger program may be treated as a derivative work and automatically subject to the "copyleft" licence terms (including, in some cases, a requirement to make the larger program freely available to the public). For example, the Common Development & Distribution License 1.0 requires Modifications, defined as including: "any file that results from an addition to, deletion from or modification of the contents of a file containing [the open source software] or previous Modifications", to be made available on the same open source basis.

Open source software can also have implications for patent rights. GPL 3.0 (the latest version of GNU's General Public License which we noted above is the most popular open source software licence type), includes a non-exclusive, worldwide, royalty-free patent licence to use any of the user's patents which are required to use the derivative software. That is, if your software program becomes subject to GPL 3.0, you may also find yourself contractually required to license out any associated patents required to use the software.

The danger of too much doom and gloom

Despite all of the above, it is important to distinguish between merely using open source software (eg, installing an open source software application and using it as intended) and incorporating open source software (eg, copying sections of software code) into a program you are developing.

Your company's policies and procedures on open source software should closely regulate "incorporating", without unduly restricting mere use. Despite its legal risks, open source software has a number of practical benefits, and has enabled rapid and beneficial development of software in many fields.

Custom modifications or plug-ins and funding your competitors

Another industry trend is for energy & resources companies to work with software providers to develop, or develop in-house, custom plug-ins or interfaces to enable better use of off-the-shelf software. For example, a company might develop custom plug-ins to interface its HR, fleet management, and scheduling tools used on a single site, or might develop custom plug-ins to enable a proprietary piece of hardware to be managed from off-the-shelf software.

These custom pieces of software may solve problems that are common to a number of players in a particular field. It can be a contentious discussion as to who should own the IP rights in these customisations.

• A software provider will often argue that the modification is built on top of, and only operates in, its off-the-shelf software application. Since the modification can only be used with the provider's background IP, it should be owned by the provider. However, this may allow the provider to re-package and sell that modification to competitors, which both allows free-riding by those competitors and may reduce any competitive advantage derived from access to the custom software.
• An energy & resources company will often argue that because it funded the development of the modification, which was built based on its operational data and confidential information, it should own the IP rights in it. This would allow the company to prevent its competitors from gaining access to, and the benefit of, the modification, but may result in costly duplication of work across an industry, slow industry-wide adoption of innovations, and reduce the incentives for software providers to assist in developing useful modifications to their off-the-shelf products.

In practice, it is often possible to negotiate win-win outcomes. However, this relies on the participants to the negotiation being alive to the IP issues and the commercial goals of both parties. In some cases, parties adopt an overly protective stance to IP, partially out of ignorance or fear of the consequences of a more permissive approach. It is equally common to see contracts that fail to address these issues at all, and create highly unsatisfactory outcomes through unintended defaults such as joint ownership, or splintered ownership with different copyright works in the same product being owned by whichever side created them.

Next steps

One of the most powerful tools for preventing or mitigating IP risks associated with software is awareness. Consider whether the appropriate stakeholders in your business are aware of these risks, or have access to advisors who are. This is particularly important if your company is involved in:

1. negotiating contracts with a material software component, especially where software is being developed, or software assets are material to the transaction value; 
2. software development – in which case you should consider whether the development teams properly manage the use of open source software, and compliance with the associated open source licence terms; or  
3. buying or selling businesses with valuable software, or for whom rights in software are material to the transaction value.

Authors: Stuart D'Aloisio, Partner; and Tim Rankin, Senior Associate.