Ваш бизнес может получить иск за чужой код, даже если его писал подрядчик

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

Подрядчик сдаёт проект, подписываются акты, продукт запускается, команда начинает работать, и кажется, что юридически всё закрыто.

Через несколько месяцев приходит претензия.

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

Формально код писал подрядчик.

Но претензия приходит не ему.

Претензия приходит компании, которая использует программное обеспечение.

Именно так сегодня начинается значительная часть ИТ-споров — не с технической ошибки, а с отсутствия в договоре нескольких критически важных механизмов защиты.

На практике один пропущенный раздел договора может стоить бизнесу:

За последние годы судебная практика по спорам о программном обеспечении заметно изменилась. Суды всё чаще анализируют происхождение исходного кода, структуру передачи прав, лицензионную чистоту компонентов и конкретные формулировки договора.

Поэтому в 2026 году договор на разработку ПО — это уже не формальность, а инструмент управления юридическим риском.

Сегодня почти любая компания зависит от программного обеспечения:

При этом код всё чаще создаётся не с нуля, а собирается из разных элементов:

Юридически это создаёт главный риск: через год уже сложно доказать, кто именно создал конкретный участок системы.

Если возникает спор, отвечать приходится владельцу бизнеса.

Большинство договоров по-прежнему содержат формулировку:

«Исполнитель гарантирует законность результата работ».

На практике этого недостаточно.

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

Здесь ключевую роль играют Заверения об обстоятельствах.

Этот механизм позволяет заранее зафиксировать:

Разработчик может прямо заверить, что:

Если такое заверение окажется недостоверным, заказчик получает право требовать:

Ключевой нюанс: ответственность возникает независимо от наличия вины.

Обзор судебной практики Верховного Суда РФ № 2 (2021) подтвердил, что заверение может быть дано не только в основном договоре, но и в приложении или отдельном документе, исходящем от стороны-гаранта.

Слабая конструкция:

«ПО не нарушает права третьих лиц».

Сильная конструкция:

«Исполнитель заверяет, что исходный код создан самостоятельно, не содержит компонентов с лицензиями, ограничивающими коммерческое использование, и не нарушает исключительные права третьих лиц».

Именно детализация потом определяет юридическую позицию сторон.

На практике большинство рисков реализуется уже после передачи проекта.

Продукт работает, встроен в процессы бизнеса, используются данные клиентов, идут продажи.

Именно в этот момент появляется претензия от третьего лица.

Для таких случаев используется Возмещение потерь.

Этот механизм позволяет заранее определить: если возникает спор по правам на программное обеспечение, исполнитель компенсирует заказчику:

Рабочая юридическая конструкция всегда состоит из двух частей:

Если одна из частей отсутствует, защита резко слабеет.

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

Типичная логика:

«Из-за ошибки системы компания потеряла клиентов и выручку».

Юридически это уже Упущенная выгода.

Именно этот блок становится самым дорогим в ИТ-спорах.

Поэтому в договоре важно заранее фиксировать:

Например: ответственность исполнителя ограничивается стоимостью договора.

Когда ограничение не действует:

Для B2B это один из базовых защитных механизмов.

Перед обращением в суд обязателен претензионный порядок.

Арбитражные суды Российской Федерации регулярно оставляют иски без рассмотрения из-за нарушений процедуры.

По умолчанию срок ответа составляет 30 дней (ч. 5 ст. 4 АПК РФ).

Но в ИТ-контракте лучше заранее установить:

Это особенно важно в быстроразвивающемся конфликте.

Компенсация за нарушение исключительных прав позволяет правообладателю взыскать:

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

Один спорный модуль внутри большой системы может стать самостоятельным предметом взыскания.

Нарушение авторских и смежных прав применяется, если стоимость нарушения превышает:

Возможные последствия:

Для бизнеса это уже риск остановки процессов.

За последние два года сильные компании заметно изменили подход к ИТ-договорам.

Если раньше юрист подключался уже после запуска продукта, то сейчас договор обсуждают ещё до первой строки кода.

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

Компании заранее спрашивают:

Сильный бизнес отдельно фиксирует:

Если продукт участвует в инвестициях, продаже бизнеса или due diligence, код становится частью стоимости компании.

Поэтому отдельно фиксируются:

Сразу определяют:

Суд почти всегда обходится дороже, чем правильная юридическая конструкция на старте.

Потому что спор — это не только юристы.

Это время команды, переговоры, потеря управляемости и репутационные последствия.

Если договор на разработку ПО выглядит слишком простым, скорее всего, основные риски в нём вообще не распределены.

А значит, в момент первой претензии каждая сторона будет читать его уже в свою пользу.

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

Антон Пуляев, адвокат

Управляющий партнёр ADVOLAW