Гайд: Защита исходного кода в КР: депонирование и NDA

Шаг 1. Как работает защита исходного кода в Кыргызстане?

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

Практическая проблема не в том, есть ли право, а в том, как его доказать. Если бывший сотрудник или подрядчик заявит, что именно он создал спорный модуль раньше вашей компании — суд будет оценивать доказательства. Свидетельство Кыргызпатента о депонировании фиксирует дату и состав версии. Git-история, внутренние задачи, переписка — тоже доказательства, но менее формализованные.

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

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

Шаг 2. Что нужно подготовить перед депонированием?

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

Версия кода. Определите, какую именно версию вы депонируете. Оптимально — релизная сборка или срез на дату завершения ключевого этапа разработки. Кыргызпатент принимает код на USB-носителе или CD/DVD; объём не ограничен, но документ должен содержать как минимум ключевые модули. Если продукт состоит из нескольких компонентов с разными авторами — решите заранее, подаёте ли одну заявку на весь продукт или отдельно на каждый компонент.

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

Техническое описание. Документ объёмом 1–3 страницы: назначение программы, основные функции, среда выполнения, язык программирования. Описание не должно раскрывать алгоритмы в деталях — это публичный документ, который будет внесён в реестр.

Документы компании. Для подачи от имени ОсОО или резидента ПВТ потребуется свидетельство о регистрации юридического лица и доверенность на представителя, если подаёт не директор лично. Нотариальное заверение доверенности для внутренних заявок не требуется.

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

Шаг 3. Как подать заявку в Кыргызпатент?

Подача заявки на депонирование программы для ЭВМ проходит через Кыргызпатент — государственный орган, ведущий реестры объектов интеллектуальной собственности. Основание — Закон «Об авторском праве и смежных правах» и подзаконные акты Кыргызпатента.

Комплект документов для подачи:

• Заявление на регистрацию программы для ЭВМ (форма Кыргызпатента)
• Носитель с исходным кодом (USB или CD/DVD)
• Техническое описание программы (1–3 страницы)
• Реферат — краткое описание до 700 знаков для публикации в официальном бюллетене
• Документ об уплате госпошлины
• Для юридического лица: свидетельство о регистрации и доверенность (если подаёт представитель)

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

После подачи заявке присваивается входящий номер с датой. Эта дата и будет считаться датой депонирования — она имеет юридическое значение при последующих спорах о приоритете.

Размер госпошлины за депонирование программы для ЭВМ следует уточнять в актуальном прейскуранте Кыргызпатента — ставки периодически индексируются. Ориентировочно это несколько тысяч сомов. Дополнительно оплачивается публикация сведений в официальном бюллетене.

Шаг 4. Что происходит после подачи заявки?

Кыргызпатент проводит формальную экспертизу: проверяет комплектность документов и правильность оформления. Содержательная экспертиза кода не проводится — ведомство фиксирует факт депонирования, а не оценивает оригинальность или патентоспособность программы.

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

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

Срок действия авторского права на программу — в течение жизни автора и 50 лет после его смерти. Свидетельство о депонировании не имеет срока действия, но фиксирует конкретную версию. При существенном обновлении продукта — более 30–40% нового кода — рекомендуется повторное депонирование новой версии. Это создаёт историю версий и защищает обновлённый функционал.

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

Шаг 5. Как составить эффективный NDA для IT-команды?

NDA (соглашение о неразглашении) — инструмент защиты коммерческой тайны, а не авторского права. Различие принципиально: авторское право охраняет конкретный текст кода, NDA ограничивает использование конфиденциальной информации — алгоритмов, архитектурных решений, бизнес-логики, клиентских данных.

Структура рабочего NDA:

• Определение конфиденциальной информации — конкретный перечень: исходный код, техническая документация, алгоритмы, базы данных, переговоры с клиентами. Расплывчатое «любая информация компании» суды трактуют расширительно, но защищает слабее конкретного перечня.
• Обязательства получателя — не раскрывать, не использовать в личных целях, хранить на защищённых носителях, немедленно уведомлять об утечке.
• Исключения — информация, ставшая публичной не по вине получателя; информация, известная до подписания; раскрытие по требованию суда или государственных органов.
• Срок — для сотрудников рекомендуется бессрочно или до 5 лет после увольнения; для подрядчиков — 3–5 лет после завершения проекта.
• Санкции — фиксированная неустойка или формула расчёта убытков. Без этого пункта взыскать что-либо реально только при доказанном крупном ущербе.

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

Travel Rule обязателен для всех VASP в Кыргызстане — без него лицензия под угрозой. Аналогичная логика применима к NDA: неподписанный NDA с подрядчиком-разработчиком — это открытая уязвимость, которая обнаруживается только в момент инцидента.

Шаг 6. Как закрепить права компании на код, написанный подрядчиком?

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

Для подрядчиков (не сотрудников) работает договор авторского заказа или договор на отчуждение исключительного права. В первом случае подрядчик создаёт произведение по заданию заказчика, и права переходят при условии явного указания в договоре. Фраза «результат работ передаётся заказчику» не является таким условием — нужна формулировка «исключительное право на программу для ЭВМ в полном объёме переходит к заказчику с момента приёмки».

Для штатных разработчиков авторское право на служебное произведение принадлежит работодателю по умолчанию — если иное не установлено договором. Но «по умолчанию» работает только при наличии документально подтверждённого служебного задания. Если разработчик написал код без задания или в нерабочее время — вопрос спорный. Закрепите в трудовом договоре, что весь код, написанный с использованием ресурсов компании или в рамках её деятельности, является служебным произведением.

Отдельная ситуация — open-source-компоненты. Включение библиотек с лицензиями GPL, AGPL или другими копилефт-лицензиями в коммерческий продукт создаёт риск «заражения» всего продукта условиями свободной лицензии. Перед депонированием и особенно перед продажей или инвестированием проведите аудит зависимостей. Это не юридическая абстракция: несколько крупных сделок по продаже IT-компаний срывались именно из-за некорректного использования open-source-компонентов.

Обзор структуры договоров с зарубежными заказчиками, включая передачу прав на код, разобран в материале «Лицензирование из Кыргызстана: структура договора».

Шаг 7. Что делать при нарушении прав на исходный код?

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

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

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

Судебная защита. Иски о защите авторских прав рассматриваются межрайонными судами по экономическим делам (МСЭД) — если обе стороны являются субъектами предпринимательской деятельности. Требования могут включать запрет на использование, изъятие контрафактных копий, возмещение убытков или выплату компенсации. Компенсация по Закону об авторском праве может определяться по усмотрению суда в пределах, установленных законодательством, — это альтернатива доказыванию точного размера убытков.

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

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

Шаг 8. Как поддерживать защиту при росте команды и продукта?

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

Повторное депонирование. При выходе мажорных версий (1.0, 2.0) или существенном обновлении архитектуры проводите депонирование новой версии в Кыргызпатент. Это не обязанность, а управление доказательной базой. Портфель свидетельств показывает историю разработки и затрудняет оспаривание приоритета.

Актуализация NDA. При каждом изменении в команде — приём нового разработчика, смена подрядчика, привлечение стажёра — подписывайте NDA. Сформируйте стандартный пакет документов при найме: трудовой договор с условием о служебных произведениях + NDA + политика информационной безопасности. Это 30–40 минут юридической работы при найме, которые могут сэкономить месяцы судебных разбирательств.

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

Аудит прав. Перед привлечением инвестиций, продажей компании или выходом на зарубежный рынок проводите аудит прав на интеллектуальную собственность. Проверяются: наличие договоров с авторами, корректность условий передачи прав, открытые лицензии в зависимостях, актуальность NDA. Результат аудита — IP-меморандум, который прилагается к материалам для инвестора.

Подробнее о структурировании сделок с участием ОсОО и вопросах корпоративного контроля — в материале «Крупная сделка ОсОО в КР: одобрение и последствия нарушения».

Чек-лист: полная защита исходного кода в КР

Используйте этот перечень для самодиагностики. Каждый пункт — конкретное действие, а не рекомендация.

• ☐ Определена версия кода для депонирования; ключевые модули выделены
• ☐ Составлен список авторов с разграничением на физических лиц и правообладателя-компанию
• ☐ Подготовлено техническое описание (1–3 стр.) и реферат (до 700 зн.)
• ☐ Уплачена госпошлина; заявка подана в Кыргызпатент
• ☐ Получено свидетельство о депонировании; хранится в оригинале
• ☐ В трудовых договорах всех разработчиков есть условие о служебных произведениях
• ☐ NDA подписан с каждым сотрудником, имеющим доступ к коду
• ☐ NDA подписан с каждым внешним подрядчиком (фрилансером, аутстафф-командой)
• ☐ В договорах с подрядчиками явно указан переход исключительного права к компании
• ☐ Проведён аудит open-source-зависимостей на предмет копилефт-лицензий
• ☐ Настроено разграничение доступа к репозиториям; ведутся логи
• ☐ Установлена процедура отзыва доступа при увольнении сотрудника
• ☐ Запланировано повторное депонирование при выходе следующей мажорной версии

Если три и более пункта не выполнены — защита интеллектуальной собственности компании имеет системные уязвимости. Это не критично в момент запуска продукта, но становится критичным при первом конфликте с командой или при попытке привлечь инвестиции.