If the contract says nothing about source code ownership, who owns it by default?

Where nothing has been specifically agreed, ownership falls back to the default position in copyright law. Taiwan's Copyright Act sets defaults for works created by a party commissioned to do so, and that default does not necessarily mean the party who paid automatically acquires every right. In other words, you may have paid and still not hold the full right to modify or reuse the work. That is precisely why an ownership clause belongs in the contract rather than being asserted after the fact. If the agreement is already signed and silent on the point, the practical route is to negotiate a written addendum with the vendor; doing that while the working relationship is still good is almost always the cheapest version of the conversation. For how the rights actually fall in your case, have a lawyer read your specific contract; this article covers the concepts and the preparation only.

The vendor says the source code costs extra. Is that reasonable?

It depends entirely on what was agreed. Some engagements are licensing arrangements rather than transfers of source code — for example, when a vendor customizes its own packaged system, the core does not travel with the project, and that is usually reflected in how the work was quoted. What is not reasonable is a contract that never addressed the question and a charge that appears only at closeout; that is a dispute created by vague terms. There is one way to avoid it: write down before signing what the deliverables are, when each one is handed over, and whether it is already covered. When an offer looks unusually cheap, the arrangements for source code and ongoing maintenance are the first things to confirm.

After the handover, do I need technical staff of my own?

Not necessarily a full-time engineer, but at least one person who knows where everything lives, how to get into each account, and who to call when something breaks. The value of a handover is not that you can change the code yourself; it is that you can hand the work to someone else at any time, which is the foundation of both leverage and risk control. A common arrangement is to name an internal point of contact who holds the accounts and documentation while day-to-day maintenance stays outsourced. The genuinely dangerous situation is one where everything sits with the vendor alone, because if that vendor stops trading or stops replying, rebuilding costs far more than keeping a current list ever would.

Source Code Ownership and Project Handover

Most projects run peacefully enough while they are in flight. The real test arrives at closeout, or on the day you decide to change vendors. The conversation tends to go like this: “Can we have the source code?” “The contract never said we had to hand it over.” “But we paid for it.”

Disputes of this kind are almost never a matter of bad faith. They happen because rights and deliverables were not written down at signing. What follows sets out how ownership actually works, what the contract should say, what you should physically receive at handover, and what to do when the other side will not cooperate. One caveat first: where an actual determination of rights is at stake, have legal counsel assess your specific contract. What is covered here is the concept and the practical preparation.

First, separate copyright, delivery, and the right to use

In everyday conversation, “this system is ours” collapses three different things into one sentence.

Copyright is the legal right in the code itself: whether it can be modified, whether it can be reused, whether it can be licensed to a third party. It does not transfer automatically because you paid for the work. It follows what the contract says.

Delivery of the source code simply means receiving the files. Receiving files is not the same as holding the right to modify or reuse them — the two are separable, and arrangements where you get the files but not the rights genuinely exist.

A right to use (a license) permits you to use the work within an agreed boundary: internal use only, perhaps, with no sublicensing and no derivative works. The boundary can be drawn wide or narrow, depending on how the clause is written.

How to decide which you need. If the system is a core business asset that you may extend, migrate to another vendor, or spin further products out of, push for assignment of copyright, or at minimum for a complete right to modify and reuse. If it is a standard marketing site or a conventional tool, a license is usually sufficient, and it often buys you a more sensible cost structure in exchange.

Why “give us the source code” is not specific enough

That sentence leaves at least three gaps.

The scope is vague. A system typically contains several distinct layers: code written specifically for your project, the vendor’s own shared components or framework, third-party open-source packages, and commercial components that were purchased. The vendor’s own layer may not travel with the project, and commercial component licenses may be registered in the vendor’s name. Each layer needs to be named.

The timing is vague. Handed over when? At closeout, when the final payment clears, or at the end of the warranty period? What happens if the engagement stops partway through? All of those scenarios deserve a sentence.

The form is vague. Receiving one archive file is very different from receiving the full version history — the complete record of every change made during development. With only the final files, whoever picks up the work next has no view of how anything evolved, and maintenance gets meaningfully harder.

Open-source license conditions are worth noting separately. The open-source components inside a system each carry their own requirements, and some of them shape how you may later distribute or commercialize the result. Open Source Licensing in Plain Language is a reasonable place to build the basic judgment.

The clauses to settle before signing

None of this needs to read like a legal treatise, but the following items should exist as written text:

Copyright ownership. Assigned to the client, retained by the vendor and licensed to you, or held jointly. If it is a license, state the boundary: modification, sublicensing, any limits of term or territory.
The deliverables list. Source code, design source files, database structure, deployment and environment configuration notes, operating manuals — itemized.
Timing and conditions of delivery. Tied to a specific payment milestone or a specific completed phase.
What the vendor retains. Which shared components do not travel with the project, whether you receive a license to use them, and whether you may modify them later.
What happens if the engagement stops early. How completed work is handed over and how accounts are settled.
How accounts and environments transfer. Who holds the primary account, and the mechanism for moving it.

The most common misstep is treating one line on a quotation — “includes source code” — as sufficient. A quotation is usually not a complete contractual document, and that phrase answers none of the questions above. Make these items mandatory questions when you evaluate partners; How to Choose a Software Development Company collects the other questions worth asking and the red flags worth watching.

Handover checklist one: code and version history

At the actual handover, the thing to confirm about code is not that you received it but that what you received works:

The complete version control history, not only the final revision.
The configuration examples needed to rebuild the project in a different environment, excluding production credentials.
Documentation that can at least answer three questions: how to install it, how to run it locally, how to deploy it to production.
An export of the database structure and any seed data.

The way to verify this is direct. Ask a different engineer — your future maintenance vendor, for instance — to follow the delivered documentation and bring the system up in a clean environment. If it runs, the handover is complete. If it does not, something is still missing. This step is worth performing before the final payment clears.

Handover checklist two: servers, domains, and environments

This is where things go wrong most often, because the pieces are scattered:

The domain. Whose name it is registered under, who holds the registrar account, when it expires, whether auto-renewal is switched on.
Hosting or the cloud platform. Account ownership, whose card the billing is attached to, what else is running there.
DNS configuration. What records currently exist and who manages them.
Certificates. Expiry dates and how renewal happens.
Backups. Where they live, how often they run, how to restore from them, and whether a restore has ever actually been rehearsed.

The domain deserves priority above everything else here. If it is registered under the vendor or a former employee, and that person becomes unreachable, your brand’s web address and email are both affected, and the recovery process is genuinely painful. If the relationship between domains, hosting, and DNS is unclear, read Domains and DNS in Plain English before working through the list.

Handover checklist three: third-party service accounts

Modern systems connect to a good number of outside services, and every one of them is a separate account with its own permissions:

Payment processing, logistics, SMS or email delivery, maps, analytics, error monitoring, social login, cloud storage, and ticketing or invoicing systems.

For each, confirm three things: whose name the account is registered under, whose phone the login and two-factor authentication are tied to, and who receives the bill. The recommended pattern is to register every service under a shared company mailbox and issue sub-accounts to the vendor, rather than handing over the primary account. When you change vendors, you then disable a set of sub-accounts instead of resetting each service one by one.

The most common misstep is inventorying only the services currently in use and missing the accounts created for testing or as a fallback. Nobody looks at those day to day, but they may still be billing, and they may still hold access to production.

Handover checklist four: documentation and operational knowledge

The documentation does not need to be voluminous, but it should answer what an incoming team asks first:

Which major functional modules exist and what each is responsible for.
Where the important business rules are expressed — pricing logic, permission rules.
What scheduled jobs run regularly, and when.
What has gone wrong in the past and how it was handled.
Known limitations and items that were never addressed.

That final item carries the most value. A handover that honestly lists known problems is far more trustworthy than one that looks flawless — problems do not disappear because nobody wrote them down; they simply cost the next person time to rediscover. As for who is responsible for what afterwards: how responsibility, service levels, and fees are divided during the maintenance period belongs to a separate agreement, and that is the subject of What Website Maintenance Actually Covers; this article deals only with the moment of closeout or changeover, and what you should have in your hands by then.

What to do when the vendor will not cooperate

Establish one thing first: is the other side unwilling to hand things over, or unable to? The second case is more common than you might expect — after staff turnover, a small team may genuinely be unable to locate complete records itself. The two situations call for different handling.

A workable sequence looks roughly like this. Put the request in writing, by email if nothing else, listing the items to be delivered, citing the contractual basis, and setting a clear date for a response. In parallel, inventory what you already control: anything registered in the company’s name, under a company mailbox and a company payment method, can usually be dealt with without the vendor’s agreement, so take control of those first. If there is still no response, move to the dispute mechanism in the contract, and at that point bring in legal counsel to assess the position.

In parallel, prepare to stop the bleeding. Confirm that domain and hosting renewals will not lapse, that backups are in your possession, and that some alternative exists to keep operations running. The worst real-world outcome is not failing to obtain the source code; it is a domain expiring or a server being suspended during the dispute, which takes the service down outright.

Prevention is far cheaper than remedy. Keep three things permanently in your own hands: the domain registered in the company’s name, every third-party service registered under a shared company mailbox, and a quarterly check that backups can actually be restored. With those three in place, even an unhappy ending to a vendor relationship leaves you holding the basis for continued operation.

Run this checklist against the system you have now and a few entries will usually come back as “I am not sure who holds that” — those are the ones to deal with first. Bring your situation to NETVANA, whether that means writing rights and deliverables into a new agreement or auditing the handover gaps around a system you already run. Software services are quoted individually rather than sold as fixed packages; once project fees are settled we transfer source code, design files, and related documentation in full, and for what each service includes and delivers, see the software services overview.

Further reading: the contract model directly shapes how deliverables get agreed, so see Fixed Price or Agile. For assessing an older system somebody else left behind, see Legacy System Modernization. For tying acceptance to payment milestones, see How Software Acceptance Works. And because hosting choices affect how difficult a handover becomes, read How to Choose Web Hosting.