Every developer has been there. You write something clever on a Friday afternoon — maybe a small automation, a utility script, a configuration that saves everyone three hours a week. You use the company laptop. You use the company's licensed tools. You push it to the company's Git.
So who owns it?
Most companies will tell you: we do. Most developers assume: probably them. And most of the time, nobody challenges it.
But in December 2025, a Russian court handed down a ruling that should make every developer in the world rethink this assumption — and make every engineering manager quietly review their employment contracts.
The Eight-Year Battle You've Never Heard Of
In 2013, a sysadmin at a sugar plant wrote a 1C (a Russian enterprise software platform) configuration to automate the weighing station for cargo trucks. He installed it at one factory in the Rusagro agricultural holding, showed colleagues how it worked, and then mostly forgot about it.
In 2017, he stumbled across an article in the company's internal newsletter. A colleague at another factory in the same holding was proudly describing how he had "developed and deployed" a truck weighing automation system. The article included specific technical details. The system was his system — but his name was nowhere.
The original developer sent a formal letter to Rusagro-Tambov in December 2017, offering to negotiate a licensing agreement. No response.
What followed was eight years of litigation: a criminal complaint, two district court rejections, two cassation appeals, three rounds of appellate review. In December 2025, the Tambov Regional Court ordered Rusagro-Tambov to pay 760,000 rubles (~$8,500 USD) in compensation.
The money is not the point. The legal logic is.
Why "You Used Our Tools" Isn't Enough
The company's defense seemed bulletproof on paper:
- The software was written by an employee of the IT department
- It was written on company hardware
- It used the company's licensed 1C platform
- It was written during working hours
This is the standard playbook for claiming work for hire or service works in most jurisdictions. And it works — most of the time.
But the appellate court dismantled each argument:
On the employment contract: The company produced a contract from 2001. The program was written in 2013. The contract had expired a decade before the code was written. The company never produced the actual contract that was in force in 2013, nor any job description listing software development as a duty, nor any formal assignment to write this software.
On the 1C license: The court cited Plenum of the Supreme Court No. 10 (April 23, 2019), paragraph 104, directly: "The mere fact that an author used the employer's materials in creating a work cannot in itself serve as grounds for concluding that the work is a service work." A license to run 1C is a license to run 1C. It is not a transfer of intellectual property rights over everything an employee creates on that platform.
On burden of proof: The court was explicit that the burden of proving a work is a service work lies with the employer, not the employee. Many first-instance courts get this backwards.
The Part About "Just Storing" Code
Here's the detail that stunned us when we read the ruling.
Rusagro-Tambov argued they had acquired a legitimate copy of the program from the original factory installation, so they were entitled to use it.
The court cited a 2016 ruling from the Supreme Court's Economic Disputes panel (case №308-ЭС14-1400) and established: even simply storing a program in a computer's memory, if the lawfulness of that storage has not been proven, itself constitutes use of the program.
In other words, "we have it but we don't run it" is not a defense. If it's installed, it's being used.
This principle cuts both ways. It protects developers whose code is silently being used without compensation. But it also means that a developer who takes copies of proprietary code when leaving a company is using that code in the legal sense — even if they never open the files again.
What This Means for Developers Outside Russia
This ruling is technically binding only in Russia, under Russian IP law. But the underlying logic mirrors debates in Germany, the UK, the US, and throughout the EU — and the outcome challenges assumptions that are common across all of them.
The "work for hire" doctrine has limits everywhere
In US copyright law (17 U.S.C. §101), work for hire requires either (a) that it was created by an employee within the scope of their employment, or (b) it was specially commissioned and falls within one of nine defined categories. The key phrase is scope of employment.
If your job description says "maintain network infrastructure" and you write an inventory automation tool on the side, there's a legitimate question about scope — especially if no one formally assigned you to write it.
In Germany (UrhG §69b), software created by an employee in the exercise of their duties belongs to the employer — but again, "in the exercise of duties" is doing a lot of legal work.
Personal projects on company time: a gray zone
At Gerus-lab, we've worked with clients across dozens of software projects — from Web3 platforms on TON and Solana to enterprise automation tools. We've seen this ambiguity create real problems:
- A developer builds a reusable library at work. They later open-source it. The employer claims ownership.
- A contractor builds a utility for Client A, then reuses the same logic for Client B. Both clients claim exclusivity.
- An engineer writes an internal tool that later becomes a product. The company never formalized the IP assignment.
None of these are hypothetical. We've seen variants of all three.
What Smart Developers Do
The Russian ruling gives us a useful checklist:
1. Document what's in scope. Your job description and any formal assignment documents define what you're employed to create. If your manager asks you to build something informally, email confirmation that it exists. Not to be litigious — to be clear.
2. Side projects need separation. If you're building something on your own time, use your own devices, your own accounts, and your own licensed tools. Courts look at the evidence of where, when, and with what the work was created.
3. Understand your jurisdiction's "scope of employment" standard. In the US, California explicitly prohibits employers from claiming ownership of work created without company resources and outside working hours (Cal. Labor Code §2870). Not every state does. Know your local law.
4. If you contribute to your employer for goodwill — document it. The developer in this case consented to the use of one installation. That good-faith act was used to argue against him, and the court cut his compensation in half because of it. Generosity without documentation can be costly.
5. Contracts matter — and their dates matter. Rusagro produced a contract from 2001. The court noted it had expired before the software was written. Old contracts don't cover future work automatically.
The Statutes of Limitations Problem
One more important detail from this case: Rusagro argued the claim was time-barred. The developer learned about the violation in 2017; he filed his civil suit in 2023 — six years later.
The court rejected the time-bar argument using the principle of continuing infringement: each day the program was installed and running on unauthorized machines was a new act of infringement. The limitations clock doesn't start when you first discover the violation if the violation is ongoing.
This matters for open source licensing too. If someone incorporates your GPL code into a proprietary product, they're not just making a one-time violation — they're continuously violating your license every day they ship that product.
The Real Takeaway
The developer in this case won. But he spent eight years and survived a failed criminal case, two district court rejections, and multiple cassation cycles to get there.
The better outcome — for everyone — is clarity upfront.
For developers: understand what your employer can and cannot claim. Know your job description. Separate your personal projects properly. Document informal contributions.
For companies: if you want to own software your employees build, create proper assignment agreements that actually cover the work as it's assigned. An old contract with a different job title is not enough.
At Gerus-lab, when we build custom software for clients — whether it's a SaaS product, a blockchain integration, or a specialized automation tool — we always formalize IP ownership in the contract before writing a single line of code. It takes five minutes. The alternative can take eight years.
Who owns your code? Make sure you both have the same answer.
Building something and need clarity on the legal and technical architecture? Talk to Gerus-lab — we help teams structure projects cleanly from day one.
Top comments (0)