Бесплатная консультация юриста

+7 (800) 301-07-30

Реклама jurik.ru

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

Правовая квалификация договора: подряд, услуги или смешанный тип?

Фундаментальный вопрос, выбор правовой основы (Глава 37 ГК РФ «Подряд» vs Глава 39 ГК РФ «Возмездное оказание услуги»). От этого зависят: порядок приемки, риск случайной гибели, сроки исковой давности, налогообложение и возможности расторжения.

Основные подходы в судебной практике (на 2026 год):

Чистый договор подряда (ст. 702–768 ГК РФ). Применяется, если результат — осязаемая вещь или конкретный программный код, переданный на носителе. Ключевой признак: воздействие на вещь (материальный носитель).
Договор возмездного оказания услуг (ст. 779–783 ГК РФ). Применяется, если результат не овеществлен (например, консультации, аудит кода, SaaS-доступ без передачи прав). Результат услуги не может быть «передан» в собственность, он только оказывается.
Смешанный договор (наиболее частая практика). Содержит элементы подряда (создание кода) и услуг (внедрение, обучение, техподдержка). Рекомендация: прямо пропишите в преамбуле: «Договор является смешанным, регулируется нормами о подряде в части создания ПО и нормами об услугах в части внедрения/поддержки».

Важный нюанс из практики: Немецкая доктрина признает подряд с нематериальным результатом. Швейцарская практика долгое время требовала овеществления, но ФВС Швейцарии допустил признание объекта исключительного права «работой», если его можно объективно проверить на дефекты. В РФ единого подхода нет — суды то признают подряд (прецедент №), то услуги (прецедент №), то смешанный тип. Четкая квалификация в тексте договора, ваша главная защита.

Обязательные условия (существенные условия)

Без этих условий договор может быть признан незаключенным (ст; 432 ГК РФ).

Предмет договора (п. 1 ст. 432 ГК РФ)

Не пишите просто «разработка сайта/приложения». Опишите:

Функциональные требования (ТЗ): Ссылка на приложение — Техническое задание (ТЗ). ТЗ, не просто приложение, а неотъемлемая часть договора.
Технологический стек: Языки, фреймворки, БД, ОС, требования к API.
Критерии готовности (Definition of Done): Как именно определяется, что работа сдана? (Прохождение автотестов, ручное тестирование по чек-листу, нагрузочное тестирование).
Форма результата: Исходный код (Git-репозиторий), Docker-образы, документация (Swagger, пользовательские руководства), доступы к CI/CD.

Исключительные права и интеллектуальная собственность (ст. 1228, 1235 ГК РФ)

Это «сердце» IT-договора. По умолчанию (ст. 1295 ГК РФ) право принадлежит автору (разработчику). Заказчику нужны права — их нужно передать явно.

Исключительная лицензия (передача прав): Заказчик получает монопольные права на использование, модификацию, сублицензирование. Разработчик не может использовать ПО сам и передавать третьим лицам.
Простая лицензия: Заказчик использует, разработчик сохраняет права и может лицензировать другим.
Территория и срок: Обязательно укажите «Восьмидесятилетний срок» или «Срок действия исключительного права» и «Во всём мире». Без этого лицензия действует только на территории РФ и 5 лет (п. 4 ст. 1235 ГК РФ).
Право на доработку/модификацию: Явно разрешите заказчику вносить изменения в код самостоятельно или через третьих лиц.

Цена и порядок расчетов

Избегайте фиксированной цены без механизма изменения (Change Request).

Поэтапная оплата (Milestones): Приемка этапа -> Подписание Акта -> Оплата.
Time & Materials (T&M): Оплата за фактически отработанные часы (требует доверия и прозрачного трекинга времени, напр., Jira/GitLab logs).
Механизм Change Request: Процедура согласования новых требований, влияющих на сроки и бюджет.
НДС: Укажите, включен ли он в цену. Внимание: доходы от передачи прав на ПО собственной разработки могут давать право на пониженные страховые взносы (п. 5 ст. 427 НК РФ), но только при соблюдении строгих условий (передача прав, адаптация, модификация, ведение БД). Налоговая проверяет суть, а не название договора (см. практику ФНС по делу ООО «*», доход от сертификатов ЭЦП не признавался доходом от ПО).

Сроки и этапы

Календарный план-график (Гант-чарт) как приложение.
Штрафные санкции (пени, штрафы) за просрочку — должны быть пропорциональны (суды часто уменьшают завышенные штрафы по ст. 333 ГК РФ).
Право заказчика на расторжение в любой момент (ст. 723 ГК РФ для подряда) с оплатой фактических затрат + дохода.

Процедура приемки-сдачи: защита от «вечной доработки»

Самая частая причина споров — отсутствие четких критериев приемки.

Гарантии, ответственность и индеминификация

Гарантии разработчика (Representations & Warranties):

ПО не нарушает права третьих лиц (нет заимствованного GPL-кода в проприетарном продукте, нет патентных тайн).
ПО соответствует ТЗ (функциональные гарантии).
Отсутствие «вредоносного кода», бэкдоров, тайм-бомб.
Наличие прав на передачу (разработчик — автор или имеет права от авторов/сотрудников).

Ограничение ответственности (Liability Cap):

Стандарт рынка, ограничение суммы ответственности суммой договора или 12-месячной оплатой (для SaaS/поддержки). Исключите ответственность за косвенный ущерб (упущенная выгода, репутационные потери, потерю данных — если нет отдельного SLA на бэкапы).

Индеминификация (Indemnification):

Разработчик возмещает убытки заказчика, если третьие лица предъявят претензии к правам на ПО (патентные тролли, претензии авторов библиотек).

Конфиденциальность и защита данных (NDA / GDPR / 152-ФЗ)

Определение конфиденциальной информации (Код, ТЗ, БД клиентов, бизнес-процессы).
Срок действия NDA: обычно 3–5 лет после расторжения договора.
Персональные данные: если разработчик обрабатывает ПДн заказчика (тестирование на продакшн-данных) — обязателен Договор о порученной обработке персональных данных (приложение к договору). Требования 152-ФЗ и ст. 28.1 (безопасность).
Кросс-граничная передача данных: если команда разработки за рубежом (Армения, Казахстан, Сербия и т.д.), нужны Стандартные договорные условия (SCC) или согласие субъектов.

Специфические условия для современной разработки (2026)

Open Source и сторонние компоненты (SBOM)

Требуйте SBOM (Software Bill of Materials), список всех зависимостей с лицензиями. Запретите использование лицензий с «вирусным» эффектом (GPL v2/v3, AGPL) без предварительного письменного согласия заказчика. Укажите политику обновления зависимостей (Dependabot/Renovate).

ИИ-генерация кода (GitHub Copilot, CodeWhisperer, локальные LLM)

Добавьте условие: «Исполнитель гарантирует, что использование ИИ-инструментов не нарушает прав третьих лиц и не накладывает на Результат ограничений, несовместимых с передачей Исключительных прав Заказчику». Уточните, кто несет риск претензий от правообладателей обучающих выборок ИИ.

SaaS / Облачная доставка

Если ПО не передается, а предоставляется доступом (SaaS):

Договор оказания услуг / предоставления доступа.
SLA (Service Level Agreement): Uptime (99.9%), RTO/RPO, время реакции поддержки (L1/L2/L3).
Право заказчика на экспорт данных (Data Portability) при расторжении (JSON/CSV/SQL dump, API).
Условия возврата/уничтожения данных заказчика (ст. 28.1 152-ФЗ).

Типовая структура договора (Чек-лист приложений)

Договор — это фреймворк. Мясо — в приложениях. Обязательный пакет:

№	Приложение	Назначение
1	Техническое задание (ТЗ) / Product Backlog	Описание функционала, нефункциональных требований (производительность, безопасность, UI/UX).
2	Календарный план-график / Roadmap	Этапы, дедлайны, зависимости.
3	Порядок приемки-сдачи (Acceptance Criteria / Test Plan)	Чек-листы, скрипты тестов, критерии «Готово».
4	Форма Акта приема-передачи	Единая форма для подписания по этапам и итогового.
5	Спецификация по цене / Rate Card	Ставки за час (T&M), стоимость этапов (Fixed Price), стоимость Change Request.
6	Лицензионное соглашение / Акт передачи прав	Отдельный документ для госрегистрации (если ПО регистрируется в Реестре российского ПО).
7	Договор о порученной обработке ПДн (ДПОПД)	Обязателен при доступе исполнителя к персональным данным.
8	Политика безопасности информации / Требования к инфраструктуре	Требования к ноутбукам разработчиков, VPN, MFA, запрет работы из кафе/общих сетей.
9	Реестр Open Source компонентов (SBOM)	Перечень библиотек, лицензий, версий.

Распространенные ошибки (Top-5)

Отсутствие ТЗ или ссылаются на «техническое задание будет согласовано позже». -> Договор незаключен по предмету.
Фраза «Права передаются по оплате» без деталей. -> Нет территории, срока, вида лицензии, права на сублицензию/модификацию. Риск: заказчик не может продать бизнес или привлечь инвестиции (Due Diligence провалится).
Игнорирование режима «Deemed Acceptance». -> Заказчик молчит месяцами, пользуется ПО, но не платит за этап, так как «не подписал акт».
Передача прав на код, но не на документацию / дизайн / бренд. -> Заказчик получает «черный ящик» без права менять логотип или обновлять инструкцию;
Отсутствие условия об эскроу (Escrow) для миссионерских систем. -> Если разработчик обанкротится (ООО «*»), заказчик не получит доступ к исходникам и ключам сборки.

Регистрация в Реестре российского ПО (Приказ Минцифры № 240)

Для получения налоговых льгот (НДС 0%, пониженные взносы, налог на прибыль 0%/3% для Сколково/АОП) и приоритета закупок (223-ФЗ, 44-ФЗ) ПО нужно зарегистрировать.

Требования: исключительное право у российской юрлица/ИП, отсутствие зарубежных контролирующих лиц (>50%), соответствие критериям (нет вредоносных функций, данные хранятся в РФ).
Договор должен предусматривать обязанность разработчика предоставить материалы для регистрации (исходники, описание, отчеты тестирования) и сотрудничать при проверке ФСТЭК/ФСБ (если ПО для госнужд/КИИ).

Качественный договор на ПО, это не «шаблон из интернета», а инженерный документ, защищающий бизнес-логику сделки. Ключевые принципы 2026 года:

Явная квалификация (смешанный договор).
Детализация предмета через ТЗ и Критерии приемки.
Полная передача Исключительных прав (территория, срок, модификация, сублицензия).
Механизм управления изменениями (Change Request).
Защита от рисков Open Source и ИИ (SBOM, гарантии чистоты кода).
Соответствие 152-ФЗ и требованиям Реестра русского ПО (если применимо).

Рекомендация: Никогда не подписывайте типовый договор без правовой экспертизы профильного юриста (IT-lawyer). Экономия на юристе на этапе заключения стоит в 10–100 раз дороже на этапе спора в Арбитражном суде г. * или Суде по интеллектуальным правам.

Статья подготовлена на основе актуальной судебной практики и нормативной базы на . Информация носит ознакомительный характер и не является правовым консультированием. Для решения конкретных вопросов обратитесь к адвокату/юристу, специализирующемуся на IT-праве (например, коллеги из профильных бутиков: «», «»).

Как составить договор на программное обеспечение