NDA, IP Assignment, and Source Code Protection When Hiring Developers in Belarus

US founder, mid-Series-A. Four-person Belarusian engineering team. The product was shipping, the team was performing, things looked clean. Then his lead investor started Series B diligence and asked for the IP assignment chain. The founder forwarded what he had — engineers’ offer letters, the EOR’s standard contract. The investor’s lawyers came back the following week with a written note. The chain wasn’t clean. The assignment language in the employment contracts wasn’t sufficient under Belarusian law to actually transfer ownership. Strictly speaking, the founder’s company didn’t own substantial portions of its own product.

There were problems. The EOR looked reputable, the contracts looked professional, the engineers were obviously working in good faith. And yet — the note was unambiguous.

Different founder, different stage, different team size — same diligence note. The gap between what foreign founders think they’re getting on IP and what Belarusian law actually delivers is one of the stubborn blind spots in this market.

This article walks through it. What the Belarusian default actually is on IP ownership. What needs to be in the contract to overcome that default. How NDAs work here. How source code protection plays out operationally. And — most importantly — what the chain looks like when you’re hiring through an EOR, because that’s where the practical risk usually sits.

Standard caveat first. We’re a recruitment agency, not a law firm. We see this from the recruiting and EOR side every week, but for legal advice on your specific contracts you need a qualified Belarusian IP lawyer. What this article gives you is the lay of the land — the questions to ask, the patterns that fail, the patterns that work.

The default that surprises every foreign founder

Here’s the Belarusian rule in plain language. Under the Civil Code and copyright law, without explicit written assignment of exclusive rights, the rights to a work created by an employee stay with the employee. The employer gets a licence — sometimes broad, sometimes narrow, depending on what the contract actually says. The employer does not get ownership.

This is materially different from the US position, where work-for-hire flips the default and the employer owns by default in most contexts. It’s also different from the UK and German positions in specific ways. Belarus is a Civil Code jurisdiction, not a common law one, and work-for-hire as a concept doesn’t carry over the way US founders assume.

The phrasing “Employee shall perform the work for the Employer’s benefit” — which sounds like it does the job in English — describes the work. It doesn’t transfer the rights to it. Without an explicit transfer, the engineer technically still owns the exclusive rights to what they built. You have a licence to use it. You don’t have ownership.

For day-to-day operations the difference is invisible. The engineer isn’t waking up one morning and demanding royalties on production code they wrote six months ago. The issue surfaces at the moment that always comes — investor diligence, an acquirer’s review, a serious enterprise client’s procurement check. At that moment somebody asks for the IP chain, and “we have a standard work-for-hire clause” stops being an acceptable answer.

HTP residency makes the operational and commercial side more flexible — English-language contracts, elements of English commercial law in commercial relationships, simpler paperless contracting. But the underlying assignment rule for employee-created IP still applies. The 2017 HTP decree didn’t dissolve the Civil Code requirement. It added flexibility on top, not a substitute underneath.

What proper IP assignment actually looks like

This is the substantive section. What needs to be in the contract — specifically, in writing, unambiguously — to actually transfer ownership of the work product from the engineer to the employer.

Description of what’s being protected

Software code, technical documentation, architectural designs, brand assets, whatever it is the engineer is creating. The protected work needs to be identified with sufficient specificity so there’s no later argument about what’s covered. “All work created during employment” reads tight in English — Belarusian courts tend to narrow it. Category descriptions hold up better. Something like “software code, technical documentation, architectural designs, and related materials created by the Employee in the performance of duties” is closer to what survives review.

The actual transfer 

This is the specific local-law concept that has no clean English equivalent. The transfer needs to be of “exclusive rights,” not just “all rights” — the term has specific meaning under the Civil Code. It needs to be in writing. It needs to be clear that it’s a transfer, not just a licence.

The standard language in a Belarusian-law-governed contract goes something like this — translated for English readers, the actual contract will be in Russian or Belarusian: “The Employee hereby transfers (assigns) to the Employer the exclusive rights, in their entirety, to all results of intellectual activity created by the Employee in the performance of their employment duties.” The specific words matter. The structure of the clause matters. “Hereby transfers” is doing real work that “shall be deemed assigned” doesn’t quite do under Belarusian Civil Code reading.

Scope

Full assignment versus licence — full assignment is what you want for owned IP. Exclusive versus non-exclusive — exclusive, you don’t want the engineer also licensing the same code to a side project. Territory — worldwide. Term — perpetual, for the full duration of the rights under law. Each of these needs to be in the contract. “All rights to use” is not the same thing.

Derivative works

This matters in product development, where engineers constantly build on earlier code. The contract should make explicit that derivative works are covered by the assignment. Otherwise, you can end up in an awkward argument about whether the new feature built on the original codebase is or isn’t part of the transferred rights. Sounds theoretical until it isn’t.

Moral rights 

Here’s the one foreign founders consistently miss. Belarusian law recognises moral rights of authors — the right to be identified as author, the right to integrity of the work, a few others. These rights cannot be transferred, ever, even with the cleanest assignment language. They stay with the engineer regardless of what the contract says.

What you can do contractually is include an obligation by the engineer not to exercise those rights against the employer. Standard practice in well-drafted Belarusian employment contracts. Almost always absent from foreign-template-derived contracts, because the moral rights concept doesn’t have a common-law equivalent to copy. Engineers rarely invoke moral rights in practice — but “rarely” is not “never,” and when it happens the absence of the non-exercise undertaking is the thing the engineer’s lawyer points at.

The EOR / sub-processor chain

If the engineer is employed by an EOR, the assignment chain runs Engineer → EOR → Foreign Client. Each link is its own contract. Each link needs explicit assignment in equivalent scope on equivalent terms. Missing a link breaks the chain — the rights stop at whichever step was weak, and the foreign client doesn’t end up with the IP even though everyone thought it was being passed through. This is the most common failure mode we see at diligence. It gets its own section below.

NDAs in Belarus — what works, what doesn’t

NDAs are enforceable in Belarus. The rules are specific though, and foreign founders sometimes assume their home-jurisdiction template is portable. Mostly it isn’t.

What actually works

Specifically identified confidential information. The NDA should describe what’s confidential — by category, by document marking, by named system. “All information disclosed during the engagement” is the formulation that gets narrowed by Belarusian courts when there’s an actual dispute. The narrower and more specific the description, the more enforceable.

Reasonable duration. Courts look at the duration of the confidentiality obligation and ask whether it’s proportionate to the legitimate interest. Three to five years post-termination is the common range for technical information. Perpetual NDAs tend to get cut down to a reasonable period. If you genuinely need perpetual protection on something specific — trade secret material — flag it specifically and explain why.

Actual operational confidentiality. The party receiving the information has to actually treat it as confidential. Document marking, access restriction, training. An NDA in writing without operational confidentiality practice tends to be hard to enforce because the court asks whether the information was genuinely treated as a trade secret. The contract is one input. The behaviour is the other input.

Liquidated damages clauses are recognized under Belarusian law. But Article 314 of the Civil Code allows courts to reduce them when they’re “manifestly disproportionate to the consequences of the breach.” A liquidated damages number anchored to a plausible commercial loss usually survives review. A number set as a deterrent rather than a calibration tends to get cut down. Calibrate to credible loss; don’t write theatre numbers you don’t actually expect to collect.

For employees, the NDA is usually folded into the employment contract rather than signed separately. For contractors and individual entrepreneurs, a standalone NDA is normal. For senior engineers leaving toward a competitor, post-employment non-disclosure paired with reasonable non-competition (also narrowly construed under Belarusian law) is the practical structure.

Source code protection — the operational stack

Here’s where foreign founders sometimes have iron-clad contracts and still lose source code, because they ignored the operational layer. The paperwork is necessary. The operational stack is at least as important. And in our experience, the operational stack is what actually gets you back if something goes wrong — the contract is what gets you damages later, which is a much worse outcome than not losing the code in the first place.

The practical defaults for source code protection with a Belarusian engineering team in 2026:

• Source code lives in EU- or US-hosted Git infrastructure. GitHub, GitLab.com, Bitbucket Cloud. Not on Belarus-located servers or on engineer laptops as the primary copy. Access is granted; the code physically sits where you control it.
• Private repositories with branch protection. Production branches are protected from direct push. Every meaningful change flows through a pull request with mandatory review.
• Signed commits where the workflow supports it. Audit trail of who pushed what, when, and who is properly attributed.
• Access controls reviewed quarterly — not annually. Engineer roles match actual responsibility. No shared accounts. No “temporary admin access” that quietly becomes permanent over twelve months.
• Corporate laptops with full disk encryption. MDM or equivalent device management, where the budget permits. No personal devices for production work.
• Logging and monitoring at the Git layer — who pushed, who pulled, who cloned, with retention. Most enterprise tiers offer this. Pay the extra for it.
• Independent backup outside engineer environments. Recovery procedure tested at least annually, not just documented.
• Same-day offboarding procedure, documented and rehearsed. When an engineer leaves, access gets revoked across Git, ticketing, cloud, CI/CD, and internal tools — within the same business day. Not next week.

HTP-resident engineering setups tend to have most of this baked in as default enterprise practice. Non-HTP setups occasionally have gaps. If you’re running a team without a documented offboarding procedure for source code access, fix that this quarter. It’s the gap that becomes a real problem in the small fraction of cases where an engineer leaves on bad terms — and you don’t know in advance which fraction.

On the jurisdictional point: source code physically held inside Belarus is subject to Belarusian law and its operational realities. Source code hosted on EU or US infrastructure and accessed by Belarusian engineers is governed by where the data actually resides. For most foreign clients the practical decision is to keep the source on EU- or US-hosted Git and grant Belarusian engineers controlled access. That single architectural choice moves a meaningful slice of risk in your favour. Worth making deliberately, not by accident.

The chain when an EOR sits in the middle

Most foreign clients hiring in Belarus do it through an EOR. The EOR is the legal employer of the Belarusian engineer. So the IP assignment chain looks like this:

Engineer → EOR → Foreign Client.

Each link is a separate contractual relationship. Each link needs explicit assignment in equivalent scope on equivalent terms. The most common failure mode we see at diligence: the engineer’s employment contract with the EOR has solid Belarusian-law-form assignment language. Clean. Properly drafted. Does the job. But the EOR-to-foreign-client contract — the master services agreement or the schedule against it — doesn’t transfer those rights onwards in equivalent terms. The chain breaks at the second link. Result: the engineer transferred IP to the EOR, but the foreign client doesn’t have it.

This is exactly the note that comes back from investor counsel.

What to look for in your EOR contract, specifically:

• Express language transferring all IP rights acquired by the EOR from the engineer onwards to the foreign client, in equivalent scope on equivalent terms. Not summarised. Not implied. Explicit.
• A representation and warranty from the EOR confirming that the engineer-side employment contracts contain the assignment language to begin with. This puts the EOR on the line for the upstream link, which is what you actually want.
• Treatment of moral rights — at minimum, a confirmation that the engineer has agreed contractually not to exercise moral rights against the foreign client.
• A cooperation clause requiring the EOR to provide further documentation if needed — sometimes you need this at M&A, sometimes for trademark or patent filings, sometimes for an audit. The EOR should be obligated to help, not optional.

The questions to ask the EOR before signing, in plain English: “Show me the engineer-side contract template for IP assignment.” “Show me how those rights flow through to me in your master services agreement.” A serious EOR has clear answers and templates ready to walk through on a call. An EOR that fumbles these questions is the EOR that will cost you the deal at diligence eighteen months later. We touched on related contract design issues in our EOR vs PEO vs Outstaffing in Belarus comparison.

Common foreign-founder mistakes

Patterns we see consistently enough to call them patterns.

“We have a standard work-for-hire clause”

That clause is a US-law construct. Belarusian law doesn’t transfer rights under it without local-style assignment language alongside. The clause isn’t wrong — it’s just insufficient. Belarusian-law-governed employment contracts need Belarusian-law-form assignment in addition to (or instead of) the work-for-hire phrasing.

Generic NDAs that don’t identify confidential information specifically

“All information disclosed during the course of the engagement” reads tight in the US. It gets narrowed by the Belarusian courts. List categories. Specify document marking conventions. The narrower and more specific the description, the more enforceable the obligation.

Access controls left to the engineer

Personal GitHub accounts used to access company repos. Personal Google accounts on company tools. “We trust our engineers” — which is true, and also irrelevant to the operational protection question. Use corporate accounts. Pay for the enterprise tier of your Git provider. The audit logging alone is worth the extra ten dollars a month per seat.

No documented offboarding procedure

The single most common operational gap. When an engineer leaves — for any reason — what gets removed, when, by whom? Without a procedure, you end up with former engineers retaining access for days or weeks. In most cases nothing bad happens. In a small fraction it does, and you don’t know in advance which fraction you’re in.

Treating moral rights as theoretical

Moral rights are rarely invoked. Rarely is it never. We’ve seen them used in disputes where the engineer felt mistreated and wanted leverage. The non-exercise undertaking costs nothing to add to the contract. The cost of leaving it out is asymmetric.

Trusting EOR templates without reviewing the chain specifically

Reputable EORs have decent templates. “Decent” doesn’t mean “matches your specific deal,” and the template might transfer rights to the EOR cleanly but not flow them through to you cleanly. Read the IP and assignment sections specifically. Ask the EOR to walk you through the chain on a video call. If they can’t do that, that’s diagnostic.

Short setup checklist

Save and forward as needed.

• The employment contract has explicit assignment (отчуждение) of exclusive IP rights, in writing, with specific output description.
• Assignment scope unambiguous — full transfer, worldwide, perpetual, covering derivative works.
• Moral rights are addressed with a non-exercise undertaking from the engineer.
• EOR-to-client contract flows rights through to the foreign client on equivalent terms.
• EOR representations and warranties confirm the engineer-side chain is in place.
• NDA identifies confidential information by category and treatment requirement, with a reasonable duration.
• Source code lives on EU- or US-hosted Git infrastructure with controlled access.
• Access controls are reviewed quarterly. Corporate accounts only. Private repos with branch protection.
• Git-layer audit logging with retention aligned to your records policy.
• Same-day offboarding procedure documented and rehearsed.
• Backup independent of engineer environments; recovery tested at least annually.

FAQ

If my engineer is employed by an EOR, do I own what they build?

Only if the chain is complete end-to-end. The engineer transfers IP to the EOR through their employment contract. The EOR transfers it to you through your master services agreement. Both links need explicit assignment in equivalent terms. If either link is weak — most often the second — you don’t own the IP, even though the engineer thought they were building for you, and the EOR thinks it has the rights. Get the chain documented before signing, not after the diligence note arrives.

Does HTP residency change the IP assignment requirements?

Not the underlying rule. The Belarusian Civil Code requirement for explicit assignment applies whether the company is HTP-resident or not. What HTP residency does change is commercial flexibility — English-language contracts and elements of English commercial law are accommodated, which makes the contract conversation smoother. But the assignment substance has to be there in local-law form regardless.

Can we use our standard US or UK contract template for Belarusian engineers?

As a starting point, yes. As the final document, no. The work-for-hire and IP assignment language in the US and UK templates doesn’t translate fully under Belarusian law. The right approach is to take your home-jurisdiction template as the commercial spine and have a Belarusian IP lawyer add the local-law assignment language, the moral rights treatment, and the specific clauses around derivative works and scope. Most clean solutions are bilingual contracts — the English version names the commercial deal, the Russian version handles the local-law mechanics, and both versions say the same thing about what the engineer is building and who owns it.

Are NDAs enforceable against Belarusian engineers?

Yes, with structure. The NDA needs to identify confidential information specifically rather than generically. It needs a reasonable duration. The party receiving the information needs to actually treat it as confidential operationally. Forum and governing law matter — an NDA governed by foreign law against a Belarusian engineer is harder to enforce in practice than one structured for Belarusian courts, even when both look strong on paper. If practical enforceability matters to your business, structure it for Belarusian forums.

Open-source contributions — who owns code an engineer commits to public projects?

Depends on what’s in the contract. By default, if the engineer’s general assignment covers all work in the course of employment, that includes open-source contributions made during work hours on work projects. Sensible employers either prohibit open-source contributions without prior approval or carve out specific permissions in the contract — the second is usually better for engineer morale. Either way, address it explicitly. Silence on this point creates ambiguity nobody wants later, and the answer-by-default tends to disappoint somebody.

If an engineer leaves and joins a competitor, what protections do we have?

Three layers. The NDA continues to apply to confidential information, assuming it’s drafted to. The IP assignment continues to apply — the engineer can’t take the code or copy it. Post-employment non-compete clauses are enforceable in Belarus but are interpreted narrowly. Duration needs to be reasonable, typically six to twelve months. Geographic scope needs to be reasonable. In some structures the former employer has to pay compensation for the non-compete period. Aggressive non-compete language tends to get cut back. Reasonable language tends to hold.

The bottom line

Belarusian IP law differs from US and UK law in ways that foreign founders consistently underestimate. The work-for-hire default doesn’t carry over. Explicit assignment in local-law form is required. The chain through an EOR needs to be coherent at every link. The NDA needs to be drafted specifically rather than imported wholesale. And the source code needs to live somewhere you actually control access.

None of this is exotic. It’s standard practice in Belarus, well understood by experienced local counsel and by serious EOR providers. The reason foreign founders get caught out is that the differences are at the level of mechanics rather than headline rules — easy to miss if you’re applying home-jurisdiction assumptions, easy to handle if you ask the right questions before signing.

The expensive version of this problem is the diligence note eighteen months in, with the founder sending us a confused email asking what just happened. The cheap version is the right questions on the EOR call before the first engineer signs anything. The cost gap between those two versions is the substance of this article.

At Recruiting.by we work with foreign founders through both IT recruitment and the operational layer — EOR, PEO, payroll. We run under HTP residency, and the IP assignment chain through our EOR structure is set up to flow rights through to the foreign client cleanly — the kind of thing investor counsel asks about at Series B. For broader HR consulting on contract structure across a scaling team, we handle that too. For a conversation about the specific contracts in your current setup, what your assignment chain looks like today, and where the gaps might sit — contact us. For legal advice on the contracts themselves, talk to a qualified Belarusian IP lawyer. We’ll point you to ones we trust if you’d like.