While the customer of an IT development might understandably wish to assume most or all intellectual property (IP) rights in the eventual product, they should consider whether this is the best course, says lawyer Michael Wigley.
"What most customers really want is a product that works at a favorable price. Whether or not they own the IP is really secondary," Wigley says.
Generally, the customer will have no interest in further commercializing the IP, unless it is a government department or research organization or in the IT business.
"By owning the IP in the newly developed product, the customer may well be worse off. If the vendor or some other party which can commercialize the software is able to sell the IP elsewhere, then the customer should be able to buy the product at a cheaper price."
The "many eyes" theory, strong in open source circles, suggests that "as the product is rolled out to other customers, faults in the software are picked up more quickly and the product is more likely to be upgraded (in future). In other words, the customer is more likely to end up with a more robust and better product," Wigley says.
A significant objection to further distribution, of course, is that the vendor, granted ownership, may sell the product to a competitor of the original customer. Such consequences can be avoided at the start by specific restraints on subsequent sale being built into the development contract.
The complex of customer's legacy code, new code, developers' library code that the developer will wish to reuse and third-party code such as a database management system makes it a nontrivial task to disentangle in the case of a dispute who owns what, the lawyers say.
Wigley gave a summary of the Perry Group case, where the High Court said a gaming machine database developed within the context of a contracted development but not originally part of the specification still belonged to the client, Pacific Software Technology, including the library code developer Perry Group had brought to the project.
On appeal the library code was released back to Perry, effectively on an irrevocable license from Pacific.
The lawyers say it is wise to tie such questions down in the contract rather than leave them to copyright law as Perry did.
Customers who don't own the IP, and particularly the source code, are vulnerable to the collapse of the supplier and disappearance of support. This can be tackled by an escrow arrangement -- placing the source code with a trusted third party in the event of such a collapse. The third party should have relevant IT expertise, Wigley suggests, since the job will involve assistance with restoring and/or upgrading the application. Source code alone is of limited use to a customer, Wigley warns.
Material escrowed should also include details of software libraries, development tools used and documentation. As with any backup data, material in escrow should be tested. Escroweurope.com notes that between 10 percent and 40 percent of source code deposited with them fails to meet tests when evaluated. Wigley cautions that each agreement should be individually negotiated for the specific circumstances of each case.