Вы подписали NDA перед тем, как показать студии идею. Чувствуете себя защищённым? Хорошая новость: вы сделали правильный шаг. Плохая: NDA и права на код в разработке MVP — это два разных инструмента, и один без другого защищает вас лишь частично. Разберём, что реально работает.
Миф: NDA защищает идею
Самое распространённое заблуждение среди основателей — что NDA (соглашение о неразглашении) защищает саму идею продукта. Это не так.
Идея как таковая не охраняется законом ни в России, ни в большинстве других юрисдикций. Нельзя запатентовать «маркетплейс для репетиторов» или «приложение для учёта личных финансов». NDA защищает только конфиденциальную информацию, которую вы раскрыли студии: бизнес-план, описание алгоритмов, данные клиентов, финансовые показатели.
Если студия возьмёт вашу идею и реализует её самостоятельно, не используя ни строчки вашей документации — доказать нарушение NDA будет крайне сложно. Идеи похожи, рынки одинаковые, а код написан с нуля.
Вывод: NDA нужен, но он — только первый слой защиты, а не полная броня.
Что реально защищает ваш продукт
Исходный код
Исходный код — это объект авторского права. Он защищается автоматически с момента создания, регистрировать ничего не нужно. Но здесь есть ловушка: по умолчанию автором считается тот, кто написал код. То есть разработчик или студия, а не вы.
Чтобы права на код перешли к вам, это должно быть явно прописано в договоре. Фраза «студия передаёт права на разработанный продукт» — недостаточно конкретна. Нужно указать: исходный код, документацию, дизайн-макеты, базы данных, скрипты деплоя.
База данных и структура данных
Архитектура базы данных — отдельный объект интеллектуальной собственности. Если студия разработала нетривиальную схему данных для вашего FinTech-продукта, это тоже нужно включить в договор.
Ноу-хау и алгоритмы
Если ваш продукт строится на уникальном алгоритме (скоринговая модель, рекомендательная система), его можно охранять как ноу-хау. Это требует конкретного описания в приложении к договору: что именно является коммерческой тайной и в каком виде оно передаётся.
Лицензия vs отчуждение: принципиальная разница
В договоре с разработчиком вы можете получить права двумя способами:
Лицензия — студия сохраняет авторство, но даёт вам право использовать код. Это как аренда. Если студия прекратит существование или расторгнет договор — вопрос о правах может стать спорным. Для MVP-продукта, который вы планируете масштабировать и продавать, лицензия — плохой вариант.
Отчуждение (передача исключительных прав) — студия полностью передаёт вам права на результаты работы. После подписания акта о передаче вы становитесь единственным правообладателем. Именно это вам нужно для MVP.
Важно: отчуждение должно быть оформлено отдельным документом — «Договором об отчуждении исключительного права» или включено в основной договор подряда с явным указанием на ст. 1234 ГК РФ. Просто слово «передаём» в тексте договора не создаёт отчуждения автоматически.
GPL-ловушка в open-source компонентах
Почти любой современный MVP использует open-source библиотеки. Большинство из них безопасны. Но некоторые лицензии содержат условия, которые могут поставить вас в неудобное положение.
Безопасные лицензии для коммерческого продукта: MIT, Apache 2.0, BSD. Вы можете использовать такой код в закрытом коммерческом продукте без каких-либо ограничений.
Опасная лицензия — GPL (GNU General Public License): если ваш продукт использует GPL-компонент, вы обязаны опубликовать весь исходный код вашего продукта под GPL. Для стартапа, строящего конкурентное преимущество на закрытом коде, это катастрофа.
Попросите студию предоставить список всех open-source компонентов с указанием лицензий. Если в списке есть GPL — спросите, можно ли заменить этот компонент на MIT/Apache-аналог.
Агрессивная разновидность — AGPL (Affero GPL): она распространяется даже на продукты, доступные через сеть (SaaS). Если студия использует AGPL-компонент в вашем веб-приложении — риск публикации кода ещё выше.
Чек-лист из 5 пунктов перед подписанием договора
- Договор предусматривает отчуждение, а не лицензию. Найдите в тексте слова «отчуждение исключительного права» или ссылку на ст. 1234 ГК РФ. Если этого нет — попросите добавить или объяснить, почему используется лицензия.
- Перечислены все объекты передачи прав. Исходный код, документация, дизайн-макеты (файлы Figma или аналога), базы данных, скрипты деплоя и CI/CD-конфигурации. Расплывчатое «результаты работы» — недостаточно.
- Прописан момент передачи прав. Права переходят к вам в момент подписания акта сдачи-приёмки или после оплаты последнего платежа — это должно быть явно указано. Не «после завершения проекта», а конкретное условие.
- Студия гарантирует отсутствие GPL-компонентов или предоставляет их список. Добавьте пункт: «Исполнитель гарантирует, что в результатах работ отсутствуют компоненты под лицензией GPL/AGPL без предварительного письменного согласования с Заказчиком».
- NDA подписан до передачи любой конфиденциальной информации. Не после брифинга, а до него. Убедитесь, что NDA охватывает всех сотрудников студии, которые будут работать с вашими данными, а не только директора.
Что включить в ТЗ для дополнительной защиты
Техническое задание — это не только список функций. Правильно составленное ТЗ усиливает правовую защиту:
- Явное указание, что все разработанные алгоритмы являются коммерческой тайной заказчика
- Требование хранить код в репозитории, к которому у заказчика есть доступ с первого дня (не только после сдачи)
- Запрет на использование студией кода в других проектах, кейсах и демонстрациях без письменного согласия
- Обязательство передать все credentials (доступы к серверам, API-ключи, домены) в момент подписания акта
Последний пункт особенно важен: студии иногда «забывают» передать доступы к облачным сервисам или регистрируют домен на себя. Пропишите это явно.
Практический совет: доступ к репозиторию с первого дня
Не ждите сдачи проекта, чтобы получить доступ к коду. Настаивайте на том, чтобы репозиторий был создан на вашем GitHub/GitLab-аккаунте с первого дня разработки. Студия работает в нём как подрядчик, вы — владелец репозитория.
Это решает сразу несколько проблем: вы видите прогресс в реальном времени, у вас всегда есть актуальная версия кода, и нет риска «потерять» репозиторий при конфликте с разработчиком.
FAQ о nda и права на код в разработке mvp
Нужно ли регистрировать программу для ЭВМ в Роспатенте?
Не обязательно, но полезно. Авторское право на код возникает автоматически с момента создания. Регистрация в Роспатенте создаёт публичную запись с датой, что упрощает доказательство приоритета в спорных ситуациях. Стоимость — около 4 500 рублей за одну программу. Для MVP с уникальными алгоритмами или если вы планируете привлекать инвестиции — регистрация рекомендуется.
Что делать, если студия отказывается подписывать договор об отчуждении прав?
Это серьёзный красный флаг. Легитимные причины использовать лицензию вместо отчуждения существуют, но их мало — например, если студия использует собственную платформу или фреймворк, который применяется в нескольких проектах. В этом случае попросите детально объяснить, что именно остаётся за студией и почему. Если внятного ответа нет — рассмотрите другого подрядчика.
Распространяется ли NDA на субподрядчиков студии?
По умолчанию — нет. Стандартный NDA обязывает только подписавшую сторону. Если студия привлекает фрилансеров или другие компании, добавьте в NDA пункт: «Исполнитель обязуется заключить аналогичные соглашения о конфиденциальности со всеми привлекаемыми третьими сторонами и несёт ответственность за их соблюдение». Это стандартная практика — нормальная студия не будет возражать.
Как проверить, какие лицензии используют open-source компоненты в проекте?
Попросите разработчиков запустить автоматический аудит лицензий — для этого есть инструменты: license-checker (Node.js), pip-licenses (Python), go-licenses (Go). Они генерируют список всех зависимостей с указанием лицензий. Вам не нужно понимать вывод самостоятельно — просто попросите предоставить этот список и убедитесь, что в нём нет GPL/AGPL без явного обоснования.