Who owns the source code in Kenya?

Almost every article a Kenyan founder finds on this question repeats the same line: “the developer owns the code unless they assign it to you.” That is the United States and United Kingdom default. It is not the full Kenyan position. Under the Copyright Act, source code is protected as a literary work, copyright in it arises automatically the moment it is written down, and the first owner is the author who wrote it. But two statutory exceptions flip that ownership to the person paying: code commissioned from an outside developer is deemed transferred to the client who commissioned it, and code written by an employee in the course of their job is deemed transferred to the employer. Both defaults are displaced by whatever the parties agree, and the statute does not even require that agreement to be written. So the honest Kenyan answer is not “the developer owns it” and not “you bought it so you own it.” It is this: ownership turns on how the work was procured and what the parties agreed, and only a signed written assignment gives you a clean transfer of ownership. This guide walks through the default rule, the commissioned-work and employee exceptions, why an unsigned transfer of ownership has no legal effect, and the written assignment that settles it.

Source code is protected, and protection is automatic

Start with what the law is protecting. The Copyright Act defines a computer program as a set of instructions, expressed in words, codes or schemes, capable of making a computer perform a task, and the same section folds computer programs into the definition of a literary work, alongside tables and compilations of data stored in a computer.¹ So source code is not its own special category of property. It is protected as a literary work, the same way a manuscript is.

Two consequences follow, and both matter for founders:

• Copyright in code arises automatically. A literary work is eligible for copyright once sufficient effort gives it an original character and it is reduced to material form. Rights accrue to the author automatically on affixation in material form, and non-registration or the absence of formalities does not bar the author’s claim.² The moment a developer commits code, copyright exists. Nobody has to register anything for the work to be protected.
• The source code is where the protected expression lives. Copyright protects the expression of an idea, not the idea itself. The High Court has confirmed that software is protected as a literary work, that this protection does not depend on registration because it accrues automatically on fixation, and that in software the expression of the idea is manifested through the source code.³

That second point cuts both ways. The same case that confirms source code is the protected expression also dismissed the claim, because the plaintiff could not show its source code had been fixed and copied. Owning code is one thing; being able to prove what you own is another. For a founder, that is an early argument for getting the code, the repository and the documentation actually delivered into your hands, not just promised.

The default first owner is the person who wrote it

Here is the rule every founder should know before negotiating with a developer. Copyright vests initially in the author.⁴ The author is the person who created the work. So as a starting point, a developer who writes code on their own account is the first owner of the copyright in it.

This is the part the foreign articles get right and the part founders intuitively fear. But it is only the starting point. The same section that vests copyright in the author carries two provisos that move ownership somewhere else depending on how the work came to be made. Those two provisos are the whole game in Kenya, and they are what the competing articles miss.

Exception one: commissioned work goes to the client who paid for it

This is the headline correction. Where a work is commissioned by a person who is not the author’s employer under a contract of service, the copyright is deemed to be transferred to the person who commissioned the work, subject to any agreement between the parties excluding or limiting that transfer.⁵

Read that slowly, because it is the opposite of the default every other article assumes. For genuinely commissioned work in Kenya, the statute presumes the copyright passes to the commissioning client. A client who commissions and pays an independent developer, with no contrary term, is treated by the statute as owning the copyright. The developer who wants to keep ownership is the one who has to say so.

Two cautions keep this honest:

• The transfer is “subject to any agreement between the parties.” A term to the contrary displaces the default in either direction. So a developer can agree to retain ownership, and a client should not assume the default does all the work, because the agreement controls. On the face of the statute, that displacing agreement does not have to be in writing. That is precisely why you should never rely on it being oral: an oral or conduct-based variation is a fact you would have to prove in court, and any actual transfer of ownership has its own writing-and-signature requirement (covered below). Reduce the ownership term to a signed clause and the argument never starts.
• A “deemed transfer” under section 31 is a statutory presumption of who is the first owner. It is not a substitute for the written, signed instrument that an actual assignment of copyright requires. The cautious practice, and the one we follow, is to spell out ownership of the code in the engagement contract itself rather than rely on the presumption.

How much weight have the courts put on this in a software dispute? Less than you might hope. The closest Kenyan authority on who owns commissioned software did not turn on the section 31 presumption at all. A developer had built and deployed its software on the commissioner’s servers; the commissioner later claimed it owned the intellectual property, relying on a clause in a draft agreement that said IP deriving from the consultancy services would belong to it. At the interlocutory stage, the court found the developer had a prima facie case that it owned the software, because the software pre-existed the engagement, no formal development or assignment agreement was ever executed, and the commissioner’s own conduct in building a replacement tool tacitly admitted the developer’s ownership.⁶

The practical lessons from that case are sharper than the statute alone:

• A draft IP clause that was never executed did not transfer anything. An agreement you negotiated but never signed protects nobody.
• Where software pre-existed the engagement, that fact helped the developer show, at the interlocutory stage, that it was the prima facie owner. The court did not decide what the commissioner ultimately held. But it points to a wider rule that flows from the licence-and-assignment framework, not from this ruling: where a developer brings an existing product and merely configures it for you, what you acquire is more likely a licence to use it than ownership of the underlying code, unless a signed assignment says otherwise.
• The court reasoned from the parties’ intent and conduct and from the absence of a signed agreement. Ambiguity got litigated. A clear signed clause is what avoids being there in the first place.

No Kenyan court has yet squarely decided, in a final judgment, that a commissioning client owns the code purely on the strength of the section 31 presumption. The closest cases were interlocutory or turned on other points. That very uncertainty is the argument for not relying on the presumption at all: a signed assignment puts ownership beyond the reach of an untested default.

Exception two: employee-created code goes to the employer

The second proviso covers code written in-house. Where a work, not having been commissioned, is made in the course of the author’s employment under a contract of service, the copyright is deemed to be transferred to the author’s employer, again subject to any agreement excluding or limiting the transfer.⁷ So code written by an employed engineer, within the scope of their job, belongs to the employer by default.

The hinge word is “contract of service.” That is the legal label for an employee. It is distinct from a “contract for services,” which is what governs an independent contractor or consultant, and an independent contractor falls under the commissioning limb, not the employment limb. The two routes lead to similar destinations (the business, not the individual coder, owns the work by default), but they get there through different provisos, and the framing of the relationship decides which one applies.

This employee dimension is what drives a recurring kind of dispute: staff who developed systems while employed later building competing software after they leave. That fact pattern featured in an early Kenyan case over six financial software systems the plaintiff had registered with the Kenya Copyright Board, which former personnel allegedly used to build a competing product.⁸

The employee-versus-contractor line is well developed in Kenyan employment law, but no reported decision has yet worked it into a settled test for who owns code in a copyright dispute. Rather than gamble on which proviso a court would apply to your facts, define the relationship and assign the copyright expressly in the contract, so the outcome does not depend on that characterisation at all.

Does paying for the code mean you own it?

No. Payment is neither sufficient nor the deciding factor on its own. What governs is the combination of how the work was procured and what the parties agreed, and a clean transfer of ownership still needs a signed instrument. Hold the three procurement pathways apart, because collapsing them is exactly the mistake the competing articles make:

Notice what payment does and does not do. In the employee and commissioning scenarios, the default already favours the business, with or without a payment narrative. In the no-contract scenario, the fact that you paid does not by itself transfer copyright; it leaves you arguing, as the commissioner in Iko discovered, from conduct and intent rather than from a clean signed page. Payment buys you a developer’s time. The signed instrument is what buys you the copyright.

Why an unsigned transfer has no legal effect

This is the conversion point of the whole question, and it is unambiguous in the statute. Copyright is transmissible as movable property, but no assignment of copyright and no exclusive licence has any effect unless it is in writing signed by or on behalf of the assignor or the licensor.⁹

In plain terms: an email saying “the code is yours,” an invoice marked “full ownership transferred,” a WhatsApp message, a handshake, a verbal promise over coffee, none of these validly assigns copyright or grants an exclusive licence. They have no effect for that purpose. If you are relying on anything other than a written instrument signed by the developer, you do not have an assignment.

There is a further wrinkle that a careful founder should know about. The Act states that an assignment shall not be valid unless it is lodged at the Kenya Copyright Board, a certificate of recordal is issued, and an entry is made in the Assignment Register.¹⁰ On a literal reading, recordal at the Board is a validity requirement for a copyright assignment, not merely an evidential step. The cautious position is therefore to treat a written, signed and Board-recorded assignment as the complete package, not to stop at signature.

How strictly that recordal requirement is enforced, that is, whether a signed but unrecorded assignment is void or merely unrecorded and still effective between the parties, has not been settled by the courts. You do not need the answer if you simply record the assignment. Lodging it at the Board and obtaining the certificate of recordal removes the question entirely, so treat recordal as part of completing the assignment, not an optional extra.

Assignment versus licence: which one do you actually need?

Founders routinely think they “bought the software” when what they actually hold is permission to use it. The two are different in kind, and the difference decides whether you can raise capital on the asset or sell the company with it.

• Assignment is a full transfer of ownership of the copyright. After a valid assignment, the rights are yours. This is what a startup raising capital or planning an exit must have, because investors and acquirers diligence whether the company owns its core technology.
• Exclusive licence is permission to use the work to the exclusion of everyone, including the owner, but ownership stays with the developer. Like an assignment, an exclusive licence has no effect unless it is in writing signed by the licensor.¹¹
• Non-exclusive licence is bare permission to use, which others may also be given. This one need not be in writing: a non-exclusive licence may be written, oral or inferred from conduct, and may be revoked at any time unless a contract says otherwise.¹²

That last category is the common trap. Where a developer simply lets a client use software with no formal document, the law can treat that as an implied non-exclusive licence to use, while copyright ownership itself stays with the developer. The founder believes they own a product; they actually hold a permission that can be revoked. If your plan is to own, build on, white-label or sell the software, a non-exclusive licence is not enough, and an implied one is worse.

To understand what you are actually acquiring on an assignment, it helps to see what the owner controls. Copyright in a literary work, which includes a computer program, is the exclusive right to control reproduction in any material form, translation or adaptation, distribution to the public, communication to the public, and making the work available.¹³ That bundle of rights is what “owning the source code” means in practice, and it is what passes on a valid assignment.

The developer keeps moral rights even after you own the code

One thing does not transfer, no matter how clean your assignment is. Independently of the economic rights, and even after those rights are transferred, the author retains the right to claim authorship of the work and to object to derogatory treatment of it that would prejudice their honour or reputation. These moral rights are not transmissible during the author’s life.¹⁴

For a founder shipping a white-label or SaaS product, this is worth understanding. Even where your company owns the copyright in the code, the individual developer keeps the authorship and integrity rights in their person. Plan for how the contract addresses crediting and modification, and take advice on the extent to which a waiver is permissible, rather than assuming a full assignment swept everything up.

The hidden ownership leak: open-source, third-party and AI-generated code

There is a way to do everything above correctly and still not own a clean, sellable product. Modern software is assembled, not written from scratch. A typical build carries open-source components, third-party SDKs and libraries, and increasingly, AI-generated code. Each of those can carry strings:

• Copyleft open-source licences (such as the GPL family) can impose obligations on how you distribute the combined product, including source-disclosure obligations that are incompatible with selling a closed, proprietary product.
• Third-party SDKs and libraries come with their own licence terms that limit what you can do with the finished software.
• Undisclosed dependencies mean you may not actually be able to license, sell or fully own the product, even though you commissioned and paid for the build around them.

The remedy is contractual, and it belongs in the development agreement: a disclosure obligation requiring the developer to list every open-source and third-party component and its licence, a warranty that the code does not infringe third-party rights and that all components are properly licensed for your intended use, and an indemnity if that warranty turns out to be false.

How a specific open-source licence or AI-generated code is treated under Kenyan copyright law is a separate question that turns on the licence and the facts, and one to take advice on for your particular build. The contractual protections above, disclosure, warranty and indemnity, are standard drafting and protect you regardless of how those questions are ultimately resolved.

The cross-border wrinkle

Many Nairobi founders hire developers abroad, and many foreign companies hire Kenyan developers. The moment the developer and the client sit in different countries, you cannot quietly rely on any single country’s default rule, because more than one legal system may have a claim to govern the work. The defaults differ: the Kenyan commissioned-work presumption described above is not the same as the United States or United Kingdom position that the foreign articles assume.

The practical answer is the same answer that runs through this whole guide, only more urgent: do not rely on a default at all. An express written assignment, with a clear governing-law clause, removes the question of which country’s default applies by stating the outcome the parties intend. Across borders, the signed instrument is not a nicety; it is the only thing that travels reliably.

Which country’s rules govern a particular cross-border build is a conflict-of-laws question that turns on the contract and the facts, and it is not one to assume away. Settle it in the document: an express assignment with a clear governing-law clause states the outcome the parties intend instead of leaving it to be argued later.

What this means in practice

Strip away the doctrine and here is what a Kenyan founder should actually do.

• Decide ownership in the contract, before any code is written. For commissioned work the statute presumes the client gets the copyright, and for in-house code the employer gets it, but both are “subject to any agreement between the parties,” and an agreement can flip either one. On the face of the statute that agreement need not be written, but never lean on that: put an express assignment of all present and future copyright in the code into the agreement, in writing, so there is nothing to argue about.
• Get it in writing and signed. An assignment or exclusive licence has no effect unless it is in writing signed by the developer. Emails, invoices and WhatsApp messages do not transfer copyright. Treat the signed instrument as the thing you are actually buying.
• Build the assignment clause to do real work. A founder-grade clause assigns all present and future copyright in the code, is signed in compliance with section 33, and pairs the legal transfer with a delivery obligation: the source code, the documentation, the repository and the access credentials handed over, not just promised. Consider a source-code escrow arrangement, and address what happens to the rights on non-payment or on termination. Lock this into your founders agreement so the IP assignment sits alongside the rest of the deal.
• Demand an open-source and third-party disclosure, warranty and indemnity. This is how you protect yourself from owning a product you cannot cleanly sell.
• For employees, use confirmatory assignments. The employer owns in-course-of-employment code by default, but a clear IP clause in the employment contract, plus a confirmatory assignment for anything close to the line, removes the argument before a departing engineer can start it.
• If you already paid and have no signed assignment, act now. Secure the repository and access credentials, then get a signed assignment or a deed of confirmation in place before the relationship cools or the developer becomes hard to reach. The worst time to ask for a signature is after a fall-out. Bring the engagement to a startup lawyer in Kenya who also builds software, for a source-code ownership review and the drafting to close the gap.

The thread through all of it is simple. In Kenya, ownership of source code is settled by how the work was procured and by the signed page, not by who typed the code and not by who sent the invoice. Get the page right, early.

Frequently asked questions

Who owns source code in Kenya by default, the developer or the client?

It depends on how the work was procured. As a starting point the author (the developer) is the first owner, because copyright vests initially in the author (Copyright Act, Cap. 130, s. 31(1)). But two exceptions flip this: code commissioned from an independent developer is deemed transferred to the commissioning client (s. 31(1)(a)), and code written by an employee in the course of employment is deemed transferred to the employer (s. 31(1)(b)). Both are subject to any agreement between the parties, so an agreement to the contrary can change either outcome, and you should always put that agreement in writing.

If I paid a developer to build my software, do I own the code?

Not automatically by reason of payment alone. If the developer was genuinely commissioned as an independent contractor, the statute deems the copyright transferred to you as the commissioning client, subject to any contrary agreement (s. 31(1)(a)). But payment by itself does not transfer copyright, an actual assignment of ownership must be in writing signed by the developer (s. 33(3)), and if there is no written contract at all you are left arguing from conduct and intent, which is exactly the position that gets litigated.

Does putting the transfer in an email or invoice work?

No. No assignment of copyright and no exclusive licence has any effect unless it is in writing signed by or on behalf of the developer (Copyright Act, Cap. 130, s. 33(3)). Emails, invoices, WhatsApp messages and verbal promises do not validly assign copyright or grant an exclusive licence. The Act also states that an assignment is not valid unless it is lodged at the Kenya Copyright Board with a certificate of recordal issued (s. 33(4)), so the cautious package is a signed and Board-recorded assignment.

What is the difference between an assignment and a licence?

An assignment transfers ownership of the copyright; after it, the rights are yours. A licence is permission to use, with ownership staying with the developer. An exclusive licence (and an assignment) must be in writing signed by the licensor (s. 33(3)); a non-exclusive licence can be written, oral or inferred from conduct and revoked at any time (s. 33(5)). If you intend to own, build on or sell the software, you need an assignment, not a licence.

Can the developer still claim authorship after I own the code?

Yes, in a limited way. Even after the economic rights transfer, the author keeps moral rights, the right to claim authorship and to object to derogatory treatment of the work, and those rights are not transmissible during the author’s life (Copyright Act, Cap. 130, s. 32). Owning the copyright is not the same as extinguishing the developer’s moral rights, so the contract should address crediting and modification.

Do I need to register the code with the Kenya Copyright Board to own it?

No, to own it. Copyright arises automatically on fixation and non-registration does not bar the author’s claim; registration under s. 22A is optional and operates only as prima facie evidence (Copyright Act, Cap. 130, s. 22). Separately, the Act states an assignment is not valid unless it is lodged at the Board and a certificate of recordal issued (s. 33(4)). Whether a signed but unrecorded assignment is actually void, or merely unrecorded and still effective between the parties, has not been settled by the courts, so the safe course is to record it: lodge the assignment at the Board and obtain the certificate of recordal as part of completing the transfer.

My developer is abroad. Whose law decides who owns the code?

That is a conflict-of-laws question that turns on the contract and the facts, and the defaults differ between Kenya, the United States and the United Kingdom. The reliable answer is not to rely on any country’s default: use an express written assignment with a clear governing-law clause so the outcome is stated rather than inferred. For a specific cross-border engagement, confirm the governing-law position with an advocate before you sign.

What should I do right now if I already paid for software but have no signed assignment?

Secure the repository and access credentials first, then get a signed assignment or a deed of confirmation in place before the relationship sours or the developer becomes unreachable. Until there is a written, signed instrument, you may hold only an implied permission to use rather than ownership. Take it to a startup lawyer who also builds software for a source-code ownership review.

Get a source-code ownership review

Ownership of your source code is decided by how the work was procured and by one signed page, not by the invoice and not by who wrote it. For commissioned work the statute leans toward the client; for in-house code it leans toward the employer; and in every case an unsigned transfer of ownership has no effect. Ambiguity is what ends up in court.

If you are commissioning a build, hiring engineers, or have already paid and never got a signed assignment, book a consultation for a source-code ownership review and the contract drafting that closes the gap. For the wider picture, start with startup legal support in Kenya and make sure the IP assignment clause is locked into your founders agreement.