Договор на разработку программного обеспечения: права и приёмка

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

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

Юридически программа для ЭВМ — самостоятельный объект авторского права: исходный и объектный код охраняются как литературное произведение (ст. 1261 ГК РФ). Отсюда четыре вопроса, которые в договоре на сайт обычно решаются одной строкой, а в договоре на ПО требуют отдельных разделов:

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

Договор с программистом: ИП, самозанятый или ГПХ

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

Если у заказчика пониженный тариф взносов (например, IT-аккредитация), он применяется и к выплатам по ГПХ — уточните у бухгалтера. У самозанятого перед каждой оплатой проверяйте статус на сайте ФНС: если он снялся с учёта, а вы заплатили, НДФЛ и взносы придётся начислять уже вам.

Риск переквалификации в трудовые отношения

По ст. 19.1 ТК РФ отношения по гражданско-правовому договору могут признать трудовыми — по заявлению исполнителя, предписанию трудовой инспекции или решению суда, а неустранимые сомнения толкуются в пользу трудовых отношений. Суды и ФНС смотрят на признаки из ст. 15 ТК и постановления Пленума Верховного суда № 15 от 29.05.2018:

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

Последствия — доначисление НДФЛ и взносов с пенями, штраф по ч. 4 ст. 5.27 КоАП (для организации — от 50 000 до 100 000 ₽) и обязанность оформить трудовой договор со всеми гарантиями.

Кому принадлежит код: ст. 1296 ГК и авторский заказ

Базовое правило — п. 1 ст. 1296 ГК: исключительное право на программу, созданную по договору, предметом которого было её создание, принадлежит заказчику, если договором не предусмотрено иное. Но у статьи есть оговорки, которые в шаблонах часто используют против заказчика:

• П. 2 — даже когда право у заказчика, исполнитель вправе использовать программу для собственных нужд на условиях безвозмездной простой лицензии весь срок действия права, если договор это не исключает. Для уникальной бизнес-логики это стоит запретить прямо.
• П. 3 — если договор оставляет право за исполнителем, заказчик получает лишь простую лицензию на использование в целях договора. Продать продукт, передать код другой команде для доработки или внести его в реестр отечественного ПО он уже не сможет.
• П. 5 — правила статьи не применяются, если исполнитель — сам автор. Программист-физлицо, самозанятый и ИП, который пишет код лично, — это авторы. С ними заключается договор авторского заказа (ст. 1288), и переход права к заказчику должен быть прямо в нём предусмотрен.

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

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

Отчуждение исключительного права или лицензия

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

Договор об отчуждении (ст. 1234 ГК) — исключительное право переходит к заказчику в полном объёме: он вправе дорабатывать, продавать, лицензировать, регистрировать программу на себя. Требования закона:

• письменная форма — иначе договор недействителен (п. 2 ст. 1234);
• в возмездном договоре должно быть условие о размере вознаграждения или порядке его определения — иначе договор считается незаключённым (п. 3 ст. 1234). Формулировка «вознаграждение за отчуждение включено в цену работ» работает, но надёжнее указать сумму или долю;
• момент перехода — по умолчанию в момент заключения договора, а для программы, зарегистрированной в Роспатенте, — в момент госрегистрации перехода (п. 4 ст. 1234); удобнее привязать его к подписанию акта по каждому этапу, чтобы при расторжении у вас остались права на уже принятый код.

Лицензионный договор (ст. 1235 ГК) — правообладатель остаётся прежним, заказчик получает право использования в оговорённых пределах. Что проверять в такой лицензии:

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

Открытые библиотеки: GPL, MIT и риск копилефта

Ни один современный проект не пишется с нуля: на React, Node.js или Laravel приходятся сотни открытых зависимостей. Права на них заказчику передать нельзя — они принадлежат авторам и используются по открытой лицензии (ст. 1286.1 ГК). Важно, какие обязательства эти лицензии накладывают на ваш продукт.

Для внутреннего веб-приложения, которое крутится на вашем сервере, GPL обычно не создаёт обязательств: распространения нет. Но как только вы продаёте программу, отдаёте клиентам мобильное приложение или десктопный клиент, GPL-компонент может обязать открыть исходники всего продукта. AGPL срабатывает даже для SaaS.

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

• исполнитель передаёт перечень сторонних компонентов с версиями и лицензиями (SBOM) — автоматически его собирают, например, license-checker для npm или composer licenses;
• компоненты под GPL, AGPL и другими копилефт-лицензиями — только с письменного согласия заказчика;
• платные компоненты (шрифты, модули, SDK) оформляются на заказчика или указываются в смете с условиями продления;
• исполнитель гарантирует, что использование чужого кода правомерно, и возмещает убытки по претензиям третьих лиц.

Исходный код и репозиторий: что должен получить заказчик

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

• репозиторий в аккаунте или организации заказчика на GitHub, GitLab или GitFlic — с первого дня, с полной историей коммитов, а не архив в конце;
• инструкция сборки и развёртывания, Dockerfile или docker-compose, файл с перечнем переменных окружения без секретов;
• миграции и схема базы данных, тестовые данные, сиды;
• документация API (OpenAPI или аналог) и описание интеграций;
• доступы к CI/CD, облаку, аккаунтам разработчика в RuStore, App Store и Google Play — на заказчика.

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

Регистрация программы в Роспатенте и реестр отечественного ПО

Госрегистрация программы: добровольно, но иногда полезно

По ст. 1262 ГК правообладатель может, но не обязан зарегистрировать программу в Роспатенте. Права возникают с момента создания кода, свидетельство их не создаёт. Зато сведения в реестре программ для ЭВМ считаются достоверными, пока не доказано иное (п. 6 ст. 1262), — в споре это удобное доказательство.

• госпошлина за рассмотрение заявки — 5 000 ₽, за регистрацию отчуждения права по договору — тоже 5 000 ₽ (ст. 333.30 НК РФ); для отдельных категорий авторов-физлиц есть льготы (ст. 333.35 НК РФ);
• депонируются фрагменты исходного кода и реферат, раскрывать весь код не нужно;
• по регламенту на регистрацию отводится 62 рабочих дня с даты приёма заявки (срок продлевается, если Роспатент запросит исправления); свидетельство выдаётся в электронной форме, бумажное — по желанию заявителя;
• если программа зарегистрирована, переход исключительного права на неё подлежит государственной регистрации (п. 5 ст. 1262).

Реестр российского ПО: когда он нужен

Единый реестр российских программ ведёт Минцифры по правилам постановления Правительства РФ № 1236 от 16.11.2015. Для внутренней CRM или личного кабинета клиентов он не нужен. Включение имеет смысл, если продукт будут покупать госзаказчики и компании с госучастием (для них действуют ограничения на иностранное ПО), если программа предназначена для объектов критической информационной инфраструктуры или если вы продаёте права на программу и хотите применять освобождение от НДС (пп. 26 п. 2 ст. 149 НК РФ распространяется только на ПО из реестра).

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

Приёмка ПО: критерии, тестовый период и акт

У программы нет «правильного внешнего вида», поэтому приёмка без заранее согласованных критериев превращается в спор мнений. Рабочая схема для договора на разработку ПО:

1. Критерии приёмки в ТЗ. Для каждой функции — пользовательский сценарий и ожидаемый результат, плюс нефункциональные требования: время ответа, число одновременных пользователей, поддерживаемые браузеры и версии ОС.
2. Программа и методика испытаний. Список проверок, на которых принимается этап. Для крупных систем ориентир — ГОСТ Р 59792-2021 (заменил ГОСТ 34.603-92): предварительные испытания, опытная эксплуатация, приёмочные испытания.
3. Тестовый стенд. Приёмка идёт на сервере, максимально близком к боевому, с реалистичными данными, а не на ноутбуке разработчика.
4. Классификация ошибок. Заранее договоритесь, что считается блокирующей, критичной, значительной и косметической ошибкой и с каким их количеством этап можно принять.
5. Опытная эксплуатация. Две–четыре недели работы реальных пользователей; найденные ошибки исправляются в согласованные сроки, после чего подписывается финальный акт.
6. Акт и передача. В акте — перечень принятых функций, версия (тег или хеш коммита в репозитории), подтверждение передачи исходников, документации и прав.

Цифры в таблице — пример, договоритесь о своих. Главное, чтобы классификация была в договоре до начала работ, а не придумывалась в день сдачи. Срок на приёмку и мотивированный отказ, а также ловушку «молчаливого» принятия мы разбирали в статье про договор на сайт — для ПО этот срок стоит закладывать длиннее, с учётом опытной эксплуатации.

Сопровождение и SLA после сдачи

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

С программистом-одиночкой отдельно продумайте «фактор автобуса»: что будет, если он заболеет или уйдёт на другой проект. Минимум — документация, код в вашем репозитории, воспроизводимое развёртывание и обязанность передать проект новой команде в течение оговорённого срока. Для продукта, от которого зависит выручка, надёжнее, когда разработку и сопровождение ведёт команда: при разработке веб-приложения знания о проекте не завязаны на одного человека.

Типичные ошибки в договоре на разработку ПО

• Договор с физлицом или самозанятым без условия об отчуждении — по п. 5 ст. 1296 правило «права у заказчика» к автору не применяется.
• «Права переходят после полной оплаты по договору» — при споре о последнем этапе вы остаётесь без прав на уже оплаченный код.
• Лицензия без срока и права на модификацию — через пять лет она истечёт, а доработать код формально нельзя.
• Код передаётся архивом в конце проекта, без истории, перечня библиотек и инструкции сборки.
• Программист годами работает «по ГПХ» с ежемесячной оплатой, графиком и корпоративной почтой.

Чек-лист заказчика перед подписанием

• Статус исполнителя проверен: ИП в ЕГРИП, самозанятый — в сервисе ФНС, у студии — договоры с авторами.
• Предмет сформулирован через результат, оплата — за принятые этапы.
• Есть прямое условие об отчуждении исключительного права с моментом перехода по акту этапа.
• Вознаграждение за отчуждение указано суммой или «включено в цену работ».
• Исключено право исполнителя использовать программу для собственных нужд (п. 2 ст. 1296).
• Для платформы исполнителя — лицензия на весь срок действия исключительного права (не «бессрочная»: без явного срока суд может применить пять лет) с правом модификации и передачи третьим лицам.
• Исполнитель передаёт перечень открытых компонентов с лицензиями; копилефт — только по согласованию.
• Репозиторий — в аккаунте заказчика с первого дня, плюс инструкция сборки и развёртывания.
• Исполнитель не регистрирует программу в Роспатенте на себя; если нужен реестр — права «без ограничения территории и срока».
• В ТЗ есть критерии приёмки, классификация ошибок и период опытной эксплуатации.
• Гарантия и сопровождение разведены, для сопровождения — отдельный договор с SLA.

Хороший договор на разработку ПО не защищает от плохого кода, но гарантирует главное: код ваш, вы знаете, из чего он собран, и можете передать его другой команде без согласия автора. Эти пункты дешевле согласовать до старта, чем восстанавливать права через суд.