Although there are many aspects to consider when drafting software development contracts, I have decided to draft my top 5 as they are the critical aspects that I have seen developers overlook or not properly address in their development contracts. These tips for software development contracts are therefore not an exhaustive list.
Scope of Works
It is essential to have the scope of works properly described before development commences. In software development contracts, the scope of works usually attaches as a schedule to the contract itself – and therefore forms part of the contract. Without a proper scope of works completed there is a risk of significant project creep.
Preparing a scope of works can be difficult, as software developers regularly use Lean methodology (Build, Measure, Learn) when developing software applications, therefore, the exact scope of many software development projects cannot be defined precisely from start to finish.
Methodology
If your company is completing the scope of works, you should describe how the scope of works will be carried out. For example, if you are using Lean Software Development methodology you should identify whether you are using Scrum, Extreme Programming or Kanban.
Given that many software developers follow Lean methodology – build, measure, learn – the project scope is meant to change through iterations. I mean, we’re not building a house here, we’re building software. Because developers often create a prototype, get some feedback, change the specs, create version 1 of the software, get more feedback and iterate some more, it is often difficult in the real world to draft the exact specs right away.
That is why it is critical to ensure that the contract terms facilitate the software development methodology that is being used, whether it be Kanban, Extreme Programming, Scrum, etc. All of the iterations must be considered and how they will be carried out. The contract needs to facilitate the interactive approach. There is an art to developing a contract with the development methodology in mind. This is where a lawyer with a technology background (shameless plug) can facilitate an agreement that helps the project move along slowly, rather than a ‘building and construction type’ contract that is fixed and archaic.
Intellectual Property
Having the right clauses in place for the assignment of IP is critical. The IP that is being transferred must be properly identified and exactly when it is transferred. Ideally, the intellectual property in the source code should be assigned upon the completion of the contract. Software developers should be aware that if the client is drafting the contract, savvy technology lawyers will draft the contract so intellectual property passes to the client upon its creation.
Further, there is more intellectual property than just source code that may need to be assigned. If your company is creating graphics, videos or animations those artistic works should be identified in the software development contract. You also should decide whether the scope of works document itself also vests in the clients.
Once you identify the intellectual property that is to be assigned, you must determine when it is to be assigned. Most companies assign the copyright upon final payment, while some software companies require a certificate of assignment and payment before IP assigns to the client.
Software development contracts that are prepared by the client, sometimes contain clauses that assign intellectual property, including copyright, upon creation. This can be problematic for software developers, as such clauses could mean that developers must hand over the code (and ownership) before the final payment is made.
Indemnities
Drafting indemnities are always a tricky part of negotiating any contract. Although you need to be indemnified, it is important to know what you want to be indemnified for. For example, if the client insists on using a third-party software application as part of your software or to integrate into a third-party application into your software, the client must indemnify you for anything that goes wrong with that software. For example, if the third-party software’s API is not properly documented – or insufficient for the required purposes, then indemnities must be drafted to protect your company from things outside of your control such as the operation or availability of third-party services or software.
Other important areas of indemnification include that for data loss, the delay that is caused by contract variations, and scheduled maintenance.
While we’re on the topic of indemnities, and if the client is drafting the contract, be sure to check that it doesn’t bind the directors to the contract in their personal name. Client-drafted software development contracts often bind the directors personally, by including the director in the definition of “Contractor” or otherwise nominating them as a ‘key person’ in the contract, which holds significant personal responsibilities. That is a significant issue that could put you and your personal assets at risk.
Restraints
Restraint clauses can predominantly be found in employment and business sale contracts. The difference in enforceability was described in Just Group Ltd v Peck (2016) 344 ALR 162:
“A court takes a ‘stricter view’ of restraint clauses in employment contracts; and will more readily uphold a restraint clause in favour of a purchaser of the goodwill of a business than a restraint clause in favour of an employer. In particular, a purchaser of a business is entitled to protect itself from competition by the vendor; but an employer is not entitled to protect itself from competition per se by an employee.”
It is difficult for employers who want to restrain their employees from working for their clients or their competitors, as being restrained from working on a particular type of software or within a specific industry, is likely considered against public policy. However, restraints can prevent clients from poaching coveted coders from the developer’s team. Therefore, it is important to put restraints in software development contracts so the hardworking developers don’t get seduced by offers of a cushy job in the client’s head office. It makes for an awkward situation that you must avoid.
Further, the skills and experience that were gained during employment cannot be restrained. In Esso Petroleum Co Ltd v Harpers Garage (Stourport) [1968] AC 269 at 298:
“a former employee may, for his own and for the public benefit, use skill experience and know how acquired in the service of the employer in legitimate competition”
You should also limit client contact with the developers where possible. All communications are to go through the project lead – that’s a rule.
