Обзор: Договор с разработчиком из КР: передача прав на ПО

Почему права на ПО не переходят автоматически?

Базовый принцип авторского права — права возникают у создателя в момент создания произведения. Это правило закреплено в Законе «Об авторском праве и смежных правах» и распространяется на программный код так же, как на музыку или литературный текст. Никакая оплата сама по себе не означает передачу прав: заказчик, перечисливший деньги за разработку, получает лишь экземпляр программы, если договор прямо не предусматривает иное.

На практике это означает: если договор с кыргызским разработчиком содержит только описание технического задания и порядок оплаты — заказчик оказывается в уязвимом положении. Он не может легально продавать продукт, создавать производные версии, регистрировать ПО как актив или передавать права инвесторам при due diligence. При этом разработчик технически сохраняет возможность использовать созданный код повторно или передать его третьим лицам.

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

Отдельный вопрос — open source компоненты. Кыргызские разработчики активно используют библиотеки с различными лицензиями (MIT, GPL, Apache, AGPL). Если договор не регулирует ответственность за соблюдение условий этих лицензий, заказчик принимает на себя неопределённый правовой риск при коммерциализации продукта.

Какие типы договоров применяются при работе с разработчиками КР?

Кыргызское право предоставляет несколько договорных конструкций для оформления отношений с разработчиком, и выбор между ними влияет не только на объём получаемых прав, но и на налоговые последствия для обеих сторон.

Договор подряда (возмездного оказания услуг) — наиболее распространённый инструмент при работе с фрилансерами и небольшими командами. Сам по себе он не передаёт права на созданный результат: для этого необходимо включить специальное условие об отчуждении исключительных прав или приложить к договору лицензионное соглашение. Без такого условия договор описывает только процесс работы, но не судьбу интеллектуального результата.

Договор об отчуждении исключительного права — полная и окончательная передача всего объёма имущественных прав. После подписания разработчик утрачивает право использовать переданный код, создавать на его основе производные продукты или выдавать лицензии третьим лицам. Это предпочтительная форма для заказчиков, которым важен полный контроль над активом — например, при продаже стартапа или привлечении венчурных инвестиций. Личные неимущественные права (право авторства, право на имя) остаются у физического лица — автора и не могут быть переданы ни при каких обстоятельствах.

Лицензионный договор — разработчик сохраняет исключительное право и предоставляет заказчику ограниченное разрешение на использование. Параметры лицензии — территория, срок, способы использования, исключительность — определяются договором. Эта конструкция популярна среди резидентов ПВТ: роялти за лицензию на ПО не облагаются налогом на прибыль в рамках льготного режима, что создаёт налоговую оптимизацию при работе с зарубежными заказчиками. ПВТ-резидентство даёт экономию налоговой нагрузки около 80% против общего режима.

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

Как корректно оформить передачу прав в договоре?

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

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

Перечень передаваемых прав. В договоре следует перечислить конкретные правомочия: право воспроизведения, распространения, переработки (создания производных версий), перевода, публичного сообщения, доведения до всеобщего сведения. Общая фраза «исключительное право» технически достаточна, но на практике при международных сделках заказчики предпочитают прямой перечень — это снижает риск разногласий при использовании ПО в юрисдикциях с иными правовыми традициями.

Момент перехода прав. По умолчанию права переходят в момент подписания договора (при отчуждении) или в момент его вступления в силу (при лицензии). Если передача привязана к приёмке результата — необходим акт приёмки-передачи как основание для перехода. Без чёткого указания на момент перехода возникает правовая неопределённость в период между разработкой и подписанием актов.

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

Гарантии разработчика. Критически важный блок, который часто упускается. Разработчик должен гарантировать: что является единственным правообладателем передаваемого кода; что код не нарушает прав третьих лиц; что в составе ПО нет open source компонентов с несовместимыми лицензиями (или — что условия таких лицензий раскрыты заказчику). Нарушение этих гарантий должно влечь обязанность разработчика возместить убытки, включая расходы на защиту от претензий третьих лиц.

Какие риски возникают при работе с ПВТ-резидентами?

Парк высоких технологий КР — режим с уникальными налоговыми преимуществами, но его применение влечёт специфические правовые особенности, которые необходимо учитывать при структурировании договора.

Резидент ПВТ работает в рамках специального правового режима, установленного Законом «О Парке высоких технологий». Это означает, что к его деятельности применяются отраслевые правила, которые в ряде вопросов отличаются от общегражданского регулирования. В частности, договорная документация ПВТ-резидентов нередко проходит проверку со стороны администрации Парка при подтверждении соответствия деятельности заявленному профилю.

Налоговый аспект — ключевой. При ставке налога на прибыль 0% и НДС 0% ПВТ-резидент не выдаёт заказчику налоговую накладную (ЭСФ) с выделенным НДС. Для заказчика, работающего в общем налоговом режиме и являющегося плательщиком НДС, это означает отсутствие входящего НДС к зачёту. При крупных суммах сделки этот фактор влияет на сравнительную экономику работы с ПВТ-резидентом против обычного ОсОО.

Travel Rule обязателен для всех VASP в Кыргызстане — без него лицензия под угрозой. Это правило становится актуальным, если ПВТ-резидент одновременно является VASP-лицензиатом Финнадзора и принимает оплату в криптовалютных активах. В таком случае договор должен учитывать AML-требования и порядок идентификации плательщика, что существенно усложняет стандартную документацию.

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

Платёжная лицензия НБКР и VASP-лицензия Финнадзора — разные документы для разных видов деятельности. Если ПВТ-резидент принимает платежи через собственный платёжный шлюз — необходимо убедиться в наличии соответствующей лицензии и отразить в договоре порядок расчётов.

Как работает схема с ПКИ и чем она отличается от ПВТ?

Парк креативных индустрий — относительно новый специальный режим с иным профилем резидентов и иными условиями. По состоянию на начало 2026 года в ПКИ зарегистрировано около 76 резидентов при общей выручке порядка 915 млн сомов. Для договоров с разработчиками-резидентами ПКИ характерны свои особенности.

Налоговая ставка ПКИ — единый налог 1% (в 2025–2026 годах) с последующим повышением до 2% с 2027 года. В отличие от ПВТ с нулевыми ставками, ПКИ-резидент уплачивает единый налог, что меняет экономику сделки. Вместе с тем перечень видов деятельности в ПКИ шире: он включает 34 вида, охватывающих разработку программных продуктов в сфере анимации, геймдева, дизайна, медиа.

Требование к структуре выручки — критически важное. Резидент ПКИ обязан получать не менее 90% выручки от ПКИ-видов деятельности. Это означает, что договор с ПКИ-резидентом должен быть квалифицирован именно как договор на ПКИ-вид разработки — иначе резидент рискует утратить право на льготный режим. При структурировании сделки следует проверять соответствие предмета договора перечню ПКИ-видов.

С точки зрения передачи прав на ПО принципиальных отличий от общего режима нет: Закон «Об авторском праве и смежных правах» применяется к ПКИ-резидентам в полном объёме. Однако налоговые последствия выплаты вознаграждения и форма расчётов (1% единый налог против 0% ПВТ) влияют на структуру цены договора.

Подробное сравнение режимов ПВТ и ПКИ с расчётом налоговой нагрузки доступно в материале ПВТ против ПКИ в Кыргызстане: для кого что выгоднее.

Что проверить при due diligence договорной базы разработчика?

При покупке IT-компании или привлечении инвестиций правовая проверка (due diligence) договорной базы с разработчиками — один из ключевых блоков. Инвестор или покупатель должен убедиться, что компания реально владеет правами на ПО, которое составляет её основной актив.

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

Трудовые договоры и условие о служебном произведении. Если разработчики оформлены в штат — необходимо убедиться, что трудовые договоры содержат условие о том, что создаваемые программные продукты являются служебными произведениями и права на них принадлежат работодателю. Отсутствие этого условия в стандартном трудовом договоре — типичная ошибка, которая обнаруживается именно при due diligence.

Договоры с фрилансерами и подрядчиками. Отдельно проверяются все договоры с внешними разработчиками — фрилансерами, субподрядчиками, иностранными контрагентами. Для каждого существенного вклада в кодовую базу должен существовать документ с условием об отчуждении прав. Практика показывает: именно договоры с фрилансерами чаще всего оказываются недооформленными.

Open source аудит. Необходимо провести анализ состава кодовой базы на предмет используемых open source библиотек и их лицензионных условий. Особое внимание — компонентам под GPL и AGPL: их использование в коммерческом продукте без соблюдения условий copyleft может потребовать раскрытия исходного кода всего продукта. Этот риск критичен для SaaS-продуктов и платформ.

Регистрация прав. В КР регистрация прав на ПО в Кыргызпатенте не является обязательной, но добровольная регистрация создаёт доказательную базу о дате создания и авторстве. При due diligence наличие свидетельства Кыргызпатента упрощает верификацию прав. Аналогичная логика применима к регистрации в иностранных патентных офисах при международной дистрибуции продукта.

Дополнительный контекст по корпоративному структурированию IT-компании в Кыргызстане — в материале IT-право и виртуальные активы в Кыргызстане: ПВТ и VASP.

Как защитить права при работе с иностранными заказчиками?

Кыргызские разработчики и ПВТ-резиденты всё активнее работают с зарубежными заказчиками — из России, США, Европы, ОАЭ. Международный контракт требует дополнительного слоя структурирования по сравнению с внутрикыргызской сделкой.

Выбор применимого права. Стороны вправе определить в договоре, право какого государства регулирует их отношения. Для кыргызского разработчика это практически важно: суды КР применяют кыргызское право по умолчанию, тогда как иностранный заказчик нередко настаивает на английском праве или праве штата Нью-Йорк. Оба варианта допустимы, но каждый создаёт свой набор рисков. При выборе иностранного права необходимо убедиться, что ключевые условия (объём передаваемых прав, гарантии, ответственность) адекватно работают в соответствующей правовой системе.

Юрисдикция для разрешения споров. МТС при ТПП КР — альтернатива государственному суду для споров с иностранным элементом. Решения МТС исполняются в 172 странах по Нью-Йоркской конвенции 1958 года — это существенное преимущество перед решениями государственных судов при работе с заказчиками из стран, не входящих в Кишинёвскую или Минскую конвенции. Для крупных контрактов арбитражная оговорка обязательна.

Валютные и платёжные вопросы. Получение иностранной валюты кыргызским ОсОО не требует специальных разрешений — валютный контроль в КР существенно либеральнее, чем в России или Казахстане. Тем не менее договор должен чётко определять валюту платежа, курс конвертации (если применимо), сроки и порядок оплаты. При работе с российскими заказчиками действующее СОИДН РФ-КР позволяет оптимизировать налогообложение роялти — ставка составляет 10% у источника по действующему соглашению.

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

Более детальный разбор налоговых аспектов международных IT-контрактов — в материале Налоговое резидентство в КР: как оформить за 183 дня.

Какие типичные ошибки встречаются в договорах на разработку ПО?

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

Ошибка 1: «Все права переходят к заказчику» без идентификации объекта. Формула хороша намерениями, но бесполезна в суде. Без чёткого описания передаваемого программного продукта — наименование, версия, функционал, ТЗ как приложение — предмет договора не определён. Суды, как правило, трактуют неопределённость предмета не в пользу заказчика.

Ошибка 2: Договор подряда без условия об отчуждении прав. Самая распространённая ошибка. Заказчик платит за разработку, получает программу, но правами не владеет. Разработчик формально вправе использовать тот же код повторно. Исправляется одним абзацем в договоре — но только до подписания.

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

Ошибка 4: Отсутствие гарантий чистоты прав. Договор без гарантий разработчика о том, что передаваемый код не нарушает прав третьих лиц, перекладывает весь риск претензий на заказчика. При масштабировании продукта или его продаже этот риск материализуется.

Ошибка 5: Неурегулированные open source компоненты. Разработчик использует библиотеку под GPL, не раскрывает этого заказчику, заказчик коммерциализирует продукт — и через два года получает претензию об обязательном раскрытии исходного кода. Договор должен обязывать разработчика раскрыть перечень всех использованных open source компонентов и их лицензий.

Ошибка 6: Отсутствие условия о будущих улучшениях. Если по завершении основного договора разработчик дорабатывает ПО — каждое такое улучшение является самостоятельным результатом интеллектуальной деятельности. Без отдельного условия о том, что права на улучшения также переходят к заказчику, история с неурегулированными правами воспроизводится применительно к каждой новой версии.

Как соотносятся права на ПО с VASP-лицензированием и криптопроектами?

Для кыргызских IT-компаний, совмещающих разработку ПО с деятельностью в сфере виртуальных активов, вопрос о правах на программный продукт приобретает дополнительное измерение — регуляторное.

VASP-лицензия, выдаваемая Финнадзором на основании Закона «О виртуальных активах», предполагает, что лицензиат самостоятельно контролирует программный код платформы или имеет на него надлежащие права. Финнадзор в 2025 году массово отзывал лицензии у ряда VASP — в ряде случаев причиной являлась в том числе неопределённость в правах на используемое программное обеспечение. Документация на права должна быть готова к предъявлению в ходе лицензионной проверки.

Смарт-контракты — особый случай. Код смарт-контракта является программным продуктом и охраняется авторским правом. Если VASP-лицензиат использует смарт-контракты, написанные сторонними разработчиками, необходимо либо получить лицензию на их использование, либо оформить отчуждение прав. Неурегулированность этого вопроса создаёт риски при регуляторном аудите.

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

AML-требования влияют и на договорную документацию. Если разработчик создаёт программный модуль для AML/KYC-проверок — договор должен содержать требования к функциональности, соответствующей стандартам Финнадзора и FATF, а также условие о ответственности разработчика за несоответствие этим требованиям. Travel Rule обязателен для всех VASP — его техническая реализация в программном коде должна быть верифицирована и задокументирована.

Подробности о получении VASP-лицензии через Финнадзор — в материале VASP-лицензия в Кыргызстане: получение через Финнадзор в 2026 году.

Практические рекомендации: минимальный чек-лист контракта

На основе анализа типичных ошибок и регуляторных требований можно сформировать минимальный перечень условий, которые должен содержать договор с разработчиком из КР — независимо от выбранной договорной конструкции.

Обязательные условия:

• Идентификация объекта: наименование ПО, версия или этап, ссылка на ТЗ как приложение
• Прямое условие о передаче исключительных прав или выдаче лицензии с конкретным перечнем правомочий
• Момент перехода прав: подписание договора, подписание акта приёмки-передачи или иной чётко определённый момент
• Вознаграждение за передачу прав (отдельно от оплаты услуг разработки или в составе единой суммы с выделением)
• Гарантии разработчика: единственный правообладатель, отсутствие обременений, отсутствие несовместимых open source лицензий
• Перечень open source компонентов и их лицензий как приложение к договору
• Условие о правах на будущие улучшения и производные версии
• Порядок разрешения споров: МСЭД (для внутрикыргызских сделок) или МТС при ТПП КР (для международных)

Дополнительные условия при работе с ПВТ-резидентом:

• Подтверждение статуса резидента ПВТ на момент заключения договора
• Порядок действий при утрате ПВТ-статуса в период исполнения договора
• Применимое право и соответствие международным стандартам (при наличии VASP-деятельности)

При due diligence дополнительно проверить:

• Трудовые договоры с разработчиками на предмет условий о служебных произведениях
• Договоры с фрилансерами и субподрядчиками
• Наличие/отсутствие свидетельств Кыргызпатента на ключевые программные продукты
• Соответствие open source аудита требованиям целевого рынка

Перейти к подробному пошаговому порядку оформления договора — в материале-партнёре: Пошагово: договор с разработчиком из КР и передача прав на ПО.

Общий обзор практики IT-права и цифровых активов БЕКЕМ — на странице IT-право и виртуальные активы. Все материалы по теме собраны в разделе Аналитика.