Articles and legal news from the Atkinson Vinden Team.

Technology Law – Why a standard supply contract won’t work

Commercial Law

We would never expect a cardiologist to perform veterinary surgery. By analogy, it is surprising therefore that some lawyers attempt to advise clients on legal issues pertaining to information and communication technology (ICT) they have no understanding of! In this article we explore some examples where not understanding the potential risks when drafting technology-related agreements can expose clients to a world of pain.  

We are frequently called on to advise our clients in relation to contracts for the supply or receipt of information technology services. Often this involves us reviewing contracts prepared by a third party, which, while technically well drafted, fail to consider many of the practical issues which arise in an ICT arrangement.

Some of the clauses we encounter, and the problems which arise are outlined below.


“payment will be made within 14 days after the Developed Software is accepted by the Customer.”

This clause may seem fair, once software has been accepted as meeting spec, you get paid. A problem arises, however, when the developer delivers the software and waits for the customer’s response…. and keeps on waiting. Meanwhile, the developer’s bills pile up and its employees need paying. This situation could be simply avoided in a few ways, such as:

  1. Allowing for partial payment to be made on delivery, with the balance payable on acceptance; and/or
  2. Requiring the customer to confirm that the software meets spec within 14 days, otherwise it is deemed accepted and payment is due.

Intellectual Property

We have encountered some software development contracts which do not clearly address IP ownership. This creates a significant issue for the recipient of developed software, as a lot of people do not understand how IP ownership arises. In short, the starting point is as follows:

  1. If your employee creates it, you own it;
  1. If an independent contractor develops it, the contractor owns it, unless you have a contract that says otherwise.

While this often does not create an issue in the day to day trading of a customer, it will always create a problem if/when you seek to sell your business and/or obtain investment. Any potential purchaser or investor is going to want to see proof that you own your IP. If you have not properly documented ownership of the IP, there is a good chance that the sale or investment will not proceed.

Of course, simply assigning the IP from the contractor to the customer can create its own issues, which leads to the next point.

Background IP

“The developer assigns all Intellectual Property Rights in the Developed Software to the Customer”

Again, this clause seems reasonable, after all, the customer is generally paying for the IP, so they should own it. The problem that arises is that most developers have particular IP, whether it be methods or software, which they may use time and again, with different customers. The clause above would effectively assign ownership of such to the first customer, potentially creating issues down the track.

A far better option is to exclude any “Background IP” from the assignment (ownership of such remaining with the developer) and granting the customer the right to use the Background IP solely for the purposes of using the Developed Software. This provides a good balance, in that the customer gets what they realistically expect, ownership and use of the final product, while the developer does not run into any issues by re-using the background IP down the track.

Limitation of Liability and Third Party IP Rights

Most contracts will have a liability clause, and any drafted by a software developer’s lawyer will generally say something to the effect of:

“The liability of the Developer is limited to the Price paid under this Agreement”

At first glance this seems reasonable, if the product does not work you get your money back, however it is possible for customers to get caught out, and be left with significant liability, most commonly where developed software breaches a third party’s IP rights. If you have software developed, you then go to market, either re-selling the software, or using it for your own customers and it turns out that your developer copied the IP from a third party, you will probably get sued. If you get sued, and lose, the damages for such can be significant, including an accounting of profits. These damages could easily exceed the price paid to the developer, meaning that you will be left to pay the difference. As such, we always recommend an exception to the above, so that the limitation does not apply where your developer has breached a third party’s IP rights.

Depending on the purpose of the software, you may require additional exceptions. If, for example, the software is intended to handle personal or sensitive information, then you may wish to have unlimited liability for any loss due to a breach of privacy.

These are just some of the many issues that arise when reviewing and negotiating IT agreements. Some others include, properly defining specifications to ensure you get/deliver what is required; maintenance agreements, to properly define how long the developer will fix bugs free of charge and when it starts getting paid; and, where full ownership of IP is not occurring, comprehensive licencing arrangements, to ensure all parties know what the customer can and can’t do with the software.

Most importantly, you need to have legal advice which incorporates and understands the peculiarities of contracts relating to information, technology and communications requirements.

If you have any questions about the above, or would like to discuss your IT requirements, please contact our commercial law team on 02 9411 4466, or by email at


Protecting your reputation starts with simplifying the complex. This handy checklist should quickly point you in the right direction and help you understand whether you have a case, and where to start to secure the best possible outocme.