Who owns the code: IP and contracts in outsourced software

OutsourcingVN is operated by Netbase JSC, so this page describes our own terms as well as common practice. It is not legal advice. It is the set of questions we would want a buyer to put to us, and the answers we give when they do. The subject is how ownership works when one accountable delivery owner runs a project across a globally sourced team, whoever ends up contributing to it. For the wider buying decision, start with the Vietnam outsourcing buyer guide.

Ownership is rarely one thing

A software project produces three kinds of material, and they are normally treated differently:

• Work created specifically for you. Application code, designs, documents and configuration written for your project. This is what a buyer expects to own, and it is what a well-drafted contract assigns.
• The provider's reusable components. Modules, libraries and productized products the provider built before your project and will use again after it. These are normally licensed to you, not transferred.
• Third-party components. Open-source libraries, commercial libraries and hosted services. Nobody in the project owns these; you inherit their terms.

If a provider says you will own "everything", ask which of the three it means. A provider that cannot separate them has either not thought about it or is describing something it cannot deliver.

Work created for you

For custom development, the intellectual property created for you belongs to you. That is the term Netbase works to, and the final terms are set in each project agreement rather than on a web page.

Two details decide whether that sentence is worth anything. The first is when ownership transfers: on creation, on acceptance of each milestone, or on final payment. Each is defensible, but you should know which one applies and what happens if the project stops halfway. The second is what counts as work created for you. Ask whether it covers designs, test suites, infrastructure definitions, build scripts, data models and written documentation, not only application source code. Our custom product engineering service produces all of those, and all of them matter when someone else has to pick the system up.

Reusable modules and productized products

Where a project uses Netbase productized modules or products, they are licensed rather than transferred. That is ordinary in this industry, and it is usually in your interest: a module that has already run in production costs less to adopt than the same thing written again. It only works if you know the module is there before you accept the proposal.

Ask for every reusable component to be named in the proposal, with its terms attached, and check:

• whether the licence is perpetual and irrevocable, or tied to a subscription;
• whether it survives the end of the relationship, including termination for cause;
• whether you may modify the component, and who owns your modifications;
• whether you may pass it to another provider or to an acquirer;
• whether you receive source code or only a deployed artefact;
• what happens if the provider stops maintaining it.

Licensed components also change the shape of your budget, because part of what you pay for is adoption rather than construction. Our guide to what a Vietnam software project costs sets out where that difference shows up.

Third-party and open-source components

Ask for an inventory: component name, version, licence and where it is used. It takes a provider an hour to produce and it answers three questions at once.

Copyleft licences such as GPL and AGPL create obligations when you distribute or host the software, and those obligations can reach your own code, not only the library. Commercial libraries are often licensed per seat or per server and may not transfer to you at all. Hosted services are contracts rather than code, and they usually sit in either your name or the provider's, which is worth settling early. The same inventory is what a security review will ask for; the companion guide on security, access and data rules covers that side.

Who actually wrote it

An assignment clause only works if everyone who touched the code is bound by it. You contract with one party: Netbase JSC, whose head office is in Hanoi, Vietnam and is the company's only office. That is the entity that signs and the entity that owes you the assignment. Netbase delivers remote-first, and a project team may combine Netbase staff, approved specialists or disclosed partners, with Netbase remaining accountable for the result. Contributors work under NDA.

What you need is not a list of countries. It is an unbroken chain from every contributor to the party that signs your contract. Put the same questions to any provider. Are contributors employees or contractors? Do their own agreements assign their work to the provider, so that the provider has something to assign to you? Are subcontractors disclosed, and are they bound by the same confidentiality and ownership terms? The global delivery page describes how our teams are composed and what is disclosed.

AI-assisted development

Netbase uses AI-assisted engineering under human review. Any provider using these tools should be able to tell you which ones, whether your code or data leaves your environment to reach them, and who reviews the output before it is committed. If you need a restriction, write it into the project definition rather than agreeing it on a call. For how we source and review what we publish, see our methodology.

Owning the code is not the same as being able to run it

An assignment gives you rights. It does not by itself give you a working system. To change or host the software without the provider you also need:

• repository access with the full history, not a zip file at the end;
• credentials, domains, certificates and account ownership in your name;
• the build and deployment pipeline, with its configuration;
• environment settings and a documented way to handle secrets;
• documentation and runbooks a new team can follow;
• a named person available to answer questions during transition.

Agree these at the start, not when you are leaving. The guide to handover and exit covers what a complete transfer looks like.

Common failure patterns

• A one-line "client owns all IP" clause with no definition of what "all" covers.
• A reusable module discovered after launch, on terms nobody read.
• Repository and cloud accounts held in the provider's name for the whole project.
• Subcontractors who never signed anything that assigns their work.
• A handover that delivers source code but no credentials, pipeline or documentation.

Where Netbase fits

Netbase delivers project-based work in which the intellectual property created for you belongs to you, with productized modules and products licensed rather than transferred, and the final terms set in the project agreement. Which model you buy affects who controls the repository day to day, so read this alongside the engagement models page. The project delivery page explains how acceptance works, since acceptance is often the moment ownership moves, and our Work records show the kinds of systems these terms have applied to.

Ask us the IP questions before the first milestone

Submit a project and ask us to answer every point above in writing. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.