Protecting software in Uzbekistan: copyright, patent or trade secret

A Tashkent fintech startup — an IT Park resident, revenue climbing, an investor ready to lead the round. During due diligence the investor's lawyer asks one question: "Show me the documents under which the company owns the exclusive rights to the code." There are none. The core of the product was written over three years by a lead developer engaged as a self-employed contractor on a services agreement, without a single clause transferring rights. By law the economic rights to that code belong to him, a private individual — not to the company the investor was about to fund. The round stalled for two months while the parties papered an assignment after the fact — and the developer, now understanding his position, raised his price. This piece is about which of the three regimes protects your software in Uzbekistan, and about the three gaps through which the right leaks out of the company before you have even started protecting it.

Three regimes: what each one actually covers

Software is not a single object but a stack of layers. Source and object code, architecture, algorithms, the interface, the data, the product name itself. Different layers are protected by different tools, and confusing them is the most common founder mistake.

• Copyright protects expression — the specific source and object code, treated like a literary work. It arises automatically at the moment of creation and covers the form, not the idea.
• A patent protects a technical solution — but not a program "as such". In Uzbekistan a computer program is expressly excluded from patentable subject matter; what you can patent is an invention implemented in software, where it produces a technical effect.
• A trade secret protects what you must not reveal at all: an algorithm, a formula, an architecture, a customer base. It protects the idea and the know-how — exactly what copyright cannot reach — but only for as long as the secret stays secret.

These regimes do not compete; they stack. A mature product is usually protected by all three at once: the code by copyright, the key algorithm by a secrecy regime, the name and logo by a trademark, and, where it matters, the look of the interface by an industrial design.

Copyright: it arises on its own, but you still want registration

The headline for founders: to have your code protected by copyright, you need to register nothing. The right arises by the mere fact of creating the work — that is the foundational principle of the Law «On copyright and related rights», and computer programs are expressly listed as protected works alongside literary ones.

So why pay to register? Because copyright is easy to hold and hard to prove. When a competitor ships a suspiciously similar product and you walk into court, the first question is: "Prove that you wrote this code, and wrote it first." The IP Center maintains a state register of computer programs and databases; registration is voluntary and produces a certificate with a fixed date and a deposited fragment of the code. It does not "create" the right — you already have it — but it turns a "my word against yours" dispute into a dispute against an official document with a priority date on your side.

Should you register every release? No. You register the versions that matter: the first commercial release, major version jumps, the build before an investment round or a deal. The state fee for registering one program runs to a few hundred thousand UZS; check the current IP Center fee schedule, which is revised roughly once a year. Against development cost it is a symbolic sum for a document that is worth more in court than any testimony.

What registration does not do: it does not check your code for originality and does not guarantee that you have not infringed someone else's rights. The certificate records "this code existed in this person's hands on this date" — nothing more. If you pulled in a third-party library under an incompatible licence, the certificate will not save you.

Patent: when an algorithm can be patented after all

The temptation to "patent the algorithm" hits every second technical founder. In Uzbekistan it does not work head-on: a computer program as such is not an invention under the Patent Law, and neither are algorithms or mathematical methods. A patent protects a technical solution to a problem, not a sequence of instructions.

The line runs along the technical effect. If your software is business logic, an interface or a way of organising data, there will be no patent. But if the program controls the operation of a device, processes a signal in a new way, raises performance or saves a resource in a measurable technical manner — you potentially have an invention "implemented in software". The claim is then drafted not over the code but over the method or the device.

When it is worth pursuing: a patent makes sense when the solution is hard to hide (it is visible from how the product works; reverse engineering is realistic) and at the same time hard to design around. But if your advantage lives in code no one sees, a patent only hurts: the application discloses the substance of the solution, gives protection in Uzbekistan for just 20 years, and only in the countries where you obtained it. More on choosing between a national and a foreign filing from our patent practice.

Trade secret: the regime that protects the idea

What copyright cannot reach (the idea, the algorithm, the method) and what you do not want to disclose in a patent is protected by the trade-secret regime. Uzbekistan has a dedicated Law «On commercial secret», and it works on the principle "protected exactly as far as you protect it yourself".

The key word is regime. Information becomes a trade secret not by itself, but once you have introduced and documented measures to protect it:

• approved a list of the information that constitutes the secret (the core source code, the architecture, model parameters, the customer base);
• restricted access and keep a record of who is cleared for what;
• written a confidentiality obligation into employment contracts and contractor agreements, backed by an NDA;
• marked the media with a "Trade secret" legend.

If no regime is in place, legally there is no secret: a departing developer who carried the algorithm off to a competitor breached nothing, because there was nothing to protect. For a software company a secrecy regime is therefore not paperwork but the only protection for the most valuable layer of the product — the one you fundamentally never show, neither in a register nor in a patent.

Work-for-hire and contractor agreements: where the right leaks out

Back to the startup from the opening. Its mistake is the most expensive and most common in tech. Here is who owns the code in three typical situations.

An employee. Code written by an employee within the scope of their duties is a work made in the course of employment. By default the exclusive right to it belongs to the employer, while the author keeps the right to attribution and to remuneration. This works in your favour — but only if the developer has an employment contract, and their duties and assignment are framed so that the disputed code falls within them. "The developer built a service in their spare time that was not part of their job" is no longer a work-for-hire, and the right stays with them.

A contractor, freelancer or outsourcing team. Here the default is the opposite: the exclusive right stays with the author-performer unless the contract expressly states that it is transferred (assigned) to the client. A services or works contract does not by itself move the right to the code — it is about the work, not about IP. That is exactly what burned the startup in the opening: services paid for, hand-over signed, and the right to the code still sitting with a private individual.

A co-founder with nothing on paper. The most explosive configuration: two people build the product "on trust", with no employment contracts and no agreement on how the rights are split. Each is a co-author, the right is jointly held, and it can only be exercised together. When one leaves, they carry off half the rights to the product — and can block a deal or a licence.

The takeaway for a founder is single: the exclusive right does not appear in the company on its own. You either acquire it as an employer through work-for-hire (with properly documented employment), or you take it from the performer by a written assignment. The mechanics of assigning an exclusive right are in our assignment guide; the same principles that govern a trademark govern code — without a written document, the right has not moved.

Open source: the licence that can become a trap

Almost every modern product is built on other people's libraries, and each comes with its own licence. Permissive licences (MIT, BSD, Apache 2.0) allow use in a proprietary product with almost no conditions — you only keep the attribution notice. Copyleft licences (GPL, AGPL) work differently: they require a derivative work to be distributed on the same terms, that is, with the source open.

The trap is that by pulling a GPL component into the core of your closed product, you may end up obliged to open your own code too — and AGPL is especially dangerous for SaaS, because it treats even providing access over a network as "distribution". For a company selling closed software, that means losing the very advantage the code was written for.

The practical minimum: keep a register of all third-party dependencies with their licences (your dependency manifest files are the first draft of that register), keep copyleft components separate from the proprietary core, and check licences before a library enters a release — not during due diligence ahead of a round.

How to choose a regime: a short decision tree

• Is it code, an interface, documentation? → copyright, automatically; register the key versions with the IP Center.
• Is it a technical solution with a measurable effect that is visible from how the product runs? → consider a patent.
• Is it an algorithm or know-how you never show? → put a trade-secret regime in place.
• Is it the look of the interface, icons, animations? → add an industrial design.
• In every case: close the ownership question — employment contracts with a written assignment of duties, assignments from contractors, an open-source audit.

In short

• In Uzbekistan code is protected by copyright, not a patent; a patent is only for a technical solution implemented in software.
• Copyright arises on its own, but registering the program with the IP Center gives you a priority date and a document for court — register the key versions.
• A trade secret protects the idea and the algorithm, but only with a confidentiality regime in place (list, access control, NDA, marking).
• The right does not appear in the company automatically: with an employee it is a work-for-hire in your favour, with a contractor it is not, until an assignment is signed.
• Open source under a copyleft licence (GPL, AGPL) can force you to disclose your closed code — keep a dependency register.

Frequently asked questions

Do I have to register a computer program for it to be protected? No. Copyright arises automatically at the moment of creation. Registration with the IP Center is voluntary and exists not to create the right but to prove it: the certificate fixes the date and content of the code, which settles the dispute over who wrote the product and when.

Can I patent a mobile app? The app as a program — no, it is protected by copyright. What you can patent is a technical solution inside it: a new way of processing data, controlling a device, compressing or transmitting a signal that delivers a measurable technical effect. Business logic and the interface fall outside a patent.

Who owns code written by a freelancer under a contract? By default, the freelancer. A services or works contract pays for the work but does not move the exclusive right to the code. For the right to pass to the client, the contract must contain an express clause assigning (transferring) the exclusive right.

What is a work-for-hire and why does it matter? It is a work created by an employee within the scope of their duties. The exclusive right to it belongs to the employer by default. For an IT company it is the main lawful channel through which employees' code becomes a company asset — but it only works with a proper employment contract that describes the duties correctly.

Does an NDA protect on its own? An NDA is necessary but not sufficient. A trade secret is protected once the whole regime is in place: an approved list of secret information, restricted access, marked media. An NDA without the rest of the regime may not be recognised by a court as an adequate protective measure.

Can I use a GPL library in a commercial product? You can, but with strings attached. GPL requires a derivative work to be distributed on the same open terms, and AGPL extends that requirement to SaaS access over a network. For a closed product that is a code-disclosure risk — copyleft components must be isolated from the proprietary core or replaced with permissive equivalents.

How long does copyright in a program last? The economic (exclusive) rights last for decades — the author's whole life and a substantial period after, after which the work enters the public domain. In practice that means rights in code do not "expire" within any horizon you care about; what matters is not the term but who holds the rights.

Software feels intangible, but legally it is a set of very concrete rights — and they either belong to your company or they do not. Registering versions, a secrecy regime and a patent reinforce protection, but all of it is pointless if the underlying exclusive right has leaked to a contractor or a co-author. Gather the rights inside the company first. Defending someone else's code is an expensive, losing exercise.