Правовая природа договора

С юридической точки зрения договор на разработку ПО чаще всего квалифицируется как договор подряда (ст․ 702 ГК РФ) или договор об оказании услуг (ст․ 779 ГК РФ)‚ в зависимости от того‚ чем является результат: материальным носителем с программой или исключительным правом на программу․

• Договор подряда: Результат, конкретный программный продукт‚ переданный на материальном носителе или через сеть‚ который Заказчик принимает по акту приема-передачи․
• Договор об оказании услуг: Исполнитель осуществляет деятельность (написание кода‚ консультирование)‚ результат которой не обязательно оформляется как передаваемая вещь․

Важно: Независимо от названия‚ суть отношений определяется условиями договора․ Ключевым моментом является фиксация передачи исключительного права или предоставление лицензии (ст․ 1235‚ 1286 ГК РФ)․

Обязательные существенные условия (Ст․ 432 ГК РФ)

Без этих условий договор может быть признан незаключенным:

1. Предмет договора (Предмет разработки): Четкое описание того‚ что создается (веб-сервис‚ мобильное приложение‚ корпоративная информационная система‚ модуль интеграции и т․д․)․
2. Цена и порядок расчетов: Фиксированная цена (Fixed Price)‚ почасовая оплата (Time & Materials) или смешанная схема․ Этапы оплаты (аванс‚ по этапам‚ по факту приемки)․
3. Сроки выполнения работ: Календарные даты или привязка к этапам (стоунам)․

Детализация предмета: Техническое задание (ТЗ) — «Сердце» договора

Согласно судебной практике (в т․ч․ позиция КонсультантПлюс и разборы дел в арбитраже)‚ Техническое задание (ТЗ) является неотъемлемым приложением к договору․ Ссылка на него в теле договора обязательна: «Исполнитель обязуется создать Программное обеспечение в соответствии с Техническим Заданием (Приложение №1 к настоящему договору)…»․

Что должно быть в ТЗ (минимальный чек-лист):

• Функциональные требования (User Stories‚ Use Cases‚ сценарии использования)․
• Нефункциональные требования: производительность‚ безопасность‚ масштабируемость‚ совместимость (браузеры‚ ОС‚ версии API)․
• Требования к стеку технологий (языки‚ фреймворки‚ БД‚ облачная инфраструктура)․
• Критерии приемки (Definition of Done / Acceptance Criteria) — как именно Заказчик проверит‚ что работа сделана․
• Требования к документации (техническая‚ пользовательская‚ API docs)․

Ключевые блоки условий договора

Перечень услуг и работ (Пример из практики)

Общий перечень услуг‚ оказываемых по договору‚ может включать (по материалам Адвокаториума и типовых бланков):

• Разработку информационных подсистем и программных компонентов;
• Проектирование‚ разработку‚ внедрение и сопровождение программного обеспечения;
• Составление‚ ведение‚ обновление‚ профилирование и техническое обслуживание баз данных‚ информационную поддержку пользователей баз данных;
• Поставку программного обеспечения (деплой‚ установку на сервера Заказчика);
• Иные услуги по согласованию между Заказчиком и Исполнителем (Change Requests)․

Интеллектуальные права (Самый спорный пункт)

По умолчанию (ст․ 1295 ГК РФ) автором программы является физическое лицо‚ ее создавшее․ Исключительное право принадлежит работодателю (Исполнителю)‚ если программа создана в рамках трудового договора․ В B2B (договор ГПХ/подряда) права не переходят автоматически․

Варианты регулирования в договоре:

1. Передача исключительного права (Цессия): Заказчик становится полноправным владельцем․ Исполнитель теряет право использовать код в других проектах (если не оговорено иное)․ Требуется письменная форма сделки (ст․ 1234 ГК РФ)․
2. Предоставление простой (неисключительной) лицензии: Заказчик получает право использования в определенных целях/территориях/сроках․ Исполнитель сохраняет права и может лицензировать код другим․
3. Исключительная лицензия: Только Заказчик и Исполнитель имеют право использования (редко применяется для кастомной разработки)․

Критически важный нюанс (совет с Хабра/практики 2024-2025): Обязательно пропишите условие о согласии автора на внесение изменений (отказ от личного неимущественного права на неприкосновенность произведения‚ ст․ 1266 ГК РФ)․

Пример формулировки: «Заказчик имеет право вносить изменения‚ дополнения и модификации в Программное обеспечение‚ разработанное Исполнителем‚ без предварительного согласия Исполнителя и авторов кода»․

Без этого пункта любой рефакторинг или обновление версии может требовать согласия фрилансеров/сотрудников Исполнителя․

Порядок приемки-сдачи работ (Акты приема-передачи)

Работа считается выполненной только после подписания Акта приема-передачи (КС-11 или свой бланк)․ В договоре нужно зафиксировать:

• Процедуру предъявления результата (демо‚ доступ к стенду‚ передача исходников в Git)․
• Сроки на тестирование Заказчиком (обычно 5-10 рабочих дней)․
• Режим «молчания = согласие»: если Заказчик не прислал замечания в срок‚ работа считается принятой․
• Перечень критических/некритических багов‚ блокирующих приемку․

Исходный код и документация

Явно укажите‚ что передается Заказчику:

• Исполняемые файлы / артефакты сборки (APK‚ IPA‚ Docker-образы‚ JAR/WAR)․
• Исходный код (Source Code) — передается ли он? При передаче исключительного права — обязательно․ При лицензии — по согласованию․
• Документация (Swagger/OpenAPI‚ ER-диаграммы‚ мануалы по деплою‚ инструкции пользователя)․
• Доступы к репозиториям (GitHub/GitLab/Bitbucket)‚ CI/CD пайплайнам‚ облачным аккаунтам (если инфраструктура создавалась Исполнителем за счет Заказчика)․

Конфиденциальность и NDA

Обязателен пункт о неразглашении коммерческой тайны‚ персональных данных (152-ФЗ)‚ ноу-хау Заказчика․ Часто оформляется отдельным Соглашением (NDA)‚ на которое ссылается договор․

Гарантии и техническая поддержка (Warranty & Support)

• Гарантийный период: Обычно 3–12 месяцев после приемки․ Исполнитель исправляет баги за свой счет․
• SLA (Service Level Agreement): Время реакции на инциденты (Critical/High/Medium/Low)‚ время восстановления (RTO/RPO)․
• Разделение: исправление дефектов разработки (бесплатно) vs доработки/новые фичи (платно‚ новый договор/доп․ соглашение)․

Ответственность сторон

• Штрафы (пени‚ неустойки): За просрочку сдачи этапов‚ за просрочку оплаты․ Рекомендуется plafon (потолок) ответственности (например‚ не более 50-100% стоимости этапа/договора)․
• Упущенная выгода: Часто исключается прямо в договоре («Стороны отказываются от требований об упущенной выгоде»)․
• Интеллектуальная собственность третьих лиц: Исполнитель гарантирует‚ что код не нарушает права третьих лиц (нет заимствований GPL-кода в проприетарный проект без согласия‚ нет пиратских библиотек)․

Типовая структура договора (Образец содержания)

Ниже приведена рекомендуемая структура документа для заключения между юридическими лицами (ИП/ООО):

1. Преамбула: Дата‚ место‚ полные наименования сторон‚ основания действия (Устав‚ Доверенность)․
2. Предмет договора․
3. Техническое задание (Приложение 1)․
4. План-график работ / Этапы (Приложение 2)․
5. Цена договора и порядок расчетов (Приложение 3 — Реестр этапов/смета)․
6. Порядок приемки-сдачи работ (Акты КС-11 / Приложение 4)․
7. Права интеллектуальной собственности (Цессия / Лицензия)․
8. Гарантии Исполнителя и гарантийное обслуживание․
9. Конфиденциальность информации․
10. Ответственность сторон (Штрафы‚ ущерб)․
11. Срок действия договора и порядок расторжения․
12. Форс-мажор․
13. Порядок разрешения споров (Претензионный порядок‚ Арбитраж/Суд)․
14. Реквизиты и подписи сторон․
15. Приложения: ТЗ‚ График‚ Смета‚ Форма Акта‚ Спецификация лицензии/цессии‚ НДА․

Типичные ошибки и риски (Lessons Learned)

Особенности 2025-2026 годов: Тренды и регуляторика

• Реестр российского ПО (Приказ Минцифры № 2570): Если Заказчик госсектор или крит․ инф․ инфраструктура (КИИ)‚ договор должен обеспечивать соответствие ПО критериям реестра (правомочия на исходный код‚ отсутствие иностранного кода в критических модулях)․
• Импортозамещение: Требования к использованию российских БД (Postgres Pro‚ Яндекс БД)‚ ОС (Астра‚ РЕД ОС)‚ фреймворков․ Пропишите в ТЗ: «Стек технологий — только из Реестра РФ»․
• Защита персональных данных (152-ФЗ‚ 149-ФЗ): Если ПО обрабатывает ПДн‚ договор должен содержать пункт о назначении Исполнителя Оператором по договору (ст․ 28 152-ФЗ) и требованиях к защите (ФСТЭК/ФСБ сертификация СЗИ‚ если нужно)․
• Электронный документооборот (ЭДО): Стандарт де-факто для B2B․ Укажите в договоре оператора ЭДО и правила обмена подписанными сканами/XML․

Договор на разработку ПО — это не просто формальность для бухгалтерии‚ а главный инструмент управления рисками IT-проекта․ Экономия на юристах на этапе составления договора почти всегда приводит к затратам в 10-100 раз большим на суды‚ доработки или потерю бизнеса․

Рекомендация: Используйте типовые бланки (например‚ из КонсультантПлюс‚ Гаранта‚ или проверенные шаблоны профильных юридических фирм вроде RTM Group‚ Адвокаториум) только как базу․ Обязательно адаптируйте их под специфику вашего проекта (Agile/Waterfall‚ Fixed Price/T&M‚ передача прав/лицензия‚ госсектор/коммерция) с участием юриста‚ разбирающегося в IT и интеллектуальной собственности․

Данная статья носит информационный характер и не является правовым консультированием․ Для подготовки конкретного договора обратитесь к квалифицированному юристу․