Один разработчик может остановить инвестиционный раунд. Как стартапу в Казахстане собрать права на ПО

Кому принадлежит код стартапа — один из первых вопросов, который задают инвесторы во время due diligence. Ошибки в оформлении прав на программное обеспечение могут стоить компании инвестиций. Управляющий партнер SOLIS Partners, LL.M. Чингис Оралбаев рассказал, как правильно выстроить цепочку передачи прав и подготовить стартап к привлечению капитала.

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

Чингис Оралбаев, LL.M. | управляющий партнер ТОО SOLIS Partners

Инвестор проверяет не только выручку, команду и корпоративную структуру. Если основная стоимость бизнеса заключена в программном продукте, один из первых вопросов due diligence звучит просто: «Какая именно компания владеет кодом и чем она это докажет?». 

Ответ: «Мы оплатили разработку», — не всегда работает. Как и ответы: «Автор состоит в штате», «Репозиторий оформлен на компанию» или «У нас есть свидетельство». Каждый из этих фактов важен, но ни один не заменяет непрерывную цепочку прав.

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

Цепочка начинается до появления компании

Юридическое лицо не может автоматически получить права на программу, созданную раньше него. Если MVP написал будущий фаундер, CTO или приглашенный разработчик до государственной регистрации стартапа, первоначальные права возникают у физических авторов.

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

На раннем этапе полезно составить IP inventory: кто, когда и в каком статусе создавал каждый значимый компонент. Этот простой реестр часто обнаруживает разрывы до того, как у их устранения появится отдельная переговорная цена.

Для работника действует режим служебного произведения — но не автоматически

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

Отсюда следуют два важных вывода: 

1. Отдельный договор отчуждения для каждого commit штатного разработчика обычно не требуется, если конкретный результат является служебным и договор не меняет законный режим
2. Одного статуса работника недостаточно. Компания должна доказать связь спорной разработки с его трудовой функцией либо поручением работодателя. Ноутбук, зарплата, рабочее время и корпоративный сервер подтверждают контекст, однако без описанной функции или задания могут не решить вопрос.

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

— трудовой договор определяет общий режим прав и обязанности работника
— должностная инструкция описывает виды создаваемых результатов
— IP-положение устанавливает корпоративный процесс разработки
— служебное или продуктовое задание фиксируется в принятом цифровом канале
— репозиторий и tracker связывают задачу с конкретным вкладом
— приемка и release подтверждают включение результата в продукт компании.

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

Подрядчик не становится работником только потому, что сидит в одном Slack

У фрилансера и студии другая исходная точка. Оплата разработки дает заказчику результат в фактическом смысле, но не обязательно весь объем исключительных прав. NDA защищает конфиденциальность. Акт подтверждает выполнение и приемку. Ни тот, ни другой документ сами по себе не заменяют письменное распоряжение авторскими правами.

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

Если разработку выполняет юридическое лицо, возникает дополнительный вопрос: получило ли оно права от своих работников, авторов и субподрядчиков? Надежная цепочка выглядит так: физический автор — подрядчик — заказчик. Гарантия студии «мы вправе передать код» полезна, но в существенной сделке инвестор может запросить подтверждающие договоры и перечень участников.

Договор также должен регулировать привлечение субподрядчиков, исходные материалы, сторонние библиотеки, open-source лицензии, AI-инструменты, документацию, гарантии оригинальности и порядок урегулирования требований третьих лиц.

Свидетельство фиксирует сведения, а не заменяет Due Diligence

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

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

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

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

Переписанный продукт может оставаться производным

Стартапы часто меняют stack и архитектуру. Однако переход на другой язык программирования не доказывает, что новая версия юридически независима. Если сохранены охраняемые элементы исходной разработки, новая версия может быть результатом переработки.

Автор производного произведения владеет своим вкладом при условии соблюдения прав на оригинал. Поэтому version history должна отвечать не только на инженерные вопросы, но и на правовые: на основе чего создавался релиз, какие элементы использованы, кто их предоставил и какие права действовали на момент переработки.

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

Коммерческая тайна не появляется от надписи confidential

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

Инженерная практика должна соответствовать документам. Личный cloud, общий пароль на команду, неограниченный экспорт репозитория и сохранение доступа после увольнения ослабляют позицию владельца коммерческой тайны независимо от качества NDA.

Что увидит инвестор в data room

Вместо одного «договора с разработчиком» инвестор обычно ищет согласованную систему доказательств:

1. Реестр продуктов, версий, авторов и правообладателей.
2. Трудовые документы и IP-положение.
3. Договоры с фрилансерами, студиями и субподрядчиками.
4. Задания, tracker и история репозиториев.
5. Акты приемки и релизы.
6. Реестр сторонних компонентов и лицензий.
7. Документы о передаче раннего MVP компании.
8. Свидетельства реестра и материалы, на основании которых они получены.
9. Правила коммерческой тайны и доступов.
10. Подтверждение offboarding и передачи контроля над инфраструктурой.

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

Юридически готовый стартап — это не компания с самым объемным архивом договоров. Это бизнес, который способен без догадок показать происхождение каждой существенной версии продукта и основание, по которому именно эта компания вправе ее использовать, изменять и передавать инвестору.