Legal Download 2.0

More practical advice on how to manage some of the most common issues that arise from software agreements

  • E-Mail
By  Chris Edwards Published  October 4, 2007

As IT professionals we understand you are well aware of the importance of software to a business. From small start-ups to multinational corporations, every business has to deal with the issue of identifying and procuring the correct software for its business operations.

In this month’s column we deal with a selection of discreet issues which we as specialist IT lawyers often encounter in advising both suppliers and customers on software agreements. We also propose some practical advice and solutions to these issues which can be used to alleviate common pitfalls.

Have the parties identified the rights which need to be granted?

Software is protected as intellectual property (IP) by the laws of copyright and in some cases by way of patents. For another party to use a software developer’s IP, a licence must be granted allowing such use. In large software and IT contracts the ‘rights’ which are granted are some of the most fiercely negotiated provisions.

The scope of such rights is crucial to both parties. A supplier will often want to limit the use of the software provided under an agreement by, for example, reference to time, location, the number of simultaneous users, type of use permitted and possibly even the hardware it is used on. Conversely, a customer is likely to require flexibility in how the software is implemented across its business. For example, a large organisation may want the ability to transfer the software to different sites or onto new hardware platforms.

Before negotiations begin a customer should consider carefully the rights it requires in the software to be procured. Will it need to enable an outsource service provider to use the software? Will it need to use the software in different jurisdictions? How many users will require the software application? In our experience, better understanding by all parties of how the software will be used in practice can often save time in negotiations – minimising the chance of a customer trying to obtain licence rights which are of little practical value.

Can the supplier grant the rights required?

Another common issue in software agreements are rights in relation to ‘Third Party Software’. A common scenario sees a main supplier (often a systems integrator) use a variety of software (sourced from different developers) which is combined and provided as part of a ‘System’ to a customer.

A customer will not want to deal with numerous software suppliers in obtaining its new System so an agreement with one main ‘lead’ supplier who promises to supply everything required is an attractive proposition. However, under such an arrangement it is crucial a customer ensures that it has the ability to use such Third Party Software as it requires. It may want to request from the supplier the terms on which the supplier itself has procured the software from the third party. This element of due diligence is beneficial particularly if it identifies potential problems early on in the contractual negotiations.

From a drafting perspective, one simple method to minimise risk in this area is to accurately define each different type of software to be provided, for example "Supplier Software" or "Third Party Software” and then through careful drafting attach the appropriate licence rights to the relevant definitions.

Both parties should be wary of standard provisions which purportedly grant wide rights in all software procured under an agreement without first investigating whether such rights can be granted in the first place.

Is the source code protected?

Where a customer has procured software that supports or operates business critical functions, it is only prudent for that customer to ensure that it has the right to support and maintain such software (through access to the human readable 'source code' of the software) in the event the supplier is unable to. However, suppliers are notoriously protective of their source code as it is the main output of thousands of hours of programming and it is not to be disclosed easily.

In such scenarios 'escrow agreements' are often a compromise position for both parties. These tri-partite agreements are entered into between the customer, supplier and a third party escrow provider, often in parallel with a software agreement. Essentially, the customer gains protection by the supplier placing a copy of the source code of the main developed software (along with all materials and documents required for a programmer of reasonable skill to support and maintain the software) with the escrow provider. The source code and various supporting documents are only released to the customer on the occurrence of certain agreed events. Such events usually include the insolvency of the supplier or where the software in question is no longer supported or maintained by the supplier.

Where the parties agree on using escrow, a customer should place their focus on ensuring any escrow agreement provides obligations on the supplier to continually update the source code and relevant materials in escrow to ensure it is the most up to date version should a 'release' event occur.

Have the parties considered provisions relating to infringement of IP rights?

Another heavily negotiated part of software agreements is a supplier's indemnity to a customer for any losses a customer may incur where its use of software, provided under a licence, infringes the IP rights of a third party.

We are increasingly seeing push-back from the supplier community around the previous standard position of granting an unlimited indemnity to a customer for infringement of third party IP through use of the software by the customer. The huge potential losses in this area, seen by extensive patent litigation in the US, have encouraged a more cautious approach by suppliers.

Customers should however ensure that the supplier is (a) required to indemnify (to an agreed extent) the customer against loss incurred as a result of an infringement, and (b) is obligated to carry out any remedial action such as providing a non-infringing version of software which performs substantially the same function as the infringing software.

Both parties need to strike a balance between protecting the customer from infringement which it cannot avoid and giving the supplier the opportunity to resolve an infringement issue or, as a last resort, terminate the licence of the infringing software.

The areas we have touched upon in this article are just some of the many issues we as lawyers encounter in advising and negotiating software agreements. Other areas of contention include acceptance procedures, warranties, the change of scope where software is being developed and licence charges. With the rapid changes in the way software is being delivered to end-users, new issues in this field will also inevitably arise. We shall continue to address these issues in future editions of this column.

The author, Chris Edwards, is a Legal Consultant with DLA Piper (Dubai)

3636 days ago
Andrew

Alex, In reference to your comment (06.10.07) can I make you aware of the escrow solution, not the escrow agreement. The solution is the tri-party agreement plus a verification of the code that is to be deposited. The verification is a secure audit and re-build of the application, documenting how the product goes from source to object code - full working application. This ensures complete continuity of the application once the agreement is executed.

3637 days ago
alex

His trying to protect and sell the escrow model of source code licensing, which is hopeless by design. In many cases source code is so much complex that nobody except author (yes, that crazy coder who did it) can produce software product out of the code. Remember about 2 years ago Windows 2000 source code leaked - does anybody create new Windows? Guess what? Noone - millions lines of code and without good guidance from author you get lost in a sec.

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code