Как проверить передачу прав на исходный код и дизайн в договоре на разработку ПО: 5 обязательных пунктов
При заключении договора на разработку программного обеспечения большинство заказчиков сосредотачиваются на сроках, бюджете и функциональных требованиях, упуская критически важный аспект — юридическое оформление передачи
Как проверить передачу прав на исходный код и дизайн в договоре на разработку ПО: 5 обязательных пунктов
Почему формальная передача прав не гарантирует владение кодом
Типичное заблуждение: если в договоре написано «исключительные права на результаты работ переходят заказчику», задача решена. На практике такая формулировка без детализации создаёт лазейки, которыми пользуются недобросовестные подрядчики или которые обнаруживаются при юридической проверке в самый неподходящий момент.
Первая проблема — отсутствие определения «результатов работ». Под это понятие может подпадать только финальная версия продукта, без исходного кода, без документации, без отдельных модулей, разработанных ранее для других клиентов. Если договор содержит только ссылку на «результат» без расшифровки состава, заказчик получает работающий продукт, но не может им полноценно распоряжаться: дорабатывать силами другой команды, продавать, модифицировать или использовать компоненты в других проектах.
Вторая проблема — права на third-party компоненты. Современная разработка редко ведётся с нуля: используются библиотеки с открытым кодом, фреймворки, плагины. Каждый из этих компонентов имеет собственную лицензию. GPL-лицензия требует открытия исходного кода производных работ. MIT и BSD позволяют закрывать код, но могут накладывать требования об указании авторства. Если в договоре не зафиксировано, кто отвечает за соблюдение лицензионной чистоты и какие именно компоненты входят в передаваемые права, заказчик может получить продукт с обременениями, о которых узнает только при проверке.
Подробнее на эту тему — Сравнить SDK для внутриигровых покупок: Unity IAP, Google P….
Третья проблема — отсутствие разграничения прав на разные элементы продукта. Исходный код, дизайн-макеты, пользовательский интерфейс, база данных, серверная логика, документация — каждый из этих элементов может иметь разный правовой статус. Особенно часто путаница возникает с дизайном: права на графические макеты входят в одну категорию, а на программный код интерфейса — в другую. Без детального разграничения заказчик формально владеет кодом, но не может использовать или продавать дизайн отдельно.
Четвёртая проблема — момент перехода прав. Если в договоре указано, что права переходят «после полной оплаты», а проект был оплачен частично или претерпел существенные изменения в ходе работы, момент перехода прав размывается. При возникновении спора стороны могут по-разному трактовать, какая именно версия продукта и в каком объёме перешла в собственность.
Пятая проблема — отсутствие процедуры верификации. Даже если права формально переданы, у заказчика нет механизма убедиться, что переданный код не содержит заимствований из других проектов, не нарушает чужих патентов и полностью оригинален. Это становится критичным при продаже бизнеса, привлечении инвестиций или реструктуризации, когда юридическая проверка становится обязательным этапом.
Подробнее на эту тему — Развитие цифровых компетенций и внедрение инновационных мет….
Таблица проверки: что искать в разделах о правах и лицензиях
При анализе договора используйте следующую таблицу для систематической проверки каждого раздела. Каждый пункт должен быть однозначно определён и не допускать двойного толкования.
| Проверяемый элемент | Что должно быть зафиксировано | Красные флаги (искать и исправлять) |
|---|---|---|
| Объекты передачи | Конкретный перечень с указанием форматов и версий | Расплывчатые формулировки: «результаты работ», «созданные материалы» |
| Вид передаваемых прав | Исключительные права, а не лицензия | Слово «лицензия» без уточнения об исключительности |
| Момент перехода прав | Дата или событие, не привязанное к доп. условиям | «После полной оплаты», «после завершения всех работ» при длительном проекте |
| Third-party компоненты | Перечень используемых библиотек с лицензиями; гарантия отсутствия нарушений | Отсутствие раздела о лицензионной чистоте; упоминание только «стандартных инструментов» |
| Ограничения на использование | Полное отсутствие ограничений | Пункты о согласии подрядчика на модификацию, ограничение круга пользователей |
| Право на передачу третьим лицам | Прямое указание возможности продажи, сублицензирования | Запрет или необходимость получения согласия автора |
| Авторство | Право не указывать авторство подрядчика | Требование сохранять копирайты подрядчика в коде |
| Ответственность | Компенсация убытков при нарушении прав третьих лиц | Отсутствие ответственности подрядчика или ограничение символической суммой |
Дополнительно проверьте: раздел об увольнении или смене подрядчика — должны ли передаваться пароли, доступы к репозиториям, исходные материалы; порядок действий при досрочном расторжении — кому переходят права и в каком объёме; раздел о форс-мажоре — не влияет ли он на уже переданные права.
Типичные ловушки в договорах с аутсорс-командами
Аутсорс-разработка имеет специфические риски, связанные с одновременной работой над несколькими проектами и использованием типовых шаблонов. Ниже описаны ловушки, которые регулярно встречаются в договорах с внешними командами.
Ловушка первая: сохранение прав на наработки и заготовки
Многие аутсорс-компании включают в договор пункт о том, что общие методологии, алгоритмы, архитектурные решения и типовые компоненты остаются их интеллектуальной собственностью. Формально код вашего проекта принадлежит вам, но фундамент, на котором он построен, остаётся за подрядчиком. При попытке передать проект другой команде для поддержки выясняется, что без оригинальной команды невозможно понять архитектуру.
Защита: добавьте в договор пункт о передаче всех прав на архитектурные решения, методологии и компоненты, созданные в рамках данного проекта. Уточните, что передаются даже те элементы, которые были адаптированы из ранее существовавших наработок подрядчика.
Ловушка вторая: право подрядчика на демонстрацию кода
В типовых договорах встречается оговорка о праве подрядчика использовать результаты работ в своём портфолио и демонстрировать код будущим клиентам. С одной стороны, это нормальная практика, с другой — если продукт содержит уникальные бизнес-алгоритмы или ноу-хау, передача этой информации конкурентам нежелательна.
Защита: либо исключите право демонстрации, либо ограничьте его публичными элементами интерфейса без раскрытия внутренней логики и бизнес-процессов.
Ловушка третья: отсутствие передачи исходников при смене подрядчика
При завершении сотрудничества и передаче проекта новой команде выясняется, что репозитории принадлежат подрядчику, доступы закрыты, а документация неполная. Добиться передачи можно только через суд, потратив месяцы и значительные средства.
Защита: с момента начала проекта обеспечьте, чтобы репозитории размещались на инфраструктуре заказчика или принадлежали ему юридически. Договор должен содержать явное обязательство передать все доступы в течение 3 рабочих дней с момента расторжения.
Ловушка четвёртая: скрытые ограничения в шаблонах
Многие аутсорс-студии используют типовые договоры, изначально разработанные для защиты интересов подрядчика. Встречаются ограничения на: использование кода в продуктах конкурентов подрядчика; модификацию в течение гарантийного срока; передачу кода в залог или обеспечение кредитов. Эти ограничения могут быть сформулированы мелким шрифтом или объектов.
Защита: требуйте от подрядчика юридическую экспертизу договора с акцентом на пункты о правах. Настаивайте на удалении любых ограничений, не связанных напрямую с предметом данного проекта.
Ловушка пятая: отсутствие порога ответственности
В некоторых договорах ответственность подрядчика ограничена суммой оплаты за последний месяц или фиксированной суммой в 50–100 тысяч рублей. При стоимости разработки в несколько миллионов рублей такая формулировка означает, что подрядчик практически ничем не рискует.
Защита: установите ответственность подрядчика в размере полной стоимости работ, умноженной на коэффициент (1,5–2), либо в размере убытков заказчика. Добавьте пункт о возмещении косвенных убытков: потерянная выгода, репутационные издержки, затраты на переделку.
Когда стандартных формулировок недостаточно: сложные сценарии разработки
Стандартный договор с пятью пунктами чек-листа работает для типовых проектов: разработка мобильного приложения с нуля, создание веб-сайта, программирование внутренней системы автоматизации. Однако существуют сценарии, в которых требуется дополнительная проработка правового регулирования.
Сценарий первый: использование open-source компонентов
Если продукт основан на open-source фреймворке с копилефтной лицензией (AGPL, LGPL с ограничениями), передача исключительных прав на весь продукт может вступать в противоречие с условиями этой лицензии. Копилефтные лицензии требуют, чтобы производные работы также распространялись на условиях исходной лицензии — то есть код должен быть открыт.
Решение: проведите аудит всех open-source компонентов до подписания договора. Определите лицензии каждого компонента. Выберите компоненты с permissive-лицензиями (MIT, Apache 2.0, BSD) для критических частей продукта. Если копилефтные компоненты необходимы, зафиксируйте в договоре, что именно эти компоненты не входят в передаваемые исключительные права, и заказчик получает на них только лицензию на использование.
Сценарий второй: комбинированный продукт с элементами дизайна и кода разных авторов
В проекте могут участвовать несколько подрядчиков: одна команда разрабатывает код, другая создаёт дизайн, третья пишет контент. Если договоры с ними не синхронизированы, возникает ситуация, когда права на код принадлежат заказчику, а на дизайн — остаются у дизайнерского агентства.
Решение: привлеките всех участников через один договор или через систему дополнительных соглашений, где каждый участник передаёт права заказчику. Включите условие, что все участники проекта обязаны подписать акт передачи прав в пользу заказчика до завершения проекта. Фиксируйте в договоре с основным подрядчиком ответственность за координацию передачи прав от субподрядчиков.
Сценарий третий: MVP и масштабирование
При разработке MVP (минимально жизнеспособного продукта) часто используются упрощённые формулировки в договоре. После успешного запуска продукт масштабируется, привлекает инвестиции, и выясняется, что исходный код MVP содержит ограничения: не все права переданы, компоненты имеют обременения.
Решение: с самого начала заключайте договор с полным объёмом прав, даже если MVP планируется базовым. Дополнительные расходы на юридически чистый договор составляют 5–15% от стоимости разработки, что несопоставимо с затратами на урегулирование правовых проблем позже.
Сценарий четвёртый: передача проекта между юридическими лицами
При реструктуризации бизнеса или продаже компании продукт переходит к новому владельцу. Если права на продукт оформлены на одну компанию, а активы продаются через другую, возникает необходимость дополнительных согласований.
Решение: при первоначальном заключении договора добавьте пункт о праве заказчика передавать права на продукт любому связанному лицу (дочерней компании, правопреемнику) без согласия подрядчика. Это упрощает последующие корпоративные операции.
Сценарий пятый: заказчик и подрядчик меняют юридический статус
Компания заказчика проходит реорганизацию, слияние или ликвидацию. Подрядчик прекращает деятельность или меняет форму собственности. В этих случаях права на интеллектуальную собственность должны сохраняться независимо от изменений в юридическом статусе сторон.
Решение: включите в договор пункт о сохранении прав независимо от реорганизации, смены собственности или ликвидации любой из сторон. Права должны автоматически переходить к правопреемнику.