How many codes must a man walk down? Coding and copyright cross paths in the FCA

For most of us, our exposure to software code is limited to the Matrix and those terrifying moments when you accidentally open Terminal on your Mac. However, as computers slowly and silently assume dominion over every facet of our lives, it’s inevitable that the mysteries of source code will increasingly confront us with novel challenges.

In IPC Global Pty Ltd v Pavetest Pty Ltd (No 3) [2017] FCA 82, the Federal Court was given the imponderable task of deciding exactly how many lines of code would constitute a “substantial part” of a program for the purposes of the Copyright Act 1968 (Cth).

Let’s introduce the characters

Firstly, there are the two companies: IPC Global and Pavetest. They’re competitors in the “construction materials testing industry”. If you want to know exactly how tough your pavement is, these are the companies you go to.

IPC is the established incumbent, the well-worn path. Pavetest is new to the scene, the road less travelled.

Next, we have the individuals. Con Sinandinos and Alan Feeley were once employees of IPC; CEO and manager of research and development, respectively. In 2012, Sinandinos and Feeley left IPC and established Pavetest. Over the next few years, Feeley worked with a computer programmer, Bin Li, to write Pavetest’s testing software.

But Li wasn’t necessarily forging his own path. And that’s where the rubber met the road.

When Feeley resigned from IPC he had a few copies of IPC’s testing software on his computer. Feeley copied the software onto Li’s computer to help Li “research an approach that [Feeley] had taken in the past” (Feeley’s evidence). During the course of writing the new software for Pavetest, Li regularly referred to the source code of IPC’s program. The end result was that Pavetest’s software contained some lines of code that were identical to the IPC software, and other lines that were similar.

IPC wasn’t particularly happy with that result and started proceedings. Pavetest then instructed Li to write a second version of the Pavetest software which removed the code that was identical or similar to IPC’s software.

IPC pursued its claim against Pavetest only in respect of the first version of Pavetest’s software.

Justice Moshinsky had three issues to deal with

1. Copyright.

Did Pavetest infringe IPC’s copyright by:

  • copying the software onto Li’s computer?; and
  • by creating its own software? This question hinged on whether the Pavetest software reproduced a “substantial part” of the IPC software.

2. Confidence.

Did IPC establish the elements of a breach of confidence?

3. Contract.

Did Feeley’s employment contract with contain implied terms that Feeley owed IPC a duty of good faith and fidelity not to engage in conduct that was destructive of the necessary confidence between IPC and Feeley? And if so, did Feeley breach those terms?

The Court found that the IPC had made out its claim for a breach of confidence, but not its claim for a breach of Feeley’s employment contract. What follows is a discussion of the copyright claims.

Did Pavetest infringe copyright by copying the software onto Li’s computer?

Having set out the facts, Moshinsky J dealt with the first copyright issue in a swift two paragraphs.

Both parties accepted that:

  1. IPC owned the copyright in its software;
  2. Feeley copied a substantial part of that software onto Li’s computer; and
  3. that act was done on behalf of Pavetest.

Accordingly, in copying the software to Li’s computer, Pavetest infringed IPC’s copyright.

Did Pavetest infringe copyright by creating its own software based on IPC’s?

This issue wasn’t as straightforward.

The evidence showed that some of the Pavetest software code was identical to the IPC software code, and that other parts of it were similar. An expert estimated that there were roughly 1,000 lines of code which corresponded between the programs (“Copied Code”).

The IPC software contained a total of about 250,000 lines of code. However, there was a large amount of internal duplication of code within the program and it was estimated that there were about 10,000 to 20,000 unique lines of code.

Under the Copyright Act 1968 (Cth), copyright will only be infringed if a “substantial part” of the original work is reproduced.

The question was: Did the 5 or 10% of code that was reproduced by Pavetest constitute a “substantial part” of the IPC software?

Moshinsky J found that it did. He pointed to three factors in particular:

1. Originality in expression.

Moshinsky J rejected Pavetest’s submission that the copied code was largely, if not entirely, unoriginal, and therefore could not constitute a substantial part of the IPC software. His Honour found that the Copied Code had the sufficient “originality of expression”. In reaching that conclusion, Moshinsky J emphasised the fact that the writing of the code required the coder to make choices and apply judgment. This had been demonstrated by the fact that Li was able to rewrite the software (for version two) without using the Copied Code. Although the “problem domain” (that is, the real world context of materials testing) heavily influenced the formulation of the code, it did not dictate it, and that meant that there was scope for originality.

Moshinsky J also rejected Pavetest’s submission that the Copied Code was not a “computer program” for the purposes of Copyright Act 1968 (Cth). The Copied Code was still “functional code” in the sense that it constituted a set of statements to be used directly or indirectly in a computer in order to bring about a certain result, even if that result was simply populating data structures.
Pavetest argued that the Copied Code lacked originality because it was derived from a protocol document. Moshinsky J rejected this argument on the basis that the preparation of the protocol document itself required the application of judgment.

2. Functionally significant.

Pavetest argued that the Copied Code was “supporting infrastructure” and related to inessential features of IPC’s software. Moshinsky J rejected this argument. Although the Copied Code was, in parts, not difficult or unconventional, it nonetheless set out functions which had an important role to play in the operation of the software. The evidence established that the code was functionally significant to the software and was not merely collections of data or related information.

3. Quality over quantity.

There was not an abundance of clarity as to exactly how many lines of Copied Code there were. It appears that no one sat down to count them, although various estimates are proffered throughout the judgment (“in the order of 1,000 lines”, “about 800”, “about 1,000”, “approximately 800”).

This, however, was not the point. Moshinsky J reiterated that the “emphasis is on a qualitative rather than quantitative assessment of substantiality”. Although the quantum of Copied Code was small relative to the total number of unique lines of code in IPC’s software (which again was the subject of assorted guesstimates: one expert stated that he would treat the software “as about 10,000 to 20,000 lines” although “it is not clear how he came up with these figures”) it was sufficient to constitute a substantial part.

This isn’t the first time copyright and code have crossed paths in the Federal Court and it’s bound not to be the last. It might be time to finally work out what Terminal actually does.