Договор разработки ПО в 2026 году: 12 ошибок,
из-за которых заказчики выигрывают суды

Время чтения: ~13 минут
Автор: Пушков Дмитрий Андреевич, юрист бюро юридической помощи «Леганта Групп»

IT-разработка — одна из самых сложных категорий договоров. На стыке гражданского права, авторского права, договоров подряда и услуг возникает множество неоднозначностей. Когда они трактуются в суде — почти всегда против исполнителя.

По статистике судебной практики 2024–2025 годов, в спорах по договорам разработки ПО заказчики выигрывают в 65–70% случаев. И почти всегда — из-за дефектов договора, которые исполнитель сам подписал.

Что изменилось в 2025–2026:

1. С 4 января 2026 года действует новая редакция раздела VI ГК РФ (ФЗ № 214-ФЗ от 07.07.2025) и статья 1252.1 — изменены правила взыскания компенсации за нарушение исключительных прав, размеры компенсации, порядок их назначения.

2. Усиление практики Суда по интеллектуальным правам. В 2025 году СИП занял жёсткую позицию по спорам о принадлежности исключительных прав на ПО — без чёткого договорного оформления - права остаются у автора-разработчика.

3. Компенсации за нарушение прав по ст. 1301 ГК РФ — до 5 млн руб. За одно нарушение. На крупных проектах с множественными объектами авторских прав компенсации легко складываются в десятки миллионов.

4. Усиление налоговых рисков по IT-аккредитации. ФСБ в 2026 году выступила за лишение аккредитации IT-компаний за допуск пользователей с VPN — это меняет ландшафт IT-льгот и косвенно влияет на договорные риски.

5. Активная практика по «служебным произведениям». Дело № А40-202764/2018 и подобные показывают: без правильного оформления служебных заданий и актов передачи прав исключительные права на разработанное ПО остаются у разработчиков-сотрудников, а не у их работодателя.

Бесплатный аудит вашего договора разработки ПО. Юристы Леганта Групп проверят 12 ключевых пунктов и оценят риски за 1–2 рабочих дня. → [Записаться на аудит]

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

Юридическая природа разработки ПО

Разработка программного обеспечения — это смешанный договор, сочетающий в себе:

• элементы подряда (создание материального результата);
• элементы возмездного оказания услуг (творческая деятельность, не сводимая к материальному результату);
• элементы договора авторского заказа (создание произведения с переходом исключительных прав);
• элементы лицензионного договора (если права передаются как лицензия).

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

Что не вписывается в типовой шаблон подряда

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

К чему это приводит на практике

Разработчик пишет код, передает продукт заказчику, получает оплату. Через год заказчик подает в суд:

• о ненадлежащем исполнении;
• о возврате оплаты как неосновательного обогащения;
• о взыскании убытков из-за «дефектов»;
• о применении компенсации за нарушение его исключительных прав (если он считает, что права не были переданы надлежащим образом).

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

Ниже приведены 12 типичных ошибок, которые встречаются в 80% договоров на разработку.

Самая частая ошибка. Из договора нельзя точно понять, что именно обязан создать исполнитель.

Антипример

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

Что это? Веб-приложение? Мобильное? Какая функциональность? Какие платформы? В каком объёме?

Как должно быть

«Исполнитель обязуется выполнить работы по разработке программного обеспечения "CRM-система для управления клиентами Заказчика" в составе:

• бэкенд на Python (Django REST Framework);
• фронтенд на React;
• PostgreSQL базы данных;
• REST API для интеграции с системами Заказчика;
• админ-панель управления;
• 12 функциональных модулей согласно Техническому заданию (Приложение №1).

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

Почему критично

При споре о «недоделанном продукте» суды смотрят на предмет договора. Если он размыт — заказчик может говорить «вы должны были сделать функцию X», а исполнитель — «нет, она не входила в объём». При расплывчатом предмете суд встаёт на сторону заказчика по принципу contra proferentem (толкование в пользу слабой стороны / против стороны, формулировавшей условие).

ТЗ — главный документ всего проекта. Часто исполнители работают «на честном слове» или с минимальным TЗ из 2–3 страниц, а потом удивляются разногласиям.

Что должно быть в ТЗ

1. Функциональные требования. Конкретный перечень функций с описанием поведения системы. Идеально — с примерами use cases.

2. Нефункциональные требования:

• производительность (количество пользователей, время отклика);
• безопасность (стандарты, методы шифрования);
• совместимость (браузеры, OS, устройства);
• масштабируемость;
• доступность (uptime).

3. Дизайн и UX. Макеты, прототипы, гайдлайны бренда.

4. Архитектура. Используемые технологии, стек, библиотеки.

5. Интеграции. С какими внешними системами, API, форматы данных.

6. Требования к безопасности данных. Особенно важно при работе с ПД — отсылка к 152-ФЗ.

7. Требования к документации. Какая документация передаётся (пользовательская, техническая, API).

8. Критерии приёмки. По каждой функции — как именно проверяется её корректная работа.

Что делать, если ТЗ нет в момент подписания договора

Часто заказчик торопит подписание, обещая «согласуем ТЗ потом». Это ловушка.

Правильный подход:

• либо ТЗ подписывается одновременно с договором (как Приложение №1);
• либо в договоре прописывается процедура согласования и фиксации ТЗ до начала работ;
• либо договор разделяется на два этапа: 1) разработка ТЗ (отдельная оплата), 2) разработка ПО по согласованному ТЗ.

В любом случае — без чёткого ТЗ работы не начинаются. «Сделаем как-нибудь» — путь в суд.

Изменения ТЗ в процессе

Любые изменения ТЗ должны оформляться письменно — Дополнительным соглашением или Заказом на изменения (Change Request) с пересмотром сроков и стоимости. Устные договорённости в процессе — неработающий инструмент.

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

Что говорит закон

По ст. 1297 ГК РФ (в редакции с 4 января 2026 года):

Исключительное право на программу для ЭВМ, базу данных или иное произведение, созданные при выполнении договора подряда либо договора на выполнение научно-исследовательских, опытно-конструкторских или технологических работ, которые прямо не предусматривали создание такого произведения, принадлежит подрядчику (исполнителю), если договором между ним и заказчиком не предусмотрено иное.

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

Что это значит для заказчика и исполнителя

Если в договоре ничего конкретно не сказано про переход прав:

• права остаются у исполнителя;
• заказчик может только использовать ПО для собственных целей (по простой неисключительной лицензии);
• заказчик не может перепродать ПО, лицензировать третьим лицам, изменять архитектуру по своему усмотрению с правовой точки зрения;
• исполнитель сохраняет право использовать ПО в других проектах.

Если в договоре написано «исключительное право переходит к заказчику»:

• права переходят полностью;
• но исполнитель имеет право использовать созданное им произведение для собственных нужд по безвозмездной простой неисключительной лицензии (если иное не предусмотрено).

Как правильно прописать

Вариант для заказчика, который хочет получить полные права:

«Исключительное право на программу для ЭВМ, разработанную Исполнителем по настоящему Договору, в полном объёме на весь срок действия исключительного права и на территорию всех стран мира переходит к Заказчику с момента подписания Сторонами Акта приёма-передачи работ и оплаты вознаграждения в полном объёме. Заказчик становится единственным правообладателем результата работ».

Вариант для исполнителя, который хочет сохранить права на компоненты:

«Исключительное право на основной результат разработки переходит к Заказчику. Однако Исполнитель сохраняет исключительное право на:

а) разработанные ранее библиотеки, фреймворки и компоненты, существовавшие до начала работ по настоящему Договору; б) общеприменимые программные модули и решения, не являющиеся уникальными для проекта Заказчика; в) методики, ноу-хау и подходы, использованные при разработке.

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

Это сохраняет за исполнителем возможность переиспользовать наработки в других проектах — нормальная практика IT-индустрии.

Когда возникают споры

Споры возникают, когда заказчик хочет:

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

Если в договоре переход прав не оформлен корректно — исполнитель может потребовать дополнительной оплаты, заблокировать сделку или взыскать компенсацию по ст. 1301 ГК РФ — до 5 млн руб. за одно нарушение.

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

Что говорит закон

По ст. 1295 ГК РФ служебное произведение — это произведение, созданное в пределах установленных для работника трудовых обязанностей. Исключительное право на него принадлежит работодателю, если трудовым или иным договором между ними не предусмотрено иное.

Но это работает только при выполнении двух условий одновременно:

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

Свежая судебная практика

Дело № А40-202764/2018 (мобильное приложение для телемедицины). Суд проверил полную цепочку: трудовой договор — должностная инструкция — служебное задание — акт передачи прав. Без любого из этих документов цепочка обрывается, и права остаются у автора.

Урок практики 2024–2025 годов: недостаточно общей фразы в трудовом договоре «работник передаёт работодателю исключительные права на все созданные произведения». Суды требуют:

• должностную инструкцию с конкретным указанием на разработку ПО;
• служебное задание с описанием конкретного объекта;
• акт передачи с описанием готового произведения;
• выплату авторского вознаграждения (отдельно от оклада).

Что нужно оформить в IT-компании

1. Трудовой договор с разработчиком. Должно быть указано:

«Работник в рамках своих трудовых обязанностей создаёт программы для ЭВМ, базы данных и иные произведения, исключительные права на которые с момента их создания принадлежат Работодателю. За использование Работодателем созданных Работником произведений Работнику выплачивается авторское вознаграждение в размере 1 (одного) рубля в месяц, что включено в его заработную плату согласно настоящему Договору».

Маленький нюанс: отдельная сумма авторского вознаграждения. По свежей практике формулировка «вознаграждение учтено в окладе» — неэффективна. Нужна отдельная строка.

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

3. Служебное задание. На каждый проект — отдельный документ с описанием задачи.

4. Акт передачи произведения. По завершении работы — акт с описанием конкретного объекта (название модуля, репозиторий, ветка, дата).

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

Что произойдёт без правильного оформления

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

Сценарий 2. Заказчик требует «чистоту прав» при сделке M&A. Юридическая проверка обнаруживает, что у компании нет цепочки передачи прав от сотрудников. Сделка срывается или цена снижается на десятки миллионов.

Сценарий 3. Компания продаёт продукт лицензиатам. Бывший сотрудник заявляет претензии — все лицензии оказываются под угрозой.

Бездействие в течение 3 лет

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

Это редко применяется на практике, но создаёт риск для архивных проектов.

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

Что должно быть в разделе «Приёмка»

1. Этапы приёмки. Для крупных проектов — поэтапная приёмка с актами по каждой стадии (например: дизайн, бэкенд, фронтенд, интеграция, тестирование). Для небольших — единая приёмка по результату.

2. Срок уведомления о готовности. Обычно 5–10 дней до даты приёмки.

3. Состав приёмочной комиссии. Кто со стороны заказчика участвует в приёмке.

4. Процедура тестирования. Какие тесты проводятся, по каким критериям, в какие сроки.

5. Срок принятия. Заказчик обязан в течение 10–15 рабочих дней либо подписать акт, либо дать мотивированный отказ.

6. Мотивированный отказ. Что считается мотивированным отказом — конкретные ссылки на пункты ТЗ, описание дефектов с воспроизводимыми шагами, скриншоты.

7. Молчаливое принятие. Условие о том, что отсутствие реакции в установленный срок означает принятие работ без замечаний.

8. Право на односторонний акт. Аналогично ст. 753 ГК РФ — при уклонении заказчика от приёмки исполнитель вправе составить акт в одностороннем порядке.

Антипример формулировки

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

Что значит «успешное тестирование»? Кто его проводит? В какие сроки? Что если заказчик считает — «не успешное», а исполнитель считает — «успешное»?

Хорошая формулировка

1. «Исполнитель уведомляет Заказчика о готовности к приёмке за 5 (пять) рабочих дней до планируемой даты приёмки.
2. Приёмка включает: (а) демонстрацию работы программного обеспечения; (б) проведение тестирования по согласованному в Приложении №2 списку тест-кейсов; (в) проверку документации.
3. Заказчик в течение 10 (десяти) рабочих дней с момента получения акта приёма-передачи и соответствующих результатов работ обязан либо подписать акт, либо направить Исполнителю мотивированный отказ в письменной форме. Мотивированный отказ должен содержать конкретное указание на пункты ТЗ, требованиям которых не соответствует результат, описание дефекта с шагами воспроизведения и скриншотами.
4. По истечении 10 рабочих дней без реакции Заказчика работы считаются принятыми Заказчиком без замечаний.
5. При уклонении Заказчика от приёмки или необоснованном отказе от подписания акта Исполнитель вправе составить акт сдачи-приёмки в одностороннем порядке. Такой акт является основанием для оплаты выполненных работ».

Что считается «дефектом»

Полезно прямо в договоре прописать классификацию:

• Критический дефект (Blocker): ПО не работает или приводит к потере данных. Подлежит обязательному устранению.
• Серьёзный дефект (Major): ПО работает с существенными отклонениями. Подлежит устранению.
• Несущественный дефект (Minor): небольшие отклонения, не препятствующие использованию. Устраняются на гарантийном этапе.
• Косметический (Trivial): опечатки, мелкие визуальные проблемы. Устраняются по возможности.

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

Это про знаменитый scope creep — расползание объёма работ.

Как возникает

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

Что прописать в договоре

1. Чёткое определение «изменение объёма» (Change Request). Любое требование вне ТЗ — это изменение.

2. Процедура подачи и обработки изменений:

• заказчик направляет письменный запрос на изменение;
• исполнитель в течение 5–10 дней оценивает влияние на сроки и стоимость;
• стороны подписывают Дополнительное соглашение с пересмотром сроков, стоимости и/или объёма;
• только после подписания исполнитель начинает работу по изменению.

3. Право исполнителя отказаться от изменения. Если изменение существенно влияет на проект — исполнитель имеет право не принять.

4. Минимальная стоимость изменения. Для предотвращения «бесплатных» мелких изменений — минимальный размер 10 000–30 000 руб. за каждый Change Request.

Антипример

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

Хорошая формулировка

«Любые изменения, дополнения или уточнения к Техническому заданию, согласованному Сторонами при подписании Договора, являются Изменением объёма работ (Change Request) и оформляются в порядке, установленном Приложением №3 к настоящему Договору. Без подписанного Дополнительного соглашения по каждому Change Request Исполнитель не обязан выполнять работы, выходящие за рамки первоначального ТЗ».

Иногда заказчики настаивают на формулировках типа «ПО должно работать без сбоев и ошибок». Это технически невыполнимое условие, согласие на которое — заявка на проигрыш в любом споре.

Реальность IT-разработки

Любое сложное ПО содержит баги. Это объективная реальность, признанная индустрией. Стандарт качества — не «отсутствие багов», а:

• отсутствие критических багов на момент выпуска;
• регулярное устранение обнаруженных багов в обновлениях;
• работоспособность ключевых функций в стандартных сценариях.

Что должно быть в договоре

1. Реалистичные критерии качества:
«Программное обеспечение должно обеспечивать выполнение всех функциональных требований, перечисленных в Техническом задании, в стандартных сценариях использования. Отсутствие критических и серьёзных дефектов на момент сдачи работ. Устранение Minor и Trivial дефектов на гарантийном этапе».

2. Гарантийный период. Обычно 6–12 месяцев с момента приёмки.

3. Объём гарантии. Что входит в гарантию (исправление дефектов в исходном ТЗ), что не входит (новые функции, изменения окружения, баги, вызванные действиями заказчика).

4. Срок реакции. Сколько времени у исполнителя на исправление каждой категории дефекта:

• Critical: до 24 часов;
• Major: до 5 рабочих дней;
• Minor: до 30 рабочих дней.

5. Что НЕ входит в гарантию:

• проблемы, вызванные изменением среды (новые версии браузеров, ОС);
• проблемы из-за нагрузки сверх описанной в ТЗ;
• проблемы из-за модификаций ПО заказчиком или третьими лицами;
• проблемы из-за отказа стороннего сервиса/API;
• новые требования заказчика.

Что произойдёт при формулировке «без багов»

Через год после сдачи заказчик находит мелкий баг, ссылается на нарушение договорных гарантий, требует возврата денег. В суде формулировка «без багов» работает против исполнителя. Грамотная формулировка с гарантийным периодом и категориями дефектов защищает обе стороны.

Это критический пункт для исполнителя. Без лимита ответственности риск растёт неограниченно.

Какие убытки может понести заказчик

При сбое в работе разработанного ПО заказчик может заявить:

• упущенная выгода (из-за простоя сервиса);
• репутационные потери;
• штрафы перед его клиентами;
• расходы на восстановление данных;
• расходы на привлечение другого подрядчика для исправления.

В крупных проектах эти суммы могут быть в 50–100 раз больше стоимости разработки.

Что прописать

1. Лимит совокупной ответственности. Стандарт IT-индустрии:
«Совокупный размер ответственности Исполнителя по настоящему Договору, включая возмещение убытков, упущенной выгоды и уплату неустойки, ограничен суммой, фактически уплаченной Заказчиком Исполнителю по настоящему Договору».
Альтернативные варианты:

• лимит, равный 100% стоимости договора;
• лимит, равный 50% стоимости договора;
• фиксированная сумма (для крупных проектов).

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

3. Исключения из лимита. Лимит обычно не применяется к:

• умышленным нарушениям;
• нарушениям конфиденциальности (если важно для заказчика);
• нарушениям прав третьих лиц.

Реакция заказчика

Заказчики часто пытаются убрать лимит из договора. Аргумент исполнителя: «Стоимость разработки не покрывает потенциальный риск 100% компенсации любых убытков. Если вы хотите снять лимит — нужно увеличить стоимость в 5–10 раз для покрытия страхового резерва».

При нормальной коммерческой логике — компромисс находится в виде лимита, равного нескольким стоимостям договора.

Заказчики обычно требуют гарантию, что разработанное ПО не нарушает прав третьих лиц. Это разумное требование, но его нужно правильно оформить.

Базовая формулировка от заказчика

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

Риски для исполнителя

При буквальном прочтении исполнитель гарантирует отсутствие любых нарушений. На практике:

• невозможно проверить, что каждая идея/паттерн не запатентованы кем-то;
• невозможно гарантировать отсутствие косвенных нарушений (например, патентного троллинга);
• невозможно отвечать за весь стек технологий, разработанных не вами.

Как защититься

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

2. Исключить ответственность за непредвиденные претензии:
«Исполнитель не несёт ответственности за претензии третьих лиц, основанные на объектах интеллектуальной собственности, которые на момент завершения работ не были опубликованы в публичных реестрах или не были известны Исполнителю при разумной проверке».

3. Установить лимит ответственности по этому пункту:
«Совокупная ответственность Исполнителя по требованиям, связанным с нарушением прав третьих лиц, ограничена суммой, фактически уплаченной Заказчиком Исполнителю по настоящему Договору».

4. Предусмотреть процедуру урегулирования претензий:

• Заказчик обязан в течение 10 дней уведомить Исполнителя о любой претензии;
• Исполнитель имеет право самостоятельно вести защиту;
• Заказчик не вправе признавать нарушения или платить компенсации без согласия Исполнителя.

Особый случай: патентные тролли

В IT-индустрии активно работают патентные тролли — компании, скупающие патенты для предъявления претензий. Защититься от них на 100% невозможно. В договоре желательно прямо указать, что иски от непрактикующих лиц (Patent Assertion Entities) — отдельный риск, не покрываемый гарантией.

Любое современное ПО содержит десятки или сотни Open Source библиотек. Каждая из них — отдельная лицензия со своими условиями.

Категории Open Source лицензий

Permissive (разрешающие) — MIT, BSD, Apache 2.0. Можно использовать почти без ограничений.

Copyleft (с обременениями) — GPL, AGPL. Если использовали — обязаны открыть исходный код своего ПО под той же лицензией. Это часто несовместимо с коммерческой моделью заказчика.

Strong copyleft — AGPL. Распространяется даже на серверное использование (если ПО доступно через сеть).

Commercial-restricted — некоторые лицензии ограничивают коммерческое использование без согласования.

Типичные ошибки

1. Использование GPL-библиотеки в коммерческом продукте. Без раскрытия кода — это нарушение, риск иска от правообладателя.

2. Несоблюдение требований к атрибуции. Некоторые лицензии требуют включения текста лицензии в продукт. Игнорирование — нарушение.

3. Использование библиотек без проверки лицензии. Разработчик добавил npm-пакет, не глядя в LICENSE. Через год оказывается, что лицензия несовместима с коммерческой моделью.

4. Не передан перечень используемого Open Source заказчику. Заказчик не знает, что в продукте, и потом сталкивается с проблемой при попытке лицензирования.

Что прописать в договоре

1. Обязанность исполнителя предоставить перечень Open Source. При сдаче работ — список всех использованных Open Source компонентов с указанием лицензий.

2. Заверение о совместимости лицензий. Исполнитель заверяет, что использованные Open Source компоненты совместимы с предполагаемой моделью использования продукта Заказчиком.

3. Согласование «строгих» Open Source. Использование GPL/AGPL — только с письменного согласия заказчика.

4. Соблюдение требований к атрибуции. Исполнитель обязан включить все необходимые атрибуции в код и документацию.

Превентивная мера

В крупных IT-компаниях используют Open Source Compliance — внутренние процедуры проверки лицензий. Это сканирование кода специальным ПО (Black Duck, FOSSA, Snyk), которое выявляет все Open Source компоненты и их лицензии. Для разовых проектов это может быть избыточно, но для крупных и длительных — обязательно.

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

Что нужно защищать исполнителю

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

Двусторонний NDA

Корректный договор содержит взаимные обязательства по конфиденциальности:

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

Со стороны Заказчика: данные о бизнес-процессах, клиентской базе, финансовая информация, технические особенности ИТ-инфраструктуры.

Со стороны Исполнителя: архитектурные решения, собственные программные библиотеки и компоненты, ноу-хау, методики разработки, коммерческие условия и ставки оплаты.

За нарушение обязательств о конфиденциальности виновная Сторона уплачивает другой Стороне штраф в размере 1 000 000 (одного миллиона) рублей за каждый случай нарушения».

Срок действия NDA

Стандартная практика: NDA действует дольше, чем основной договор. Обычно 3–5 лет после прекращения договорных отношений. Для критически чувствительной информации — бессрочно.

Что не покрывает NDA

В формулировке нужно указать:

• информацию, которая стала публично известна не по вине стороны;
• информацию, которая была известна стороне до начала отношений;
• информацию, полученную от третьих лиц на законных основаниях;
• информацию, раскрытие которой требуется по закону.

Что произойдёт, если стороны решат прекратить отношения? Без чётких правил — конфликт и суд.

Сценарии расторжения

1. По соглашению сторон. Самый простой сценарий — стороны подписывают соглашение о прекращении.

2. Односторонний отказ заказчика. По ст. 717 ГК РФ заказчик вправе в любой момент отказаться, оплатив выполненные работы и возместив убытки. Но это нужно правильно оформить в договоре.

3. Односторонний отказ исполнителя. В каких случаях исполнитель может отказаться? Просрочка оплаты, нарушение существенных условий заказчиком.

4. Расторжение в судебном порядке. При существенных нарушениях.

Что прописать

1. Право заказчика на немотивированный отказ. С условием возмещения фактически выполненных работ + согласованной компенсации.

2. Право исполнителя на отказ при просрочке оплаты. Например, при просрочке более 30 дней.

3. Порядок взаиморасчётов при расторжении:

• что оплачивается;
• по какой ставке;
• в какой срок;
• судьба переданных материалов и кода;
• возврат предоплаты.

4. Передача результатов работ. Что передаётся заказчику при расторжении (исходный код, документация, данные).

5. Объём прав заказчика. На незавершённый продукт.

6. Обязательства, переживающие расторжение:

• конфиденциальность;
• интеллектуальные права;
• гарантии (на то, что уже сдано);
• разрешение споров (применимое право, подсудность).

Антипример

«Договор может быть расторгнут по соглашению сторон или в судебном порядке».
Слишком обобщенно. Половина споров — об условиях расторжения.

Хорошая формулировка

1. «Заказчик вправе в одностороннем порядке отказаться от исполнения Договора, уведомив Исполнителя не менее чем за 14 календарных дней. В этом случае Заказчик оплачивает Исполнителю стоимость фактически выполненных к моменту получения уведомления работ, а также фиксированную компенсацию в размере 30% стоимости невыполненной части работ.
2. Исполнитель вправе в одностороннем порядке отказаться от исполнения Договора при: (а) просрочке оплаты Заказчиком более 30 календарных дней; (б) непредоставлении Заказчиком необходимой информации или материалов более 14 рабочих дней при письменном уведомлении.
3. При расторжении Исполнитель в течение 10 рабочих дней передаёт Заказчику исходный код и документацию по результатам работ, выполненных к моменту расторжения. Исключительные права на эти результаты переходят к Заказчику только при условии полной оплаты.
4. Условия о конфиденциальности, исключительных правах, гарантиях и применимом праве сохраняют силу после расторжения Договора».

Договор разработки ПО — это документ, в котором каждая формулировка может стоить миллионы. По статистике судебной практики 65–70% споров между заказчиками и разработчиками выигрывают заказчики — почти всегда из-за дефектов договора.

Главные принципы защитного договора:

1. Не использовать чужие шаблоны. Каждый бизнес уникален, договор должен учитывать вашу модель работы.
2. Чётко описывать предмет и границы. Без этого любые споры — на стороне заказчика.
3. Прорабатывать переход прав. Это не «галочка», а ключевой пункт всего договора.
4. Оформлять служебные произведения внутри компании. Без этого права остаются у разработчиков.
5. Устанавливать лимит ответственности. Без него — неограниченный риск.
6. Прописывать процедуру изменений объёма. Защита от scope creep.
7. Балансировать интересы обеих сторон. Перекос всегда работает против вас в суде.

Юристы Леганта Групп специализируются на IT-праве и договорах разработки ПО по всей территории Российской Федерации. Мы:

• разрабатываем индивидуальные шаблоны договоров разработки под специфику вашего бизнеса;
• проводим экспертизу входящих договоров с подготовкой протокола разногласий;
• оформляем правовую инфраструктуру по служебным произведениям;
• сопровождаем сделки по передаче исключительных прав;
• ведём споры по договорам разработки в арбитражных судах и Суде по интеллектуальным правам;
• защищаем по искам о компенсации за нарушение исключительных прав;
• сопровождаем регистрацию ПО в Роспатенте и в Едином реестре российских программ;
• консультируем по Open Source compliance и лицензионной чистоте.

Бесплатная консультация юриста по договорам разработки ПО — 30 минут с экспертом по IT-праву.
[Записаться на консультацию] | [Позвонить: +7 (XXX) XXX-XX-XX] | [Написать в WhatsApp]


Статья носит информационный характер и не заменяет индивидуальной юридической консультации. По состоянию на май 2026 года.
Источники: Гражданский кодекс РФ часть IV (ст. 1252, 1252.1, 1295, 1297, 1301), Федеральный закон от 07.07.2025 № 214-ФЗ, обзоры судебной практики Верховного Суда РФ за 2024–2026 годы, практика Суда по интеллектуальным правам, дела № А40-202764/2018 и иные.