Software dos and don’ts: patents, copyright and licensing

Gary Whiting has been a patent attorney for more than 20 years, with almost half of that time spent in-house. Based on his experiences, Gary has outlined seven top tips for successfully navigating the IP world, when software developers are looking to patent their technology.
Software businesses often move quickly. A developer spots a problem, builds a tool, improves the code, tests the product and starts thinking about customers, funding or commercial partnerships.
That speed is useful. It is also where intellectual property issues can be missed.
Many software developers assume that copyright will protect everything that matters. Others believe software cannot be patented at all. Some rely on open-source components without fully considering the licence terms. These assumptions are understandable, but they can create problems later, especially when a business starts looking for investment, licensing opportunities or an exit.
So, can software be protected by IP? Yes. Software can be protected through a combination of copyright, patents, trade marks, registered designs, trade secrets and contractual rights. The right approach depends on what the software does, how it creates commercial value and how the business plans to use it.
This guide explains the key software IP dos and don’ts for developers, software companies and technology businesses.
Key takeaways for software developers
Software IP is not just about copyright. Copyright may protect the code itself, but it will not always protect the underlying idea, technical process or commercial advantage behind the software.
Software may be patentable in some cases. In the UK and Europe, software “as such” is not usually patentable, but computer-implemented inventions can be protected where they provide a technical contribution.
Open-source software needs careful handling. Some licences are permissive, while others may place restrictions on how software can be used, modified or commercialised.
Ownership should be clear from the start. If contractors, consultants or external developers have helped create the software, the business should make sure the relevant IP rights have been properly assigned.
A strong software IP strategy should support the commercial plan. The right approach for a SaaS business may be different from the right approach for a company developing AI tools, embedded systems, cybersecurity software or technical algorithms.
Do consider every type of software IP
A common mistake is to think that software IP begins and ends with copyright. Copyright is important, but it is only one part of the picture.
Copyright can protect source code, object code, manuals, written documentation and certain original materials created during development. However, it does not usually prevent someone else from independently creating software that performs a similar function using different code.
That distinction matters. If the real value of the product lies in how it solves a technical problem, how it processes data, how it controls a device or how it improves performance, copyright alone may not be enough.
Other rights may also be relevant. Patents may protect certain technical software inventions. Trade marks can protect the product name, platform name or company brand. Registered designs may protect visual aspects of a graphical user interface. Trade secrets can help protect confidential algorithms, processes, datasets or technical know-how. Contracts can define who owns the software and how it can be used.
For example, a SaaS company may rely heavily on copyright, trade marks, confidentiality and licence terms. A business developing a new image-processing system, encryption method or industrial control platform may need to consider whether patent protection is available as well.
The practical point is simple: do not assume one form of IP protection is enough. Software businesses should look at the full commercial picture before deciding what to protect.
Don’t assume software cannot be patented
One of the most persistent myths in software development is that software cannot be patented. The reality is more nuanced.
In the UK and Europe, software “as such” is excluded from patentability. However, that does not mean every software-related invention is automatically excluded. A computer-implemented invention may be patentable if it solves a technical problem in a new and inventive way.
The important question is not simply, “does this involve code?” Most modern technology involves code. The better question is, “does the software produce a technical effect beyond a normal computer program?”
Examples may include software that improves image processing, increases the efficiency of data storage, enhances network security, reduces processing load, controls machinery, improves error correction or enables a technical system to work in a better way.
A simple business method implemented in software is unlikely to be enough. A technical solution to a technical problem may be different.
This is why early advice can be valuable. If the invention may be patentable, public disclosure can damage the ability to protect it. Publishing the idea, pitching it too openly, putting detailed information online or sharing it without confidentiality protection can create issues.
Before disclosing a potentially valuable software invention, developers should consider whether a patentability review is needed.
Do protect the parts of the software that create value
Not every part of a software product will be equally important. Some elements may be standard, replaceable or based on third-party tools. Others may be central to the business.
A useful software IP strategy starts by identifying where the value sits.
Is the value in the code itself? Is it in the algorithm? Is it in a technical process? Is it in the dataset? Is it in the user interface? Is it in the brand? Is it in how the software integrates with hardware, cloud infrastructure or existing enterprise systems?
For example, a software product may have a clean interface and strong branding, but the most valuable asset could be a back-end process that improves speed or accuracy. Another product may not involve a patentable technical invention, but its brand, user data, documentation, contracts and recurring licence model may be commercially important.
This is where many businesses take too narrow a view. They ask, “can we protect the software?” when the better question is, “which parts of the software business need protection?”
That shift leads to better decisions.
Don’t ignore open-source software licences
Open-source software can be extremely useful. It can speed up development, reduce costs and help teams avoid rebuilding standard components from scratch.
However, open source does not mean free of obligations.
Different open-source licences impose different conditions. Some are relatively permissive. Others can place more significant restrictions on how software is distributed, modified or combined with proprietary code.
This matters most when open-source components are used in core product architecture. A developer may introduce a dependency during the early build stage because it solves an immediate technical problem. Months later, the business may discover that the licence creates complications for commercialisation, investment or acquisition.
For example, a buyer or investor may ask whether the company has used open-source software, whether those licences have been reviewed, and whether any obligations affect the proprietary codebase. If the business cannot answer clearly, it can slow down due diligence.
Good practice is to keep a record of open-source components, licence types and how each component is used. This does not need to be complicated at the start, but it should be accurate enough to avoid surprises later.
Do make sure the business owns the software
Software ownership can become messy when development involves multiple people.
If software is created by employees as part of their employment, the employer may own the relevant rights, subject to the employment contract and applicable law. However, the position can be different where contractors, freelancers, consultants, agencies, founders or collaborators are involved.
A common mistake is assuming that paying a contractor to write code automatically transfers ownership. In many cases, the business may need a written assignment of IP rights to make ownership clear.
This is especially important for startups. Investors will usually want to know whether the company owns or controls the technology it relies on. If key parts of the code were created by a former contractor without a clear assignment, this can become a serious issue.
The same applies to university spinouts, joint development projects and collaborations between technical founders. Everyone may be aligned at the beginning, but uncertainty over ownership can become difficult once the product becomes valuable.
The best time to fix ownership is before the software becomes commercially successful.
Don’t treat confidential information casually
Some valuable software assets are not best protected by registration. In some cases, confidentiality may be the most practical form of protection.
Trade secrets and confidential information can include algorithms, model-training methods, product roadmaps, technical processes, customer data structures, internal documentation or deployment methods.
However, confidentiality only works if the information is actually treated as confidential.
That means controlling access, using suitable confidentiality agreements, limiting disclosure, documenting who has access to sensitive information and avoiding unnecessary public detail in pitch decks, demos or marketing materials.
For example, a company may want to show what its software achieves without revealing exactly how the underlying process works. The commercial message can still be strong, but the technical detail should be managed carefully.
This is particularly important where the business is still deciding whether patent protection may be available. Public disclosure before filing can damage patent prospects.
Do align software IP protection with the business model
Software IP strategy should not be separate from commercial strategy. The right form of protection depends on how the business plans to make money.
A SaaS company may need strong licence terms, trade mark protection, confidentiality controls and clear data provisions. A company licensing technical software to enterprise customers may need contracts that define permitted use, support, modification rights and ownership of improvements. A business developing embedded software for devices may need to consider patents, regulatory requirements, product design and hardware integration.
A startup seeking investment may need to show that it owns its core technology, understands its open-source exposure and has a realistic plan for protecting future innovation.
A company preparing for acquisition may need clean records, clear assignments and evidence that its IP position can withstand due diligence.
The best software IP strategy is not always the one with the most registrations. It is the one that protects the commercial advantage the business actually depends on.
Don’t overlook software IP in investor due diligence
Investors and acquirers do not only look at whether a software product works. They also look at whether the company owns it, whether it can defend it, and whether any hidden risks could affect future value.
Common due diligence questions include:
- Who wrote the code?
- Does the company own the IP?
- Were contractors or third parties involved?
- Has open-source software been used?
- Are there any restrictive licence obligations?
- Has the business disclosed anything that may affect patentability?
- Are product names protected by trade marks?
- Are there confidentiality agreements in place?
- Does the company have a clear IP strategy?
These questions can feel administrative, but they can have a real impact on valuation and deal confidence.
For software businesses, IP is often part of the investment story. It helps show that the company has more than a working product. It has assets, control, defensibility and a plan for growth.
Practical software IP checklist
Before launching, licensing, fundraising or discussing a sale, software businesses should consider the following:
- Check whether the core technology may be patentable before making detailed public disclosures.
- Confirm who owns the code, especially where contractors, agencies or external developers were involved.
- Keep a record of open-source components and the licences that apply to them.
- Review whether copyright, patents, trade marks, registered designs, trade secrets or contracts are needed.
- Protect product names, platform names and key brand assets where appropriate.
- Use confidentiality agreements before sharing sensitive technical or commercial information.
- Make sure customer contracts and licence terms match the intended business model.
- Review IP ownership and licensing before investor due diligence begins.
This type of review can help identify issues early, when they are usually easier and cheaper to resolve.
Need advice on software IP?
Software IP can be complex because different rights often overlap. Copyright, patents, trade marks, designs, trade secrets and contracts may all have a role to play.
For developers and technology businesses, the most important step is to review IP early, before key decisions are made about disclosure, licensing, investment or commercial launch.
Our software and electronics patent attorneys advise developers, SaaS companies, AI businesses, technology investors and software-led organisations on patentability, ownership, open-source risk and long-term IP strategy.
If your business is developing, licensing or commercialising software, getting advice early can help protect the value you are building.
