Skip to main content
Industry Insights

Who Owns the Code? IP and Handover Questions for Offshore Engineering Agreements

Separate code rights from repository custody. Review contributors, licenses, agreements and a practical handover before an offshore engineering engagement.

By Jake Parks6 min read
Who Owns the Code? IP and Handover Questions for Offshore Engineering Agreements

To establish who owns code created by an offshore engineer, examine the applicable law, the people and entities contributing to the work, and the actual rights and transfer terms in the agreements. Repository access, an invoice or a confidentiality clause alone does not answer the entire ownership question.

For US companies working with Philippine engineers, combine legal review with an operational handover plan. The company needs appropriate rights to use and maintain the software, and its team needs the practical ability to do so. Those are related responsibilities with different evidence.

Define the work and its contributors

List what the engagement may produce: application code, tests, designs, documentation, infrastructure definitions and other agreed material. Identify who creates it and which entity signs the relevant agreement. Ask whether other employees, subcontractors or pre-existing components may be involved.

The US Copyright Office's computer-program guidance explains copyrightable expression in computer programs and registration considerations. That is different from establishing ownership of every idea, process, dependency or associated business asset. Have your adviser specify the rights required for the actual work.

A provider's statement that “you own everything” should lead to concrete follow-up: which work, created by whom, under which agreements, and when do the necessary rights take effect? Confirm the scope instead of assuming a short phrase resolves every contribution.

Ask how the rights reach your company

An agreement with an intermediary may need support from agreements with the people creating the work. Your legal reviewer should examine the applicable ownership, assignment, licensing and related obligations across that chain.

The Copyright Office's works-made-for-hire circular describes specific US conditions and explains that the concept can be complicated. Do not assume that writing “work for hire” makes every contractor contribution fit those conditions.

The Philippine Intellectual Property Code, Section 178, contains distinct ownership rules for employment and commissioned works. That is a reason to obtain advice on the actual relationship and written terms. This article does not determine governing law, provide an assignment clause or resolve a dispute.

Make a rights-and-handover inventory

The following original worksheet is a preparation tool for legal and technical owners. It deliberately separates rights evidence from operational custody.

Asset or responsibility Rights question for review Handover evidence for the technical team
New application code and tests Which rights are assigned or licensed, by which contributors and when? Agreed repository, change history and instructions to run relevant checks
Existing tools or modules What is excluded from assignment and what use is licensed? Inventory, version and information needed to maintain or replace the component
Open-source dependencies Which licenses and obligations apply to the intended use and distribution? Dependency inventory and required notices or license files
Designs and documentation Are these included in the defined work product and permitted uses? Editable source files and current operating documentation
Build and deployment assets Who controls the accounts and what rights or subscriptions remain necessary? Named account owners, build instructions and a tested access-transfer plan
End of engagement Which delivery, retention, deletion and assistance obligations apply? Receiving owner, unresolved issues and confirmed access closure

GitHub's repository-licensing guidance explains that licenses define permissions and that public code is not automatically unrestricted. Ask your reviewer about the actual dependencies and intended use. A contract assigning new code should not be treated as permission to ignore third-party license terms.

Include the team's AI-tool policy in the discussion where relevant. Establish permitted inputs, confidentiality boundaries, disclosure and review expectations. Do not assume a generated output comes with a universal ownership or non-infringement guarantee.

Walk through a fictional handover

Imagine a fictional warehouse dashboard built with an existing charting library, new inventory views and a deployment script. The application is stored in a company repository, but the deployment runs through a developer's personal account.

The repository copy gives the company code custody. It does not, by itself, establish rights to the charting library, complete the contributor agreements or transfer deployment control. The legal owner checks those rights and terms. The technical owner documents the deployment path and arranges a controlled account transition with the authorized parties.

The receiving engineer should be able to build the agreed version using documented steps and identify the required services. Test the handover within the approved environment. Do not paste passwords into documentation or share a personal login to make a transfer seem complete.

Record issues as open until resolved. A missing license document, unclear contributor obligation and inaccessible deployment account are different problems; each needs an owner and evidence of resolution.

Agree the exit while collaboration is straightforward

Define what will be delivered when the engagement ends, in which format, by whom and under which payment or assistance terms. Identify the receiving technical owner and the process for closing access after the agreed transfer.

Keep confidential information in approved systems. Confirm retention and deletion obligations, including backups or records that may need to be preserved. A promise to delete “everything immediately” may conflict with other responsibilities; have the relevant advisers and security owner settle the actual terms.

Our secure-access guide covers permissions during an authorized engagement. Use this inventory to connect that operational control to the rights and handover questions in the agreement.

Confirm the terms for your Arca engagement

Bring your rights requirements and handover expectations to Arca when discussing a Philippine engineering hire. Have qualified counsel review the actual agreements; an educational article is not a statement of your contract terms or a substitute for that review.

Use the partner-verification guide to track the documents and unresolved questions before signature. A useful outcome is a clear chain of responsibility and a handover your team can perform—not an ownership claim supported only by possession of a repository.

Frequently asked questions

Does having the repository prove we own all rights?

No. Repository custody is operational evidence. Examine contributor agreements, applicable law and third-party permissions with qualified counsel.

Does an NDA transfer code ownership?

Do not assume it does. Confidentiality and intellectual-property transfer address different matters; have the actual agreements reviewed.

Can we assume contractor code is work made for hire?

No. The cited US guidance describes specific conditions. Cross-border ownership and transfer terms need analysis of the actual facts and applicable law.

What should be recorded about dependencies?

Record components, versions, licenses and required notices or permissions. Assignment of new work does not remove third-party license obligations.

What makes an operational handover useful?

A named receiver should obtain agreed source, build and operating instructions, controlled account access and a record of unresolved issues. Verify the transfer without sharing personal credentials.

Share