Software IP: follow the code, contracts and components

Map the release rather than the idea

A software product can contain code written by employees, a contractor's interface, purchased icons, open-source libraries and customer-provided material. Start with the release that will actually reach users. List its components and contributors, then connect each item with a repository, delivery record or agreement. This makes the inventory concrete enough for technical and business teams to use together.

Copyright protects qualifying expression, including computer programs, rather than the underlying idea or method. That distinction matters when describing what is valuable about an app. An original implementation and the broad concept of its feature are different things. Avoid treating a description of the business model as evidence that every competing implementation would infringe your rights.

Read the rights chain alongside delivery

For each external contribution, locate the agreement that governs its use. Check whether the business relies on a licence or a transfer, and flag provisions needing review under the applicable law. Payment, a source-code handover and access to a repository are practical facts; none should be used alone to explain the whole rights position. Keep revisions and signed documents together.

Open-source components need an equally clear record. Record the component, version, licence and way it is used or distributed. Different licences contain different conditions, and a familiar project name is not enough to identify those conditions for a particular release. Assign responsibility for reviewing changes when dependencies are updated, rather than leaving the first inventory untouched until a transaction or dispute.

Keep the technical-invention question separate

The patent question is more nuanced than asking whether software can be patented. Under the European Patent Convention, computer programs as such are excluded. A computer-implemented invention can nevertheless require examination of technical character and the other patentability requirements, including novelty and inventive step. Calling an application artificial intelligence or automation does not settle that examination.

If a project appears to solve a technical problem, prepare a description of the implementation, its technical effect and the evidence supporting it. Keep the planned disclosure of that material in view. This creates a starting point for a qualified assessment without claiming that every useful algorithm is patentable. The software inventory and the technical note serve related but distinct purposes.

Make the inventory useful after launch

Decide who maintains the inventory and when it changes. A release checklist can ask whether new code, assets or integrations require a document update. Record access to confidential repositories separately from public code. Make the rights information available to the people preparing customer contracts, because a promise about ownership or licensing should correspond to what the product actually contains.

Before an investment, licence deal or major release, turn missing documents into specific questions with named owners. Identify what is known, what needs confirmation and what requires professional review. An organised folder cannot cure a missing right, but it can reveal the problem while there is still time to address it. This article provides a preparation framework, not a legal audit of a software product.

Check the official source