A familiar technology transaction begins with the wrong question
A founder hires a developer to build a customer portal. The invoices are paid, the platform goes live and investors begin due diligence. Then someone asks for the source-code repository, intellectual-property assignments, licences for pre-existing modules, open-source disclosures and written authority to modify or transfer the software. The founder has a working product. What the founder may not have is an intelligible map of the rights behind it.
The problem is sometimes described too simply: “If I paid for it, I own it.” Kenyan copyright law is more nuanced. Payment and commissioning are important, but ownership depends on the statutory default, any agreement that changes it, and whether the disputed work was newly commissioned or had already existed before the engagement.
This matters to technology companies because the value of a software asset often lies as much in the right to maintain, adapt, commercialise and transfer it as in its ability to run today.
Kenya protects computer programs as copyright works
The Copyright Act treats a computer program as a literary work. Section 22 addresses eligibility and the automatic accrual of copyright upon fixation; registration is not generally what creates the right. Section 26 defines economic acts controlled by the owner, including relevant reproduction and adaptation rights.
Section 31 is particularly important. Copyright vests initially in the author, but the section contains a statutory rule for qualifying commissioned works and works made in the course of employment: subject to an agreement excluding or limiting the transfer, copyright is deemed transferred to the commissioner or employer. The default is therefore not that an external developer always keeps every right. Nor does it mean every component within a delivered platform automatically belongs to the customer.
The commissioning relationship must be analysed alongside scope. A developer may deliver original code created under the commission, a pre-existing software library, licensed third-party components and open-source tools. Those components need not share the same ownership or permitted-use position.
A Kenyan software case shows why project documents matter
In Iko Solutions Limited v Mobile Decisioning Africa Limited [2021] KEHC 12551 (KLR), a Kenyan High Court considered a dispute over software used to reconcile mobile-service transactions. The parties disagreed over whether the software was an existing solution brought into the relationship or intellectual property developed for the customer under consultancy arrangements. Their evidence included draft terms, confidentiality arrangements, correspondence and descriptions of what had actually been deployed.
At paragraph 35, in an interlocutory application, the court held that Iko had established a prima facie case with a probability of success in its ownership claim. That was not a final determination of every intellectual-property issue at trial. The distinction matters: an interim ruling is valuable as a warning about documentary risk, but it should not be overstated as conclusive law on all commissioned software.
The commercial lesson is sharp. An unsigned draft IP clause, scattered emails and unclear treatment of pre-existing code are poor substitutes for an executed agreement that describes what rights move and when.
An assignment, an exclusive licence and access to source code are not the same thing
Section 33 of the Copyright Act permits assignment and licensing of copyright. It also requires assignments and exclusive licences to be in writing and signed by or on behalf of the relevant rights holder. A non-exclusive licence may arise differently under the statute, including by implication from conduct in appropriate circumstances.
The agreement should therefore answer separate questions. Who owns new project deliverables? Which pre-existing libraries remain with the developer? Does the customer get a perpetual right to run and modify those libraries? May the customer sublicense or transfer the rights to a buyer or group company? Who can grant rights in third-party code? What happens on termination?
Source-code delivery is another question. Being able to run an application through a hosted service is not the same as having the repository, build instructions, credentials and lawful permissions needed for another developer to take over. A buyer who cannot migrate or maintain the platform may face serious operational risk even where copyright ownership looks favourable on paper.
What changes when an AI coding assistant joins the team?
AI-assisted development introduces another contractual layer. The software team may rely on model-generated suggestions, third-party APIs, repository integrations and vendor terms. It is tempting to assume that all AI-assisted output is either automatically owned by the customer or automatically outside copyright. The Kenyan statutory framework does not justify either sweeping conclusion for every factual scenario.
The safer transaction practice is to identify which material was created by employees or contractors, which was licensed or reused, and what contractual representations the developer can genuinely make about provenance and rights. The developer should also be required to identify material third-party and open-source dependencies and the obligations attached to them.
Where personal or confidential data was used with coding tools, the legal questions extend to confidentiality, privacy, security and vendor restrictions. These are related risks, not substitutes for the core copyright analysis.
Build the rights map before the investor asks for it
The best time to address software title is before coding begins. A clear development agreement can distinguish background intellectual property from project-specific deliverables, set out assignment or licensing mechanisms, require repository handover, define acceptance milestones and allocate support, confidentiality and security obligations.
For a mature product, an IP clean-up exercise can still be valuable. It may require collecting employment and contractor agreements, identifying missing assignments, reviewing open-source disclosures and documenting the licences that permit the product to operate. That exercise is often less expensive than trying to cure defects in the middle of financing or acquisition diligence.
The deeper point is that software value is not just technical. It depends on whether the business can prove that it has the rights it needs to use, change, sell and scale the product.
How KKN Law can help
For the startup, the objective is to launch and commercialise software without losing control over a critical asset. The friction arises at handover, vendor exit, investment or acquisition—when title, licences and source-code access are scrutinised.
KKN Law can translate that risk into a rights map and transaction documents that make the business more investable and less dependent on undocumented assurances.
Prepare and negotiate software-development, commissioning, assignment and licensing agreements, with clear separation of new and background IP.
Audit contractor, employee, open-source and third-party licences for a founder, buyer or investor.
Review deliverables, source-code access, escrow, support, exit and handover mechanisms.
Document IP chain of title for a venture financing, acquisition or strategic partnership.
Assist with disputes over reuse, copying, infringement, confidential code and contractual access rights.
By Gerald Kiti Founding Partner KKN Law LLP.