Договор на доработку программного обеспечения (ПО) — это вид гражданско-правового контракта‚ направленный на модификацию‚ обновление или функциональное расширение уже существующего программного продукта. Юридически такие отношения чаще всего квалифицируются как договор заказной разработки (подряда) на создание произведения (ст. 1296 ГК РФ) или договор авторского заказа (ст. 1288–1290 ГК РФ)‚ в зависимости от статуса исполнителя.

Ниже представлен подробный обзор структуры‚ обязательных условий и рисков при составлении такого договора на 2026 год‚ основанный на актуальной судебной практике и положениях ГК РФ.

Правовая природа договора: определение вида контракта

Главная ошибка сторон — неверное определение вида договора. От этого зависит‚ кому принадлежат исключительные права на результат и как они переходят к заказчику.

• Договор авторского заказа (ст. 1288–1290 ГК РФ) — заключается непосредственно с физическим лицом — автором (не трудовой договор). Критически важно: права на результат изначально принадлежат автору. Заказчик получает исключительные права только при условии выплаты отдельного авторского вознаграждения‚ отличного от оплаты труда/работ.
• Договор на создание произведения (ст. 1296 ГК РФ) — заключается с организацией или ИП (подрядчиком)‚ которые не являются авторами (авторы работают у подрядчика по трудовому или ГПХ договору). Исключительные права переходят к заказчику по умолчанию (если иное не оговорено) при приемке результата и оплате.
• Гос/муниципальный контракт (ст. 1298 ГК РФ), специфика: права остаются у подрядчика‚ если в контракте не оговорено иное.

Обязательная структура договора на доработку ПО

Грамотный шаблон должен содержать следующие разделы:

Предмет договора (п. 1)

Четкое описание того‚ что именно дорабатывается:

• Наименование и версия исходного ПО.
• Ссылка на Техническое задание (ТЗ) на доработку как неотъемлемый приложение.
• Критерии готовности (Definition of Done): «Доработка считается выполненной после прохождения тест-кейсов №… и развертывания на стенде заказчика».

Техническое задание (ТЗ) и ПМИ (п. 2)

Источник 1 подчеркивает: недостаточно четкое описание ТЗ и отсутствие Программы и методики испытаний (ПМИ) — главные причины споров.

• ТЗ должно быть версионируемым. Любые изменения — только через Доп. соглашение или протокол согласования.
• ПМИ описывает: виды тестов (unit‚ интеграционные‚ нагрузочные)‚ окружение‚ данные для тестов‚ критерии провала/успеха.

Этапы и сроки (п. 3)

Доработка часто итеративна. Рекомендуется разбить на этапы (спринты/мажорные релизы) с промежуточной приемкой и оплатой.

1. Этап 1: Анализ кодовой базы и рефакторинг (срок: Х дней). Результат: отчет + обновленный репозиторий.
2. Этап 2: Реализация модуля Y (срок: Y дней). Результат: работающий функционал + автотесты.
3. Этап 3: Интеграция‚ UAT (приемо-сдаточные испытания)‚ передача документации.

Порядок приемки-сдачи (п. 4)

Ключевой механизм защиты сторон:

• Подписание Акта приема-передачи результатов работ (КС-11 / свой формат).
• Срок на проверку заказчиком (например‚ 5 рабочих дней).
• Правило «молчание = согласие»: если заказчик не прислал претензии в срок‚ работа считается принятой.
• Протокол расхождений при обнаружении багов: критичность (Critical/Major/Minor)‚ сроки фикса.

Интеллектуальные права (п. 5) — САМОЕ ВАЖНОЕ

Для договора с юрлицом/ИП (ст. 1296 ГК РФ):

• Исключительные права на результат доработки (новый код‚ изменения) переходят к Заказчику в полном объеме (мировой‚ без ограничений способов использования) с момента приемки и полной оплаты.
• Права на исходное ПО (если оно лицензионное Заказчика) остаются у Заказчика. Исполнитель получает неисключительную лицензию на использование исходного кода только для целей выполнения договора.
• Гарантия Исполнителя: результат не нарушает права третьих лиц (нет заимствований GPL-кода без согласования‚ нет пиратских библиотек).

Важно: Если Исполнитель использует свои фреймворки/библиотеки (Background IP)‚ в договоре должно быть: «Исполнитель предоставляет Заказчику неисключительную лицензию на использование собственных компонент [название] в составе Результата доработки на безвозмездной/возмездной основе‚ без ограничения территории и срока».

Цена и порядок расчетов (п. 6)

Модели тарификации (по Источнику 1 — более 18 вариантов‚ основные):

• Fixed Price (Фиксированная цена) — при четком ТЗ. Риск переработок на Исполнителе.
• Time & Materials (T&M) — оплата фактических часов (Rate * Hours). Гибкость‚ но нужен строгий контроль табелей (Jira/GitLab логи).
• Milestone-based — оплата по этапам (см. п. 2.3). Баланс рисков.

Обязательно: валюта (рубли для РФ)‚ НДС‚ срок оплаты после подписания Акта (обычно 5–14 дней)‚ штрафы за просрочку платежа.

Ответственность сторон (п. 7)

• Штрафы за просрочку сдачи этапов: 0.1–0.5% от стоимости этапа за день (пропорционально ст. 333 ГК РФ).
• Штрафы за просрочку оплаты: пеня (ключевая ставка ЦБ / 300 * сумма долга * дни) или фиксированный %.
• Ответственность за дефекты (гарантия): бесплатное устранение багов в течение Гарантийного периода (обычно 3–12 месяцев после приемки всего проекта).
• Ограничение ответственности: plafon (потолок) — обычно до 100% стоимости договора/этапа. Исключение: ущерб от утечки конфиденциальной информации‚ нарушение ИП прав — полная ответственность.

Конфиденциальность и НДА (п.

Защита исходного кода Заказчика‚ бизнес-логики‚ баз данных‚ доступа к инфраструктуре (VPN‚ SSH ключи). Срок действия — бессрочно или 3–5 лет после расторжения.

Форс-мажор и разрешение споров (п. 9–10)

• Арбитраж по месту нахождения Ответчика (Заказчика), стандарт для B2B.
• Досудебный претензионный порядок (обязателен для арбитража): 30 дней.

Специфика «Доработки» vs «Разработки с нуля»

Приложения — неотъемлемая часть договора

Договор без приложений юридически слаб. Обязательный пакет:

1. Приложение 1: Техническое задание (ТЗ) на доработку — версионируемое‚ с номерами версий и датами согласования.
2. Приложение 2: Программа и методика испытаний (ПМИ) — как проверяем.
3. Приложение 3: Календарный план-график — с контрольными точками (Milestones).
4. Приложение 4: Форма Акта приема-передачи — со ссылками на коммиты/теги в Git‚ артефакты в Nexus/Artifactory‚ отчеты Allure/JUnit.
5. Приложение 5: Спецификация по миграции/развертыванию (Deployment Guide), инструкция для DevOps Заказчика.
6. Приложение 6: Реестр Background IP Исполнителя — список используемых своих наработок‚ которые встраиваются в результат.

Типовые ошибки и чек-лист проверки перед подписанием

Ошибка №1: «Сделайте лучше/быстрее/современнее» без ТЗ

Решение: Никаких работ без подписанного ТЗ v1.0. Любые правки — через Change Request (CR) с оценкой влияния на срок и бюджет.

Ошибка №2: Отсутствие доступа к репозиторию/инфраструктуре у Заказчика

Решение: В договоре: «Исполнитель предоставляет доступ к приватному репозиторию (GitHub/GitLab/Bitbucket) Заказчику в режиме Read/Write с Дня подписания». Код — актив Заказчика‚ он не должен быть заложником у фрилансера/аутсорсера.

Ошибка №3: Игнорирование регресса

Решение: В ПМИ обязательно пункт: «Полный прогон регрессионного набора тестов перед каждым релизом доработки».

Ошибка №4: Незакрытые права на библиотеки (Open Source / Proprietary)

Решение: Гарантия Исполнителя: «Все сторонние компоненты имеют лицензии‚ совместимые с коммерческим использованием и передачей прав (MIT‚ Apache 2.0‚ BSD). GPL/AGPL компоненты используются только с письменного согласия Заказчика».

Ошибка №5: Работа без Актов (по сообщениям в мессенджерах)

Решение: Строгое правило: нет подписанного Акта (ЭДО/подпись/скан) — нет оплаты‚ нет перехода прав. Сообщения в Telegram/Slack — не доказательство приемки в суде.

Образец формулировки ключевого пункта «Переход прав» (для вставки в договор)

Исключительное право на Результаты работ (исходный код доработки‚ обновленную документацию‚ тестовые сценарии)‚ созданные в исполнении настоящего Договора‚ переходит к Заказчику в полном объеме (во всех известных на настоящий момент способах использования‚ на весь мир‚ на весь срок действия исключительного права) с момента подписания Заказчиком Акта приема-передачи соответствующего Этапа/Работы и полной оплаты за данный Этап/Работу.

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

В случае использования Исполнителем в Результатах работ собственных предварительно разработанных компонент (библиотек‚ фреймворков‚ модулей), «Фоновые компоненты» (перечень см. Приложение №6)‚ Исполнитель предоставляет Заказчику безвозмездную (либо за фиксированную плату‚ указанную в Приложении №6) неисключительную лицензию на использование Фоновых компонент в составе Результатов работ на безограничной территории и на весь срок действия исключительных прав‚ с правом сублицензирования в пользу аффилированных лиц Заказчика.

Договор на доработку ПО, это не просто бумага для бухгалтерии‚ а главный инструмент управления рисками IT-проекта. В 2026 году акцент смещается на:

• Прозрачность процессов: доступ к Git‚ CI/CD‚ таск-трекеру в реальном времени.
• Автоматизацию приемки: привязка Актов к прохождению пайплайнов (Green Build + Allure Report).
• Чистоту IP: аудит зависимостей (SCA — Software Composition Analysis) как обязательное условие сдачи этапа.

Используйте представленную структуру как основу‚ но всегда адаптируйте условия под специфику вашего стека (Legacy Java/.NET‚ Microservices Go/K8s‚ Embedded C++‚ ML-models) и под баланс интересов сторон. Для сложных проектов (бюджет > * руб.) рекомендуется юридическая экспертиза проекта договора профильным IT-юристом.

Данная статья носит информационный характер и не является правовым консультированием. Нормы законодательства (ГК РФ‚ 44-ФЗ/223-ФЗ для госзаказов) могут меняться. Актуальность информации на .