There can be pitfalls in ordering bespoke software. One is control of the source code of your application. This can be complex. The biggest issue is ongoing support, but there are three issues:
Some software is written in compiled languages, like C++. The programmer writes what is called source code in, say, the C language. This is then compiled into an executable (exe) file. There are other languages. For example, most web applications are written in languages like PHP and Java Script. In these cases the source code is deployed unchanged. In such cases, you should be able to access the source code from your web server. However, some web sites are generated by software like Adobe. You may find in these cases that you do not have access to the source code and the site can only be changed by the holder of the source code.
Support and maintenance
This often causes major problems. You commission some software, install it, sign it off and pay for it. You then find the software house charges high fees for any extra work on the application. Many software houses adopt this approach. Others consider it to be unethical.
The worst problems occur after disagreements. If you fall out with the supplier, and this happens far too often, you will be stuck. You may have to order new software. Even taking data from the old software can be difficult.
To overcome this, the contract should clearly state that the software company must make the source code available to you, or at least to a third party. It must also state that the source code must be handed to the client at the end of contract.
This will only normally arise if you or the software company decides to sell your application as a package. The legal issues are complex, but, in the absence of a clear agreement, it is quite likely that the software house would own the copyright of the source code.
If there is any possibility that you would want to market the software, this should be discussed before the contract is signed. In fact, many software houses (including McMillan) would be very happy to collaborate with you in marketing a package. This needs to be made clear at the outset.
But what about the software house using parts of the code in other contracts? In reality it will be difficult to stop this, and in any case you would be unlikely to be able to profit if that did happen. It does help to check before agreeing to the order.
Software houses do sometimes go out of business. If this happens and you don’t have access to the source code, you will be in trouble. Escrow agreements are common, and state that an up to date copy of the source code must be deposited with a third party.
Some care needs to be taken in drafting the terms of the escrow agreement. By default, the source would probably only be released following the commercial failure of the supplier. The author’s view is that it should be released at the end of contract.
Summary: useful contract clauses
Apart from normal terms and conditions, the contract should:
- Define the copyright
- State that at the end of a maintenance agreement, you will have full access to the source code.
- If the supplier is not prepared to deliver the source code to you, insist that an escrow copy is deposited with a third party. Also insist that you have the right to access this at the end of a maintenance agreement.
Problems are more likely to occur with larger software houses. Smaller ones need to be more flexible and they will need you as much as you need them. So negotiation will be simpler and you won’t need anything like as much access to lawyers.
About the author
John McMillan is a software developer based on the Essex Suffolk border in England, close to Cambridge and North East London. He writes business programs to order, his applications have carried out many business functions.