Disputes Over IT Products and Software Code: Who Owns Them?

Software Code as an Object of Law

According to the Law of Ukraine “On Copyright and Related Rights” dated December 1, 2022, No. 2811-IX (hereinafter—the Law), a computer program is a set of instructions in the form of words, numbers, codes, diagrams, and symbols expressed in a form suitable for reading by a computer. Article 20 of the Law expressly provides that computer programs are protected as literary works. Copyright arises from the moment of creation and does not require registration or any formalities (Part 2 of Article 11). This is confirmed in paragraph 17 of Resolution No. 5 of the Plenum of the Supreme Court of Ukraine dated June 4, 2010 , which states that protection extends to computer programs regardless of the manner or form of their expression, and in paragraph 18—that a work is considered created from the moment it is given any objective form.

Fundamentally: the form of expression of the program—source code and object code—is protected. Ideas, algorithms, concepts, and functionality are not protected by copyright. This was explicitly confirmed by the Supreme Court in its ruling of May 22, 2023, in Case No. 760/16961/19 , interpreting Article 10 of the TRIPS Agreement and Article 18 of the Law: “only the form of expression of programs is subject to protection, i.e., source and object codes, while their structure, algorithms, and ideas are not subject to protection.” A competitor may create a program with similar functionality by writing their own code.

At the same time, the list of protected objects extends beyond the code itself: specifications, flowcharts, databases, and interfaces. The situation with interfaces is not entirely clear-cut. In the case of Lotus Development Corp. v. Borland International, Inc. (U.S. Court of Appeals, First Circuit, 1995; affirmed by the U.S. Supreme Court), the court recognized a menu interface as a method of operation, which is not subject to copyright protection. In Oracle America, Inc. v. Google LLC (U.S. Supreme Court, 2021), the copying of 11,500 lines of the Java API was found to constitute fair use. The court noted that Google had copied only the portion of the API necessary to ensure compatibility with the Java platform, and that such use was transformative in nature. The decision does not mean that APIs are generally not protected by copyright—the Court deliberately left this question open, deciding the case solely on the basis of the fair use doctrine.

Although decisions by U.S. courts are not a source of law in Ukraine, these cases are significant for two reasons. First, Ukraine is a party to the Berne Convention and the TRIPS Agreement, which form a common international framework for copyright protection, and Ukrainian courts already rely on TRIPS provisions when interpreting national legislation (in particular, in the aforementioned Supreme Court ruling of May 22, 2023, in Case No. 760/16961/19). Second, the principle of distinguishing between an idea and its form of expression, upon which both cases are based, is explicitly enshrined in Article 18 of the Law and Article 9(2) of the TRIPS Agreement, so the findings in Lotus and Oracle can be used as a compelling doctrinal argument in Ukrainian courts when deciding on the patentability of interfaces and APIs.

To identify indirect copying in the case of Computer Associates International, Inc. v. Altai, Inc. (U.S. Court of Appeals, Second Circuit, 1992), a three-step “Abstraction-Filtration-Comparison Test” was formulated: abstraction (reconstructing the order of creation from the code to the main function), filtration (separating protected elements from ideas and scène à faire), and comparison of the remaining protected core—the so-called “golden nugget.”

This test has become an international standard for analyzing non-literal software copying and has been adopted by courts in the EU, the UK, Australia, and other jurisdictions. In Ukraine, judges generally do not examine the code themselves—this is done by court experts in computer-technical expertise. The Altai-test methodology can be used by experts as a scientifically sound investigative tool when conducting computer-technical examinations, and by the parties as an argument in procedural documents when substantiating the fact or absence of copying of non-literal elements of a program.

Correct identification of the subject matter of the dispute is of decisive practical importance. When a party asserts a claim regarding a “software product,” the court must determine exactly what is the subject of the dispute: the source code, the compiled application, the database, the interface design, or a combination thereof. Each of these elements may have a different legal regime and different rights holders.

Author and Rights Holder

The author of a computer program is always a natural person. They hold inalienable moral rights (Art. 11 of the Law): authorship, name, and the integrity of the work.

Economic rights (Article 12 of the Law)—reproduction, distribution, adaptation, public communication, and other forms of use—determine who may commercially use the code, license it to third parties, or prohibit such use. Property rights may belong not to the author, but to another person—the employer, the client, or the acquirer under a contract. In IT disputes, the subject of the conflict is precisely these economic rights: who has the right to use, modify, and commercialize the software product. The author-programmer’s moral rights are preserved in this context but do not affect the distribution of commercial rights.

An important nuance for startups: co-authorship of the original program does not automatically extend to its modifications. In Case No. 760/16961/19 , the co-author of the original program lost the dispute in three instances because he could not prove a creative contribution to each subsequent version of the product.

Work for Hire: When an Employee Creates the Code

Article 14 of the Law defines a work made for hire as a work created by an employee in connection with the performance of duties under an employment contract (agreement). For code to be recognized as a work made for hire, several conditions must be met simultaneously: the existence of an employment relationship, the creation of the program during the term of the employment contract, at the employer’s expense, and within the scope of duties or pursuant to a written work assignment.

The Law established that property rights to a work for hire belong to the employer from the moment of creation, unless otherwise provided by the contract. This resolved a long-standing conflict between Article 429 of the Civil Code (joint rights) and the previous version of the Law. The severity of this conflict is illustrated by Case No. 760/18303/14-ц : employees of a state-owned enterprise registered copyright in their own names for a program created under a government contract. The court of first instance ruled against the employer, erroneously applying Article 429 of the Civil Code. The Kyiv Court of Appeals (ruling dated February 6, 2024) overturned the decision, recognized the program as a work made for hire, and invalidated the employees’ certificate, applying Article 16 of the Law “On Copyright and Related Rights” in the 1993 version, which was in effect at the time the disputed legal relationship arose. Key conclusion: the state of funding and non-payment of royalties do not alter the status of a work made for hire.

In practice, employers make common mistakes: they fail to include software development in a programmer’s job description, do not formalize work assignments, and do not document the creation of deliverables. If the employment contract lacks a clear description of duties related to code creation, a programmer may argue in a dispute that a specific development went beyond the scope of their job duties and, therefore, is not a work-for-hire.

A separate risk involves working on corporate equipment. In Case No. 756/960/15-ц, the Kyiv Court of Appeal refused to recognize the contractor’s authorship without a copyright certificate. In Case No. 2-6118/11, the Solomyanskyi District Court of Kyiv emphasized: an object module in and of itself is not proof of authorship. Conclusion: side projects—in your free time and on personal equipment.

Client and Contractor: The Riskiest Scenario

Outsourcing development, including the widespread practice in Ukraine of collaborating with individual entrepreneurs (FOPs), is the riskiest model for determining the rights holder. Article 15 of the Law establishes that property rights to a work created on commission are transferred to the client in their entirety from the moment of creation, unless otherwise provided by the commission agreement. This is a new provision that has significantly improved the position of clients compared to previous regulations.

It is important to distinguish between the transfer (disposition) of property rights and licensing. Transfer means the complete transfer of all property rights to the transferee. A license merely grants permission to use the work in a specified manner and for a specified term. If the contract contains only wording regarding the “performance of work,” the court may classify the relationship as a contract for services: the client receives a tangible result but not intellectual property. This is confirmed in the Supreme Court’s ruling in Case No. 910/2683/19 regarding the mixed nature of a software development contract (elements of a contract for work and Article 1112 of the Civil Code).

Key documents that the client must ensure are in place from the very start of the relationship with the developer: a contract with an IP clause, technical specifications, and acceptance and transfer certificates specifying the transfer of property rights. These documents form the evidentiary basis for ownership of rights long before any dispute arises—and it is precisely their absence that is the most common reason why a client loses in court, even when they have full factual control over the product.

Technical control does not guarantee ownership rights

Access to a GitHub repository, cloud infrastructure, or keys constitutes de facto control, not legal title. GitHub and GitLab platforms record the authorship of commits and the history of changes, which can serve as evidence. However, control over a repository does not imply ownership of the code—just as storing a painting does not make the custodian the owner. The court evaluates technical evidence in conjunction with contractual relationships and deeds of assignment.

The party controlling the infrastructure may block access to the product without having the rights to do so—this gives rise to separate claims for access.

Even loading a program into RAM can constitute copying: paragraph 31 of Resolution No. 5 of the Plenum of the Supreme Court of Ukraine dated June 4, 2010 ( ) states that storing a copy of a program in a computer’s memory constitutes a violation of economic copyright.

Open-source as a hidden factor

Modern development is impossible without open-source components—up to 80–90% of a commercial product’s codebase may consist of open-source libraries. Licenses (MIT, BSD, Apache 2.0, GPL, LGPL, MPL) have fundamentally different terms. Using GPL components without complying with the terms may require the source code of the entire product to be disclosed. License incompatibility can make legal distribution impossible—each component must be checked for compatibility.

The “unclean hands” doctrine denies legal protection to anyone who has violated licenses themselves. This principle was applied in the case of Lasercomb America, Inc. v. Reynolds (U.S. Court of Appeals, Fourth Circuit, 1990), where the court denied the plaintiff copyright protection due to abuse—the inclusion of terms in the license agreement that restricted competition.

The doctrine of unclean hands as such is not part of Ukrainian law, but its logic corresponds to the general principles of Ukrainian civil law. In particular, Part 6 of Article 13 of the Civil Code of Ukraine prohibits actions committed with the intent to cause harm to another person or in a manner that constitutes an abuse of rights, and Part 3 of Article 16 of the Civil Code grants the court the right to deny protection of rights to a person who abuses their civil rights. Therefore, the argument regarding the “dirty hands” of a counterparty who has itself violated the licensing terms of open-source components may be relevant in Ukrainian court proceedings as well—through the mechanism of abuse of rights.

An open-source audit can shift the balance of power in a dispute: if the “author’s” code turns out to have been borrowed from open libraries, the scope of the disputed rights will be significantly reduced.

How to Prove Code Copying

The plaintiff must prove: the identification of the product, the authorship and origin of the code, the legal basis for acquiring the rights, and the fact of the infringement. Copying can be direct—borrowing code in the same language with “cosmetic” changes (renaming variables, rearranging blocks, renumbering lines)—or indirect: borrowing the structure, sequence of operations, and interfaces without copying the code itself. A simple “cosmetic overhaul” does not make a program an original work.

For indirect copying, the case of Computer Associates v. Altai established a three-step test: abstraction (reconstructing the creation sequence from the code back to the main function), filtering (separating protected elements from ideas and the scène à faire), and comparison. The result of filtering is the “golden nugget”: the protected core of the program.

In Ukraine, judges generally do not examine the code themselves. This is done by court experts in computer and technical forensics. The quality of the expert’s conclusion is often a decisive factor. In the same case No. 760/16961/19 , the fragment of source code attached to the registration certificate proved insufficient to identify the program—and the court found it impossible to establish the fact of modification. The lesson is clear: keep the complete source code for every version of the product, otherwise even indisputable authorship will be impossible to prove.

Recommendations for Businesses

In-house: a programmer’s job description must explicitly include software development; each project must be accompanied by a written work assignment; work results should be documented in reports specifying the transfer of property rights. A separate confidentiality agreement (NDA) should be provided for. Regarding post-employment non-compete clauses—the effectiveness of such provisions in Ukrainian jurisdiction is limited due to the absence of direct legislative regulation; therefore, in practice, protection is primarily ensured through NDAs and agreements on the non-disclosure of trade secrets.

Outsourcing/Individual Entrepreneurs: The contract must contain a comprehensive IP clause: a direct reference to the transfer of all property rights to the client, a definition of the transfer date, and a list of specific rights. It is recommended to include the contractor’s obligation to transfer source code, technical documentation, and all access rights, as well as liability for infringing third-party rights through the unlicensed use of open-source components.

Documentation that holds up in a dispute: systematic maintenance of repositories with named author identification, signed acceptance and transfer acts for each development stage, a registry of used open-source components and their licenses, and, if necessary, state copyright registration as an additional protective measure.

Conclusions

The owner of an IT product is not the person who paid for the development, not the person who has access to the repository, and not even the person who wrote the code. The owner is the person who holds legal title—a properly documented basis for acquiring property rights. Since the Law came into effect, the rules for the distribution of rights have become significantly clearer, but they only apply if properly formalized in a contract.

The contractual and evidentiary basis is more important than technical control over the code. Control over a GitHub account or cloud server grants de facto power, but not legal authority. Dispute prevention is significantly cheaper than litigation—the costs of properly formalizing IT relationships legally are a fraction of the potential losses for a business that risks losing rights to its core product.