Key Considerations in Commercial Software Development Contracts

03 April 2018

Dharma Sadasivan

Commercial software development contracts (otherwise known as software service agreements) have some unique considerations that other commercial contracts may not have. This is a brief primer on some key issues that you should think about when entering into such a contract, whether you are the software developer (the "Developer") or the client looking to onboard the software (the "Client").

Background
 
Commercial software development contracts set out the terms of software development projects, and the projects themselves can be thought of as comprising two parts – the development phase and the maintenance phase.
 
During the development phase, the Developer "develops" the software solution (the "Solution") for the Client. Most Developers are turnkey solution providers – i.e. they have a standard, generic platform (the "Platform") which provides a framework for their software solution, and a library of modules that provide various functions, which can be integrated into and run on the Platform (the "Modules").
 
The Platform and Modules can be customized or modified in various ways to allow for customized user interfaces and experiences, company workflows, industry practices, color schemes, white labelling, etc. If completely new functions are needed, these can also be developed from scratch to run on the Platform ("New Modules").
 
The Solution therefore comprises the modified/customized Platform and Modules, as well as the New Modules (where required).
 
The maintenance phase follows the deployment of the Solution. During this phase, the Developer provides service support to the Client. This may include fixes for bugs, support in response to unscheduled downtime, security patching, upgrades to the Solution, etc.
 
Key considerations
 
Against this backdrop, the following are some key considerations that parties should resolve during their contract negotiations:
 
Ownership of Intellectual Property: Each party typically tries to lay claim over the Solution, or as much of the Solution as possible. A Developer will want to retain ownership of the intellectual property in the Solution so that it can reuse the Platform and Modules for future projects, and ordinarily will seek to retain ownership of the intellectual property in the New Modules so that these can be added to its library of Modules. Meanwhile the Client will want to ensure that it has the unfettered right to use the Solution freely and as needed, without the Solution being held hostage by the Developer. The Client will also want to ensure that it can use the Solution if anything happens to the Developer, such as the Developer becoming insolvent and winding up.
 
User Acceptance Testing: A robust User Acceptance Testing ("UAT") process should be detailed in the contract to provide clarity on whether and when a Client has accepted the Developer’s work. This will help minimize disputes over performance and acceptance of the work. A detailed UAT process can also help to clarify how and when payment milestones are met.
 
Security vs Confidentiality vs Personal Data Protection: These are discrete concepts that should not be conflated, although they often are – much to the confusion of the parties later on.
 
"Security" relates to operational processes that ensure the protection of whatever data is being protected. Security clauses should therefore set out the various operational obligations that a party must undertake in order to have adequately protected the data in question. For example, a party may be required to store data on a private cloud server based in Singapore only, with any changes to this arrangement being subject to the prior mutual agreement of the parties in writing.
 
"Confidentiality" relates to the legal obligation to keep data confidential. Confidentiality clauses should identify what sort of data the parties will treat as confidential (e.g. employment data, business plans, trade secrets, etc), as well as any exceptions (e.g. data legitimately obtained from a third party).
 
"Personal Data Protection" relates to the protection of personal data, which is regulated in Singapore by the Personal Data Protection Act 2012 ("PDPA"). Other jurisdictions may have their own personal data protection frameworks requiring compliance. Under Singapore law, personal data is data that, whether true or not, can be used to identify an individual on its own or in combination with other data that an organization may have or be likely to have. Examples of personal data include financial information, health records, mobile phones, personal email addresses, names, NRIC/passport numbers, photographs, and video recordings.
 
Some of these concepts may overlap. For example, personal data is often classified as a type of confidential data, which may in turn be subject to certain security protocols. However to ensure that the three concepts are not conflated and their corresponding obligations are clear, each should be dealt with separately.
 
Indemnities: An indemnity is a promise by the indemnitor to assume the liability falling on the indemnitee under certain circumstances. An indemnitor should therefore be circumspect about providing indemnities, and carefully restrict the circumstances under which an indemnity arises.
 
That said, it is quite common for reciprocal indemnification clauses to be used in software development contracts because Developers want to protections against building their software in reliance of information that the Client may not have obtained legitimately, while Clients want protections against using software that the Developer may have plagiarized, or for which the Developer did not obtain the proper third-party licenses.
 
Exclusions and Limitations of Liability: Parties will generally try to exclude liability were possible, but the parties should also consider and negotiate the scope of any limitations of liability to manage their risk in case the exclusions fail or do not apply.
 
Disputed payments: Parties should always consider how they will handle disputed payments, particularly because software development projects are often based on achieving milestones. There are a variety of ways to structure a disputes payment process, but the primary point of negotiation is often whether a disputed payment should be paid upfront and then reimbursed (if needed) upon the adjudication of the dispute, or if the disputed payment should be withheld pending the conclusion of the dispute.
 
Source Code and Escrow: Source code can be a point of contention between Clients and Developers, as Clients will want to ensure they can continue to use a software platform that they have paid for, while Developers want to protect their business by ensuring they do not give away so much source code that their Solution can be replicated by their Client or competitors servicing the Client. A common solution to this is to hold the source code in escrow, to be released only under certain circumstances. As such, the parties need to carefully consider what “trigger events” will release the source code and whether their interests are protected in those scenarios.
 
One common trigger event is for source code to be released if the Developer is winding-up, on the basis that in such circumstances, the Developers will already be ceasing business so there is no longer anything to be gained by them in protecting the source code.
 
Termination: Termination clauses should always be embraced rather than feared, and particular attention should be paid to these clauses if you are the Client. Key issues include who has termination rights and how to exercise them, payments that may crystalize upon termination, and migration of data out of the Developer’s platform.

​
Dharma Sadasivan
Associate Director, BR Law Corporation
[email protected]