NDA, передача прав на ИС и защита исходного кода при найме разработчиков в Беларуси

Фаундер из США, середина Series A. Команда из четырёх инженеров в Беларуси. Продукт релизится, команда работает, всё выглядит чисто. Дальше ведущий инвестор начинает Series B due diligence и просит показать цепочку передачи прав на ИС. Фаундер пересылает то, что есть — оффер-леттеры инженеров, стандартный контракт EOR. Через неделю юристы инвестора возвращаются с письменной заметкой. Цепочка не чистая. Формулировки о передаче прав в трудовых договорах по белорусскому праву права не передают. Строго говоря, у компании фаундера нет прав на существенную часть собственного продукта.

Появились проблемы. EOR выглядит серьёзным, контракты — профессиональными, инженеры явно работают добросовестно. И тем не менее — заметка от юристов однозначная.

Другой фаундер, другая стадия, другой размер команды — та же заметка от due diligence. Разрыв между тем, что иностранный фаундер думает он получает по ИС, и тем, что реально даёт белорусское право, — это одно из устойчивых слепых пятен на этом рынке.

Эта статья разбирает картину. Какой в Беларуси дефолт по правам на ИС. Что нужно прописать в контракте, чтобы этот дефолт перебить. Как работают NDA. Как практически устроена защита исходного кода. И — главное — как выглядит цепочка, когда нанимаете через EOR, потому что именно там обычно сидит реальный риск.

Дисклеймер сразу. Мы рекрутинговое агентство, не юридическая фирма. Мы видим это с рекрутинговой и EOR-стороны каждую неделю, но за правовой консультацией по вашим конкретным контрактам нужно обращаться к профильному белорусскому юристу по ИС. 

Тот самый параметр по умолчанию, который удивляет каждого иностранного основателя. 

Белорусское правило простым языком. По Гражданскому кодексу и закону об авторском праве, без явной письменной передачи исключительных прав права на произведение, созданное работником, остаются у работника. У работодателя возникает лицензия — иногда широкая, иногда узкая, в зависимости от того, что реально написано в договоре. У работодателя не возникает права собственности на результат.

Это существенно отличается от позиции США, где практика найма работников меняет правила игры по умолчанию, и в большинстве случаев работодатель по умолчанию является собственником. Также это отличается от позиций Великобритании и Германии в некоторых аспектах. Беларусь – юрисдикция Гражданского кодекса, а не общего права, и концепция найма работников не применяется так, как это предполагают основатели США. 

Формулировка «Работник выполняет работу в интересах Работодателя» — по-английски звучит вроде нормально — описывает работу. Она не передаёт права на её результат. Без явного отчуждения исключительных прав инженер технически по-прежнему обладает исключительными правами на то, что создал. У вас есть лицензия на использование. У вас нет прав собственности.

В повседневной работе разница незаметна. Инженер не просыпается однажды утром и не требует роялти за код, написанный им полгода назад. Проблема возникает в тот самый момент, который всегда наступает — проверка инвесторами, анализ со стороны приобретающей стороны, проверка со стороны серьезного корпоративного клиента. В этот момент кто-то запрашивает цепочку интеллектуальной собственности, и ответ «у нас есть стандартный пункт о выполнении работы по найму» перестает быть приемлемым. 

Резидентство в рамках Программы высокого уровня интеллектуальной собственности (HTP) делает операционную и коммерческую сторону более гибкой — контракты на английском языке, элементы английского коммерческого права в коммерческих отношениях, упрощение безбумажного оформления договоров. Однако базовое правило о передаче прав на интеллектуальную собственность, созданную сотрудниками, по-прежнему действует. Указ HTP 2017 года не отменил требование Гражданского кодекса. Он добавил гибкости сверху, а не заменил его снизу. 

Как выглядит правильная передача прав на ИС

Это основная часть договора. Что должно быть прописано в договоре — конкретно, в письменной форме, недвусмысленно — для фактической передачи права собственности на результат работы от инженера к работодателю. 

Описание того, что охраняется

Программный код, техническая документация, архитектурные проекты, фирменные активы — всё, что создаёт инженер. Защищаемая работа должна быть обозначена достаточно конкретно, чтобы в дальнейшем не возникало споров о том, что именно подпадает под действие закона. Фраза «Вся работа, созданная в процессе трудовой деятельности» звучит лаконично — белорусские суды, как правило, сужают её. Категории работ выдерживают проверку лучше. Что-то вроде «программный код, техническая документация, архитектурные проекты и сопутствующие материалы, созданные Сотрудником при исполнении служебных обязанностей» ближе к тому, что выдерживает проверку. 

Сама передача (отчуждение исключительных прав)

Это специфический термин белорусского права без чистого английского эквивалента. Передача должна быть именно «исключительных прав», не «всех прав» — у термина в Гражданском кодексе конкретное значение. Должна быть в письменной форме. Должно быть однозначно, что это именно передача, а не лицензия.

Стандартная формулировка в белорусском трудовом договоре выглядит примерно так — приведу концептуальный перевод, сам контракт будет на русском или белорусском: «Работник передаёт (отчуждает) Работодателю в полном объёме исключительные права на все результаты интеллектуальной деятельности, созданные Работником при выполнении трудовых обязанностей». Конкретные слова имеют значение. Структура клаузы имеет значение. «Передаёт» делает реальную работу, которую «считается переданным» не вполне делает в логике белорусского ГК.

Объём

Полное отчуждение или лицензия — вам нужно полное отчуждение, если хотите владеть. Исключительная или неисключительная — исключительная, чтобы инженер не лицензировал тот же код на сторонний проект. Территория — мировая. Срок — бессрочно, на полный срок действия прав по закону. Каждый из этих пунктов должен быть в контракте. «Все права на использование» — это не то же самое.

Производные произведения

Это важно в продуктовой разработке, где инженеры постоянно строят поверх существующего кода. В контракте должно быть прямо прописано, что производные произведения тоже покрываются передачей. Иначе через год вы рискуете спорить, является ли новая фича, построенная на базовой кодовой базе, частью переданных прав. Звучит теоретически — пока не возникает спор.

Личные неимущественные права автора

Вот тут иностранные фаундеры стабильно пропускают. Белорусское право признаёт личные неимущественные права автора — право авторства, право на неприкосновенность произведения, ещё несколько. Эти права непередаваемы. Никогда. Даже при самой чистой передаче исключительных прав. Они остаются у инженера, что бы в договоре ни было написано.

Что можно сделать в договоре — это включить обязательство инженера не осуществлять эти права против работодателя. Стандартная практика в хорошо составленных белорусских трудовых договорах. Почти всегда отсутствует в контрактах, собранных из иностранных шаблонов, потому что в common law такой концепции нет, и копировать неоткуда. Инженеры редко используют моральные права на практике — но «редко» не «никогда», и когда такое происходит, отсутствие этого обязательства — то, на что показывает юрист инженера.

Цепочка EOR / sub-процессоров

Если инженер работает в EOR, цепочка распределения прав выглядит следующим образом: Инженер → EOR → Иностранный клиент. Каждое звено представляет собой отдельный контракт. Каждое звено требует явного распределения прав в эквивалентном объеме и на эквивалентных условиях. Отсутствие звена разрывает цепочку — права прекращаются на том этапе, где возникли проблемы, и иностранный клиент в итоге не получает интеллектуальную собственность, хотя все думали, что она передается дальше. Это наиболее распространенный вид сбоев, который мы наблюдаем при проведении комплексной проверки. Ему посвящен отдельный раздел ниже. 

NDA в Беларуси — что работает, что нет

NDA в Беларуси исполнимы. Правила специфические, и иностранные фаундеры иногда думают, что их шаблон из домашней юрисдикции сюда переносится. По большей части — нет.

Что реально работает

Конкретно идентифицированная конфиденциальная информация. NDA должно описывать, что конфиденциально — по категориям, через маркировку документов, через перечисление систем. «Вся информация, раскрытая в ходе сотрудничества» — это формулировка, которую белорусские суды сужают, когда дело реально доходит до спора. Чем уже и конкретнее описание, тем легче исполнить обязательство.

Разумный срок. Суды смотрят на срок действия обязательств конфиденциальности и оценивают, пропорционален ли он защищаемому интересу. Три–пять лет после прекращения отношений — обычный диапазон для технической информации. Бессрочные NDA обычно подрезаются до разумного периода. Если действительно нужна бессрочная защита на что-то конкретное — материал коммерческой тайны — выделите это отдельно и объясните почему.

Реальное операционное обращение с информацией как с конфиденциальной. Получающая сторона должна реально с ней так и обращаться. Маркировка документов, ограничение доступа, инструктаж. NDA в письменной форме без операционной практики конфиденциальности тяжело исполняется — суд спрашивает, обращались ли с информацией как с действительно коммерческой тайной. Договор — это один вход. Поведение — другой вход.

Неустойка (штрафная неустойка) по белорусскому праву признаётся. Но статья 314 Гражданского кодекса даёт суду возможность уменьшить её, если она «явно несоразмерна последствиям нарушения». Размер неустойки, привязанный к правдоподобным коммерческим потерям, обычно переживает проверку. Размер, заданный для устрашения, а не для калибровки, — обычно режется. Калибруйте под реальные ожидаемые потери; не пишите театральные цифры, которые вы и не рассчитываете реально получить.

Для сотрудников NDA обычно встраивается в трудовой договор, а не подписывается отдельно. Для подрядчиков и ИП — отдельное NDA нормальная практика. Для senior-инженеров, уходящих к конкуренту, постдоговорная неконкуренция (тоже узко интерпретируемая в Беларуси) в паре с NDA — практическая структура.

Защита исходного кода — операционный слой

Вот где иностранные основатели иногда заключают железные контракты и всё равно теряют исходный код, потому что игнорируют операционный уровень. Документация необходима. Операционный стек как минимум не менее важен. И, по нашему опыту, именно операционный стек позволяет вернуть деньги, если что-то пойдёт не так, — контракт же позволяет получить компенсацию позже, что гораздо хуже, чем если бы код вообще не был потерян. 

Практические настройки защиты исходного кода в белорусской инженерной команде в 2026 году: 

• Исходный код находится в EU- или US в Git-инфраструктуре. GitHub, GitLab.com, Bitbucket Cloud. Не на серверах в Беларуси и не на ноутбуках инженеров как первичная копия. Доступ выдаётся; физически код лежит там, где вы это контролируете.
• Приватные репозитории с branch protection. Production-ветки защищены от прямого push. Все осмысленные изменения идут через pull request с обязательным review.
• Signed commits, где это поддерживается рабочим процессом. Аудит-след по тому, кто что коммитил, когда, с правильной атрибуцией.
• Контроли доступа пересматриваются раз в квартал — не раз в год. Роли инженеров соответствуют реальной ответственности. Никаких общих аккаунтов. Никакого «временного админ-доступа», который тихо становится постоянным за двенадцать месяцев.
• Корпоративные ноутбуки с полным шифрованием диска. MDM или эквивалент, где бюджет позволяет. Личные устройства для production-работы не используются.
• Логирование и мониторинг на Git-слое — кто пушил, кто пуллил, кто клонировал, со сроками хранения. Большинство enterprise-планов это даёт. Заплатите за это.
• Независимый бэкап вне инженерных окружений. Процедура восстановления проверяется хотя бы раз в год — не просто описана.
• Процедура same-day-офбординга, прописанная и отрепетированная. Когда инженер уходит, доступ отзывается во всём — Git, тикетная система, облако, CI/CD, внутренние инструменты — в тот же рабочий день. Не через неделю.

В компаниях-резидентах ПВТ большая часть этого уже встроена в стандартную энтерпрайз-практику. У не-ПВТ-сетапов иногда есть пробелы. Если ваша команда работает без задокументированной процедуры офбординга по доступу к коду — почините это в этом квартале. Это тот пробел, который становится реальной проблемой в небольшой доле случаев, когда инженер уходит на плохих условиях, — и вы заранее не знаете, в какой именно доле окажетесь.

По юрисдикционному моменту: исходный код, физически лежащий в Беларуси, подпадает под белорусское право и его операционные реалии. Исходный код в EU- или US-инфраструктуре, к которому белорусские инженеры имеют доступ, регулируется тем, где данные физически сидят. Для большинства иностранных клиентов практическое решение — держать исходники в EU- или US-хостящемся Git и давать белорусским инженерам контролируемый доступ. Это одно архитектурное решение перемещает заметный кусок риска в вашу сторону. Стоит делать его осознанно, а не случайно.

Цепочка, когда между вами и инженером стоит EOR

Большинство иностранных клиентов, нанимающих в Беларуси, делают это через EOR. EOR — юридический работодатель белорусского инженера. Поэтому цепочка передачи прав на ИС выглядит так:

Инженер → EOR → Иностранный клиент.

Каждое звено представляет собой отдельные договорные отношения. Каждое звено требует явного уступки прав в эквивалентном объеме и на эквивалентных условиях. Наиболее распространенная ошибка, которую мы наблюдаем при проверке: трудовой договор инженера с EOR содержит четкие формулировки об уступке прав в соответствии с белорусским законодательством. Чисто. Правильно составлено. Выполняет свою функцию. Но договор между EOR и иностранным клиентом — генеральный договор на оказание услуг или приложение к нему — не передает эти права дальше на эквивалентных условиях. Цепь обрывается на втором звене. Результат: инженер передал интеллектуальную собственность EOR, но иностранный клиент ею не владеет. 

Именно такая заметка и приходит от юристов инвестора.

Что искать в EOR-контракте, конкретно:

• Прямую формулировку, передающую все права на ИС, приобретённые EOR у инженера, далее иностранному клиенту, в эквивалентном объёме на эквивалентных условиях. Не подразумеваемо. Не суммарно. Явно.
• Заверения и гарантии EOR, что трудовые договоры с инженерами содержат соответствующую формулировку отчуждения на верхнем звене цепочки. Это ставит EOR под ответственность за upstream-звено — что вам и нужно.
• Обработку моральных прав — как минимум подтверждение, что инженер договорно обязался не осуществлять личные неимущественные права против иностранного клиента.
• Положение о сотрудничестве, обязывающее EOR предоставить дополнительные документы, если они понадобятся — иногда это нужно на M&A, иногда для регистрации товарных знаков или патентов, иногда на аудит. EOR должен быть обязан помочь, а не «может рассмотреть».

Вопросы, которые стоит задать EOR до подписания, простым языком: «Покажите мне шаблон трудового договора с инженером в части передачи прав на ИС». «Покажите, как эти права протекают ко мне через ваш MSA». Серьёзный EOR имеет на эти вопросы готовые ответы и шаблоны, по которым можно пройтись на видеозвонке. EOR, который на этих вопросах буксует, — это тот EOR, который через полтора года стоит вам сделки на due diligence. Связанные вопросы по дизайну контрактов мы разбирали в сравнении EOR vs PEO vs Outstaffing в Беларуси.

Типичные ошибки иностранных фаундеров

Паттерны, которые мы видим достаточно стабильно, чтобы называть их паттернами.

«У нас есть стандартный work-for-hire clause»

Этот clause — конструкция права США. Под белорусским правом он права не передаёт без сопровождающей формулировки отчуждения в местной форме. Сам пункт не «неправильный» — он просто недостаточен. Трудовые договоры под белорусским правом нуждаются в отчуждении в местной форме либо вместо work-for-hire, либо вдобавок к нему.

Шаблонные NDA, не идентифицирующие конфиденциальную информацию конкретно

«Вся информация, раскрытая в ходе сотрудничества» — звучит плотно по-английски. Сужается белорусскими судами. Перечисляйте категории. Прописывайте маркировку документов. Чем уже и конкретнее описание, тем легче исполнить обязательство.

Контроли доступа, отданные инженеру

Личные GitHub-аккаунты, используемые для доступа к корпоративным репозиториям. Личные Google-аккаунты на корпоративных инструментах. «Мы доверяем нашим инженерам» — что правда, и при этом не имеет отношения к операционному вопросу защиты кода. Используйте корпоративные аккаунты. Платите за enterprise-план Git-провайдера. Одно только аудит-логирование стоит лишних десяти долларов в месяц на одного человека.

Нет задокументированной процедуры офбординга

Самый частый операционный пробел. Когда инженер уходит — по любой причине — что отзывается, когда, кем? Без процедуры вы получаете бывших инженеров с активным доступом днями или неделями. В большинстве случаев ничего плохого не происходит. В небольшой доле — происходит, и вы заранее не знаете, в какой доле окажетесь.

Считать моральные права теоретическими

Моральные права используют редко. Редко не значит никогда. Мы видели, как их применяли в спорах, где инженер чувствовал себя обиженным и хотел рычага. Обязательство не осуществлять моральные права в договоре стоит вам нуля. Стоимость его отсутствия — асимметричная.

Доверять шаблонам EOR без отдельного просмотра цепочки

У авторитетных EOR есть неплохие шаблоны. «Неплохие» не означает «соответствуют вашей конкретной сделке», и шаблон может передавать права EOR без проблем, но не передавать их вам без проблем. Внимательно изучите разделы об интеллектуальной собственности и переуступке прав. Попросите EOR подробно рассказать вам о всей цепочке сделок по видеосвязи. Если они не могут этого сделать, это диагностический признак. 

Короткий setup-чеклист

Сохранить и переслать команде.

• Трудовой договор содержит явное отчуждение исключительных прав на ИС, в письменной форме, с конкретным описанием охраняемого результата.
• Объём передачи однозначный — полное отчуждение, мировая территория, бессрочно, с покрытием производных произведений.
• Моральные права отработаны через обязательство инженера не осуществлять их против работодателя.
• EOR-to-client контракт передаёт права дальше иностранному клиенту в эквивалентных условиях.
• Заверения и гарантии EOR подтверждают, что цепочка на стороне инженера в порядке.
• NDA идентифицирует конфиденциальную информацию по категориям и режиму обращения, с разумным сроком.
• Исходный код живёт на EU- или US-хостящейся Git-инфраструктуре с контролируемым доступом.
• Контроли доступа пересматриваются раз в квартал. Только корпоративные аккаунты. Приватные репозитории с branch protection.
• Аудит-логирование на Git-слое со сроками хранения, согласованными с вашей политикой по записям.
• Процедура same-day-офбординга прописана и отрепетирована.
• Бэкап независим от инженерных окружений; восстановление проверяется хотя бы раз в год.

Вопрос-ответ

Если мой инженер трудоустроен у EOR, мне принадлежит то, что он пишет?

Только если цепочка целая по всей длине. Инженер передаёт ИС в EOR через трудовой договор. EOR передаёт её вам через MSA. Оба звена нуждаются в явной передаче на эквивалентных условиях. Если слабое любое из звеньев — чаще второе — у вас прав нет, хотя инженер думает, что работал на вас, и EOR думает, что права у него есть. Документируйте цепочку до подписания, а не после прихода заметки от due diligence.

Влияет ли резидентство ПВТ на требования к передаче ИС?

На базовое правило — нет. Требование Гражданского кодекса о явной передаче применяется и к ПВТ-резиденту, и к не-резиденту. Что резидентство ПВТ меняет — это коммерческая гибкость: разрешён английский язык контрактов, в коммерческих отношениях допускаются элементы английского коммерческого права, контрактный разговор идёт глаже. Но субстанция отчуждения должна быть в местной форме независимо.

Можно ли использовать наш стандартный американский или британский шаблон под белорусских инженеров?

Как стартовую точку — да. Как финальный документ — нет. Формулировки work-for-hire и передачи прав в US/UK-шаблонах не переезжают полностью под белорусское право. Правильный подход — взять домашний шаблон как коммерческий каркас и попросить белорусского IP-юриста добавить местную формулировку отчуждения, обработку моральных прав и конкретные клаузы по производным произведениям и объёму. Чаще всего чистое решение — двуязычный договор. Английская версия описывает коммерческую сделку. Русская версия закрывает местную правовую механику. И обе версии говорят одно и то же про то, что инженер создаёт и кому это принадлежит.

Что делать, если через полгода обнаружили, что цепочка прав сломана?

Чинится, но почистить дороже, чем сделать правильно с самого начала. Стандартный сценарий: письменное соглашение о подтверждении (ратификация), подписанное инженером (и EOR, если он в середине), подтверждающее и переоформляющее передачу. Иногда сопровождается единоразовой выплатой — зависит от состояния отношений. Большинство инженеров идут навстречу. Некоторые — нет, особенно если более широкие отношения уже подпорчены. Вывод: настраивайте цепочку правильно до того, как возникло какое-то напряжение. Дешевле. Чище. Быстрее.

Исполнимы ли NDA против белорусских инженеров?

Да, при правильной структуре. NDA должно идентифицировать конфиденциальную информацию конкретно, а не общо. Должен быть разумный срок. Получающая сторона должна реально обращаться с информацией как с конфиденциальной операционно. Форум и применимое право имеют значение — NDA под иностранным правом против белорусского инженера тяжелее исполнить на практике, чем NDA, структурированное под белорусские суды, даже если оба на бумаге выглядят одинаково крепкими. Если вам важна практическая исполнимость — структурируйте под белорусский форум.

Open-source — кому принадлежит код, который инженер коммитит в публичные проекты?

Зависит от того, что в договоре. По умолчанию, если общее отчуждение инженера покрывает всю работу в рамках занятости, в это попадают и open-source-коммиты, сделанные в рабочее время на рабочих проектах. Разумные работодатели либо запрещают open-source-вклад без предварительного согласования, либо вырезают конкретные разрешения в договоре — второй вариант лучше для морали инженеров. В любом случае проговорите это явно. Молчание по этому пункту создаёт двусмысленность, которой никто не хочет потом, и ответ-по-умолчанию обычно кого-то разочаровывает.

Если инженер уходит к конкуренту — какая у нас защита?

Три слоя. NDA продолжает действовать на конфиденциальную информацию, если оно нормально написано. Передача ИС продолжает действовать — инженер не может взять код или скопировать его. Постдоговорная неконкуренция исполнима в Беларуси, но интерпретируется узко. Срок разумный — обычно шесть–двенадцать месяцев. Географический охват разумный. В некоторых структурах бывший работодатель должен платить компенсацию за период неконкуренции. Агрессивные неконкурентные клаузы режутся. Разумные — обычно держатся.

Какое право выбирать для договора — белорусское или иностранное?

Трудовой договор между инженером (или EOR) и инженером — регулируется белорусским правом. Это не выбор по существу. MSA между EOR и иностранным клиентом — может регулироваться иностранным правом, и часто так и делается. Практический результат слоистый: передача ИС на стороне инженера происходит под белорусским правом, передача EOR-клиент происходит под тем правом, которое регулирует MSA. Оба слоя должны быть согласованы. Оба должны говорить одно и то же про объём. Иначе цепочка разваливается на стыке.

Главное

Белорусское право по ИС работает иначе, чем американское и британское, способами, которые иностранные фаундеры стабильно недооценивают. Дефолт work-for-hire сюда не переезжает. Нужно явное отчуждение в местной форме. Цепочка через EOR должна быть согласованной на каждом звене. NDA нужно составлять конкретно, а не переносить шаблон целиком. И исходный код должен жить там, где вы реально контролируете доступ.

Ничего экзотического тут нет. Это стандартная практика в Беларуси, хорошо понимаемая опытными местными юристами и серьёзными EOR-провайдерами. Иностранные фаундеры попадают на этом потому, что отличия — на уровне механики, а не громких правил. Легко пропустить, если применяешь предположения родной юрисдикции; легко закрыть, если задать правильные вопросы до подписания.

Дорогая версия этой проблемы — заметка от due diligence через полтора года, и фаундер пишет нам растерянный имейл с вопросом, что только что произошло. Дешёвая версия — правильные вопросы на звонке с EOR до того, как первый инженер что-то подписал. Разница в стоимости между этими двумя версиями и есть содержание этой статьи.

В Recruiting.by мы работаем с иностранными фаундерами и через IT-рекрутинг, и через операционный слой — EOR, PEO, payroll. Работаем в режиме резидента ПВТ, и цепочка передачи ИС через нашу EOR-структуру выстроена так, чтобы права чисто протекали к иностранному клиенту — то, про что юристы инвестора спрашивают на Series B. По более широкому HR-консалтингу на тему контрактной структуры под масштабирующуюся команду — это тоже к нам. Если хочется поговорить про конкретные контракты в вашей текущей конфигурации, как сейчас выглядит ваша цепочка прав и где могут сидеть пробелы — напишите нам. За правовой консультацией по самим контрактам — к профильному белорусскому IP-юристу. Если нужно, мы подскажем тех, кому доверяем.