Договор на разработку ПО: права на код, приёмка, гарантия

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

Ниже — разбор ключевых условий договора на разработку программного обеспечения с точки зрения обеих сторон. Это не юридическая консультация: формулировки нужно адаптировать под ваш проект с юристом. Но после этой статьи вы будете знать, какие вопросы задать и что проверить. Про выбор самого подрядчика мы писали в статье как выбрать подрядчика на разработку, а про модель оплаты — в материале фиксированная цена или оплата по часам.

Какой тип договора выбрать

Права на код: главный раздел

Гражданский кодекс содержит специальное правило для программ, созданных по заказу: если договором не предусмотрено иное, исключительное право на программу, созданную по договору, предметом которого было её создание, принадлежит заказчику. Но полагаться только на это правило рискованно: договор может быть квалифицирован иначе, а часть кода подрядчик мог создать раньше и использовать повторно. Поэтому в договоре прямо пропишите, что происходит с правами.

• Отчуждение исключительного права на результат работ заказчику в полном объёме — с момента подписания акта или полной оплаты этапа.
• Перечень того, что считается результатом: исходный код, скомпилированные модули, база данных и её структура, дизайн-макеты, документация.
• Отдельный порядок для заранее созданных компонентов подрядчика — его собственных библиотек и платформы: на них заказчик получает бессрочную неисключительную лицензию, достаточную для использования, изменения и передачи программы третьим лицам.
• Сторонние и открытые компоненты используются на условиях их лицензий; подрядчик передаёт их перечень и гарантирует, что лицензии допускают предполагаемое использование.
• Обязанность подрядчика обеспечить, чтобы его сотрудники и субподрядчики передали ему права, — иначе он не сможет передать их вам.
• Цена отчуждения права включена в стоимость работ — это стоит указать явно.

Открытые библиотеки: о чём договориться

Современная программа на 80–95% состоит из открытых компонентов: фреймворков, библиотек, утилит. Это нормально и экономит деньги. Но у открытых лицензий разные условия: одни разрешают почти всё, другие требуют раскрывать исходный код производных программ при распространении. Для внутренней CRM это обычно неважно, для коробочного продукта — может быть критично. Попросите подрядчика вести перечень зависимостей с их лицензиями и не использовать компоненты с «заражающими» лицензиями без согласования, если вы собираетесь распространять программу.

Этапы, ТЗ и изменения

Договор должен ссылаться на техническое задание или план работ, где описан результат каждого этапа. Чем конкретнее, тем меньше споров на приёмке: не «модуль клиентов», а «список клиентов с поиском по телефону и ФИО, карточка клиента с историей заказов, экспорт в Excel». Шаблон и логику документа можно взять в статье техническое задание на разработку или собрать черновик в генераторе ТЗ.

• Порядок изменений: заявка на изменение, оценка подрядчика, письменное согласование, корректировка сроков и цены.
• Что считается изменением, а что — исправлением ошибки: ошибка — несоответствие согласованному ТЗ, всё остальное — изменение.
• Сроки зависят от заказчика: если заказчик задерживает материалы, доступы или ответы, сроки сдвигаются автоматически.

Приёмка

1. Подрядчик передаёт результат этапа и уведомляет о готовности к приёмке.
2. Заказчик в оговорённый срок — например, 5–10 рабочих дней — проверяет по сценариям приёмки и подписывает акт или направляет мотивированный перечень замечаний.
3. Замечания — только о несоответствии ТЗ, с описанием шагов воспроизведения.
4. Подрядчик устраняет замечания в согласованный срок, после чего проводится повторная проверка только исправленного.
5. Если заказчик не подписал акт и не направил замечания в срок, работы считаются принятыми. Это защищает подрядчика от бесконечной приёмки.

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

Передача исходников и доступов

Гарантия и поддержка

Гарантийный срок — период, в течение которого подрядчик бесплатно исправляет ошибки, то есть несоответствия ТЗ, обнаруженные после приёмки. Обычно это 3–12 месяцев. Важно отделить гарантию от поддержки: гарантия не включает доработки, обновление зависимостей, консультации и работу с инфраструктурой. Всё это — отдельный договор поддержки с понятным составом работ и временем реакции. Как его устроить и сколько это стоит — в статье поддержка сайта после запуска: SLA и расходы.

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

Ответственность и конфиденциальность

• Неустойка за просрочку этапа по вине подрядчика и за просрочку оплаты заказчиком — симметричная и разумная, например 0,1% в день с ограничением 10% от стоимости этапа.
• Ограничение ответственности подрядчика суммой договора — стандартное условие; для критичных систем обсуждайте отдельно.
• Конфиденциальность: коммерческие сведения и данные заказчика не раскрываются, доступы удаляются после окончания работ.
• Персональные данные: если подрядчик получает доступ к ПДн клиентов, нужно поручение на обработку с мерами защиты по 152-ФЗ. См. уровни защищённости ПДн.
• Право подрядчика упоминать проект в портфолио — с согласия заказчика и без раскрытия конфиденциальных сведений.

Если исполнитель — фрилансер или самозанятый

С частными разработчиками договор часто вообще не заключают: договорились в мессенджере, перевели деньги, получили архив. Для небольших задач это может работать, но для системы, от которой зависит бизнес, риски те же, что и со студией, только защищены вы ещё хуже. Минимальный набор условий одинаков: результат работ и сроки, отчуждение исключительного права, передача кода в ваш репозиторий, порядок приёмки и оплаты по этапам.

С самозанятым можно заключить договор подряда или оказания услуг; он выдаёт чек на каждую оплату. Убедитесь, что исполнитель сохраняет статус на момент оплаты, и не превращайте договор в фактические трудовые отношения — постоянный график, подчинение внутреннему распорядку, работа только на вас: это риск переквалификации. Если разработчик работает с субподрядчиками, договор должен обязывать его получить от них права на код. Иначе через год может выясниться, что часть системы формально принадлежит человеку, которого вы никогда не видели.

И ещё одно правило для любого исполнителя: оплачивайте этапами против результата, который можно проверить, а не авансом за весь проект. Это дисциплинирует обе стороны и делает спорные ситуации дешевле.

Пример: во что обходится плохой договор

Условная компания заказала CRM за 2,4 млн ₽ по договору оказания услуг без условия о правах. Через год подрядчик поднял ставку поддержки вдвое, компания решила перейти к другой команде. Выяснилось: репозиторий на аккаунте подрядчика, исключительное право не передано, сервер оплачивается с карты подрядчика.

1. Переговоры о передаче прав и кода: подрядчик просит 30% от стоимости разработки — 720 тыс. ₽.
2. Альтернатива — переписать систему с нуля: 2–2,5 млн ₽ и 4–6 месяцев.
3. Простой при переезде сервера без инструкций: ещё 2–5 рабочих дней.
4. Правильный договор с отчуждением прав и передачей кода в репозиторий заказчика стоил бы нескольких часов работы юриста — порядка 20–60 тыс. ₽.
5. Вывод: условия о правах и доступах окупаются в десятки раз ещё до первого конфликта.

Оценить стоимость проекта до переговоров о договоре можно в калькуляторе стоимости разработки или калькуляторе CRM на заказ, а составить бриф — в генераторе брифа.

Короткий чек-лист договора

• Тип договора соответствует работе: результат или процесс.
• Отчуждение исключительного права на результат, лицензия на заготовки подрядчика.
• Перечень открытых компонентов и их лицензий.
• ТЗ или план с конкретным результатом каждого этапа.
• Порядок изменений и влияние на сроки и цену.
• Приёмка с мотивированными замечаниями и сроком.
• Передача кода, доступов, документации, проверка восстановления.
• Гарантийный срок отдельно от поддержки.
• Симметричная ответственность, конфиденциальность, поручение на обработку ПДн.

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

Если хотите обсудить проект и условия договора до старта работ — напишите нам или посмотрите, как устроена наша разработка.