Tip 1 - Scope of use
It is common for a supplier to restrict the customer’s use of software. Most customers of standard software would expect not to get exclusive use. The supplier should also specify the duration of the licence, whether the licence is in relation to a particular site or a particular number of users. Also, while the supplier might agree that the customer can use for the purposes of their business, the supplier should ensure the customer cannot re-sell or offer “bureau” services for their clients without negotiating with the supplier first. To verify use, the supplier should add an audit right.
Tip 2 – Escrow
If the supplier is developing bespoke software, escrow is commonplace and the supplier will probably have to make regular deposits during the development cycle. Escrow for standard software is not always appropriate and yet customers will often ask for it. Even experienced software developers will take a while to get to grips with code they have just received from escrow. To minimise the impact on the supplier, either set up multi-licensee escrow if many customers are likely to request it. Or, if only a few ask for it, perhaps they will get sufficient comfort from the supplier promising in the licence to enter into an escrow arrangement at the future request of the customer. It’s still escrow, but just not now.
Tip 3 - Don't over promise
It is inevitable that a supplier will have make some promises – that is, make representations or grant warranties – for the software but suppliers should make sure they don’t over-promise in the sales process. After a long battle a UK court recently ruled that an EDS representative had fraudulently misrepresented to Sky how long the project would take, potentially exposing EDS to a large compensation claim. A supplier will generally promise that it has the rights to grant the licence. If the licence is for the supplier’s standard software, the supplier should not state in the licence that the customer is relying upon the supplier to select the software to achieve the customer’s objectives. Whether or not the supplier discussed the objectives, the customer could reject the software if it does not solve them. Instead, a supplier should warrant that the software will perform “materially” or “substantially” in accordance with the specification and put the onus on the customer to check it does what it needs. Then restrict this warranty to a specified period. It is rare to promise more than 90 days.
Tip 4 - Excluding risk
As with any business relationship, the supplier will want to reduce or exclude its risk. On the whole, these reductions or exclusions must be reasonable otherwise they might not be enforceable – the English courts look at a number of factors in making up their minds. For example, is the supplier licensing the software on its standard terms which it refuses to amend? Has the supplier capped its liability to a particular amount which is much lower than the likely losses the customer will suffer if the software fails to perform? Does the supplier’s insurance cover exceed its liability cap? Is the supplier doing the data backup or providing disaster recovery and yet trying to exclude liability for loss of data? Often, suppliers will accept higher risk if the customer will pay more.
Tip 5 - Supplier's sanctions
If the customer breaches the software terms, consider what sanctions the supplier can impose. It’s all very well having escalation procedures and mediation but being able to take decisive action is often what matters. For example, if the customer fails to pay for maintenance can the supplier stop providing the maintenance releases? If the customer fails to pay the annual licence fee, can the supplier cut them off?
Tip 6 - Data security and protection
Suppliers must comply with EU data protection legislation. This means they must ensure that they hold and process a customer’s data fairly and lawfully and that they hold the data securely. Suppliers should address these issues in the licence with the customer. Their responsibilities don’t stop there though. They must also ensure that they put in place appropriate measures with their data “storer” – perhaps a data centre provider – to ensure they comply with the legislation too. This is particularly relevant for suppliers who store data outside the EU, for example as part of a cloud service.
Tip 7 - Back-to-back terms
If a supplier is reselling a third party service, such as hosting or storage in the cloud, the supplier’s provider will be aiming to reduce its liability where possible. The supplier should not only seek to obtain the best protection it can from its providers, but also ensure that it does not promise greater protection to its customers. This “back-to-backing” allows a supplier in the middle to pass obligations and liabilities up or down the chain rather than being stuck with it and being attacked from both sides.
Tip 8 - Service levels and credits
Service credits are losing their appeal. Most customers figure that their supplier will simply increase charges to offset the cost of service credits. From a supplier’s point of view, avoiding service credits makes for a great business case. Having said that, most customers will want to specify key performance indicators and a robust service level agreement. If it is for a cloud-based service, this is often the only reassurance that a customer will have. Where the supplier is able to offer failovers/backups and a quick response to rectify the service this might be sufficient for a customer without resorting to cumbersome service credit – or liability – claims.
Tip 9 - Intellectual property rights indemnity
A customer will legitimately expect a supplier to indemnify it in respect of breaches of third party intellectual property rights. This is one of the key battle lines between proprietary and open source sellers with proprietary software houses claiming that customers get better protection than by using open source, which could have been modified by anyone in the community leaving the door wide open to infringing code. Suppliers can also sell proprietary and open source together. If a supplier is willing to give an indemnity it should consider restricting it to its key trading territories (excluding, for example, US intellectual property rights if it is not trading in the US) and liability for open source. Also, think about capping the indemnity even if this is a higher cap than the supplier’s general cap on liability. After all, an indemnity is only usually any good if the supplier has the appropriate insurance.
Tip 10 – Recompense for complete failure of service
As mentioned in tip 8, even if a supplier avoids service credits, it is unlikely to avoid all liability for a complete failure of service. When working out how much liability it can exclude (see tip 4) the supplier will need to bear in mind that a customer will not want to carry all the risk in the contract. Equally, the supplier will not be willing to provide a full compensation for all a customer’s losses. A supplier should ensure that it does not grant a customer an indemnity to compensate for losses, especially as indemnities are often carved out of the general liability cap.
For further information, please contact Frank Jennings, Partner in our Technology Group on email@example.com.
This article previously appeared in the Federation Against Software Theft's newsletter "FastForward" in two parts in May and June.