Who owns the code in outsourced software

Quick answer

Paying for software does not by itself make you the owner of the code. In most countries the person or company that writes the code holds the copyright unless a written agreement assigns it to you, so ownership should be stated clearly in the contract before work starts. At 2good, the source code, documentation and intellectual property belong to the client on acceptance and payment, and that is written into the Statement of Work.

Why ownership is a question at all

Many founders assume that if they paid for the work, they own it. It feels obvious. The law in most places takes a narrower view. Copyright in software usually belongs to whoever created it, and when the creator is an outside company, that company is the first owner. Employment changes this for staff writing code in the course of their job, but an outsourced vendor is not your employee.

So the contract does the work. A clear written assignment moves ownership from the vendor to you. Without one, you may end up with a licence to use the software, perhaps an implied one, and a licence is a weaker position. It may not let you modify the code, sell the product, bring in another vendor, or raise investment on the strength of owning the technology.

This matters most at three moments: when you want to change vendors, when an investor or buyer asks who owns the product, and when a dispute arises over money. In each case the question is answered by what was signed, and memories of a friendly kick-off call carry little weight.

What the contract should say

A clear assignment

The agreement should say, in plain words, that the vendor assigns to you all copyright and other intellectual property in the work it produces for you. Good drafting covers the code, the database design, the documentation, the designs and any written material made for the project. It should also say when the assignment takes effect, for example on acceptance and payment of each increment.

What the vendor keeps

Most vendors reuse their own general tools, libraries and know-how across clients. That is reasonable, and a sensible contract recognises it. The usual approach is that the vendor keeps ownership of its pre-existing tools and grants you a permanent licence to use them as part of your product. What you want to avoid is a contract where core parts of your product are quietly treated as the vendor's own.

Third party and open source components

Almost every modern application uses open source libraries and some paid services. These are never fully yours, because someone else owns them. The contract should require the vendor to tell you which third party and open source components are used, under which licences, and whether any licence places obligations on you, such as publishing your own source code. Some licences do, and that can matter a great deal for a commercial product.

Moral rights and waivers

In some legal systems the author of a work keeps certain personal rights even after copyright is assigned. Many software contracts include a waiver or consent clause to deal with this. Your lawyer will know whether it is needed where you and your vendor are based.

Confidentiality

Ownership of code and confidentiality of your business information are separate points. A good agreement covers both: who owns what is built, and how the vendor treats the data, plans and customer details it sees along the way.

What to ask for at handover

Owning the code on paper helps only if you can get hold of it. Agree the handover list in writing at the start, and check each item when work is delivered.

| Item | What good looks like | | --- | --- | | Source code | The complete code, in a repository you control, with the history of changes | | Repositories | Your organisation owns the repository account; the vendor has access you can remove | | Credentials | Admin logins for hosting, domains, databases, app store accounts and paid APIs, held in your name | | Build and deploy steps | Written instructions to build, configure and release the software from scratch | | Documentation | Architecture notes, data model, setup guide and a record of key decisions | | Licence list | Every third party and open source component, with its licence | | Design files | The source design files, along with the exported images |

Repositories and accounts in your name

The simplest protection is to own the accounts from day one. Create the code repository under your own organisation and invite the vendor in. Open hosting, domain and app store accounts in your company's name and give the vendor the access it needs. If the relationship ends, you remove their access and carry on. Recovering accounts held in a vendor's name is slow and uncomfortable, even when everyone is acting in good faith.

Credentials

Ask for a credentials register: a list of every system, who holds admin access, and where the keys are stored. Passwords and secret keys should be shared through a password manager or a secure vault, never in chat messages or email threads.

Documentation that someone else could use

The real test of documentation is whether a different team could pick up the project and continue. A setup guide that works on a fresh machine, a description of how the data fits together, and a short record of why key decisions were made will save weeks for whoever comes next. Our guide on handing over code, credentials and documentation has a fuller checklist.

How 2good handles ownership

2good is the delivery model of Code Colonies Private Limited, based in India and delivering for clients worldwide. Ownership is part of the terms from the first conversation.

• The source code, documentation and intellectual property for the work belong to you on acceptance and payment.
• That position is written into the signed Statement of Work, so it sits alongside the scope and the acceptance criteria.
• Each block of work comes with documentation and a delivery note describing what was built.
• Third party costs and licences, such as hosting, paid APIs and app store fees, are agreed in writing before work starts.

Because you pay after you accept the work, ownership and payment move together. You test each increment against the specification, accept it, pay for it, and it becomes yours. There is no advance, and no stage where you have paid for code you do not yet own. The pay after acceptance page sets out how acceptance works.

We encourage clients to hold the repository and hosting accounts in their own name from the start, and we work inside them. If you later bring development in house or move to another vendor, the handover is a matter of removing our access.

Questions to ask any vendor

Whoever you buy from, these questions bring ownership into the open early:

• Does the contract assign copyright and other intellectual property in the work to us, and from what point?
• Which of your own tools or components will be in our product, and what licence do we get for them?
• Will you give us a list of open source and third party components and their licences?
• Will the code live in a repository we own from the first day?
• Which accounts will be opened in our name, and which in yours?
• What documentation will we receive with each delivery?
• What happens to the code and our data if we stop working together?

A vendor who answers these clearly and puts the answers in writing is one you can work with. Hesitation on the first question is worth taking seriously.

Where to start

If you are preparing to commission software, put ownership into your specification and agreement alongside the scope. The specification starter will help you outline the work, and you can see the commercial terms on the offer. When you are ready to discuss a project, contact us.

Intellectual property law differs between countries, so confirm the wording of any assignment with your lawyer before you sign.

Sources

• India Code: the official text of the Copyright Act, 1957 and other central laws.
• Copyright Office, Government of India: registration and guidance on copyright in India.