парафа
← БлогПрактика · · 8 мин

Проверка договора на разработку ПО: кому принадлежит код и что считается принятой работой

В договоре заказной разработки два вопроса дороже всех остальных: исключительное право на программу (ст. 1296 ГК) и порядок приёмки. Разбираем, что проверять заказчику и подрядчику: исходный код, open source, гарантийные багфиксы и выход из проекта.

Договор на разработку программного обеспечения обычно собирают из формы подряда, добавив слово «код». В результате не урегулированными остаются ровно те вопросы, из-за которых IT-проекты попадают в суд: чьи права на программу, что такое «готово», кто чинит баги после приёмки и что забирает заказчик при расставании. Разбираем по порядку.

Права на программу: умолчание в пользу заказчика

Исключительное право на программу, созданную по договору, предметом которого было её создание, принадлежит заказчику, если договором не предусмотрено иное (ст. 1296 ГК РФ). Подрядчик при этом сохраняет право использовать программу для собственных нужд на условиях безвозмездной неисключительной лицензии — тоже если договор не скажет иного. Заказчику важно проверить, что договор прямо назван договором на создание ПО (иначе применима другая статья с обратным умолчанием) и что «иное» в тексте не спрятано: формулы «права переходят после полной оплаты» превращают задержку платежа на день в использование программы без прав.

Предмет и ТЗ: от чего считается scope

Проверьте иерархию документов: договор, техническое задание, бэклог, переписка в трекере — что из этого фиксирует объём работ и как оформляется его изменение. Для waterfall-модели это ТЗ с процедурой допсоглашений; для agile — оплата итерациями с приёмкой каждого спринта. Опасна смесь: фиксированная цена «по ТЗ», которое стороны договорились «уточнять в рабочем порядке», — готовый спор о том, входила ли доработка в цену.

Приёмка: что такое «готово»

  • Критерии приёмки: тестовые сценарии, критичность дефектов (блокирующие/некритичные), допустимо ли принятие с некритичными замечаниями.
  • Срок приёмки и последствия молчания заказчика — для подрядчика защита от вечного тестирования, для заказчика риск автоприёмки.
  • Мотивированный отказ: в какой форме, с каким уровнем детализации, сколько циклов исправлений включено в цену.
  • Опытная эксплуатация: входит ли она в приёмку и кто отвечает за инциденты в этот период.

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

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

Чужие компоненты: open source и лицензии третьих лиц

Любой современный проект собирается поверх чужих библиотек. Проверьте гарантии подрядчика: результат не нарушает прав третьих лиц, используемые open-source-компоненты совместимы с планируемой моделью использования (копилефт-лицензии могут обязать раскрыть ваш код), список сторонних компонентов передаётся с результатом. Для подрядчика симметричная оговорка — заказчик отвечает за материалы, которые передал он: логотипы, контент, купленные компоненты.

Гарантия и багфиксы: бесплатно ли чинятся ошибки

Разграничьте три вещи: исправление дефектов, выявленных на приёмке (входит в цену работ), гарантийный период после приёмки (срок и что считается гарантийным случаем), и поддержку с развитием (отдельные деньги). Форма подрядчика обычно объявляет любое обращение после подписания акта платной доработкой; форма заказчика — растягивает бесплатную гарантию на годы. Рабочая середина — гарантийный срок с обязательством чинить воспроизводимые дефекты, не вызванные доработками третьих лиц.

Вопрос «кто чинит баг через месяц после акта» стоит задать до подписания договора. После — на него отвечает не логика, а переговорная позиция.

Выход из проекта

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

Как проверить быстрее

Парафа проверяет договор на разработку ПО с позиции вашей роли — заказчика или подрядчика, — подсвечивает пункты о правах, приёмке и гарантии и собирает найденное в готовый протокол разногласий. Первые три договора — бесплатно; что входит в проверку — на странице модулей.

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

Мы используем технические cookie для работы сайта и аналитические (Яндекс.Метрика) — чтобы улучшать сервис, в обезличенном виде. Подробнее в Политике cookie.