Контрольный список: Договор с разработчиком из КР: передача прав на ПО
Договор с разработчиком из Кыргызстана должен явно передавать исключительное право на ПО — без этого заказчик получает лишь лицензию, а право остаётся у автора. Ниже — 13 конкретных пунктов, которые нужно проверить перед подписанием или при аудите существующего договора.
Зачем нужен отдельный контрольный список для КР?
Кыргызстанское авторское право следует логике континентальной системы: исключительное право на ПО возникает у автора в момент создания и не переходит автоматически к заказчику по факту оплаты. Закон об авторском праве и смежных правах прямо устанавливает, что права передаются только по письменному договору с явным перечнем передаваемых правомочий. Если договор написан расплывчато — суды КР, как правило, толкуют неясности в пользу автора.
Дополнительную сложность создаёт распространённость ПВТ-разработчиков: резиденты Парка высоких технологий работают в особом налоговом режиме, и условия договора влияют на расчёт подоходного налога (5% вместо стандартных 10%). Ещё одна специфика — частое использование физических лиц вместо ОсОО, что меняет порядок удержания налогов заказчиком. Этот список охватывает оба сценария.
Наконец, для IT-компаний с иностранным участием критична возможность беспрепятственного распоряжения правами за рубежом: экспорт ПО, лицензирование иностранным клиентам, включение в продуктовый стек. Договор должен это прямо допускать. Подробнее о праве КР для IT — в обзоре IT-права и виртуальных активов КР.
Какие пункты должен содержать договор с разработчиком из КР?
1. Явное указание на отчуждение исключительного права
Договор обязан содержать формулировку «передаёт (отчуждает) исключительное право» — не «предоставляет лицензию», не «разрешает использование». Без слова «отчуждение» или «передача исключительного права» суд, как правило, квалифицирует договор как лицензионный, и право остаётся у разработчика. Это ключевое условие, без которого все остальные пункты теряют смысл для заказчика.
2. Точное описание объекта: что именно передаётся
В договоре необходимо перечислить конкретные программные продукты или компоненты — с наименованием, версией или функциональным описанием. Общие формулировки вроде «все результаты работ» оспариваются: суды требуют идентифицировать объект авторского права. Приложите техническое задание или спецификацию как неотъемлемую часть договора.
3. Условие о служебных произведениях (если разработчик — штатный сотрудник)
Если разработчик работает по трудовому договору, исключительное право на ПО, созданное в рамках трудовых обязанностей, по Закону об авторском праве принадлежит работодателю. Однако это правило работает только при двух условиях: задание зафиксировано письменно, и оно входит в должностные обязанности. Убедитесь, что трудовой договор и должностная инструкция охватывают конкретный вид разработки — иначе право останется у сотрудника.
4. Положение о подрядчиках и субразработчиках
Если разработчик привлекает третьих лиц (фрилансеров, субподрядчиков), договор должен обязывать его обеспечить передачу прав от субподрядчиков до момента передачи результата заказчику. На практике цепочка прав часто обрывается на уровне фрилансера — это одна из самых распространённых проблем при due diligence IT-компаний в КР.
5. Порядок передачи исходного кода и документации
Право на ПО без исходного кода — неполноценный актив. Зафиксируйте в договоре: формат передачи (репозиторий, архив), состав документации (архитектурные схемы, API-описания, инструкции по развёртыванию), сроки передачи и ответственность за задержку. Отсутствие исходного кода в договоре — частая причина споров при расторжении отношений с разработчиком.
6. Гарантии отсутствия обременений: open source и сторонние компоненты
Разработчик обязан гарантировать, что ПО не использует компоненты с лицензиями, несовместимыми с коммерческим распространением (GPL, AGPL). Включите в договор: список используемых сторонних библиотек, их лицензии, подтверждение совместимости с коммерческим использованием. При нарушении этого условия заказчик несёт риск претензий от правообладателей open source-компонентов.
Для IT-компании выбор между ПВТ, ПКИ и обычным ОсОО зависит от структуры выручки и команды. Покажем расчёт экономии на вашей модели — и проверим действующие договоры с разработчиками на предмет правовых рисков.
Обсудить IT-проект7. Налоговый статус разработчика и последствия для заказчика
Налоговые обязательства заказчика зависят от того, кто разработчик: физическое лицо, ИП, ОсОО или резидент ПВТ. Если разработчик — физическое лицо без ИП, заказчик выступает налоговым агентом и обязан удержать подоходный налог (10%) и перечислить взносы в Соцфонд. Если разработчик — резидент ПВТ, ставка подоходного налога составляет 5%, а обязанность удержания зависит от формы правоотношений. ПВТ-резидентство даёт экономию налоговой нагрузки около 80% против общего режима — запросите подтверждение статуса до подписания договора.
В договоре зафиксируйте: налоговый статус разработчика, кто несёт обязанность по уплате налогов, и что разработчик обязан уведомить заказчика об изменении статуса. Это предотвращает доначисления по итогам проверки ГНС.
8. Вознаграждение: разграничение стоимости работ и вознаграждения за передачу прав
Закон об авторском праве и смежных правах допускает безвозмездную передачу прав между юридическими лицами, но на практике налоговые органы могут переквалифицировать нулевое вознаграждение за права как скрытую схему. Рекомендуется выделить в договоре отдельную строку: стоимость разработки и вознаграждение за отчуждение исключительного права. Это снижает риски при налоговых проверках и упрощает признание расходов.
9. Моральные права автора: отказ от права на имя и неприкосновенность
По кыргызскому авторскому праву личные неимущественные права (право авторства, право на имя, право на неприкосновенность) не отчуждаются. Однако разработчик может дать письменное согласие на модификацию ПО без указания его имени. Зафиксируйте в договоре: заказчик вправе вносить изменения в ПО без согласования с автором и без указания его имени в продукте. Без этого условия переработка ПО формально требует согласия разработчика.
10. Конфиденциальность и NDA
Договор должен содержать режим конфиденциальности в отношении технических решений, алгоритмов и бизнес-логики ПО. Укажите: срок действия обязательства конфиденциальности (как правило, 3–5 лет после прекращения договора), перечень сведений, составляющих коммерческую тайну, и ответственность за нарушение. Режим коммерческой тайны в КР регулируется Гражданским кодексом КР — договорное закрепление усиливает позицию заказчика в споре.
11. Гарантийные обязательства и исправление ошибок
Установите гарантийный срок (как правило, 6–12 месяцев) и порядок устранения дефектов: срок реагирования на критические ошибки (например, 24 часа), на некритические (5 рабочих дней), порядок приёмки исправлений. Без гарантийных условий требовать от разработчика устранения ошибок после приёмки работ можно только через суд — на основании общих норм Гражданского кодекса КР об ответственности подрядчика.
12. Применимое право и порядок разрешения споров
Для договоров с разработчиком из КР применимое право — как правило, право Кыргызской Республики. При наличии иностранного заказчика рекомендуется зафиксировать юрисдикцию явно. Для споров стоимостью свыше $50 000 целесообразно предусмотреть арбитражную оговорку с передачей дела в МТС при ТПП КР: решения исполняются в 172 странах по Нью-Йоркской конвенции. Государственный суд — МСЭД — также эффективен, но сроки рассмотрения в среднем дольше.
Если разработчик — резидент ПВТ, договор может содержать специальные условия о юрисдикции в рамках регулирования ПВТ. Проверьте соответствие договора актуальному регулированию ПВТ КР.
13. Условия об эскроу исходного кода
При долгосрочных проектах или когда ПО критично для бизнеса заказчика, рекомендуется предусмотреть эскроу-соглашение: исходный код депонируется у нейтральной стороны и передаётся заказчику при наступлении оговорённых условий (прекращение деятельности разработчика, грубое нарушение договора). Это страховка на случай, если разработчик прекращает работу или становится недоступен. В КР функцию эскроу-агента может выполнять нотариус или специализированная IT-компания.
Как проверить существующий договор на соответствие списку?
Если договор с разработчиком уже подписан, проверка занимает в среднем 2–3 рабочих дня при наличии всей документации. Алгоритм: сначала устанавливается тип договора (отчуждение или лицензия), затем проверяется идентификация объекта, цепочка прав от субподрядчиков, налоговый статус разработчика и наличие гарантийных условий.
Критические дефекты — отсутствие явного отчуждения права и неидентифицированный объект — невозможно устранить задним числом без подписания дополнительного соглашения. Налоговые дефекты (неверно определённый агент, отсутствие разграничения вознаграждений) могут повлечь доначисления при проверке ГНС. Срок обжалования акта проверки ограничен 30 днями — пропуск означает принятие решения ГНС.
Для компаний, привлекающих инвестиции или готовящихся к продаже, правовая чистота прав на ПО — обязательный элемент due diligence. Инвестор, как правило, запрашивает весь массив договоров с разработчиками и проверяет цепочку прав на каждый программный компонент. Подробнее о структуре IT-компании в КР — в разделе аналитики БЕКЕМ.
Что делать, если разработчик отказывается от передачи прав?
Разработчик вправе отказаться от заключения договора об отчуждении права — никаких требований к обязательной передаче закон не содержит. В этом случае стороны могут согласовать лицензионный договор с максимально широким объёмом прав: исключительная лицензия, неограниченная территория, бессрочный срок, право на переработку и сублицензирование. Такая конструкция функционально близка к отчуждению, хотя право формально остаётся у разработчика.
Второй вариант — перестроить отношения: нанять разработчика в штат, обеспечив создание ПО в рамках трудовых обязанностей (служебное произведение). В этом случае исключительное право по закону переходит к работодателю. Третий вариант — создать собственную структуру разработки внутри ПВТ: резиденты ПВТ работают в предсказуемом правовом режиме, а споры о правах на ПО разрешаются быстрее. Консультации по выбору структуры — через практику IT-права БЕКЕМ.
Если отношения с разработчиком уже прекращены, а права не были оформлены, восстановить их через суд возможно при наличии доказательств: переписка, техническое задание, акты приёмки. Суды КР в ряде дел признавали право заказчика на использование ПО, созданного в рамках фактически выполненного заказа, — но это не равнозначно исключительному праву. Позиция суда зависит от конкретных обстоятельств и доказательной базы.
Особенности для ПВТ-разработчиков
Резиденты ПВТ работают в специальном правовом режиме: нулевая ставка налога на прибыль, нулевой НДС, подоходный налог 5% (вместо 10%) и взнос 1% в Дирекцию ПВТ. Режим бессрочный с 2024 года. При заключении договора с ПВТ-резидентом заказчику необходимо запросить свидетельство резидента ПВТ и проверить его актуальность: Финнадзор в 2025 году активно проверял ПВТ-компании, и статус мог быть изменён.
Для договора с ПВТ-резидентом-ОсОО НДС не начисляется на стоимость разработки — это стандартное условие режима. Если ПВТ-разработчик — физическое лицо (а это распространённая практика в малых проектах), порядок налогообложения меняется: заказчик-юрлицо выступает налоговым агентом по подоходному налогу со ставкой 5%. Это нужно прямо зафиксировать в договоре.
Отдельная проблема — договоры с ПВТ-разработчиками, работающими на иностранные компании: выплата вознаграждения нерезиденту за права на ПО может подпадать под СОИДН РФ-КР (для российских заказчиков). СОИДН РФ-КР действует и не приостановлено: ставка по роялти — 10%. Если вознаграждение за передачу прав квалифицируется как роялти, это влияет на налогообложение у источника выплаты в России. Подробнее — в материале об автоматическом обмене информацией КР.
Типичные ошибки при оформлении договора с разработчиком
Первая и наиболее распространённая ошибка — договор подряда без условия о передаче прав. Заказчик оплачивает разработку, получает работающий продукт, но права на ПО остаются у исполнителя. Это обнаруживается при due diligence, при попытке перепродать продукт или при конфликте с разработчиком.
Вторая ошибка — смешение режимов: в одном договоре одновременно упоминаются «передача прав» и «лицензия». Суды КР, как правило, при неустранимом противоречии признают договор лицензионным — по принципу ограничительного толкования в пользу автора. Решение: использовать один режим и явно прописать его.
Третья ошибка — отсутствие условия о правах на промежуточные версии и черновики. Если разработка велась итерационно, каждая версия ПО — самостоятельный объект авторского права. Без соответствующего условия права на промежуточные версии могут оставаться у разработчика, что создаёт риски при восстановлении более ранних версий продукта.
Четвёртая ошибка — игнорирование прав третьих лиц при разработке в команде. Если над проектом работали несколько разработчиков, каждый из них является соавтором соответствующих компонентов. Договор должен регулировать не только отношения с основным исполнителем, но и содержать механизм получения прав от всех соавторов — через прямые договоры или через обязательство исполнителя урегулировать права субавторов самостоятельно. Смотрите также: налоги в ПВТ: ответы на распространённые вопросы.
Чек-лист: 13 пунктов для проверки договора перед подписанием
- Договор содержит явную формулировку «отчуждение исключительного права» (не лицензия)
- Объект договора идентифицирован: наименование ПО, версия или функциональное описание
- Для штатных разработчиков: задание зафиксировано письменно и входит в должностные обязанности
- Разработчик обязан обеспечить передачу прав от субподрядчиков и фрилансеров
- Порядок передачи исходного кода и документации зафиксирован (формат, сроки, состав)
- Разработчик гарантирует отсутствие GPL/AGPL-компонентов или их совместимость с коммерческим использованием
- Налоговый статус разработчика подтверждён, обязанность агента определена
- Вознаграждение за разработку и за передачу прав разграничены отдельными строками
- Разработчик дал согласие на модификацию ПО без указания его имени
- Установлен режим конфиденциальности с конкретным сроком (3–5 лет)
- Гарантийный срок и порядок устранения дефектов описаны в договоре
- Применимое право и юрисдикция зафиксированы (рекомендуется МТС при ТПП КР для споров свыше $50 000)
- Для критичного ПО — предусмотрен эскроу исходного кода
Материал носит информационный характер и не является юридической консультацией. Для решения конкретного вопроса обратитесь в юридическую фирму БЕКЕМ.
Актуально на: 26 мая 2026 г.
Услуги БЕКЕМ по теме
Частые вопросы
1. Нужно ли регистрировать договор о передаче прав на ПО в Кыргызстане?
Регистрация договора об отчуждении исключительного права на программу обязательна через Кыргызпатент, если программа была ранее зарегистрирована. Для незарегистрированного ПО регистрация договора не требуется, но письменная форма обязательна по Закону об авторском праве и смежных правах. На практике большинство договоров на заказную разработку в КР заключаются без регистрации — при условии правильно составленного текста это допустимо и юридически полноценно.
2. Что произойдёт, если договор не содержит явного условия о передаче прав?
По умолчанию исключительное право остаётся у автора-разработчика. Заказчик получает лишь право использования в рамках, определённых договором. Суды КР, как правило, толкуют неоднозначные условия в пользу автора. Чтобы права перешли в полном объёме, в договоре необходима явная формулировка об отчуждении всего исключительного права — без купюр и без ссылки на «передачу прав по умолчанию».
3. Распространяются ли льготы ПВТ на договоры с разработчиком?
Резидент ПВТ платит подоходный налог 5% вместо 10% и не платит налог на прибыль и НДС. Если разработчик является резидентом ПВТ, это влияет на налоговые обязательства сторон и порядок выставления счётов. Заказчику нужно запросить подтверждение статуса резидента ПВТ и учесть это при согласовании условий оплаты, чтобы правильно выполнить обязанности налогового агента или освободиться от них.
Право-300 · Best Lawyers · 1 000+ дел с 2009 года
Вы заключаете договор с разработчиком из КР или проводите аудит существующих соглашений — каждый IT-проект требует уникальной комбинации правовой структуры и налогового режима. Разберём вашу на встрече.
Обсудить IT-проект