Traditional wisdom has it that if one company commissions another to develop an IT solution then the client – not the developer – should own the software that's created. As a result, countless hours of contract negotiations are spent on arguing about intellectual property rights (IPRs) ownership.

But, as is so often the case, traditional wisdom is (mostly) wrong. So why do we waste our time when we all have better things to argue about?

Well, to start with, there's a lot of value in IPRs. It's not wrong to care about IPRs. For a technology business – or, indeed, even a non-technology business – IPRs represent value. I only have to look at the dozen or so technology company buy-outs that I've worked on in the past couple of years to see that IPRs are prized – and priced – highly.

Any form of IPR – whether patent, copyright, trademark or design – represents in effect a form of legalised monopoly or exclusive right to use a particular product, invention, work or brand; and, more importantly, the right to prevent others doing so.

But, too often, moral righteousness gets confused with commercial reality when it comes to issues of ownership of IPRs. We instinctively feel that if we pay someone else to develop a product or create an artwork or write software, then we ought to "get" what we pay for: and we draw a direct link to insisting on ownership.

I don't dispute that, for some types of IPRs, that approach may still be correct, but I doubt whether it remains true in most cases in relation to ICT-related IPRs such as copyright in developed software. In almost every case nowadays, a client can obtain virtually all the benefits of IPR by taking an appropriate licence – and can do so more cheaply, more effectively than by insisting on ownership.

The real questions to ask when negotiating an IPR arrangement is: what do I need to do with these IPRs? And do I really want to prevent you doing anything with it?

Take the scenario of a software provider engaged to develop a customised application. Almost always, that development will be simply a layer of programming that sits, like icing on a cake, on top of a provider's standard offering or standard toolkit. In almost every case, the custom app development will not be able to function without the underlying program. So whatever has been developed is likely to be of little or no useful purpose without the underlying base product. If the customer insists on owning the developed application, it's likely that the provider will be less able to guarantee the quality of what's developed, it will try to create a standalone product that doesn't integrate well with its underlying base product, and the resulting development will be less able to be supported in an appropriate way during its life.

The customer really ought to forget about ownership and insist on a very wide licence to use and modify what's developed together with an ongoing licence to use the base layer of software for all its business purposes. If it has that, then it essentially has secured a complete protection in terms of value of the product itself. Additionally, the service provider is incentivised to create something that's fully integrated and, because it will own the developed application and so may have the ability to use it elsewhere, it will be able to factor in future reusability into the cost of development. So the product ought to be cheaper and better.

In most cases, the customer really ought not to care whether the developed product is used for third parties. Admittedly, that's not always the case and I can think of examples where financial institutions are concerned to retain a competitive edge over the competition. But that's usually fairly short-term and doesn't last more than a number of months and can usually be covered by restrictive covenants on the provider not to recycle the developed software application for a period of time. But even then, there's no copyright in ideas so a general concept that's been developed is unlikely to be prevented from leaking out anyway.