Who owns software created by a contractor

Software ownership should be resolved before development begins. A contractor may retain copyright unless the written arrangement provides the rights the customer needs. Separate newly developed code from pre-existing tools and third party components, then consider how the business will maintain and distribute the product. ^[1]

Review subcontractors, repositories, build instructions and dependency licences. The right to use a hosted service is different from ownership of its code. If continuity matters, assess the practical ability to deploy, support or move the software when the original developer is unavailable.

Separate ownership from a working software handover

Create two lists: the rights the company needs and the materials required to operate the application. Copyright ownership, a source-code copy and access to a hosted service are different things. A business can hold a broad licence yet be unable to deploy because essential configuration or accounts remain with the contractor.

Identify the intended operating model. If the customer is buying a subscription, ownership of the provider's platform may not be part of the deal. If it commissions a bespoke application, it may need modification, maintenance and transfer rights. The contract should describe that model clearly rather than using own the software as an undefined promise.

Trace every contributor and component

Ask who wrote the code and whether subcontractors contributed. Review the rights arrangements at each stage. Contractor-created copyright can remain with the creator unless an appropriate agreement provides the required rights. ^[1] Paying the main developer does not automatically establish that the company owns work supplied by another contributor.

Maintain a dependency list identifying third-party libraries, frameworks, fonts and other assets. Record the relevant licences and how the software is used or distributed. Permission to use another party's IP is limited by the applicable terms. ^[2] Do not describe open-source components as ownerless or assume every licence permits identical commercial use without conditions.

Define rights in new and background code

Identify code developed specifically for the project and tools the contractor already uses elsewhere. Decide whether the company receives an assignment or licence for each category. The arrangement should permit the intended maintenance, hosting and customer distribution without unnecessarily claiming ownership of unrelated developer tools.

State when rights take effect and what permission exists before final payment. If the application launches in stages, address each release. A payment dispute should not reveal for the first time that the company lacks the permission it assumed for live use. Review the actual wording and commercial needs before accepting a generic ownership-on-payment clause.

Specify the technical deliverables precisely

Agree repository access, source history, build instructions, deployment documentation and configuration records. Identify external services and who owns their accounts. Separate production secrets from documents that can be shared broadly. The company should control the credentials necessary for its operations through secure arrangements rather than depend on a contractor's personal account.

Ask the receiving technical team to verify that the delivered materials can build and operate the agreed version. A folder containing source code may omit a proprietary component or undocumented deployment step. This practical check does not prove legal ownership, but it can reveal a continuity gap before the contractor's engagement ends.

Address updates, defects and future development

State whether maintenance includes rights in fixes and new features on the same basis as the original work. Check what happens when another developer is appointed. The company may need permission to disclose code and documentation to that provider, subject to appropriate confidentiality and licence restrictions.

Keep changes to third-party dependencies under review. A later release can introduce a different licence or service dependency even where the main contract remains unchanged. Assign responsibility for maintaining the component record and raising material rights issues before release. This is more useful than a one-time declaration that the original application contained no known problem.

Plan departure and dispute handling

Define handover assistance, outstanding work and access changes if the contractor leaves or the agreement ends. Consider whether escrow is proposed and what it actually contains and releases. Escrow is not a substitute for a usable rights arrangement or verified technical materials. Review its trigger, completeness and practical value for the business.

If ownership is already unclear, preserve contracts, invoices, repository history and communications. Do not assume the company may remove third-party notices or publish the code to force a resolution. Obtain advice on the existing permissions and the agreement needed to close the gap.

Prepare for investment or sale

Keep the contributor agreements, component licences and technical handover evidence together. A buyer needs to understand both legal control and operational continuity. Record unresolved rights rather than describing all software as proprietary without support.

Read Subcontracting responsibilities and consent for subcontracting chains. IP ownership review can help assess ownership and permissions in contractor-built software, with technical verification and specialist licence analysis scoped to the actual product and intended use.

Illustrative scenario

A company pays for a bespoke booking application, but the code sits only in the contractor's personal repository. The review identifies missing access and unclear rights in reused components. The company agrees a documented rights position and a tested handover of code, deployment instructions and essential configuration.

Preparation checklist

• Identify contributors and their written IP commitments.
• Separate bespoke code, background tools and dependencies.
• Agree company-controlled access to required repositories.
• Check modification, distribution and transfer rights.