You may not raise it on the sales call, but it is fair to wonder whether the product would still be yours if things went wrong. Paying for code does not settle that: a signed assignment from a vendor that holds the rights moves ownership to you, and accounts in your name keep you in control from the first commit.
Why paying is not owning
Copyright law in each of the countries below starts from the same rule: the author of a work owns it first (17 U.S.C. §201(a) in the US). In the US, the UK and Australia, the big exception is employment, where work an employee writes as part of the job belongs to the employer. That exception helps your vendor, whose engineers are usually its employees. It does not reach you, because you are the vendor's client, not its employer.
So when a company outside your own writes software for you, the default owner is usually that company. The table shows the default in four countries.
| Where | Who owns code an outside company writes for you, by default | What moves it to you | Source |
|---|---|---|---|
| United States | The company that wrote it, unless the work fits one of nine narrow "work made for hire" categories and both sides signed an agreement saying so | A transfer in writing, signed by the owner | 17 U.S.C. §201, §101 and §204(a) |
| United Kingdom | The company that wrote it; the employer rule covers employees only | An assignment in writing, signed by or on behalf of the owner | Copyright, Designs and Patents Act 1988, s.11 and s.90(3) |
| Australia | The company that wrote it; the employer rule covers employees under a contract of service | An assignment in writing, signed by or on behalf of the owner | Copyright Act 1968, s.35(6) and s.196(3) |
| Nepal | Whoever paid remuneration for the work; the Act does not say how that applies to a foreign client of a Nepali company | A written agreement | Copyright Act 2059 (2002), s.6(2)(c) and s.24(1) |
Nepal's rule looks the friendliest to a client, because it points at whoever paid.1 But the Act does not say how that applies when a company abroad pays a Nepali company whose employees wrote the code. Which country's rule a court applies to code written in Kathmandu for a company in Texas is a legal question in its own right. A written, signed assignment that meets the requirements of every country involved sidesteps most of it.
Why "work made for hire" falls short
Many contracts written by US companies call the software a "work made for hire" and stop there. The label does less than it appears to. Under US law, a work made for hire is either an employee's work within the scope of the job, or a commissioned work that falls into one of nine categories and comes with a signed agreement (17 U.S.C. §101).
The nine categories are:
- a contribution to a collective work
- part of a film or other audiovisual work
- a translation
- a supplementary work
- a compilation
- an instructional text
- a test
- answer material for a test
- an atlas
Custom software is not on the list. Stretching "compilation" or "contribution to a collective work" to cover it is not something to rely on.
What does the work is the clause after the label. A well-drafted contract says that if the software is not a work made for hire, the vendor assigns it to you anyway. That assignment meets the US requirement that a transfer be in writing and signed (17 U.S.C. §204(a)). If your contract has the label but no assignment behind it, that is the gap to fix, whether you are a US company hiring an offshore team or based in the UK or Australia.
If that contract is already signed, you do not need to wait for a renewal. Ask the vendor for a separate written, signed assignment of the work so far, while the relationship is still good.
The chain from engineer to you
Ownership reaches you through two links, and a break in either one leaves you short. The first runs from the person who typed the code to the vendor, whether that vendor is down the road or an offshore development partner in Nepal. The second runs from the vendor to you.
The first link is usually sound when every engineer is an employee. In the US, the UK and Australia, the employer rule gives the vendor its employees' work, and in Nepal the vendor is the one paying them.
The link weakens when someone outside the payroll touches the code: a freelancer, a subcontracted agency, or a friend helping over a weekend. In the US, the UK and Australia, whoever wrote that part, or their employer, keeps it unless they transfer it to the vendor in writing. Nepal's rule on whoever paid may cover a freelancer the vendor paid, but not a friend it did not. Either way, a signed transfer settles it, because a vendor cannot pass on what it does not own.
The second link is your contract. Under section 24(1) of Nepal's Copyright Act, the owner may transfer economic rights by written agreement. A written assignment signed by the vendor meets that rule and the US, UK and Australian rules at the same time.
What an NDA does not do
A non-disclosure agreement answers a different fear. A typical NDA stops the vendor from disclosing what you tell it, and usually from using it for anything except your project: your product plans, your data, your customers, your code. It says nothing about who owns the code the vendor writes, and signing one does not make you the owner of anything.
What an IP assignment covers
- Who owns the code, designs and documents created for you
- When that ownership moves to you
- What the vendor keeps and licenses to you instead
- The vendor's promise that it had the right to transfer it
What an NDA covers
- Information you disclose, marked or described as confidential
- How long that information must stay confidential
- What the vendor must return or destroy when the work ends
- Who inside the vendor may see it
Signing a mutual NDA before a first detailed conversation is reasonable, and if a vendor refuses, ask why. Keep it short and mutual, since both sides share things on a scoping call. Then make sure the development contract, not the NDA, carries the ownership terms.
An NDA is also only as strong as your ability to enforce it. It is useful as a clear record of what was promised. It is weaker as a threat of court action across borders, which is why governing law and dispute resolution matter in the clauses below.
Seven clauses to check before signing
Contracts for offshore software work differ in length and style, but the ownership question lives in a handful of clauses. Check them in this order. The first three decide what you own, the next three decide whether the vendor could give it to you, and the last decides what you can do if something goes wrong.
The assignment is present, not promised
Look for "hereby assigns," not "agrees to assign" or "will assign." Lawyers prefer the first wording because it is drafted to transfer rights as the code is written. The second can be read as a promise to sign something later, which is exactly the document that is hard to get once a relationship has ended badly.
It says when ownership moves
There are two common answers. On creation means you own the code as it is written, and on payment means it moves when the invoice covering it is paid.
On payment protects the vendor against a client who stops paying, but it can leave disputed work in limbo, which an investor's or acquirer's lawyer is likely to ask about. Neither answer is wrong, as long as the contract states one.
Background IP is licensed, not assumed
Vendors often bring their own libraries, templates or tools, and those usually stay theirs. The contract should list what counts as background IP. It should also give you a perpetual, irrevocable, royalty-free license to use and modify it as part of your product. That license should extend to whoever maintains the product after the vendor, and transfer with the product if you sell it.
Open-source components are listed
If your product uses open-source packages, each one comes with license obligations. Ask for a list of dependencies and their licenses, and for a rule that copyleft licenses such as the GPL or AGPL are not added without your approval.
AI-generated code is addressed
In January 2025, the US Copyright Office concluded that prompts alone do not make someone the author of AI output, and that such output is protected only where a human determined enough of its expression. Using AI as an assistant does not remove protection from the human work around it (Library of Congress). A contract should say whether AI coding tools may be used on your work, and the vendor should assign whatever rights exist in the result.
The vendor warrants who wrote the code
The vendor should promise that everyone who works on your code is its employee or has transferred their rights to it in writing. It should also agree that no subcontractor is used without your written consent. This is the clause that protects the first link in the chain.
Governing law and disputes are realistic
Choose a law you and your lawyer understand, and a way of resolving disputes that produces something enforceable where the vendor is based.
Nepal acceded to the New York Convention on foreign arbitral awards in 1998. It applies the convention only to awards made in another contracting state, and only to relationships Nepali law treats as commercial (UNCITRAL). An award from arbitration seated in another convention country, in a commercial relationship, falls within that commitment. Recognition is still not automatic and goes through a Nepali court.
Own the accounts too
Every clause above may one day need enforcing, from another country, against a company that disagrees. The strongest protection is one you never have to enforce: the code already sits in accounts your organization controls.
Create the repository, cloud accounts, app store accounts and domain in your organization's name before the first commit, and invite the vendor in. How to vet an offshore development partner covers how to test a vendor on this, and what you should hold on the last day of an engagement. With the accounts in your name, you already hold the code, and the assignment settles who owns it instead of being your only way to get it back.
How NextraLogic handles ownership
Every NextraLogic developer works under an employment contract that assigns ownership of their work to the company. We do not use freelancers: every line of code we write for you comes from our own in-house team, so the first link in the chain is already in writing.
In most of our contracts, ownership then passes to you as the code is written, so by the time we hand over your project, you own all of the code we wrote for it, with nothing held back. Some engagements set the timing differently, and when they do, the contract says so. We sign a client's own master services agreement and NDA, or offer ours, and we can work under the client's governing law.
Questions buyers ask about ownership
Do I need a lawyer in Nepal to hire a Nepali software company?
Not always, but have a lawyer who knows your own law review the contract, and ask them whether the assignment and governing law clauses need local advice. For a large engagement, or a product you expect to sell or raise money on, a short review by a Nepali lawyer is worth considering.
Can I enforce my contract against a company in Nepal?
It can be done, if you plan the route when you sign rather than when you need it. Nepal is a party to the New York Convention, so an arbitration award made in another contracting state, in a relationship Nepali law treats as commercial, can be recognized through Nepal's courts. Keeping your code in your own accounts means you rarely need to rely on that route to get your product back.
Does an NDA stop a vendor from reusing my idea?
A typical NDA stops the vendor from disclosing, and usually from using, the confidential information you shared. It does not give you ownership of an idea, and in the US, copyright does not protect ideas at all, only the way they are expressed (17 U.S.C. §102(b)). If you need a vendor not to build a competing product, that is a separate clause, and whether it can be enforced varies by country.
Who owns code an engineer wrote with an AI assistant?
Under the US Copyright Office's January 2025 report, the human-written and human-shaped parts can be protected, while output produced from prompts alone may not be protected at all. Other countries may treat it differently. Your contract should still assign to you whatever rights exist, and say whether AI tools may be used on your project.
The Copyright Act 2059 (2002), as amended in 2005, in the unofficial English translation available from Nepal's Copyright Registrar's Office. Check the Nepali text for any point that turns on exact wording.
↩