The core answer
The person who writes the code is not automatically the person who owns it for your business. Thai law has default rules, and they differ depending on whether the developer is your employee or an outside contractor. They also stop at the edge of the code that was actually created for you.
The rule (Copyright Act B.E. 2537). A computer program is protected as a literary work (section 4). If the developer is an employee, section 9 says the copyright belongs to the employee unless a written agreement says otherwise, and the employer may publish the work for the purpose of the employment. If the developer was commissioned, section 10 says the hirer owns the copyright unless the creator and hirer agreed otherwise. An assignment must be in writing and signed by both sides (section 17).
Our practical view. Do not rely on the defaults. Use a written contract that names who owns what, assigns the code to your company in writing, lists what the developer may keep (their tools and pre-existing code), and ties payment to tested milestones. The clause checklist in section 8 is the part to hand to your lawyer.
1. Is source code protected by copyright in Thailand?
Yes. Section 4 defines "literary work" to include computer programs, and defines a computer program as instructions, a set of instructions or anything else used with a computer to make it work or produce a result, in any programming language. Section 15 gives the owner the exclusive rights to reproduce or adapt the work, communicate it to the public, rent the original or copies of a program, benefit from the copyright, and license others.
Section 4 also treats modification of a program in a substantial part, without it being a new work, as "adaptation". So if you later hire a second developer to change the first developer's code, you need the right to adapt it, either by owning the copyright or by a licence that covers modification.
2. If I hire a developer, who owns the code?
It depends on the relationship.
| Relationship | Default rule | What it means in practice |
|---|---|---|
| Employee (employment contract) | Section 9: copyright belongs to the creator (employee) unless agreed otherwise in writing. Employer may publish the work as the employment requires. | The company has use rights tied to the job, but not necessarily ownership. Add an ownership clause to the employment contract. |
| Contractor or agency (hire of work) | Section 10: hirer owns the copyright unless the creator and hirer agreed otherwise. | Helpful default, but only for work created under the commission. |
| Freelancer working informally, no contract | Unclear in practice. The facts decide whether it is employment, hire of work or something else. | Avoid. Sign a contract before work starts. |
For a contractor, the contract can be classed as hire of work, which section 587 of the Civil and Commercial Code defines as a contract in which the contractor agrees to accomplish a definite piece of work and the hirer agrees to pay for the result. A fixed-scope software build is usually of this kind. Retainers, staff augmentation and ongoing support may look more like employment or a service arrangement, which is why the label in the contract does not settle the question by itself.
3. Why is a written assignment still necessary?
Four reasons.
- The default has gaps. Section 10 only reaches work the developer created for the commission. Libraries, frameworks, templates and code the developer wrote before your project are not created "for you".
- Section 10 can be varied. If an agency's standard terms say "developer retains all rights", that is the "agreed otherwise" in the statute.
- Proof. In a dispute, a signed clause saying "all code, documents and designs created in the project are assigned to the client" is far easier to show than an argument about classification.
- Section 17. If you want an assignment rather than a licence, it must be in writing, signed by both parties. If no duration is stated, the law treats it as ten years. A permanent transfer needs wording such as "for the whole term of copyright protection".
Moral rights are separate. Under section 18, the creator can claim authorship and object to distortion or modification that damages their reputation, unless otherwise agreed in writing. Contracts often include a clause on how the developer may be credited and that the client may modify the code.
Assignment or licence? A perpetual, exclusive, irrevocable licence can sometimes meet a business need and is common when the developer reuses a core platform for other clients. If you choose a licence, state whether it is exclusive, whether you may modify, sub-license, host with third parties and transfer it in a sale of the business. Our guide on brand and trademark ownership when setting up a company covers the parallel question for names and logos.
4. What should happen to repositories and access?
Ownership of the code means little if the developer holds the only copy. Contract for practical control:
- The repository sits in an account owned by your company (organisation-level), with the developer invited as a contributor.
- Cloud accounts, domain names, app-store listings, API keys and certificates are registered to your company, not to an individual.
- The developer commits regularly, so the code you paid for exists in your repository at every milestone, not only at the end.
- Credentials are handed over through a secure channel and rotated on handover.
- Customer or personal data in test and production systems is handled under rules agreed in advance. See our PDPA compliance checklist and the guide on company AI policy and customer data, which covers source code in public AI tools.
5. What about open-source and third-party components?
Almost all modern software includes components the developer did not write. Their licences travel with them. At a practical level:
- Permissive licences generally allow use in commercial products if you keep the required notices.
- Copyleft licences can attach conditions to software that combines with or distributes the component, and in some cases may require releasing your own source code under the same licence. The conditions differ by licence and by how the software is used (for example, distributed to customers or only run on your server), so have the actual licence reviewed before you rely on a component.
- Paid third-party components (SDKs, fonts, templates, payment or map APIs) usually have per-project or per-seat fees and may not transfer to you automatically.
Contract points: the developer lists every third-party and open-source component with its licence (a bill of materials), warrants that nothing in the deliverable forces disclosure of your proprietary code, and does not add components with restrictive licences without your approval. The developer should also warrant that they have the right to deliver the code and that it does not infringe others' rights. We do not give a verdict on a specific licence here. Confirm the text of the licence involved.
6. How should milestones and acceptance testing work?
Thai law does not set a software acceptance procedure, so the contract must. This matters because under section 598 of the Civil and Commercial Code, if the hirer accepts the work, defects and all, without objection, expressly or by conduct, the contractor is generally not liable for the defect, unless it could not be discovered at handover or the contractor concealed it. Silence after delivery can therefore work against you. Set a fixed review period, and say that use in production for testing is not acceptance.
Hypothetical example (illustrative figures). A company commissions an online ordering system for THB 600,000. The table below shows how payment can follow tested deliveries.
| Milestone | What to deliver | Acceptance test | Payment (example) |
|---|---|---|---|
| 1. Specification and design | Written requirements, user flows, screen designs, technical plan | Client signs off the written scope; open questions closed | 20% |
| 2. Core build | Working core features on a test server, code in the client's repository | Test cases from the specification pass; no open critical defects | 30% |
| 3. Integration and data | Payment, notification and data import working with test accounts | Agreed test script run by the client; import reconciled to source data | 20% |
| 4. User acceptance testing (UAT) | Full system on a staging environment, release notes | Client tests for the agreed period; defects classed by severity; no critical or major defect open | 20% |
| 5. Go-live and handover | Production deployment, source code, documentation, credentials, training | Production smoke test; handover checklist signed | 10% (withheld until signed) |
Good acceptance wording includes: who tests, on what environment, with which test cases, how many days to review (for example 7 to 14, set to the project), how defects are classed (critical, major, minor), when the developer must fix them, and what happens if the review period passes with no reply. Many clients prefer that silence is not deemed acceptance; if the developer insists on deemed acceptance, make the period long enough to test properly.
7. Changes, defects and ending the contract
Change requests. Scope creep is the most common dispute. Require changes to be written, priced and signed by both sides before work starts, with the effect on schedule stated. Say who decides if a request is a "change" or a "defect".
Warranty and defects. Absent a contrary term, section 600 of the Civil and Commercial Code makes the contractor responsible for defects that appear within one year of delivery (five years for buildings on land, which is not relevant to software). Section 601 bars a claim brought more than one year after the defect appears. The statute was written for physical work, and how a court would apply it to software is a question to put to a lawyer, so set the warranty by contract: length, definition of a defect, severity levels, response and fix times, and whether support after the warranty is a separate paid plan.
Ending the contract. Under section 605, the hirer may end a hire-of-work contract while the work is unfinished, by compensating the contractor for loss from the cancellation. The contract should be more specific: notice period, payment for work done to date, and, importantly, that all code and documents created so far are delivered even if the project is stopped. Also cover termination for the developer's breach (missed milestones, abandonment) and for yours (non-payment), and tie transfer of ownership to payment so that you are not forced to choose between paying a disputed bill and losing the code.
Handover. On completion or termination: full source code and build scripts, database schema, deployment instructions, environment and credentials list, the open-source bill of materials, and a short period of knowledge-transfer support. If the developer wants to keep the repository or hosting, require an escrow or a regular copy delivered to you.
8. Contract clause checklist
- Parties, project description and a written specification attached as an annex.
- Fixed price or time-and-materials rules, with a payment schedule tied to accepted milestones.
- Ownership: express written assignment (section 17) to your company, stating it is for the whole term of copyright, signed by both parties.
- Carve-out: developer's pre-existing tools and code are listed, with a licence to you that is perpetual, irrevocable and covers modification and hosting.
- Open-source and third-party list (bill of materials) with licences, plus a warranty on no disclosure obligations for your code.
- Repository and accounts owned by your company; regular commits; handover of credentials.
- Acceptance procedure: test cases, environment, review period, severity classes, deemed-acceptance rule.
- Change-request process in writing, priced before work.
- Warranty period, defect definition, fix times and support terms.
- Confidentiality, personal-data handling and security obligations (see the PDPA guide above).
- Moral rights and credit: how the developer is credited; client may modify.
- Subcontracting only with your approval, and the same assignment from each subcontractor.
- Delay remedies, liability cap and indemnity for infringement claims.
- Termination rights, payment for work to date, and delivery of code on exit (section 605 applies as the default).
- Governing law, forum, and e-signature arrangements. See electronic signatures on company contracts.
Written contracts are far easier to prove than spoken ones; see why in verbal contracts and their enforceability.
Further reading
- Brand and trademark ownership when setting up a Thai company
- Company AI policy and customer data in Thailand
- Electronic signatures on company contracts
- Are verbal contracts enforceable in Thailand?
- BOI for SaaS founders: overseas IP and Thai development
Own the code on paper before you pay for it: a signed assignment, a company-owned repository and payment tied to tested milestones protect you better than any default rule.
We draft and review software development, licensing and service agreements for Thai businesses. Initial consultation is free — call +66 92 254 2045 or send us the details. See also contracts and documents and legal retainer.
This guide is published by Suwanvara Law Firm — a Khon Kaen law firm established in 1986. General information only, not legal advice on a specific matter.
