The one thing to know
In India, paying for software does not automatically make you its owner. Copyright stays with the author unless there is a written assignment. If your contract does not say you own the code, you probably do not.
This is the least glamorous topic in software procurement and the one that causes the most expensive surprises. Businesses discover the problem at exactly the wrong moment — when they want to change vendors, raise investment, or sell.
Why "I paid for it" is not enough
Under the Copyright Act, the person who creates a work generally owns the copyright. There is a narrow exception for works created by employees during employment, but an external agency or freelancer is not your employee.
So without a written assignment, the common outcome is: you paid for the work, you can use the delivered product, but the developer retains copyright in the code. That means they can reuse it, and you may have limited rights to modify it or hand it to someone else.
Where this bites hardest: due diligence. Investors and acquirers routinely ask for proof that you own your core technology. A missing assignment clause can delay a funding round for weeks, reduce your valuation, or — if the original developer is uncooperative or unreachable — become genuinely difficult to remedy.
What a good contract actually says
You do not need elaborate legal drafting. You need these points stated plainly:
- Assignment of copyright The contract should assign all intellectual property in the custom work to you, effective on final payment. "Assign" is the operative word — not "grant a licence to".
- Scope of the deliverable Explicitly include source code, database schemas, build scripts, configuration, and design files — not just the compiled or deployed output.
- Third-party components identified A list of open-source libraries and their licences, plus any commercial licences you must maintain yourself.
- Pre-existing material licensed If the developer reuses their own framework, you need a perpetual, irrevocable licence to it — otherwise your product depends on something you cannot control.
- Delivery mechanism and timing Code pushed to a repository you own, throughout the project — not handed over as a zip file at the end.
- Documentation and credentials Deployment instructions, environment details, and all accounts transferred.
Ownership versus licence, in practice
| You can… | With ownership | With a licence |
|---|---|---|
| Modify the code | Yes | Only if permitted |
| Hire another developer | Yes | Often restricted |
| Move to different hosting | Yes | Sometimes restricted |
| Sell the business with the software | Yes | May need consent |
| Stop paying the developer | Yes | May end your rights |
| Prove ownership in due diligence | Yes | No |
Warning signs during negotiation
- The contract says "licence" or "right to use" where you expected "assign" or "transfer".
- You are told source code access is "not standard practice" — it is standard for custom work.
- Code lives only on the vendor's servers or private repository throughout the project.
- A build price that seems low, paired with a compulsory ongoing fee you cannot exit.
- Hosting locked to the vendor with no migration path.
- Domain or cloud accounts registered in the vendor's name rather than yours.
If you cannot take your code and hire someone else tomorrow, you did not buy software — you rented it.
Open-source components: what to actually check
Essentially all modern software builds on open-source libraries. This is normal and good. The licences matter:
| Licence type | Examples | Commercial implication |
|---|---|---|
| Permissive | MIT, Apache 2.0, BSD | Use freely; keep attribution notices |
| Weak copyleft | LGPL, MPL | Usually fine; changes to the library itself must be shared |
| Strong copyleft | GPL, AGPL | Can require releasing your own source — get advice before shipping |
| Commercial | Paid components | You must hold and renew the licence yourself |
Ask for a dependency list with licences at handover. Reputable developers produce this readily; it is generated automatically by standard tooling.
Protecting yourself from day one
- Create your own repository first Open a GitHub or GitLab account in your company's name and invite the developer into it. You then always hold the current code, regardless of how the relationship ends.
- Register accounts yourself Domain, hosting, and cloud services in your company name with your email. Grant the developer access rather than the reverse.
- Tie final payment to handover The last instalment releases on delivery of code, documentation, and credentials.
- Get the assignment in writing before work starts Retrospective assignment requires the other party's cooperation, which you may not have later.
Our own position, for transparency: we assign full ownership of custom code to clients on final payment, deliver into a repository the client controls from day one, and provide a dependency licence list at handover. We think that should be the industry norm rather than a selling point.
If you are already in this situation
If you have discovered you do not own code you depend on, options in rough order of preference: negotiate a retrospective assignment (often achievable for a fee while the relationship is intact), obtain a broad perpetual licence as a fallback, or plan a rebuild of the critical components. The first is dramatically cheaper than the last, and gets harder the longer you wait.
Commissioning software and want the ownership terms right before you sign? Talk to us. See also the 12 questions to ask before hiring.