Whether a software license agreement is properly constructed for a transaction depends on a range of factors. Of course, management of intellectual property rights for the copyright owner is a key area for close consideration. This entails defining the territory – usually countries – for the use of the software.
Software Development Contracts
A key indicator for complexity is whether the software licence is or will be part of a larger agreement to develop software from scratch – that old-fashioned word bespoke may ring a few bells. When computer software is developed under a contract, the proper advice is that a document specifying what the software will do at the end of the day should be incorporated into the agreement. Whether it is referred to as the functional specification, functional requirements or the requirements document is immaterial. What is important is that it defines with reasonable clarity what the software will do; and of course on a functional level.
Packaged Software Contracts
On the other end of the spectrum is a software licence for packaged software. In this case, the software is not to be built to any person’s particular specification, but rather the software supplier has gone to trouble of identifying a need in a market and constructed the software to fill the gap in the market. Sometimes – and more frequently – niche software is built with configuration options to deal with a broad array of configurations to suit different flavours of businesses. So, an accountancy package may be tailored to businesses from 10 people to 1,000 people. The point is this: software of this nature is fundamentally packaged and is sold as it is. There may be a requirement for extended configuration to suit the particular client’s needs, but in the end it is packaged and not software built to anyone’s particular specification, as is the case with software development contracts.
The difference may be obvious in this regard, but time and time again the wrong contract is used due to misconception as to the fundamental nature of what is being delivered.
After determining the fundamental nature of the software, some of the other matters that are frequently dealt with in so called software license agreements are:
1. The provision of maintenance and support service
2. Installation and testing
3. Service level agreements, delivery of improvements (whether they are updates or upgrades, rather than hot fixes). The software related services may be agreed in a separate document or they may be incorporated into the same agreement as the software licence. We return to these below.
Intellectual Property Rights
Terms of License
Assuming that the software supplier does not intend to assign the copyright in the software to the licensee, the terms of the licence are of crucial importance to software suppliers’ further exploitation of the software.
On the most generic level, there are 3 types of licences that may be granted: non-exclusive licences, sole licences and exclusive licences. Licences though, as they are only ‘permissions’ may be framed in anyway the parties wish. A software supplier will often wish to licence their software to a number of clients. In this case, the licence will be a non-exclusive licence as the software supplier grants a non-exclusive right to the licensee to use the software. Sole licences do not appear too often, and they simply mean that the licensor (the software supplier) grants a single licence to a party to use the software, and they retain the right to use the software themselves. On the other end of the licensing spectrum is the exclusive licence. In the event that a software supplier wishes to grant the licensee the right to use the software to the exclusion of all others, an exclusive licence is granted. Some care needs to be taken when granting exclusive licences, as courts will look at the terms of the exclusive licence and decide whether it is in substance an assignment. If it is, then a court will order that the licence term was not at law a licence at all, but rather an assignment and thus divesting the software supplier of all rights in the software.
Here is a brief example of the complexity that can be introduced in granting licences.
Suppose a supplier designs and constructs software that manages couriering of documents from office to office of business. It is possible for the software supplier to grant non-exclusive licences to businesses in a particular trade, say banking to use the software. Those licences may be restricted to use in a particular geographic region such as the City of London. The software supplier may then grant non-exclusive licences to businesses in the financial sector in Manchester to use the software. Further, the software supplier may grant an exclusive licence to a person to develop the source code to perform additional functions. This exclusive licence would deprive the software supplier from further developing the source code himself. So licensors of software are able to flexibly grant permissions to use the software, and restrict its use geographically, by industry and any other basis that appeals to them.
Extensions of these types of licensing are non-transferable and non-assignable licences, which effectively prevent licensors from selling or licensing others to use the software. One of the exclusive rights of the copyright owner is the distribution right – the right to licence others to distribute software. This is the foundation of the reseller agreements, whereby third parties are authorised to licence software on the software suppliers’ behalf. Most software licences do not grant the licensee the right exercise the distribution right as it would allow them to sell licences for the software.
Furthermore licences may be set for a fixed term or the grant of licence may be perpetual – allowing the licensee to use the software forever subject to any other conditions imposed by the licensor.
When the software is licensed on a per use basis, it is a good idea to provide that a register be maintained of copies made of the software, in addition to monitoring software use by Active Directory on Windows systems. Such implementations facilitate denying software use by electronic means. If this is to be done however, the licensor must be informed in the contract document.
Intellectual Property Rights Indemnities
In software licence agreements, these indemnities are geared to protect the licensee from primary liability for infringement where their use of the developed software would infringe patent rights or copyright. As innocence is no defence to infringement, a user of the software infringes intellectual property rights simply by using it. It is worthwhile to note however that the innocence may be taken into account in the assessment of damages. These indemnities are becoming more important to licensees as an incidental effect of the popularity in obtaining patent rights. Patented inventions may be combined with other inventions, and although in patent cases infringement may be difficult to prove in the absence of great expense, the existence of patent rights in software is the best form of protection, because there is no defence that the software was independently created. That defence is only available in copyright infringement cases.
In order to claim the benefit of an indemnity, the indemnifier should require that they have conduct of the defence of the infringement defence proceedings and insist on the cooperation and assistance of the indemnified party in defending the claim. This to some extent allows the indemnifier to control their costs and run the defence in their best interests. The software supplier is in the best position to run the defence in any event due to their knowledge of the development of the software and the sources drawn on in developing it.
Usually accompanying intellectual property indemnities are provisions requiring the software supplier to replace infringing aspects of the source code and failing this, pay the expenses of the licensee in doing so.
Payment for Licences
Owing to the nature of the rights of the licensor in granting software licenses, the licensor is able to structure the payment for licences to build in flexibility to payment structures.
Restrictions may also be placed on the use of software over a network, per machine, single use, on specified equipment, per user, per site, worldwide, by territory or any combination of these.
The most basic form of licence seems to be a fixed sum for an organisation. Extensions of this form of licence may be for a set number of users with additional licences incurring an additional fee for a fixed period. For multifaceted software, different fees may be applied for different the types of licences required. For instance, an organisation may require additional administration licences or data processing licences each of which would attract a different price point.
Where licences granted are not intended to be perpetual, the timing of renewal payments should be set out and the method of calculation of the sum falling due. Properly drafted contracts should allow for price rises over the course of the licensing period together with price rises in materials and human resources. Also, the parties should consider whether they want the licence to renew automatically, or to automatically lapse.
It is worthwhile providing for interest rates where payments are late, but failing that the Late Payments of Commercial Debts (Interest) Act 1998 will apply for those late payments.
Where software has been commissioned, there may well be hardware requirements to host the software or other expenses such as staff costs, other materials and travel expenses that should be dealt with in the agreement. For clarity, whether the prices are inclusive or exclusive of VAT it should be made clear to avoid doubt as to who will be liable for the tax in the event it becomes payable in unexpected circumstances.
Additional Services and Improvements (Upgrade Services)
Provision may be made in software license agreements for further development and/or customisations by the software supplier. These are commonly dealt with in two ways. Firstly, the supplier may be required to provide a quote for the development services requested by the licensee or alternatively the software supplier may be granted entitlement to charge time and materials at published rates. It is rare in this day and age for suppliers to be given a blank cheque to perform further services for licensors wishing to improve the functionality of the software.
In packaged software and commissioned software licence agreements, especially in the case where the software is licensed on a non-exclusive basis and constantly improved and developed, licences often entitle the licensee to improvements for a fixed period. In the case that a licensor has uniquely funded the development but receives the software at a reduced price, more favourable rights to receive improvements are commonly encountered.
Effective change control provisions are imperative to prevent scope creep, but in order to be effective, a functional specification or other document must be incorporated into the agreement to provide a point of reference for change control. Change Control provisions also allow an elegant mechanism for the software supplier to extend the delivery time scales. Where scope creep occurs, the supplier may not have a problem performing the additional work, but to perform the work in the same timeframe as original work is unrealistic. The focus in this sense is contract management: managing the deliverables, and when they are to be delivered. Change control is not to be underestimated.
Factory Acceptance Testing
In order for a software supplier to ensure their products are fit for purpose, factory acceptance testing must take place before a software product is released.
For off the shelf products the onus is solely on the software supplier to ensure the product meets the functional requirements and is bug free to avoid having to patch copies of software already released to market.
However, in more bespoke or customisable solutions the responsibility for successful factory acceptance testing prior to release falls on both parties. The majority of the responsibility falls on the software supplier to ensure that the product is tested in house prior to release.
Time pressure to deliver often reduces the actual time spent on this phase of software development to a minimum. This is a cause of a far greater number of faults being reported in the user acceptance testing phase which is a more costly exercise for both parties.
To ensure factory acceptance testing occurs and is performed adequately obligations must be placed upon the software supplier to deliver test documentation to the customer for review prior to the customer signing off to receive a release. The test results should contain certain numbers of test iterations across the whole software suite.
Obligations must also be placed upon the customer to deliver in a timely manner items such as a suite of test data and test scripts to the software supplier. Forcing this co-operation through contractual agreement creates a balance in the contract to focus the parties minds on the job in hand thereby reducing the time spent user acceptance testing on a customer’s site thereby reducing cost.
User Acceptance Testing
Released software invariably involves some degree of acceptance testing and the methods of conducting it are more or less onerous on the software supplier. To properly conduct acceptance testing, the purchaser should be given the opportunity to prepare their own test data and test scripts. The acceptance testing should be conducted in the presence of the software supplier so that instances of apparent defects may be dealt with immediately, and if the tests are successful obtain the acceptance certificate immediately, as acceptance certificates are the precursor to payment. Provision for retesting should be set out to allow a speedy process in the event that a genuine defect is identified during acceptance testing process. Warranty periods for software maintenance arising from defects should run from the acceptance date and not before.
As businesses become more sophisticated in respect to the delivery of computer software, so does the requirement for cogent user documentation.
This is a minimum requirement for packaged and commissioned software. In the event that the intellectual property rights are to be assigned to the commissioner of the software, delivery of design documents, project management documents and user requirements documents are likely to be required to be delivered at the conclusion of the development project, to enable the commissioner of the software to develop the software in its own right.
Usually there is no commercial reason to grant rights to access these development documents where the software is subject to a package licence, or where the licensee is simply entitled to use the software.
Training may take a variety of forms. In the case of commissioned software, the software supplier may need to ‘train the trainer’ of the licensee as a minimum requirement, or for additional fees, conduct formal training sessions for end users. Much depends on the complexity of the software and computer literacy of the intended user base.
Escrow agreements are geared to protect the licensee paying a software supplier to design and construct software that meets their particular needs. These agreements are relied upon when the software house loses the means to continue to support the software whether through liquidation or lack of will. Escrow contracts are premised on the state of affairs that the licensee is never in possession of the source code, and to that extent, the licensee is exposed to the risk that if the software supplier or software house fails, they have recourse to the source to maintain and develop that source code. The conditions for release of the software to the licensee may be made as particular as the parties wish to make them. The more formal flavour of escrow agreements involves an independent trusted third party who specialise in providing escrow services. They take possession of the source code for the software, and undertake by contract to release the source code to the licensee only in the specified circumstances. The licensee gains some comfort in managing their risk in investing in the software development in the first instance.
Penalty Payments for Failure to Deliver
Rather than be forced to commence litigation in order to recover damages and to reduce the administrative cost of contract management, incorporation of penalty payments (liquidated damages) clauses into software license agreements is increasingly commonplace. Already, liquidated damages clauses are frequently used as the means for recovery for failure to meet agreed service levels. These liquidated damages payments come in the form of service level credits. The difficulty with liquidated damages clauses to setting the damages to be paid in the event of breach or non-performance to a level that does not qualify as a penalty or a forfeiture, which are unenforceable in the English legal system. The linchpin in determining whether a liquidated damages clause will be considered a penalty or forfeiture is whether the sum of liquidated damage is a genuine pre-estimate of the loss that will be suffered as a result of the breach that leads to the right for liquidated damages to be paid. Agreeing sums to be paid by way of liquidated damages however does not limit the payee to accept the specified or calculated sum in the event of a breach, as they may still sue for damages at large.
The two provisions that cater for termination in practically every professionally prepared document – where the parties have near equal bargaining power – are that either party may terminate in the event of a material breach or where one party enters liquidation or is otherwise insolvent.
Incorporating other rights to terminate largely relies on the nature of the services to be provided. Having right to terminate the contractual obligations assumes that there are continuing obligations under the contract. If the contract simply grants a perpetual software licence for a fixed fee, then it stands to reason that there is little need for rights to terminate. The modern style of contract drafting, even for packaged software (which are commonly instances of a perpetual licence grant ion) commonly exist in software licence agreements, and generally relate to the failure of the provider to meet specified minimum service levels.
Consequences of Termination
In the case of outsourced software services, exit management provisions are essential to ensuring a timely and professional handover of the outsourced services when terminating contracts. In the context of software developed and subsequently licensed, it may be that it is appropriate for the licensor to
1. Hand back user documentation
2. Delete all copies of the software residing on servers and workstations
3. Deliver up copies of the software on backup media and
4. Destroy confidential information.
Certificates of compliance may be used to obtain confirmation that the post-termination requirements of the contract have been adhered to.
On a related issue, this is where managing software licensing by electronic means is a useful tool to prevent use of the software. This is an under utilised measure by licensors to ensure that the computer software cannot be used.
Limitations of Liability
Limiting liability can be one of the most contentious issues in negotiating licence terms. The purpose of limitations of liability is to exclude or otherwise limit liability that arises in a party in the event of a breach of contract or negligence in performing the contract. Liability that cannot be excluded should be insured and there is a good case for employing other means to manage corporate liability and protect the assets of a company, which naturally includes intellectual property assets. Liability arising from negligence that causes personal injury or death cannot be limited or excluded in any case. The types of liability that may be excluded include property damage; loss of profits, business or revenue; consequential or incidental loss; loss of goodwill and the damage caused by the loss and destruction of data.
In technology contracts that use facilities such as the Internet that are outside the control of the parties, force majeure clauses may be used to absolve the parties of liability when something goes wrong. Force majeure clauses may refer to named events as well as a general type of event. The effect is to avoid the instance of a party being in breach where the events are outside their control.
The basic checklist for some of the provisions that are often sensibly incorporated into software license agreements is:
1. The Parties
2. The Price
3. Obligations of the Software Supplier
4. Obligations of the Licensee
5. User Acceptance Testing Procedures leading to Acceptance, including warranty periods that will apply thereafter
6. Additional Services
7. Change Control
8. Training Requirements
9. Escrow Agreement
10. Service Levels
11. Service Level Compensation
12. Liquidated Damages
13. User Documentation
14. Rights to Improvements
15. Confidentiality obligations
16. Intellectual Property Rights
a. Branding rights
b. Terms of licence
17. Confidentiality obligations
18. Termination clauses
19. Consequences of Termination
20. Limitations of Liability