introduction

You’ve come up with a great business idea, sorted your business structure, and possibly used some of our legal guides like legal basics for startups and our templates to help to do that.  What comes next?

Unless you’re one of the lucky few, your next focus is likely to be finding and securing customers – the obvious lynchpin to your business success.  A customer is a complex beast – risk averse and wanting all you can eat for the price of salad and water.  So finding a contractual balance that meets the needs of the customer, while protecting your business, can be tricky.

Also, if you are seeking big game clients (large institutional customers, e.g. government departments, banks, telcos, and energy sector participants), you’ll probably have to contract on their terms.  There’s no getting around this (unless you’re Oracle or Microsoft) but if you want to effectively and efficiently negotiate those terms, you will need to focus your attention on the material risk issues and understand what you can live with.

This guide is the first in a series that, together, will give you a great foundation to work out what you should focus on and how you should protect your interests in your IT contracts with customers.

This guide focuses on intellectual property (IP) arrangements for those suppliers who are developing IP and solutions for customers.  Getting right the IP arrangements in an IT contract will often be your, and your customer’s, highest priority.

key drivers

When thinking about IP, it’s often useful to consider the key drivers for each party.

  • your drivers: need to protect your pre-existing and independently developed IP (background IP), e.g. you will want to retain the right to reuse your background IP (and possibly IP developed for the customer), and to protect the confidentiality of that IP, to create further value for your business
  • customer’s drivers: needs to ensure it has the rights required to fulfil the purpose for which it is procuring the IP; is likely to want to own any IP that it is paying the cost of developing, especially if the IP provides a competitive edge; is likely to want ongoing rights to modify the IP so that it can get the full expected lifetime benefit of its investment.

Often, these drivers result in the parties focusing negotiations on who will own the IP.  But that can mean the underlying drivers are not actually addressed.  If you are struggling to reach agreement on IP ownership, it’s a good idea to take a step back and think about each of these underlying drivers and what mechanisms can be used to meet each party’s needs.

the usual IP position

Where you are developing specific software, a solution, or other IP for a customer, unless you have an exceptional negotiating position (or your customer is very laid back), it is likely that the customer will want to own, or have a high degree of control over, the IP.

We discuss the usual IP position in a development contract below.

customer owns newly developed IP

If the customer fully pays for the development, it will own that new development and have full rights of reuse.  Often this is tied to a stated purpose so as to protect the supplier’s background IP and commercial position.

background IP is licensed

To the extent that any of your or a third party’s background IP is incorporated into that development, that background IP is licensed to the customer with rights that are broad enough to enable the customer to use the development for its intended purpose.  Often a customer also will want rights to modify the background IP to maintain, support and enhance the development, which is usually reasonable.  To protect your ability to commercialise and reuse your background IP in the future, you should ensure this licence:

  • is not exclusive. An exclusive licence would, of course, prevent you from using background IP for another purpose
  • is limited to use for a stated purpose and in a stated location, i.e. the customer can only use background IP for the reason that the deliverable was procured and in a particular territory (i.e. NZ). If the customer can use background IP for any reason, it could create breach of third party IP risk, along with limiting your ability to commercialise that IP
  • clarifies when a customer’s service providers can use and access the background IP. g. if the customer can modify the background IP to repair and maintain the deliverable, can it delegate this right to its IT services providers?  If so, you should think about ensuring any service provider is subject to a written confidentiality obligation and a requirement to only use the background IP for the purpose.

escrow

If the background IP is substantial, or a critical part of the development, the customer may seek an escrow arrangement for the source code for the background IP.  We’ll be discussing escrow in our next installment in this series of guides.

retaining rights to the new IP

Of course, often you may be developing IP for your customer and you will be able to see how you could further use the IP to improve your own commercial position, e.g. use it for other customers in other sectors.  Depending on your negotiating position, or how you incentivise your customer (e.g. discounted development costs), you may be able to retain ownership of the IP or have a perpetual licence to use it for your own purposes.

If you retain ownership, expect that the customer will want to ensure a broad and perpetual licence to use the developed IP, and possibly the right to further develop that IP.

Other benefits you may be able to offer a customer in order to retain ownership or obtain a perpetual licence to reuse, include:

  • providing the customer extra security over the viability of the IP long-term – if the supplier is able to commercialise the IP, it’s more likely to create a secure product that will be maintained and supported as a standard code base, which gives the customer better certainty as to the lifespan of its development
  • restricting your ability to commercialise the IP in the customer’s market. A key driver for a business doing bespoke development is to gain competitive edge over its competitors.  Given this, a customer is likely to be more amenable to you reusing the IP if it knows its competitors won’t get their hands on it
  • paying a royalty to the customer for the use of the IP (although this can be messy, and we would avoid this if possible)
  • agreeing to provide the customer with new customisations, add-ons, etc. (extras) for free. In this case, it’s a good idea to put some limits around this, because it could prove onerous or have unintended effects.  g. consider making available extras only for a set period after completing the original development (e.g. 5 years) or where they are made generally available to your customers – this would exclude any bespoke add-on that may have been created specifically for another customer.

Whichever IP position you adopt, make sure you’re clear on who owns future improvements to background IP.  If a customer can improve or modify background IP as part of its use of a development and the customer will own that improvement or modification, you may want to obtain a non-exclusive licence to those improvements for your own purposes.  That said, if you want an exclusive licence back, this may well breach competition law and we suggest you seek specialist advice on this.

work for the NZ Government

If you are negotiating the IP arrangements for a development for the NZ Government, it’s a good idea to have read the current state sector guidelines for the different IP options that agencies should consider for software development.  See Guidelines for Treatment of Intellectual Property Rights for ICT Contracts.

The guidelines:

  • acknowledge that government agencies have previously assumed a default position that the customer agency should own all IP
  • promote consideration of alternatives for non-mission critical E.g. the customer agency owning all of the new IP in the deliverables, with a licence back to the supplier for its use and commercial exploitation.  Another alternative is the supplier owning all of the new IP in the deliverables, and providing a licence to the customer agency and other state services agencies, for any purpose other than commercial exploitation (this is the recommended option where the IP is not of critical importance to the customer agency).  The reason for promoting alternatives is that the NZ government is not in the business of commercialising IP and, as a result, it is preferable that it obtains only the rights it needs to the relevant IP, and enables the supplier to take the IP to market
  • recommend confining the default position (that the customer agency owns all new IP in the deliverables, with no licence back to the supplier) to situations where there are good security reasons for preventing the IP from being commercialised or where the IP rights apply to a critical government ICT system.

If followed, these guidelines would open up fantastic opportunities for NZ tech businesses to leverage off work for NZ Government agencies and to commercialise that IP.  However, in our experience:

  • the guidelines are ignored by agencies (diplomatically speaking, adoption of the guidelines has been slow . . .)
  • the (not always legitimate) argument is made that the IP is critical so the default position should apply.

Despite this, it is useful to understand the guidelines to open up the possibility of discussing alternatives.  And, at the very least, government agencies should be pressed to explain their IP position by reference to the guidelines.

use of open source software

Until recently, due to the relative infancy of open source software (OSS), there was a great deal of customer nervousness on the use of OSS in IT projects and supply arrangements.

However, OSS is now widely used by tech businesses.  We think the use of OSS should be embraced by both suppliers and customers.  Its use reduces the costs of development (good for the supplier) and should have a resulting knock-on effect to customer pricing (good for the customer).

If you are using OSS, always bear in mind that you cannot transfer ownership of something you don’t own, unless you want to subject yourself to legal action and a claim for damages.

Also, the OSS will be subject to its own licence terms that will transfer with the OSS, i.e. any further use of the OSS must be consistent with those terms.  There are a number of different types of OSS licences.  The Open Source Initiative has a great site which includes copies of the most widely used OSS licences and has a good FAQ section on open source licensing.  Briefly, OSS licences often fall into the following general categories:

  • permissive licences (e.g. Apache license, version 2.0). These licences allow a person to freely use the OSS without restriction, provided there is attribution and the licensor has no liability for use
  • copyleft licences (e.g. the GNU general public license v3.0): Copyleft licences can require that, if the OSS is used, modified or distributed by a person, anything derived from the OSS must be made available on the same terms as the original OSS (including the requirement for source code to be made available at no cost).  Most customers will seek comfort from a supplier that any OSS used in a project is not copyleft so as to avoid any risk of the copyleft licence attaching to the customer’s IP
  • licences with other limitations on use (e.g. restrictions on distribution, modifying, and/or sublicensing).

If you are using OSS in a customer development that the customer will own, you will need to ensure that OSS is carved out of the concept of new IP (to be owned by the customer) so that ownership is not transferred.  The OSS should form part of the background IP licence (which in turn will need to be consistent with the terms of the OSS licence).  In practice, this is not usually an issue because most OSS licences are broad.

If you are simply licensing IP to the customer and that IP incorporates OSS, you will need to ensure your licence is consistent with the relevant OSS licence.

Where the customer is paying a lot of money for the solution, you should expect that the customer will want a good understanding of what the IP comprises and whether any OSS is incorporated.  As a minimum, your customer will want some comfort around your use of the OSS, e.g.:

  • confirmation that you have right to licence to the customer all third party IP (including OSS) incorporated into a deliverable on the terms of the licence set out in the customer contract
  • confirmation that the licence terms for any OSS used in the IP are not copyleft (see our discussion above on this)
  • a list of all OSS included in any deliverable (including details of the relevant OSS licence and version governing its use), for the purpose of assessing any risk and/or to ensure compliance with the OSS licensing terms.

These types of comfort are common and, provided you have done your own homework on the OSS so understand the OSS licensing terms, they shouldn’t be a problem.

IP indemnities

As a general rule, if you are licensing, developing or otherwise supplying IP, you should expect to provide an indemnity to protect the customer if that IP breaches a third party’s intellectual property rights.  In terms of risk allocation (based on who is best able to manage the risk of a claim and who is in the best position to assess and prevent that risk), the supplier normally bears this burden.

An IP indemnity is an obligation or promise on the part of the indemnifier (usually the supplier) to pay the indemnified party (usually the customer) if a third party claims that the customer’s use of the IP breaches that third party’s IP rights.  The indemnity is usually limited to the costs, losses, etc. arising out of the claim, and not other costs and losses – although the supplier may still be liable for these other costs and losses under another clause in the contract.

IP indemnities in NZ

IP indemnities in NZ follow a standard formula.  As a result, they are usually non-contentious – although the devil is in the detail.  While these clauses often have the same formulation, you should always carefully read the indemnity if supplied by the customer as their lawyer may have tweaked it to make it more favourable for its client.  We discuss below the key things you need to think about in an IP indemnity.

scope

Ensure the scope of the indemnity is sufficiently narrow, e.g.:

  • limited to losses arising from the third party claim itself (i.e. the costs of litigation and/or any award of damages made against the customer), and not other losses
  • in what circumstances should the indemnity not apply? There should be a clear statement that the indemnity only applies where the claim arises out of the customer’s use of the IP in accordance with the contract (i.e. if the customer is acting outside the scope of the licence, there should be no indemnity protection).  Other common carve outs include where the IP claim is caused by the use of customer or other third party data (i.e. not supplied by the supplier), by the modification or alteration of the IP by a person other than the supplier, by any development undertaken by the supplier at the direction of the customer (this being the Nuremberg defence of IP indemnities), and by the customer’s use of the IP in combination with software or other IP not supplied by the supplier.

relationship with liability caps and limits

Is the indemnity subject to any limitation of liability?  As a general rule, liability caps and limits do not apply to IP indemnities, on the basis that customers simply won’t wear the risk of the high costs and awards in litigation.  However, in some situations, you may be able to negotiate a cap, e.g. where the IP is developed based on your customer’s design or you are in a strong negotiating position.

defence of a claim

Are you able to control any negotiation or litigation (including settlement) relating to the claim and prevent the customer from doing things that may hurt your case?  Normally, there would be restrictions and processes included to enable this, e.g. the customer must provide you notice of claim as soon as possible, you have the right to control the defence of the claim (including any settlement), and the customer will provide you with reasonable assistance and information in the defence of the claim (normally, at your cost).  Larger customers may want you to consult them on any defence, possibly get their approval for any settlement, and may want to be represented during any negotiation or litigation.

alternative remedies

Can you provide alternative remedies to resolve the IP claim?  Often, the easiest way to fix an IP infringement issue (at least in relation to keeping the customer happy) is to modify the IP so that it no longer infringes, or to obtain a licence from the third party whose rights are infringed.  These should be included as specific options, along with an ability to terminate the contract with the customer if neither proves possible.

IP indemnities overseas

More care is required if you are supplying IP overseas or the IP may be used in an overseas jurisdiction.  It’s a good idea to get some in-market advice on what is usual for indemnities in that market and the common risks.

In particular, some markets are crowded with competing technologies.  Market participants are very willing, and often financially able, to actively protect their patch.  A widely known example of this is the long-standing mobile device/smartphone wars between Apple and Samsung.

Also, in some markets, there are entities (sometimes referred to as non-practicing entities (NPEs) or, more derogatively, patent trolls) that hold and attempt to enforce patents, even though they do not manufacture products or supply services based upon those patents.  This is a particular issue in the US where the losing litigant is not normally required to pay the winning litigant’s legal costs.

This being the case, a supplier may need to seek restrictions on its indemnity to mitigate those risks (e.g. limiting the indemnity to breach of copyright in the territory – because a lot of litigation relates to patent infringement).  Of course, a narrower indemnity may need to be justified to the customer.  A good starting point for your argument is that to provide a broader indemnity would require a significant increase in the fees associated with the IP, i.e. the IP has been priced based on a narrower indemnity.

next up

That sums up our thoughts on IP issues under development contracts.  Watch out for our next guide in this series in which we’re planning to discuss product licensing and escrow.