The Offshore IP Checklist for US Founders: Assignment, Work-for-Hire, Repos

To own the code an offshore team writes for you, get a signed written assignment of IP from the vendor, and make sure the vendor holds those rights from its own engineers. Under US law, custom software from a contractor is generally not a "work made for hire", so the label alone does not transfer ownership. Keep the repository in your organisation from the first commit.

This checklist is for US founders hiring a development agency or studio outside the United States. RAITHub is one of those studios, based in Dhaka, Bangladesh. This is general information, not legal advice. Contract terms and the law of each country involved decide the answer for you; confirm with your lawyer before you sign. If you are trying to get code back from a developer you already hired, start with how to get your source code from a developer instead.

What is the difference between an IP assignment and work made for hire?

Work made for hire is a rule about who counts as the author from the start. An assignment is a transfer of rights from the author to someone else. For software built by an outside company, the assignment is usually the one that does the work.

The US Copyright Office's Circular 30 (revised August 2024) explains that a work is made for hire in only two situations: when an employee creates it as part of their regular duties, or when a work that is specially ordered or commissioned falls into one of nine listed categories and the parties expressly agree in a written instrument signed by both that it is a work made for hire. The nine categories are a contribution to a collective work, part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, and an atlas. "If a work fails to satisfy any of these requirements, it is not a work made for hire."

Software is not on that list. So when an agency's engineers write your application, you are not their employer, and a clause calling the code "work made for hire" may not make you the author. That is why contracts use an assignment, and why 17 U.S.C. § 204(a) matters: a transfer of copyright ownership "is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed" (17 U.S.C. § 204, Cornell LII).

Mechanism	How it works	Does it fit an offshore agency build?	What to check
Work made for hire (employee)	The employer is the author from the start	Only between the agency and its own employees, not between you and the agency	That the agency's employment contracts give it the rights under its local law
Work made for hire (commissioned)	Nine categories only, with a signed written agreement	Rarely; custom software is not a listed category	Do not rely on this label alone
Written assignment	The owner transfers the rights in a signed writing	Yes, this is the main tool	Present wording ("hereby assigns"), scope, and who signs
Licence	You get permission to use; the vendor keeps ownership	For the vendor's pre-existing tools and libraries	That it is perpetual, irrevocable and covers modification

Many US contracts use both: the work is declared a work made for hire "to the extent permitted", and anything that is not is assigned. Ask your lawyer whether that belt-and-braces wording suits your case, and whether the assignment is a present transfer ("hereby assigns") rather than a promise to assign in future, which is generally treated differently.

Why does the chain of title matter with an offshore agency?

Because the agency can only assign rights it actually holds. The code is written by individual engineers, so the rights have to pass from each engineer to the agency, and then from the agency to you. That first link is governed by the law of the country where the engineers are employed, not by US law.

• Employees of the agency. Ask the agency to confirm in the contract that its employment agreements give it ownership of work its engineers create, so it can assign that work to you.
• Freelancers or subcontractors the agency uses. Each needs their own written assignment to the agency, or directly to you. Ask whether any subcontractors will touch your code, and require your approval before they do.
• The agency's pre-existing code. Internal libraries, starter kits and tools the agency built before your project should be licensed to you, not left unmentioned.

A warranty that the agency has the right to assign everything it delivers, and a promise to sign further documents if needed later, close the gap cheaply. They matter most when you raise money or sell the company, because investors' and buyers' lawyers will ask for the chain.

Why should the repository be in your organisation from day one?

Because possession is the practical half of ownership. A contract gives you the right to the code; a repository in your own organisation means you already have it, every day, without asking anyone.

On GitHub, organisation owners have "complete administrative access", and GitHub recommends limiting the owner role to "no less than two people" (GitHub: roles in an organization). Those two should be you and a co-founder or trusted colleague, not the vendor. The vendor's engineers join as a team with write access to specific repositories. A minimal setup with the GitHub CLI:

# 1. Create the private repository in YOUR organisation before any code is written.
gh repo create your-org/your-app --private

# 2. Create a team for the vendor's engineers.
gh api -X POST orgs/your-org/teams -f name=vendor-team -f privacy=closed

# 3. Give that team write ("push") access to this repository only. Not admin.
gh api -X PUT orgs/your-org/teams/vendor-team/repos/your-org/your-app -f permission=push

Do the same for everything the product runs on: hosting, the domain, the database, payment and email accounts, all registered to your company with the vendor as a removable member. Then, if the relationship ends, you remove a team rather than negotiate a handover.

The offshore IP checklist

#	Item	Where it belongs
1	Present assignment of all IP in deliverables to your company	MSA
2	Work-made-for-hire wording "to the extent permitted", as a backstop	MSA
3	Warranty that the vendor holds the rights from its employees and subcontractors	MSA
4	Your approval required before subcontractors touch the code	MSA
5	Licence to the vendor's pre-existing tools included in the deliverables	MSA
6	Disclosure of open-source components and their licences	SOW or delivery checklist
7	Deliverables defined as source code with history, migrations, configuration and docs	SOW
8	Repositories in your organisation from the first commit	SOW, and your GitHub settings
9	All service accounts registered to your company	SOW, and your account settings
10	Confidentiality of your code, data and business information	NDA, signed before any access
11	Handover and data deletion on termination	MSA
12	Promise to sign further documents confirming the assignment	MSA

What goes in the MSA, the SOW and the NDA?

Three documents, three jobs. The master services agreement (MSA) sets the permanent legal terms for the whole relationship, including IP. Each statement of work (SOW) describes one piece of work: scope, deliverables, timeline and price. The non-disclosure agreement (NDA) protects confidential information, and is usually signed first, before you share anything.

• Put the IP assignment in the MSA, so it covers every SOW, including ones you sign later. An assignment that lives only in a single SOW can leave the next piece of work uncovered.
• Keep the SOW about the work. A precise list of deliverables turns "the code" into items you can check at handover.
• Sign the NDA before access, not with the contract. The first technical call often involves sharing a repository or a data model.
• Check which country's law governs, and where disputes go. A US founder usually wants a US state's law; confirm with your lawyer how that works with a foreign vendor.

What about open-source and AI-generated code?

You cannot be assigned rights that nobody holds. Two cases need attention.

Open-source components come with their own licences, and you inherit those terms with the code. Most permissive licences are easy to live with; some copyleft licences place conditions on how you distribute software that includes them. Ask for a list of dependencies and licences at each delivery.

AI-generated code raises a newer question. The Copyright Office's January 2025 report on copyrightability says copyright protects human authorship, and that material generated by AI without sufficient human control is not protected (US Copyright Office: Copyright and Artificial Intelligence). Most professional code today mixes human and AI-assisted work, and how much protection that mix has is still developing. Ask your vendor how AI tools are used and reviewed, and ask your lawyer how your contract should deal with it.

Is source code escrow worth it for an offshore build?

Usually not, if the repository has been in your organisation since the first commit. Escrow means a third party holds a copy of the source code and releases it to you on agreed conditions, such as the supplier going out of business (source code escrow, overview). That solves a problem you do not have when you already hold the code.

Escrow earns its fee when you license software you do not own and cannot hold, such as a supplier's platform your business depends on. If you do pay for it, pay for verification too, so someone actually builds the deposited code. The source code handover guide compares escrow with repository ownership in more detail.

What if you already started without these?

Fix it while the relationship is good. Ask the vendor to sign a confirmatory assignment covering all work delivered so far, transfer the repositories into your organisation, and move the service accounts into your company's name. If the vendor has stopped responding, the 48-hour recovery plan covers what to lock down first, and a code rescue engagement covers taking the code over.

Why RAITHub for a US founder

• You own the IP. RAITHub's contracts assign the IP in all work to the client, and an NDA is standard before any code or data is shared.
• Your accounts, from day one. If you want the repository and hosting in your own organisation from the first commit, set it up that way; that is what we recommend on the audit call.
• Code a future team can take over. Tested, documented and built to be handed over. TheSkinProof, the founder's own venture rather than a client project, runs 217 API endpoints and 750+ tests; PropDesk runs 1,024 tests.
• Clear terms. Fixed-scope projects or a dedicated monthly team, a free 15-minute technical audit, then a fixed written quote. See the MVP development service or the SaaS development service. For choosing a vendor in Bangladesh generally, see how to choose a software company in Bangladesh and Bangladesh vs India for software outsourcing.

When you don't need us

• You need your contract drafted or reviewed. That is a lawyer's job. RAITHub gives no legal advice.
• Ownership of existing code is in dispute. See a lawyer before anyone changes the code.
• You need a US-based vendor or an on-site team. RAITHub has no US office.
• You need a certified vendor. RAITHub is not SOC 2 or ISO 27001 certified.

Sources checked on 29 September 2026. General information only, not legal advice; confirm with your lawyer.

If you want an offshore build with the IP and the repository in your hands from the start, book the free 15-minute technical audit. Bring your MSA template if you have one.

Frequently asked questions

Is software written by an offshore agency a work made for hire?

Generally not for you. Under US law, a commissioned work is made for hire only if it falls into one of nine categories listed in Circular 30, with a signed written agreement, and custom software is not one of them. Use a written assignment. This is general information; confirm with your lawyer.

What does an IP assignment need to be valid in the US?

Under 17 U.S.C. § 204(a), a transfer of copyright ownership must be in writing and signed by the owner of the rights, or their authorised agent. Ask your lawyer to check the wording, scope and signatories.

Who should own the GitHub organisation?

Your company, with at least two of your own people as owners, as GitHub recommends. The vendor's engineers should be a team with write access to specific repositories, not owners.

Should the IP clause go in the MSA or the SOW?

Usually the MSA, so the assignment covers every statement of work, including later ones. The SOW then defines the deliverables that the assignment applies to.

Do I need source code escrow with an offshore developer?

Usually not, if the repository is in your organisation from the first commit and the contract assigns the IP to you. Escrow suits software you license from a supplier and cannot hold yourself.

Does RAITHub assign IP to the client?

Yes. The client owns the IP in all work, and an NDA is standard before any code or data is shared.