The case, heard by the Employment Relations Authority late last year, hinged on whether Michael Oliver, who did development work for Palmerston North firm Autoweb Solutions, was an employee or a contractor. The Authority determined he was an employee.

The employee/contractor distinction is an important one, and has been the source of a number of court disputes. While the Autoweb case was simply a wage dispute, the employee/contractor distinction could also potentially have intellectual property implications.

The default position under section 21 of the Copyright Act is that (most) copyrightable works created by an employee “in the course” of employment – e.g. software – are owned by the employer (whether or not the employee is actually paid). This is not the case if the person creating the work is a contractor. In that case, the so-called commissioning rule applies (see Copyright ownership and software development). If a developer had been “hired” (as an employee or contractor) to write some specific code, then the employer/hirer will likely have commissioned the work and will therefore own in.

But the situation could easily become more murky, with the possible result that a non-employee developer owns copyright in code they produced for their principal (though not in a “commissioning” situation) – for an example, see “Free design” and the commissioning rule. This cuts both ways: contractors should be careful not to be deemed employees in order to avoid the risk of IP created in the course of a project being inadvertently owned by their “employer”. Note that the words “in the course” are important, as discussed in the recent ERA case of Abbott v Chief Executive, Whitireia Polytechnic [2010] NZERA 766.

As is often the case, a proper contract is the answer – though as the Autoweb case makes clear, it is the substance of the relationship not the labeling of it that is determinative. In the case of employees, it is a legal requirement that there be a written employment contract. Contracts with contractors should clearly state which party retains any resulting IP.

In short, a customer had engaged an engineering firm to produce designs for an industrial machine. Unfortunately the terms of the engagement were unclear, and a dispute arose (some years later) between the customer and the engineering firm as to who actually owned the designs. The customer claimed that because it had commissioned those works, and provided an implied agreement to pay for them, and the designs were made pursuant to that commission, it (the customer) owned the copyright, by virtue of the commissioning rule. The engineering firm denied there had been a commissioning as defined in the Copyright Act, and that it therefore remained the owner of the designs.

The Court noted the orthodox position that:

Whether a work is “commissioned”; what the scope of that commission is; and the date on which the commission arises are all necessarily questions of fact in each case.

And it offered the following sage advice:

Patently, the better practice is to have a written agreement, and software developers and purchasers would be well advised to see that sound industry contracting procedures are put in place.

The critical issue was whether or not the customer had agreed to pay for the works – a requirement of the commissioning rule. Normally, payment (or an agreement to pay) is not in question, but was complicated in this case by the engineering firm claiming that it had provided a “free design service” in order to attract new customers. Because the designs had been provided for free, it claimed, the customer had not agreed to pay for the work and there could not have been a “commissioning” as defined in the Copyright Act.

The Court of Appeal rejected the engineering firm’s argument (which had been accepted in the High Court). It said that the engineering firm had offered “free design” on the basis that it would get to do the subsequent manufacturing work (which wasn’t free), and this was sufficient to create an intended-to-pay commissioning. The Court said it was “everyday commercial sense” that such an arrangement would be regarded as two parts of the same deal, and the customer had “agreed to pay” for the design work as part of the overall design-and-manufacture arrangement. It would be artificial to divide the “free design” and the subsequent intended manufacturing into two separate transactions. The Court therefore ruled that the copyright in the works was owned by the customer.

This is a useful case that demonstrates a pragmatic and commercially realistic substance-over-form approach to what was a murky factual situation. But, as the Court noted, these very costly disputes are easily avoidable by having a simple, appropriate agreement in place.

Note: the Government is proposing to repeal this rule. As of April 2009, the amending Bill (carried over from the previous Labour-led Government)  sits at number 18 on the Government’s Order Paper (right after the Dog Control Amendment Bill), so the rule may not be repealed for some time.

The commissioning rule – who owns 1^st copyright in code?

If a software developer is hired (i.e. “commissioned”) by a customer to develop some code, an important question is who owns the copyright in the resulting code – the customer or the developer? The rule that governs who owns commissioned works is known as the commissioning rule, which in New Zealand is contained in section 21 of the Copyright Act 1994. Under that rule, the answer will typically be one of the following scenarios:

1. If the software developer is a person (as opposed to a company) who was hired as an employee (part time or full time) by the customer, then the customer (i.e. employer) will own the copyright in any original code produced by the developer.
2. If the software developer (either a person or a company) is contracted by the customer to produce some code, and is to be paid for it, then the “default rule” is that, again, the customer will own the copyright in any original code produced by the developer. Importantly, the customer will have ownership of the software whether or not they have actually paid the developer for it.
3. If the software developer (either a person or a company) is contracted by the customer to produce some code, and both agree that the developer will own the copyright, then the developer will own the copyright in the code they develop for that customer. The agreement would usually be in writing (though it need not be a formal, or even signed, contract). A verbal agreement will suffice, though without any written evidence, it may be difficult to prove what was agreed.

The simple rule is that if the software developer and the customer agree in advance as to who will own the copyright, then that agreement will prevail.

However, in reality as many will know, the contracting/paperwork side of software development can be a bit of a mess. Projects are started without contracts being place, undocuments variations and “sub-projects” may emerge, “interim” off-contract solutions are implemented, and final agreements may never be signed.

In particular, with the increasing use of agile development methodologies, the emphasis is even more on delivering working code than negotiating contractual terms – though as always, getting a contract in place before starting is highly recommended.

When the parties have not agreed (usually in writing) who will own the copyright, then the “default rule” is that the customer will own the copyright (scenario 2 above).

Copyright ownership and code reuse

Copyright ownership is of particular importance to software developers who reuse code – which means virtually all developers. Simply, unless a developer owns copyright in some particular code (or obtains an appropriate licence), they are not entitled to reuse that code anywhere else. This applies even if the developer wrote the code themselves – no copyright ownership, no reuse. If the developer does not own the copyright, then the copyright owner’s approval (or their authorised licensee) must be obtained.

This is the basis on which open source software works. Under the GPL version 3, for example, a developer is licensed to reuse the code as they see fit (subject to some conditions). The developer does not actually own the copyright of the open source code they are reusing, but they are licensed by the copyright owner(s) to reuse the software in their projects.

For in-house code libraries, it is essential that the developer retains copyright in the relevant code they develop. Often, this code will not be of particular commercial value to any one else but the developer who wrote it, but it is very valuable to the developer to be able to reuse it in other projects. It should be noted that if a developer already owns copyright in code that is used in a customer project, then the developer will not be at risk of losing that existing copyright. But if the code library is modified, then the copyright in those modifications may be be deemed to be owned by the customer. It is easy to imagine how this could potentially result in complex, tangled situations.

Unfortunately, it is not possible to retrospectively “claw back” ownership of code that has been developed for and owned by another customer. In this situation, the developer would need to get the customer to assign (e.g. transfer ownership of) the copyright to them. If the customer wants to own the copyright of code they have paid for – which is perfectly reasonable – then the developer may want to either separate out and retain ownership of common, generic code that they intend to reuse on other projects, or license back such code.

In any case, it is much easier to deal with these issues at the outset of the project, in the form of a clear, easily understood contract.