Why Procurement of Intellectual Property Is Tricky...Until you Read This

My first couple of years in Procurement were spent in scientific organisations in the defence space, where I procured a lot of research. In other words, I was buying the intellectual property, or a right to use, the outcomes of research activities. I also dealt with Universities where we would fund Ph. D.s, get access, and use their results.

Sounds weird compared to a lot of traditional procurement out there, but coupled this with my contract knowledge and the couple of months I spent working in the Intellectual Property Team with some incredible patent attorneys means I know a little bit about the procurement of ideas. Additionally, many of you likely have procured Intellectual Property when procuring consultancy services, contingent labour, software development, or any analysis work.

My old notebook (some of these notes are from 2017) is full of my thoughts about the process, mapping out approaches, and the constant mention of the need to update spreadsheets (so gross).

Anyway, more about how this information is priceless to me in another piece. Let’s talk about Intellectual Property.

What is Intellectual Property?

The UK Government website offers a clear definition:

And when you put those creations down onto paper, onto your PC via code, a Word doc, or an article like this, you create an object protected, without any positive action, in copyright law.

Suppose I were to design a logo or a particular shape for a component. In that case, I’d need to seek the protection of that new asset of mine by applying for a trademark, a patent, or a design right, depending on what was more relevant.

Let’s use the example that you’re procuring the services of a consultancy that will come into your business, embed within your software teams, create code for a specific project that will be used in your SaaS application. They will be paid for such a service.

You need to consider the following:

The last thing you want is to pay a lot of money for the supplier to work on some code but for them to own that part of the code base in your product. I’ve seen sneaky and awful attempts to sneak in code owned by a supplier, for them to either receive a payment regularly for that code or to get a slither of ownership of the product their code lives within.

Additionally, we need to understand how that code was created and the methods used to create it.

So, let’s cover each of these points.

A requirement will usually follow an internal business case. The internal business case is always critical, and you must ensure that procurement has some input in your organisation.

I would always try to bring a sense of realism to the table around the deliverables in the business case, which, at times, especially in the scientific realm, can become lofty in ambitions but devoid of materiality.

I will use some simple examples here, as anecdotes can be helpful.

For the requirement, we want the following:

So, we have two requirements that set the foundation for what will be delivered here. But we don’t have a way to “get” that ownership of whatever work is undertaken. And that’s where we need to use our deliverables.

We cannot own or have the right to use a person’s brain. So, we need the people working with us to take their thoughts and ideas and craft a usable document or object that we can take with us.

With the research contracts, we could have the following deliverables:

Consultancy Services and Contingent Labour Services don’t differ much here.

You’d likely ensure you have a right of use or ownership over any work they create to fulfil the requirements. This is a wide and all-encapsulating contractual right but one that is regularly accepted (except for background intellectual property rights, which we will cover in a moment). However, we still have the challenge of needing a usable format for the deliverables. So, the intellectual property rights will be acquired through the:

You can apply this logic to just about any category where you are looking to acquire both the knowledge of the supplier and the physical outcome (whether that is a component or a code base).

There are typically two ways you want to obtain rights over the work performed (or the deliverables).

You want to be the owner outright, meaning all rights pass to you (the best practice for you would be to do this on creating the “thing”. The supplier will likely suggest that this should be done on payment. Push back on this, but if you don’t have the leverage, then create some highly incentivised payment terms.

Or you want a right to use the outcome in any way, anywhere, and transfer as you require. This is usually where you will spend time negotiating, but if your requirement is clear, there should be no issues around this…JOKES. This still will crop up a ridiculous amount of times, so get comfortable talking about it.

This can be tricky at times, but usually, you’ll never acquire ownership of this. However, there are two workarounds:

1 - The Supplier creates a deliverable that is removed from this and contains no background intellectual property but utilises their know-how. Sometimes, this is too difficult to get right.

2 - They provide a deliverable that includes this, but you get a right to use it and commercialise it as you see fit. Just ensure that you aren’t stuck with them forever if you need to make changes or upgrades, as I’ve seen suppliers use this to get locked in on the sly.

I don’t want to make these articles too long, so I’ll stop here. If you’ve got any follow-up questions, best practices, or different views, then please post those in the comments to help our community members.

Intellectual Property is one area I highly recommend you get “good at” as it can make a huge difference when buying if you have competency here.