This Agreement is made on [date] Parties 1 [Insert name of supplier], a company incorporated in [England and Wales] under number [insert registered number] whose registered office is at [insert address] (Supplier); and 2 [Insert name of customer], a company incorporated in [England and Wales] under number [insert registered number] whose registered office is at [insert address] (Customer), each of the Supplier and the Customer being a party and together the Supplier and the Customer are the parties. Background (A) The Supplier provides the Cloud Services as described in this Agreement to various third party customers. (B) The Customer wishes to evaluate the Cloud Services for [use in its business]. (C) As set out in this Agreement, the Supplier has agreed to run certain Tests on various Customer Content during the Test Period utilising the Cloud Services and to produce a Report of the outcome of those Tests. The parties agree 1 Definitions and interpretation 1.1 In this Agreement: Authorised Customer Systems • means [insert details of Customer systems that Supplier will need to access for the Tests if any, eg certain application programming interfaces etc]; Business Day • means a day other than a

A software audit occurs when a software supplier seeks verification that a customer’s use of licensed software is in accordance with the terms of the licence granted. This Practice Note provides guidance on: • the role of a software audit and the risk to customers • the factors that may trigger an audit • how to prepare for the risk of an audit • how the organisation undergoing an audit should conduct the audit • how the organisation undergoing an audit should react to the final report, including responding to unfavourable results and negotiations It also considers litigation relating to software audits. This Practice Note is based on the audit practices of leading international software suppliers. The guidance in this Practice Note should be applied and adapted on a case-by-case basis, as appropriate in the circumstances. The role of an audit and the risk for customers The audit notice Formal audit processes are usually initiated by the supplier sending a written notification, which may be sent by letter, email, portal

This Agreement is made on [insert date] (the Commencement Date) between the following: Parties 1 [insert supplier name] a company incorporated in England and Wales whose registered number is [insert company number] and whose registered office is at [insert registered office] (the Supplier); and 2 [insert customer name] a company incorporated in England and Wales whose registered number is [insert company number] and whose registered office is at [insert registered office] (the Customer), each of the Supplier and the Customer being a party and together the Supplier and the Customer are the parties. Background (A) The Supplier is [insert Supplier’s background details and the background to the relevant transaction]. (B) The Customer is [insert Customer’s background details]. (C) The Supplier wishes to develop certain Software (as defined below) and the Customer wishes to engage the Supplier to develop the same on the terms of this Agreement. The parties agree: 1 Definitions and interpretation 1.1 Words shall have the meanings given to them in this Agreement, including without limitation as set out below: Acceptance or Accepted • means in relation to any Software successful completion of the Acceptance Tests or deemed acceptance in accordance with this Agreement; Acceptance

Software development—in brief A software development agreement is used where a customer engages a software developer to design, develop, test and (sometimes) install and maintain bespoke software. The growing adoption of artificial intelligence (AI) tools, including AI-assisted code generation, large language models and machine learning, has introduced new considerations around development methodology, intellectual property ownership and fee structures that practitioners should address in these agreements. Software development is often a key component of systems integration agreements as well. These agreements cover the acquisition, development and integration of an entire IT system including hardware and software. The software component of the system often involves the development of a significant proportion of bespoke or adapted software by the developer or integrator. In both cases, the payment mechanism used to determine what fees are payable by the customer (and when) is an important component which (along with other contract provisions such as the limits and exclusions of the developer’s liability for contract breach, the calculation of liquidated damages for late delivery by the developer, and the

How to use this Checklist This Checklist sets out the key provisions to include when drafting a software development agreement. For additional analysis of points raised in this Checklist, see Practice Note: System development and systems integration agreements and Precedent: Software development agreement. Further specific issues are explored in Practice Notes: Software development agreements—fees, expenses and disbursements and Software development—agile method. This Checklist can also aid the drafting of a simple non-binding heads of terms. For assistance with this, see Precedent: Heads of terms—commercial contracts. The third column can be used to record observations or comments as the Checklist is worked through. Checklist Further information Notes (if any) Parties ☐ Confirm each party’s legal status and whether any third parties (such as group affiliates) will benefit from the proposed agreement. See Precedent: Parties clause. ☐ Confirm whether any third party will guarantee performance or financial obligations. Commencement and duration ☐ Confirm the proposed commencement or effective date. ☐ Confirm if there are any preconditions which must be satisfied before the proposed agreement can take effect. ☐

This Agreement is made on [insert date] (the Commencement Date) between the following: Parties 1 [Insert supplier name] a company incorporated in England and Wales whose registered number is [insert company number] and whose registered office is at [insert registered office] (Supplier); and 2 [Insert customer name] a company incorporated in England and Wales whose registered number is [insert company number] and whose registered office is at [insert registered office] (Customer), each of the Supplier and the Customer being a party and together the Supplier and the Customer are the parties. Background (A) The Supplier is[ an experienced software developer and] [insert the Supplier’s background details and the background to the relevant transaction]. (B) The Customer is [insert the Customer’s background details]. (C) On the terms of this Agreement, the Supplier will develop software for the Customer, and licence (or procure the licensing of) certain other software applications. The parties agree: 1 Definitions and interpretation 1.1 Words shall have the meanings given to them in this Agreement, including as set out below: Acceptance • means the successful completion of all Acceptance Criteria for all Acceptance Tests; Acceptance Criteria • means, in relation to an Acceptance Test, the criteria which must be met for that Acceptance Test to be successfully completed

Agile software development methods are now being widely used in the IT sector and are increasingly advocated as preferable to the traditional waterfall development model. However, contracting for agile software development projects remains a challenge. Most standard software development contracts were designed for use with the waterfall model and can be difficult to reconcile with the principles that underpin Agile working practices. What is Agile? ‘Agile’ is an umbrella term for a number of different software development models or methods (including Scrum, Extreme Programming (XP), Crystal Clear and Dynamic Systems Development Method (DSDM)). A detailed overview of these development models is beyond the scope of this Practice Note. However, for further information about how Agile development models work in practice, see Bird & Bird’s Position Paper: Contracting for Agile software development projects. Waterfall v Agile Software Methodologies—key distinctions The waterfall model The key feature of the waterfall model is that it is sequential—development of the software in a single process — the project is divided into a sequence of separate phases (ie design, coding, testing

Introduction Escrow is a process under which two or more parties place property, documents or other materials in the hands of a trusted third party, known as an escrow agent. The escrow materials are released to one of the parties only on the occurrence of an agreed release event, such as satisfaction of specified obligations or another party’s default. Escrow has become a widely available method of protecting the interests of both software licensors and licensees. Licensors may be unwilling to disclose commercially sensitive materials relating to the design and operation of their software. However, without access to those materials, a licensee may be unable to maintain or support the software if the licensor fails to do so. Depositing those materials in escrow, for release to the licensee following specified supplier failures, may therefore be acceptable to the licensor while protecting the licensee’s business continuity. This Practice Note examines the use of source code escrow, focusing in particular on when source code escrow is used and the key provisions of escrow agreements. Source code escrow Software is commonly described

This Checklist outlines key points to be considered when two parties are placing software in the hands of a trusted third party (an ‘escrow agent’). The software is released to one of the parties following an agreed release event, such as satisfaction of that party’s obligations, or failure of another party’s obligations. See also: • Practice Note: Software escrow • Escode Single Licensee Escrow Agreement • Escode Multi Licensee Escrow Agreement • Escode Multi Licensee Deposit Account Agreement • Escode Escrow as a Service (Access) Agreement • Escode Escrow as a Service (Replicate) Agreement • Escode Escrow as a Service Scale Agreement (Multi Customer Deposit Account) The third column can be used to record observations or comments as the Checklist is worked through. Checklist Further information Notes (if any) Recitals and parties ☐ Background and purpose of escrow arrangements. Set out the parties and purpose of the escrow agreement giving detail of the reasons why an escrow solution is being used. ☐ Details of licence grant. Set out details of the software licence to which the escrow agreement

This Checklist is aimed primarily at customers (licensees). It is intended to give an overview of the key terms usually found in a supplier agreement to license ‘on-premise’ software installed on the customer’s infrastructure. For issues related to the licensing and deployment of software as a service (SaaS), see Practice Note: Cloud computing—introduction and Precedent: Software as a service (SaaS) agreement—pro-customer. For further reading and template documents relating to this Checklist, see: • Practice Note: Key issues in software licence agreements • Practice Note: Warranties and indemnities in software licence agreements • Precedent: Software licence—pro-customer • Precedent: Software licence—pro-supplier • Negotiation guide—IT contracts Checklist Further information Notes (if any) Grant and scope of licence ☐ Is the software clearly and adequately described? The customer should be clear what it is contracting for. There may also be warranties from the supplier that the software will perform as described. ☐ Who has the right to use the software? Contractors and other group companies should be expressly included if relevant.See Practice Note: Key issues in software licence agreements—Licence grant and scope. ☐

This Agreement is made on [date] Parties 1 [Insert name of supplier], a company incorporated in [England and Wales] under number [insert registered number] whose registered office is at [insert address] (Supplier); and 2 [Insert name of customer], a company incorporated in [England and Wales] under number [insert registered number] whose registered office is at [insert address] (Customer), each of the Supplier and the Customer being a party and together the Supplier and the Customer are the parties. Background (A) The Supplier is the licensor of certain software applications. (B) The Customer is [insert details of Customer’s background/background to licence or relevant transaction.] (C) The Supplier has agreed to grant to the Customer, members of its group and certain authorised third parties a licence to use the software applications on the terms of this Agreement. The parties agree: 1 Definitions and interpretation 1.1 In this Agreement: Authorised Third Parties • means any third party (including agents and contractors) engaged to provide services to the Customer or to any Customer Affiliate including any supplier to whom the Customer or any Customer Affiliate has outsourced any part of its business; Business Day • means a day other than a Saturday, Sunday or bank or public

This Agreement is made on [date] Parties 1 [Insert name of supplier], a company incorporated in [England and Wales] under number [insert registered number] whose registered office is at [insert address] (Supplier); and 2 [Insert name of customer], a company incorporated in [England and Wales] under number [insert registered number] whose registered office is at [insert address] (Customer), each of the Supplier and the Customer being a party and together the Supplier and the Customer are the parties. Background (A) The Supplier is the licensor of certain software applications. (B) The Customer is [insert details of the Customer’s background/background to licence or relevant transaction.] (C) The Supplier has agreed to grant to the Customer a licence to use the software applications on the terms of this Agreement. The parties agree 1 Definitions and interpretation 1.1 In this Agreement: Authorised Licensees • means the [entities] identified in paragraph 6 of Schedule 1; Business Day • means a day other than a Saturday, Sunday or bank or public holiday in England; Commencement Date • means the date of this Agreement; Confidential Information • has the meaning given in clause 15; Description • means the description of the Supplier Software set out in paragraph 1 of Schedule 1; Force Majeure • means as defined in clause