For most tech companies, intellectual property is the business. It's what gives the product its value, what investors have decided is worth investing in, and what any potential buyer will want to be confident about before completing a deal. And yet IP is consistently one of the areas where clarity of ownership hasn't kept pace with how the company has actually grown.
This article explains the most common IP ownership issues that arise in due diligence on tech businesses, why these issues can create real problems for any potential sale (as well as for new contracts), and, more usefully - what you can do about it now.
The Core Question: Does the Company Own What It Thinks It Owns?
This sounds like it should have an obvious answer. It often doesn't.
The nature of a technology business means that IP ownership is often created over time, by multiple people, in a variety of circumstances. Code gets written, products get built, brands get used, websites get updated. But the legal question, who actually owns the rights, depends on the specific facts of each situation. Default legal rules don't always produce the result business owners assume.
Under English law, the Copyright, Designs and Patents Act 1988 (the “Act”) provides that the creator of a work owns the copyright in it (don’t worry, we won’t be delving into the detail). Employees are an exception: where someone creates something in the course of their employment, the employer generally owns the result. Contractors and freelancers, however, are treated differently.
The Contractor Problem
Increasingly, tech businesses use contractors, freelancers or agencies to perform development work. This often makes sense, particularly when working within budget constraints. However, under the Act, where a contractor writes code for your business that contractor owns the copyright in any code they create unless there is a written agreement that explicitly assigns ownership to the company. A verbal understanding will not suffice, nor will any other document that merely describes the services provided. Even a contract that says the work is done 'for' the company, or that refers to 'work for hire', does not transfer ownership under the Act - unlike in the US, the concept of work for hire doesn't operate in the same way here.
For clarity: without a specific written assignment, the code belongs to the contractor. The company may have a licence to use it, but that's not the same as owning it, and the scope and durability of that licence will rarely be clear.
In practice, this means that some tech businesses have built products on somewhat shaky foundations. That matters at any time, but it matters especially when investors or acquirers start asking questions about the chain of title.
It may be fixable but it will require contacting former contractors to obtain retrospective assignments. Many will cooperate if you approach it correctly, but it takes time, and some may be harder to locate or less willing than you'd like. It can be a painful process, but the earlier you address it, the easier it is.
This doesn’t just relate to your product. If you have used a marketing agency or website designer to build your website, you should ensure you have appropriate ownership rights - or have at least considered what you want to own at the outset of the relationship.
Founder IP: What Happened Before the Company Existed?
This can catch businesses off guard more often than you might think.
It is common for a founder to start building the product, or at least the early concept of it, before the company was incorporated.
As mentioned earlier in ‘The Core Question’, any work undertaken prior to incorporation belongs to the individual. It will only belong to the company once the founder executes an IP assignment - a document that formally transfers any relevant pre-incorporation IP to the company. This is something that should happen at formation, but it often doesn't because early-stage companies are moving fast and legal housekeeping falls behind. If it hasn't been done, it needs to be dealt with as soon as possible.
Most founders are surprised by this. They set up the company, they put the work into it, they built the business. The idea that the legal ownership might not have transferred is counterintuitive, but it is question investors will ask, and the answer should be clear.
Open Source: Useful, but Not Without Risk
Most tech products incorporate open source software in some form. That's entirely normal but not all open source licences are entirely free to use and may come with risks.
The licences that tend to cause concern in due diligence are so-called 'copyleft' licences - particularly the GPL family. These licences contain provisions that, in certain circumstances, require you to make the source code of your own product available under the same licence. Whether and to what extent that obligation has been triggered depends on how the open source component has been used and integrated.
Investors will ask about this. Their concern is whether a copyleft obligation could affect the value or exclusivity of the product. The honest answer in most cases is that the risk is manageable, but you need to know what open source is in your stack, under what licences, and how it has been used.
An audit of your dependencies - including transitive dependencies, not just the direct ones - will tell you what you're working with. Some businesses have done this; many haven't. If you're using a package manager, the information is generally accessible, but interpreting the licence implications requires some care. If you can manage an audit, we also recommend putting in place a policy for the use of open source software, with escalation requirements if any of the licences with ‘copyleft’ elements are used so that there is oversight and understanding of what they might affect within the business.
Employee Inventions and Side Projects
Employment contracts for technical staff should include provisions dealing with IP ownership, confirming that any IP created in the course of employment belongs to the company. Most modern contracts for employees in any position do include this, but older contracts, informal arrangements, or contracts adopted from templates may not be adequate.
There's also a more specific issue worth mentioning: where an employee works on something in their own time, using their own equipment, in a field unrelated to their day job, they may have an arguable claim to own the result and many employers would not wish to contest this. However, the dividing line isn't always obvious, and there's a related risk where a technical employee is simultaneously working on a side project that could eventually compete with or be confused with the company's own product.
None of this needs to generate anxiety - it’s all about awareness. It does mean that employment contracts for technical staff should be reviewed with some care, and that any known situations involving side projects or pre-employment work should be addressed before they become an issue in due diligence.
Registered IP: Trade Marks, Patents, and What You've Actually Protected
In the UK, copyright arises automatically; you don't need to register it. However, there are other forms of IP protection which do require registration, and many tech companies have either done this incompletely or not at all.
Trade marks protect brand identifiers: names, logos, slogans. If you haven't registered your trade mark, you may have common law rights through use, but these are harder to enforce and don't offer the same clarity as a registered mark. On a practical level, an unregistered trade mark can create uncertainty when investors ask about brand protection.
Patents protect technical inventions, and they're relatively rare in software businesses, not because software can't be patented, but because the bar to patentability is high (you would have to demonstrate the software makes a substantial technical contribution and could not be deemed a ‘next step’ in its area of application); the process of patenting requires publication of the details of the software (which you may wish to keep secret); and the process is expensive and slow. Most software businesses don’t need them but if you think there is a genuinely novel technical innovation at the core of what you've built, it's worth taking advice on whether patent protection makes sense.
Domain names, design rights, and database rights are also worth considering, depending on the business. By no means should you be considering registering everything, but you should have a clear and accurate picture of what protection exists for your product and IP in general and where the gaps are.
Third-Party IP in Your Product
The due diligence process will also consider whether any third-party IP is incorporated in your product or in use elsewhere in your business that requires a licence - for example, licensed software components, APIs with commercial terms, stock imagery, design assets, and data feeds.
The relevant questions are where licences are in place, whether they're adequate for commercial use, and whether there are any restrictions that could become relevant on a change of ownership. Some licences are personal and don't automatically transfer if the company is sold. Some have volume or usage limits that the business may have grown beyond, so part of any IP audit will be to review existing contracts. You may find that some of your licences prohibit sub-licensing, or embedding in a commercial product in the way the company is using them. It is better to address this before it is flagged as an issue in due diligence, where it could reduce the value of your product or business.
Most businesses have some licences to tidy up or confirm. But knowing about them in advance means you can address them calmly rather than at pace during a deal.
What to Do With All of This
An IP audit doesn't need to be a large or especially expensive exercise. What it requires is a methodical review of how the product was built, who built it, what agreements were and are still in place, and what third-party components are involved. Experienced legal input helps because the issues that matter, and how material they are, aren't always obvious without context.
The businesses that get through IP due diligence smoothly are generally not the ones with perfect IP positions - it's rare for any growing tech company to have everything completely in order. They're the ones that understand their position, have addressed what can be addressed, and can explain the rest clearly.
If you haven't looked at this recently, it's worth doing before you need to. A deal process is an uncomfortable time to be discovering gaps.
This article is for general informational purposes only and does not constitute legal advice. If you would like to discuss your specific situation, please get in touch with the ClearCube team at hello@clearcube.law