Who Owns Your Software? Source Code & Copyright (2026)

Paying for development does not automatically make the copyright or the source code yours. Under Japanese copyright law, unless the contract says otherwise, the copyright stays with the party that actually wrote the program — the development company. For the client to own the rights, the contract must explicitly state that copyright is assigned to the client. Leaving this vague is where problems start: it surfaces years later, when you want to modify the system or hand it to another vendor.

This guide is written for non-technical owners and procurement leads. It covers four things in order: (1) copyright and source code are two separate things, (2) which contract clauses to check, (3) what actually goes wrong when you cannot secure the rights, and (4) a pre-order checklist.

These are easily confused, but you need to treat them separately.

In other words, "receiving the source code" and "being assigned the copyright" must be agreed as two separate promises. You may hold the source files, yet if the copyright remains with the developer, you may need permission to modify them. Only when you secure both do you truly own a system you can freely grow over time.

Intuitively you assume "I paid, so it's mine," but copyright law works the opposite way. Absent a specific clause, the copyright to the program belongs to the development company that created it. Paying for it does not, by itself, transfer the copyright to you.

So when the contract is silent on rights, it's not unusual for the relationship to default to "the source code belongs to the developer; the client merely has a license to use it." Disputes usually erupt because the client never knew this, and only discovers it years later when a modification or vendor switch is on the table.

- You can't switch developers: without the source code, a new vendor can't inspect the internals, so only the original developer can maintain it — classic vendor lock-in
- Every change means extra fees and negotiation: if the rights sit with the other side, even small changes require per-request quotes and permissions, hurting you on speed and cost
- You're stuck if the developer folds or goes silent: if both the rights and the source live with them, the day the company disappears, nobody can touch your system
- You can't reuse or resell it: if you want to spin your workflow off into a separate product, you can't do so freely without owning the copyright

The third risk is underrated. We cover the fallout in What to Do When You Can't Reach the Company That Built It and the Guide to Switching Developers, but securing the rights and the source at ordering time prevents most of these situations up front.

Even if the legalese looks dense, the points that matter are few. When you receive a contract (or its draft), confirm these three are spelled out.

"Moral rights" may be unfamiliar: these remain with the maker even after copyright is assigned, covering things like not having the work altered without consent. To modify freely in the future, it's standard practice to add a line that the developer "will not exercise moral rights." The difference between contract types (contract-for-work vs. quasi-mandate) is explained in The Basics of Software Development Contracts.

Note that assigning all rights to the client may raise the price, because the developer can no longer reuse the same components (generic libraries) on other projects. A practical compromise is a line like "business logic rights go to the client; generic components remain reusable by the developer." The key is to put in writing, before ordering, exactly how much freedom your company will have — so no one argues about it later.

Modern development routinely mixes in existing open-source software (OSS) and AI-generated code. Both carry rights caveats.

- OSS comes with license terms: even if you contract for "copyright assigned to the client," the rights to the OSS parts do not transfer. OSS is used under its own license (MIT, GPL, etc.). Some, like GPL-family licenses, impose obligations when you modify or distribute, so ask for a list (a bill of materials) of which OSS was used
- AI-generated code: how copyright applies to AI-generated code is still evolving. Confirm how far the developer can guarantee the rights, and at minimum, get a warranty that the code does not infringe third-party rights

- [ ] Does the contract clearly state that copyright is assigned to the client?
- [ ] Is there a clause that moral rights "will not be exercised"?
- [ ] Do the deliverables explicitly include the full source code, build steps, and design docs?
- [ ] Have you reviewed the list of OSS used and their licenses?
- [ ] Is there a warranty that no third-party rights are infringed?
- [ ] Have you checked the price difference between full assignment vs. letting the developer reuse generic components?

Deciding these before ordering costs almost nothing, while negotiating "can I have the rights after all?" once the system is live inflates both cost and effort. For what to receive at acceptance, see What Is Acceptance Testing? What to Confirm at Handover.