Who Owns the Source Code? Ownership and Handover Explained

Of all the questions that come up between the first quote and the signed contract, one of the two most common is whether the client actually owns the source code. The answer is not "it depends how well you negotiated." There is a default rule in law, and if the contract does not address it clearly, the default applies.

The default rule: no written agreement, no ownership

Article 11 of the Regulations on Computer Software Protection states that where software is commissioned from another party, ownership of the copyright is determined by a written contract between the commissioning party and the developer. In the absence of a written contract, or where the contract is silent on the point, the copyright belongs to the developer. Two things follow from this. First, the agreement has to be in writing; verbal assurances do not count. Second, handing over source code and transferring ownership are separate acts. The first transfers files, the second transfers rights. A contract that says only "source code shall be delivered" leaves the client holding compilable code while the rights to copy, modify, sublicense and register the software may still sit with the vendor.

Six deliverables that belong in every handover

Once source code ownership is settled, the handover itself still needs a standard. Projects that end with a single zip file typically cost the incoming party two to four weeks just to get the environment running, and that time is ultimately paid for by the client. A complete handover includes:

• The full code repository, with commit history on main and development branches, not just a final snapshot;
• Build and deployment scripts that run from scratch on a clean server;
• Database schema scripts and a note on initial data;
• A third-party dependency list with version lock files such as package.json, pom.xml or requirements.txt;
• API documentation and environment configuration, including test and production addresses and how credentials are transferred;
• Account and asset transfer: domain, servers, cloud platform, app store developer accounts, payment merchant accounts.

The two items most often missing are the build scripts and the dependency list. Without them, the source code is just a pile of text that has to be re-excavated later.

Three ownership arrangements and what each costs

The first is full ownership by the client. This is the most common arrangement and the most expensive: the developer gives up the right to reuse the code elsewhere, and quotes typically run 5 to 15 percent higher than a licence-only arrangement.

The second is client ownership with the developer retaining its own generic components and frameworks. This is the middle path, priced close to the first option, but the contract annex must list item by item which components count as generic, or disputes will follow.

The third is developer ownership with the client receiving a perpetual, irrevocable licence that permits modification. This is the cheapest option and suits internal management systems where the code never needs to be transferred to a third party. The licence must state explicitly that the client may modify the code and may engage a third party to modify it, otherwise a change of vendor gets blocked.

Open source components and third-party SDKs

More than thirty percent of a typical delivered codebase is open source components, and two real risks sit there. The first is strong copyleft licensing, the GPL family in particular, which requires derivative works to be released under the same terms; using it inside a closed-source commercial product is a breach. The second is commercial SDKs priced by call volume or device count, where the client's own expansion after handover lands the bill on the client. Ask the developer for a third-party component list annotated with licence type and billing model during contracting. One page saves a great deal of trouble later.

Software copyright registration: who files and who is named

Registration is not a precondition for holding the copyright, but it is the evidence used in infringement claims, subsidy applications and public tenders. The registered owner should match the party named as copyright holder in the source code ownership clause. The common mistake is a developer quietly registering in its own name while the client only finds out later. A workable clause: within 30 days of acceptance the developer supplies the materials needed for registration, including thirty pages of source code from the beginning and thirty from the end, a user manual and the application form; registration is filed in the client's name and the client pays the fee.

Five sentences you can copy into the contract

All source code, design files, documents and copyright arising from this project, meaning all economic rights other than the right of attribution, vest in the client on the date the client pays the full contract price. The developer transfers the six deliverables above within ten working days of acceptance and supports one complete deployment in the client's new environment. The developer warrants that the deliverables contain no code infringing third-party intellectual property and bears responsibility and compensation if a dispute arises. The list of open source and commercial third-party components is attached, with licence type and billing model disclosed in writing by the developer. The developer may not reuse this project's code for a competing product sold to another client in the same industry for 24 months after delivery.

Source code ownership is one sentence during negotiation and one lawsuit after things go wrong. It is not really a technical clause; it is a pricing clause. Decide which rights you need first, then judge whether the quote makes sense.