Menu
Do you really need to own it?

Do you really need to own it?

What you need to know before you sign off an enterprise technology procurement

The standard approach by many organisations when they commission the development of something (or where it is created as a by-product of work paid for) is that they want to own that item. It is only natural to adopt this approach. After all if it is your money that has been spent creating it why shouldn’t you own it? While this may seem a rhetorical question, in trying to answer it we can develop a useful process to assess whether it is in an organisation’s best interest to own it.

Why own it?

Ownership of the intellectual property (IP) in a work will give you the greatest flexibility and control over what you can do with that work. For example, you will be able to copy it, modify it, sell it, assign it, give security over it, and license others to use it. But can these same rights be secured through a licence granted to your organisation by the person you have commissioned to develop the work?

Could the licensor get into financial difficulty?

In many cases, provided that the licence is sufficiently broad, it may leave the customer largely in the same position as an owner of the IP rights. I say “largely” as the rights of a licensee are still rights derived from contract, and therefore at risk of loss should the contract be challenged or should something happen to the licensor (such as insolvency). In these circumstances the rights of the licensee may be at risk of being set aside in favour of a party that has in good faith, paid good value for the rights.

Do you need the flexibility?

Assuming that the party you are dealing with is unlikely to get itself into financial trouble then a licence may suffice. If this is the case then you should consider what rights do you need to use the IP? What do you plan to do with it? Is it something that you will need to license to other members of your group or to third parties, such as your customers or service providers? Will you make a business out of it?

Before you insist on ownership think: What is needed? What risks are there if you do not own it? Is there a value that can be released if you do not own it? Are there benefits that you can secure if you do not own it?

For example if you have developed a new system to track customer behaviour, is this something you could use elsewhere in your group of companies? Could it be used for other purposes in the same industry or the same purpose in different industries? If you can be confident that you know the full range of uses, it might be that a licence is all that is required.

However you will also need to ensure that the licence is sufficiently broad to enable you to do all that you need. To the extent that you are unsure, the licence should be as broad as possible. Remember though that broader rights might come at a cost. To the extent that you might find you become a competitor to the developer, then the developer may price this into the charges it seeks for the development. So flexibility comes at a price.

Does it deliver a competitive advantage?

Generally when something is developed the person commissioning it feels that they are breaking new ground. They feel that this development will give them an edge over the competition because it is something that is not generally available. This should be tested each time. Is this something that will deliver an advantage? If so will it always deliver this advantage or is it something that will be caught up in relatively quick time? Can any competitive advantage be protected through an exclusivity arrangement? For example, would it suffice if the developer is restricted for a specific period of time from licensing others in your line of business or others in New Zealand so that you can be the first to market? By limiting the focus of the restriction you allow the developer to re-use and perhaps through this secure cost savings for the project.

Are there costs to ownership?

As already alluded to above there can be costs for the customer when they seek to own the creation. These can arise in a number of ways. The developer may load a cost (or not deliver a cost saving) equating to the perceived opportunity cost of the developer not being able to commercially exploit the creation.

Equally if the customer is going to own the creation then the developer may not want to use tools or components that it has used elsewhere or may be able to use elsewhere. This is because once the creation is owned by the customer any such re-use will be prohibited as it breaches the customer’s IP. (Unless of course the developer secures a licence to re-use.)

Finally there is likely to be a support cost to having ownership of the creation. To the extent that the creation is a modification to an existing product (or to the extent it is a standalone product) it will not become a standard offering and so any future developments by the developer will not include the creation in the development cycle. If it is modification to a product then the modification will not be taken into account when the product is upgraded and so the cost of changing the modification so the latest version of the standard product can work with it will fall to the customer. If it is a standalone product the developer is unlikely to develop new versions of improvements to it as there is only one customer.

It is not a given that ownership of IP in a new creation is the best thing. Before you insist on ownership think: What is needed? What risks are there if you do not own it? Is there a value that can be released if you do not own it? Are there benefits that you can secure if you do not own it?

Simon Martin is a partner at Hudson Gavin Martin, an IP and technology law firm.

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags SLAcontractEntrepreneurial IT Leaderslegal insightSimon Martin

More about Hudson

Show Comments