The building blocks of a Master Software Development Agreement

In this article, we have a look at some of the important aspects that must be kept in mind when drafting a Master Software Development Agreement

The Master Software Development Agreement provides the framework within which the Customer engages the Developer.

The Parties to the Master Software Development Agreement will also agree on Statements of Work which detail the Service that the Developer will provide.

 

The Master Software Development Agreement can be agreed to before any Statements of Work are concluded.

Building blocks

Building blocks of a Software Development Agreement

The scope will typically include the general terms of engagement which may include the design, development, creation, testing, delivery, installation, configuration, integration, and customisation of the Software.

 

The scope may also address general support, maintenance, and training the Developer will need to provide to the Customer.

For larger projects, it is important to have structures and processes in place to manage the contract effectively. 

 

Under contract management, change control will be dealt with - For example, how the process will work if a change to the agreed Specification is required.

 

The Parties may also agree to establish a Steering Committee overall supervision of each Party’s performance and the direction of the activities under this Agreement.

The Developer is responsible for delivering the Software Deliverables as per the Statement of Works, which may detail certain Functional and Technical Specifications.

 

Testing needs to take place to ensure that the Software meets the Specifications agreed to.

 

The acceptance testing provisions will detail the process that must be followed after delivering a Software Deliverable, what happens if there are Non-Conformities, and what if there are repeated failures of Acceptance Tests.

The Software created will constitute intellectual property which the Customer generally owns. However, the newly created intellectual property is usually not the only intellectual property that must be dealt with in the Master Software Development Agreement.

 

To create the new intellectual property, the Developer needs to use its know-how, existing software and other intellectual property (Background Intellectual Property) to create the new intellectual property (Foreground Intellectual Property).

 

The Master Software Development Agreement will need to stipulate the terms of the Background Intellectual Property licence that the Developer will provide to the Customer to enable the Customer to use the Foreground Intellectual Property without any infringement.

 

Read more on building intellectual property clauses.

The payment provisions will detail payment terms, overdue amounts, method of payment, setoff, taxes, payment disputes etc.

 

Read more on payment clauses.

Both Parties would generally want to protect such sensitive information, which, if disclosed to certain third parties, will be detrimental to their business. The confidentiality provisions provide which information must be regarded as confidential, obligations relating to handling confidential information, and what happens if there are unauthorised disclosures.

 

Read more on confidentiality clauses.

Unrecoverable losses and maximum liability are generally dealt with under the limitation of liability provisions. Unrecoverable losses may include, for example, consequential losses, and claims relating to breach of data protection provisions may be limited under the maximum liability amount to a fixed amount.

 

Read more on the limitation of liability clauses.

The Customer and Developer will usually provide certain mutual warranties. These may include, for example, that they have the legal capacity to enter into the Agreement and that they have not offered unlawful or prohibited inducements to the other Party or any other person in connection with the Agreement.

 

Then there will also be warranties that relate to the Software.

Typical warranties will include that the Software will perform in conformity with the Specifications, it will not contain viruses, it will not contain any copyleft licences etc.

 

Breach of the warranties will also need to be addressed, and the disclaimers which will apply will also need to be included.

 

Read more on warranty clauses.

An indemnity that you will often find in Master Software Development Agreements is an indemnity relating to Intellectual Property infringement claims.

 

The indemnity provisions need to identify what will be regarded as indemnified losses (what will be covered), what will trigger the indemnity and the claims procedure.

 

Read more on indemnity clauses.

The Developer may be required to take insurance against, for example, cyber crimes. The insurance provisions should detail the type of cover to be taken out, the amount of cover required, what happens if there is a failure to maintain cover and obligations to produce certificates confirming cover. 

These clauses may give the Customer "early warning" of trouble. If the Developer faces financial instability, it could tumble into bankruptcy, and it could lose the will or ability to perform vital services. But if the Customer sees that trouble far enough in advance, it can protect itself—by terminating the contract, retaining another developer,  taking back the data, etc.

Technology is evolving at a rapid pace and a Customer may want to have the right to benchmark the Developer's performance and price.

 

If found that the Developer does not meet die benchmarking requirements, the clause may provide certain remedies to the Customer.

 

Whether or not such a clause will be included will depend on the respective bargaining power of the Parties.

The Developer may want to include Personnel and Non-Solicitation clauses to restrict the Customer from "poaching" their employees.

 

Read more on Personnel and Non-Solicitation clauses.

For a Customer, it may be difficult to determine whether or not the Developer is executing their obligations under the Agreement. Audit rights allow the Customer, or their authorised representative, to conduct certain audits.

With the audit clause, aspects often addressed include notices of audits, the number of allowed audits, confidentiality and what happens if there is an adverse finding.

The Parties may conclude the Master Software Development Agreement for a fixed term. There may also be auto-renewal of the Term, which must also be detailed within this section.

 

The termination provisions detail when a Party can terminate the Agreement before the Term ends and may also provide for termination assistance the Developer must provide if the Agreement is terminated.

 

Read more on term and termination clauses

How will the Parties deal with disputes? Through a Court process or alternative dispute resolution? Are there different processes for different disputes - For example, expert determination for disputes relating to technical aspects of the Software?

 

Read more on dispute resolution clauses.

The boilerplate clauses will include the provisions relating to public disclosure, third-party beneficiaries, how amendments will be dealt with, how notices under the Agreement must be provided, assignment etc.

 

Read more on boilerplate clauses.

FAQs

A Master Software Development Agreement is a framework agreement that goes hand-in-hand with Statements of Work (SoW).

 

The Master Software Development Agreement contains general terms and conditions applicable to the transactions. On the other hand, the SoW contains more specific information relating to the Software that must be developed. For example, the technical and functional specifications, timeframes, fees etc.

 

A Master Software Development Agreement allows for a more agile process where various "sprints" are undertaken to complete a project. Each "sprint" with its respective milestones and dates are agreed and documented as separate SoWs.

 

With a "standard" Software Development Agreement, the specifications of the project is fixed at the signing of the Agreement or agreed during a "consultation phase" preceding the start of the project.  

"Source Code" is the code that a developer writes to program an application/website. This code is "human readable" and this is the code that you want to protect.

 

"Object Code" is "machine-readable". In other words, it is numeric code made of binary numbers such as 0s and 1s and is understood by a machine. 

 

For a more detailed explanation on Source Code vs. Object Code, have a look at this article

Incorporating Open Source Components as part of Software certainly helps when developing Software and means that there is no need to "reinvent the wheel" when it comes to certain component of the Software.

 

However, Open Source can cause problems down the line for the Parties. Certain types of Open Source Components carry copyleft licences.

 

A copyleft licence requires that the Customer use the licence model if it redistributes the Software. In other words,  if the Open Source Component is inserted into the Software, the Customer may (depending on the Open Source Licence) be required distribute the Software with source code and the right to modify and redistribute. Obviously such a scenario may have far reaching consequences for a Customer and for this reason Open Source Components must be appropriately addressed in the Software Development Agreement.

In addition to Open Source Components, Developers may leverage other software (for example, through integrations) to develop the Software. 

 

The Third Party software may provide for certain functionality required for the Software, but may carry it's own terms when using the Third Party software. For example, you may use and embed the Third Party software as part of your Software, but You may only use it for internal business purposes. If this is the case, you will have problems when commercialising your Software. 

 

Furthermore, it is not necessarily only Third Party software that can cause problems, and using Third Party documents, data, know-how, ideas, methodologies, specifications, software, content, and technology, in any form, may have the same implecations for the Customer.

 

For the above reason, it is important to adequately address the use of Third Party Materials in the Software Development Agreement.

The Author

Martin Kotze

Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries. 

He is also one of the co-founders at DocNinja and regularly advises companies on how to contract better with their customers and vendors. 

This is a free 30min consultation to better understand your business and your needs.

Table of Contents

Schedule a call with a Solutions Specialist

martin@docninja.io

+27 82 891 3029