An NDA Doesn't Mean You Own Your Code: The IP Assignment Clause for Offshore Software Development

Plenty of founders sign an NDA with an offshore vendor, see "work made for hire" in the contract, and assume the code is theirs. Often it isn't, at least not yet.

You own code written offshore when a signed IP assignment clause says the vendor "hereby assigns" it to you, effective as each piece is created. An NDA doesn't do that. Neither does a "work made for hire" label, and neither does paying the invoices.

We're a software company, not a law firm, so treat the annotated clause wording below as a standard to take to your lawyer.

What makes you own offshore code?

A written assignment, signed by the vendor, that transfers the code to you in the present tense as it's created. Every other clause either supports that sentence or doesn't touch ownership.

In most countries, code starts out belonging to the vendor or its engineers, not to you. Moving ownership to you takes a signed document. US law says a copyright transfer "is not valid unless" it's in writing and signed by the owner (17 U.S.C. §204(a)). The UK (CDPA section 90) and India (section 19 of its Copyright Act) require writing too, and Nepal's Act provides for transfer "by making a written agreement" (section 24).

The tense of the verb matters. In Stanford v. Roche, a researcher signed one agreement in which he would "agree to assign" his rights, and another in which he "do[es] hereby assign" them. The Federal Circuit read the first as a promise and the second as a completed transfer.

The Supreme Court affirmed in 2011 on a different question, leaving that reading in place, though two justices questioned it (563 U.S. 776). It was a patent case, but it's why careful drafters write "hereby assigns" (Orrick, 2023).

The UK's Act also lets a signed agreement assign copyright in code not yet written. Ownership then passes automatically the moment the work is created, provided no one has a better claim to it (CDPA section 91). That's how an "on creation" clause works, though not every country allows it.

Doesn't my NDA cover ownership?

No. A standard non-disclosure agreement (NDA) controls who may see and share your information. It says nothing about who owns what the vendor writes.

Picture an architect who signs an NDA about your house plans. She's promised not to show them around, but she still owns the copyright in her drawings unless a contract assigns it.

Keep the NDA, and put ownership in its own clause. If your NDA has an IP section, that section is what counts. For the full chain from engineer to vendor to you, see who owns the code in an offshore project.

Isn't my code a "work made for hire"?

Usually not, when an outside company writes it. Under US law, commissioned work is "made for hire" only if it fits one of nine categories and both sides sign a written agreement saying so.

The categories include translations, compilations, instructional texts, tests and atlases (US Copyright Office, Circular 30, revised 2024). Custom application code isn't on the list, and a work that fails the conditions "is not a work made for hire."

Offshore, there's a second problem: work made for hire is a US doctrine, and your code is written elsewhere. A US appeals court faced this with articles written by Russian nationals and first published in Russia. It applied Russian law to decide who owned them (Itar-Tass v. Russian Kurier, 1998). German law has no concept of work made for hire at all (Orrick, 2023).

Local law also fills any gap your contract leaves:

• India: an assignment with no stated period is deemed to last five years, and one with no stated territory covers only India (Copyright Act 1957, section 19).
• Nepal: the economic right in a work "prepared on payment of remuneration" goes to whoever paid for it (Copyright Act 2002, section 6). That's the right to copy, adapt and sell it. When a client pays a company that pays an engineer, who "paid" is open to argument.

Keep the "work made for hire" line if your lawyer wants it, but back it with an assignment that says "worldwide" and covers the full term of the rights.

What's wrong with "upon final payment"?

It leaves all the code with the vendor until the last invoice clears. A dispute about the final milestone becomes a dispute about the whole product.

Take a hypothetical $60,000 build: six $10,000 milestones over 24 weeks, each invoice due 15 days after its milestone. Even if all goes well, a final-payment clause means you own no code until about week 26. Now suppose you dispute the last $10,000 because the final delivery looks incomplete:

Five paid milestones at $10,000 is $50,000, and $50,000 divided by $60,000 is 83%. Under the first clause, you've paid for most of the product and own none of it.

The same gap bites if the vendor fails or is sold before that invoice, since code it still owns is its asset. It bites in a funding round's due diligence too. And if the relationship collapses, you're taking over a failed offshore project without clear title.

Vendors have a real reason for the trigger: it's their leverage. Freelancer posts on DEV Community in 2026 recommend transferring ownership only on receipt of final payment, to guard against unpaid invoices (March 2026 post; July 2026 post). The worry is fair, but the leverage should sit over future work, not over code you've paid for.

Under an on-creation clause, the vendor has one milestone at stake in this dispute: $10,000, or 17% of the contract. It can still recover that as a debt, and your exposure drops from $50,000 of code you don't own to nothing. If a client stops paying mid-project, the vendor also carries the work done before suspension takes effect, so keep invoice terms and notice periods short.

If you have a contract with a payment trigger in front of you, we can walk through its IP and payment terms on a free 30-minute scoping call. It isn't legal review, but you'll know what to ask your lawyer.

What should the IP assignment clause say?

It should transfer everything the vendor makes for you, in the present tense, as each piece is created, with payment kept separate. These seven clauses are the standard we recommend asking for.

1. Assignment on creation

Vendor hereby assigns to Client, automatically as each Deliverable is created, all right, title and interest worldwide in the Deliverables, including all copyright and other intellectual property rights, for their full term.

• "Hereby assigns ... as each Deliverable is created" is a present transfer, with no gap between writing code and owning it.
• "Worldwide" and "full term" override local defaults such as India's five years and India-only territory.

2. Deliverables, defined broadly

"Deliverables" means all source code, object code, tests, build and deployment scripts, infrastructure configuration, designs and documentation created for Client under this Agreement, in any state of completion.

• "In any state of completion" covers half-finished work if the project stops.

3. Work made for hire as a backup

To the extent any Deliverable qualifies as a work made for hire under US law, it is one. Otherwise, it is assigned under clause 1.

• The label stays where it helps, and nothing depends on it.

4. Payment kept separate from ownership

Non-payment does not delay, condition or reverse the assignment in clause 1. Vendor's remedies for late payment include interest at [rate], suspension of further work on [5] business days' written notice, and termination, in addition to recovering the unpaid amount.

• This is the trade for dropping the payment trigger. You and the vendor fill in the brackets.

5. Everyone in the chain

Vendor warrants that every person working on the Deliverables has signed a written present assignment of their rights to Vendor and, where local law allows, waived or agreed not to assert moral rights.

• The vendor can only assign what it owns. Moral rights (an author's right to be credited and to object to changes) can't be assigned. The UK allows waivers; France and Germany generally don't (Orrick, 2023).

6. Pre-existing code and open source

Vendor keeps the pre-existing materials listed in Schedule [X] and grants Client a non-exclusive, perpetual, irrevocable, worldwide, royalty-free, transferable and sublicensable license to use and modify them as part of the Deliverables. Vendor will list all third-party components with their licenses.

• The schedule stops "pre-existing" from growing later, and "transferable" lets the license move with the company if you sell.

7. Further documents and your repository

Vendor will sign any further document reasonably needed to confirm the assignment, and will commit all Deliverables daily to repositories Client owns and controls.

• Title on paper and code in hand are different things. You want both.

When is on-creation the wrong ask?

When you're licensing the vendor's own product, or when local law won't let future rights transfer. Sometimes a compromise is fine.

• You're buying access to the vendor's platform. Expect a license, not an assignment, and negotiate its term, exit rights and data export.
• The job is small and paid upfront. Timing stops mattering once you've paid in full.
• Future rights can't be assigned where the vendor is. Orrick reports that French law treats an assignment of future rights as void. Ask a local lawyer for the usual workaround, such as a present assignment signed at each delivery.
• The vendor won't move. Assignment milestone by milestone on payment, with code in your repository from day one, caps your exposure at one milestone. "Upon final payment" doesn't.

What if you've already signed?

You can fix it with a one-page amendment that swaps in clauses 1 and 4 and assigns all code written so far. Ask before the next milestone, not after a dispute starts.

If the vendor refuses, ask for assignment milestone by milestone, confirmed in writing after each payment. Either way, get a signed confirmation at the end listing the repositories and deliverables. It costs the vendor little and gives you one document to show in due diligence.

What should you send your vendor?

Send the seven clauses and ask for the payment trigger to come out of the IP section. A vendor that expects to deliver and get paid gives up little, because it keeps its leverage over future work.

If the team will also be able to reach your customers' personal data, send the data processing terms in the same round; here is what the GDPR requires when you outsource.

Selling in Singapore? Add the data transfer terms to the same contract before the team can reach customer data; here's what Singapore's PDPA requires for overseas transfers.

For other warning signs in a vendor's paperwork, see our offshore development red flags, or our offshore development overview for how an engagement runs day to day. Buying from Germany? Offshore software development for Germany covers the Werkvertrag and acceptance (Abnahme) questions a German contract raises.

This is general information, not legal advice.