Who Owns the Source Code of Your Custom Business System?

A business owner who commissions a custom system — a booking platform, an inventory dashboard, an app tying a few tools together — rarely asks about source code ownership until something goes wrong: the developer stops responding, a second vendor is brought in to make changes, or the business wants to move the system to a new host. By then, whether you actually own what you paid for depends entirely on what a contract said months or years earlier, not on how large the invoice was. This guide explains what Malaysian law actually says, why copyright alone often isn't enough, and the concrete questions and documents that settle the question before it becomes a dispute.

The short answer: Malaysian law leans in your favour, but only by default

Under Section 26 of Malaysia's Copyright Act 1987, when a copyright work, including software, is created as a commissioned work rather than under a contract of employment, ownership is deemed to transfer to the person who commissioned it, unless the contract between the parties says otherwise. In plain terms: if you paid a developer to build a custom system for your business, Malaysian law's starting position is that you, not the developer, hold the copyright, provided nothing in the agreement reverses that.

Why so many businesses still don't actually own their code

The catch is in "unless the contract says otherwise." Many standard developer and agency contracts include a clause that retains intellectual property with the vendor and licenses the client only a right to use the finished software, or say nothing about ownership at all, leaving it to be argued over later. An informal engagement with no written contract is worse still: the statutory default may technically apply, but with nothing in writing, it is much harder to prove what was actually agreed if a dispute ever reaches that point.

Copyright is not the same as usable ownership

Even a business that holds clear copyright over its custom system can still be functionally locked out of it. Owning the copyright is a legal right; running, maintaining and changing the system needs the actual working parts, which copyright alone does not hand over automatically:

• The source code itself — not just access to a hosted, compiled version, but the underlying files a developer would need to read, edit and rebuild the system.
• Technical documentation — how the system is structured, what each part does, and how to set it up on a different server if needed.
• Admin, server and database credentials — the logins that actually let someone operate and change the system, not just use it.
• Clarity on third-party and open-source components — most custom builds use existing libraries and frameworks under their own separate licenses, which a business should know about even if it owns everything original built on top of them.

A business that owns the copyright but never receives these still depends entirely on the original developer to do anything with its own system.

What "commissioned work" actually means under the Act

It's worth being precise about what the law is actually deciding here: copyright, not a trademark, a patent, or a business's data. Copyright protects the specific code and documentation as a creative and technical work. It doesn't, by itself, say anything about who owns the data the system stores once it's in use, or the brand name the system is sold or marketed under — those sit under different areas of law and are worth settling separately if they matter to the project.

Section 26 draws a line between two situations that are easy to confuse. If software is written by someone's own employee, as part of their job, the employer owns it under the normal rules of a contract of service — there's rarely a dispute there. A custom business system is almost always the second situation instead: a contract for service, where an outside developer or agency is commissioned and paid a fee to produce a specific piece of software. It's this second category the "deemed to transfer to the commissioning party" default applies to, and it's also the category where the contract's wording does the real work, since the law explicitly lets the parties override the default in either direction.

How the contract actually changes the outcome

The same custom system, built by the same developer, can land in three different ownership positions depending entirely on three or four sentences in a contract:

Only the first row is a position worth relying on. The other three all leave a business exposed to some degree, even though the second and fourth technically have the statutory default on their side — a default that has never been argued in your specific case is not the same thing as a settled right.

Red flags to look for in a vendor's standard contract

Most agencies and freelance developers work from a template contract they reuse across clients, and templates vary enormously in how they handle ownership. A few clauses are worth reading twice before signing anything:

• "Client receives a licence to use the Software" rather than "ownership transfers to Client" — a licence is permission to use something someone else owns, not ownership itself.
• IP transfer conditional on "full and final payment" with no further detail — reasonable on its face, but worth confirming it actually triggers automatically rather than requiring a separate signed handover document nobody follows up on.
• No mention of source code delivery at all, only "the Software" — ambiguous enough to be read either way later, which is exactly the kind of ambiguity a dispute turns on.
• Ownership or access tied to an active maintenance contract — meaning access could lapse the month a retainer is cancelled, even for code already paid for in full.
• No disclosure clause for third-party or open-source components — leaving a business unaware of what it's actually allowed to do with parts of its own system.

Questions to ask before you sign, not after

The cheapest time to settle ownership is before a quote is accepted, while it is still one line in a contract rather than a dispute. Before signing, ask:

• Does the contract explicitly state that source code and IP transfer to me, and at what point — ideally on final payment or project sign-off?
• Will I receive the full source code repository, not only a built or hosted version, and how will it be delivered?
• Who owns the hosting, domain, API and admin accounts the system runs on once the project is handed over?
• Are any open-source or third-party components used, and under what licenses?
• Does ownership or access change if I stop paying an ongoing support or maintenance retainer?
• Can I take the code to a different developer later if I need to?

What if you never got this in writing?

Plenty of businesses are already running a custom system built years ago on a handshake or a short email exchange, with no IP clause anywhere. The statutory default under Section 26 likely still favours the business as the party that commissioned and paid for the work, but relying on that in an actual dispute is weaker than having it in writing. The practical fix does not require reopening old arguments, and is usually simpler than it sounds:

• Find whatever contract or email thread exists and check it for any IP or ownership wording at all, even informal.
• Send a short, polite written request asking the developer to confirm, in writing, that ownership sits with the business and to provide the source code repository, documentation and admin credentials.
• Ask specifically about third-party and open-source components used in the build, so there are no surprises later if the system needs to move to a new developer.
• Keep that confirmation on file alongside the original engagement records — it becomes the document a future dispute, audit or new developer would actually need to see.
• If the developer is unresponsive or refuses, that in itself is useful information, and the point at which getting advice from a lawyer becomes worthwhile rather than optional.

This applies whether it's a web app, a business system or a mobile app

Source code ownership is not specific to one type of build. The same Copyright Act provision, and the same practical checklist of code, documentation, credentials and license clarity, applies whether the custom project is a web app or dashboard, a multi-role business system with integrations, or a mobile app. The platform changes what the code looks like; it does not change who is entitled to hold it.

This is general information about how Malaysian copyright law treats commissioned software, not legal advice for a specific contract. For a live dispute or an agreement under negotiation, get advice from a qualified lawyer.

Common mistakes

• Assuming the statutory default settles everything. Section 26 only applies "unless the contract says otherwise" — it's a starting position, not a guarantee, and many standard contracts already say otherwise.
• Treating copyright and source code delivery as the same thing. A business can own the copyright on paper and still never receive a single file it can actually open and edit.
• Signing a contract with no IP clause at all because the relationship feels informal or trusted. A good relationship today doesn't settle what happens if the developer is unreachable in two years.
• Not asking about third-party and open-source licenses. Owning your original code doesn't clarify what you can and can't do with the libraries it's built on.
• Letting ownership depend on an ongoing retainer without reading that clause carefully — some contracts quietly tie access to a support subscription staying active.
• Waiting until a dispute to ask for the source code. The best point of leverage to request it is before final payment, not after the relationship has already soured.
• Assuming an old, undocumented system is a lost cause. A written request to the original developer, even years later, is usually still worth sending before assuming the position can't be fixed.

Where Gotka Technologies fits

Gotka's App & System Development service builds web apps, business systems and mobile apps, with pricing confirmed by a written quote rather than a fixed rate card, so the terms of a project — including what is handed over at the end of it — are settled up front rather than assumed. A system built this way still needs somewhere reliable to run; Gotka's Cloud Hosting plans on LiteSpeed servers cover that alongside the rest of a growing business's website and email. If you're still deciding whether a custom build is the right call in the first place, see our guide on off-the-shelf software vs a custom system: how to choose.

Key terms used in this guide

• Copyright Act 1987: the Malaysian law governing ownership of creative and software works, including Section 26 on commissioned work.
• Commissioned work: software built by an outside party for a fee, rather than by an employer's own staff.
• Contract for service vs contract of service: the legal distinction between hiring an independent contractor (for service) and employing staff (of service), which determines which default ownership rule applies.
• IP clause: the part of a contract stating who owns the intellectual property created under it, and when ownership transfers.
• Source code: the actual, human-readable files a developer writes, as opposed to a compiled or hosted version a client can only use, not edit.
• Statutory default: the ownership outcome the law applies automatically when a contract is silent, which a written clause can override in either direction.
• Open-source component: existing code used inside a custom build under its own separate license, which a business should know about even for code it otherwise owns outright.
• Written quote: a priced, scoped proposal that, done properly, settles cost, timeline and ownership terms before development starts.