Правильно составленный договор является фундаментом успешного взаимодействия между заказчиком и исполнителем (разработчиком) в сфере IT․ В российском гражданском праве не существует единого типа договора «на разработку ПО», поэтому выбор правовой формы определяет распределение рисков, порядок приемки работ, режим интеллектуальной собственности и налоговые последствия․

Выбор правовой основы: виды договоров

Согласно Гражданскому кодексу РФ (ГК РФ), отношения по созданию ПО чаще всего оформляются через три основных типа договоров․ Выбор зависит от этапа жизненного цикла ПО и цели сторон․

Договор подряда (ст․ 702–768 ГК РФ) — классический вариант

Применимость: Создание уникального программного продукта по техническому заданию (ТЗ) с передачей заказчику исключительных прав․

• Суть: Подрядчик обязуется выполнить работу (создать ПО) и сдать результат заказчику, а заказчик — принять и оплатить․
• Результат: Материальный носитель (код на GitHub, флешка, доступ к репозиторию) + исключительное право․
• Приемка: Акт приема-передачи результатов работ (КС-2, КС-3 или собственный формат)․ Риск случайной гибели до приемки на подрядчике․
• Гарантии: Подрядчик отвечает за качество (дефекты) в течение гарантийного срока (по умолчанию — 1 год от приемки, ст․ 756 ГК РФ)․

Договор возмездного оказания услуг (ст․ 779 ГК РФ) — для сопровождения, аудита, консалтинга

Применимость: Техподдержка, код-ревью, DevOps-настройка, рефакторинг, консультации по архитектуре․ Результатом является процесс, а не осязаемый уникальный продукт․

• Особенность: Нет обязательной приемки по акту (если не оговорено), оплата за время (Time & Materials) или за факт оказания․
• Риски: Исполнитель не гарантирует достижение конкретного бизнес-результата, если это не прописано в СЛА (SLA)․

Договор лицензирования / уступки исключительного права (ст․ 1234–1238 ГК РФ) — для готовых решений (Box, SaaS, On-premise)

Применимость: Передача прав на уже существующее ПО (SaaS-подписка, коробочная версия, внедрение тиражируемого продукта)․

• Лицензия (простая/исключительная/полная): Право использования в определенных пределах (территория, срок, способы)․ Авторство и исключительное право остаются у разработчика․
• Уступка права (Assignment): Полная передача исключительного права заказчику․ Разработчик теряет право использовать ПО (если не оговорено обратное)․ Требует письменной формы и госрегистрации при переходе исключительного права (для программ для ЭВМ регистрация в Роспатенте добровольна, но желательна для оспаривания)․

Смешанные и специфические модели

• Аутстаффинг (Outstaffing): Договор о предоставлении персонала (ст․ 56 ТК РФ / 124 ГК РФ) или ГПХ с физлицом/ИП․ Заказчик управляет сотрудником напрямую․
• Agile / Scrum договор: Рамочный договор (Master Services Agreement) + Спринт-планирование (Sprint Backlog) как приложения․ Оплата за спринт или за стори-поинты․ Сложно вписать в жесткий «Подряд», требует гибких условий приемки (Definition of Done)․
• SaaS (Software as a Service): Договор о предоставлении доступа к функционалу ПО (не передача копии)․ Регулируется нормами оказания услуг + лицензирования․

Обязательные и рекомендуемые условия (Структура договора)

Независимо от типа, любой договор должен содержать условия, предусмотренные ст․ 432 ГК РФ․

Предмет договора (Самое важное)

Недостаточно написать «разработка сайта/приложения»․ Необходимо сослаться на приложения:

1. Техническое задание (ТЗ) / Terms of Reference (ToR): Функциональные и нефункциональные требования, стек технологий, интеграции, макеты (Figma), API-контракты․
2. Критерии приемки (Acceptance Criteria / Definition of Done): Как именно проверяется работа (тест-кейсы, UAT-сценарии, нагрузочное тестирование)․
3. План-график / Roadmap: Этапы (Майлстоуны), дедлайны, зависимости․

Интеллектуальные права (IP) — «Сердце» IT-договора

Стандартная схема (Work for Hire):

• Исключительное право на созданный код/дизайн/документацию переходит к Заказчику с момента приемки (или оплаты)․
• Авторское право (право авторства, имя) остается у разработчиков (физлиц)․
• Разработчик сохраняет право использовать общие библиотеки, фреймворки, паттерны (Background IP), созданные до договора․

Ключевые пункты для прописки:

• Момент перехода прав (приемка акта vs полная оплата)․
• Право разработчика включать работу в портфолио (NDA permitting);
• Гарантия «чистоты» прав: нет заимствований GPL-кода в проприетарный проект, нет нарушения прав третьих лиц․
• Регистрация в Роспатенте (кто инициирует, кто платит)․

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

• Фиксированная цена (Fixed Price): Только при детальном ТЗ․ Риск переработок на подрядчике․
• Time & Materials (T&M): Почасовая ставка + расходы․ Требует прозрачного та-трекинга (Jira, GitLab, Harvest) и ежемесячных актов․
• Milestone-based: Оплата за этапы (Дизайн -> Бэкенд -> Фронтенд -> Тесты -> Деплой)․
• Предоплата / Постоплата / Эскроу: Стандарт — 20-30% предоплата, остальное по актам․ Для T&M — постоплата за отчетный период․
• Валюта: Только рубли (для резидентов РФ, ст․ 317 ГК РФ, 15 ФЗ-173)․ Индексация не допускается для ФП, допускается для T&M (пересмотр ставок раз в год)․

Порядок приемки-сдачи (Взаимодействие сторон)

1. Демонстрация (Demo) на стенде исполнителя․
2. Внутреннее тестирование QA исполнителя․
3. Передача артефактов (код, миграции БД, инструкции, Docker-образы)․
4. UAT (User Acceptance Testing) заказчиком на тестовом/продакшн-окружении (срок 5-15 рабочих дней)․
5. Подписание Акта приема-передачи (или протокола расхождений при багах)․
6. Деплой на Продакшн (Go-live) — часто отдельный этап/акт․

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

• Гарантийный период: Обычно 3–12 месяцев после приемки․ Исправление багов (Bug fixes) за счет исполнителя․
• SLA (Service Level Agreement): Время реакции (Response time) и восстановления (Resolution time) по приоритетам (Critical / High / Medium / Low)․
• Исключения из гарантии: Изменения кода заказчиком, смена окружения/ОС/БД без согласования, DDoS, действия третьих лиц․
• Техподдержка (платная): Отдельный договор/доп․ соглашение после гарантии․ Обновления безопасности, минорные фичи, мониторинг․

Конфиденциальность (NDA) и неконкуренция

• Определение конфиденциальной информации (Код, БД, Бизнес-процессы, ТЗ, Финансы)․
• Срок действия (обычно 3–5 лет после расторжения)․
• Штрафные санкции за утечку (неустойка)․
• Non-compete / Non-solicit: Запрет на абвор сотрудников и работу с конкурентами (для ключевых исполнителей, срок до 1 года, с компенсацией)․

Ответственность сторон и разрешение споров

• Неустойки: За просрочку этапов (0․1–1% от стоимости этапа в сутки), за просрочку оплаты (ключевая ставка ЦБ или %)․
• Ограничение ответственности (Liability Cap): Критично для исполнителя․ Обычно — лимит = 100% стоимости договора или стоимости этапа․ Исключение: утечка конфиденциальной информации, IP-нарушения, умысел/грубая неосторожность․
• Исключение косвенных убытков (Consequential damages): Упущенная выгода, репутационный ущерб — обычно исключаются․
• Судебная юрисдикция: Арбитраж по месту нахождения ответчика (или по соглашению)․ Медиация как предусловие․

Типовые структурные образцы условий (Клаузылы)

Пример 1: Условие о переходе исключительных прав (для Договора подряда)

П․ X․1․ Исключительное право на Результаты работ (программный код, техническую документацию, дизайн-макеты, базы данных), созданные в исполнении настоящего Договора, переходит к Заказчику с момента подписания Акта приема-передачи результатов соответствующего Этапа (Работы в целом)․

П․ X․2․ Подрядчик гарантирует, что Результаты работ не нарушают исключительных прав третьих лиц․ Подрядчик обязуется возместить Заказчику все убытки, включая судебные издержки и штрафы, возникшие в связи с претензиями третьих лиц к правомерности использования Результатов работ․

П․ X․3․ Подрядчик сохраняет за собой право безвозмездно использовать в своей деятельности общие алгоритмы, программные модули, библиотеки, фреймворки и ноу-хау (Background IP), разработанные до заключения Договора или параллельно с ним, при условии, что их использование не позволяет третьим лицам получить доступ к Конфиденциальной информации Заказчика или уникальной бизнес-логике Проекта․

П․ X․4․ Переход исключительного права не влечет перехода права авторства․ Подрядчик (авторы — физлица) сохраняют неимущественные права (право авторства, право имени)․ Заказчик обязуется указывать авторство разработчиков в документации/интерфейсе ПО по запросу Подрядчика․

Пример 2: Условие приемки для Agile / Итеративной разработки

П․ Y;1․ Работы выполняются Итерациями (Спринтами) продолжительностью 2 (две) недели․ Состав работ Итерации фиксируется в Плане спринта (Sprint Backlog), утверждаемом Сторонами в системе управления проектом (Jira/GitLab) не позднее начала Спринта․

П; Y․2․ Приемка результатов Спринта производится по итогам Demo-сессии и прохождения Автоматизированных тестов (CI/CD pipeline: Unit, Integration, E2E)․ Критерии готовности (Definition of Done): код в ветке main, пройден Code Review, обновлена документация (Swagger/Confluence), нет багов Severity Critical/High․

П․ Y․3․ Акт приема-передачи по Спринту подписывается в электронном виде (ЭДО / подпись в таск-трекере с усиленной КЭП) в течение 3 рабочих дней после Demo․ Отсутствие возражений заказчика в течение срока считается безусловной приемкой․

П․ Y․4․ Оплата за Спринт производится в течение 5 банковских дней после подписания Акта․ Если Заказчик не предоставил доступы/данные/аппрувы, блокирующие работу, Спринт считается выполненным по объему готовых задач, Акт подписывается односторонне Исполнителем․

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

П․ Z․1․ Общая совокупная ответственность Исполнителя по всем претензиям Заказчика, вытекающим из или связанным с настоящим Договором (включая неисполнение или ненадлежащее исполнение обязательств), не может превышать сумму, равную 100% (ста процентам) стоимости соответствующего Этапа работ / Договора в целом, по которому возникла претензия․

П․ Z․2․ Стороны соглашают, что ни одна из Сторон не несет ответственности за косвенные убытки, упущенную выгоду, потерю данных, репутационный ущерб, простои бизнеса, даже если Сторона была уведомлена о возможности такого ущерба․

П․ Z․3․ Ограничения, установленные п․ Z․1 и Z․2, не применяются к ответственности за: (а) нарушение обязательств по конфиденциальности (раздел N); (б) нарушение интеллектуальных прав третьих лиц (раздел X); (в) умысел или грубую неосторожность; (г) неустойки за просрочку оплаты/сдачи (раздел П)․

Обязательные приложения (Чек-лист)

Договор без приложений юридически ничтожен или несет колоссальные риски․ Минимальный пакет:

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

• Отсутствие ТЗ или «ТЗ на 2 страницы»: Ведет к бесконечным Change Requests, спорам о scope creep и судам․ Решение: Инвестируйте в Discovery-фазу (платную) перед основным договором․
• Передача прав «после полной оплаты» при T&M: Заказчик платит месяцами, права переходят только в конце․ Если заказчик уходит — у него нет прав на код․ Решение: Переход прав по этапам/месяцам пропорционально оплате․
• Игнорирование Open Source лицензий (GPL, AGPL, MPL): Использование copyleft-библиотек заражает весь код вирусным эффектом․ Решение: Пункт в договоре: «Исполнитель гарантирует отсутствие GPL/AGPL кода в проприетарной части․ Используются только MIT/BSD/Apache 2․0»․ Автоматические проверки (SCA: Snyk, Dependabot, Syft)․
• Нет условия про доступы к инфраструктуре (Git, Cloud, Domains): При разрыве отношений заказчик теряет доступ к репозиторию/AWS/домену․ Решение: Обязательное условие: «Все аккаунты создаются на почте/организации Заказчика․ Исполнитель — гость/админ․ При расторжении — передача владения в течение 24 часов»․
• Фиксированная цена без пула рисков/буфера: Исполнитель в убытке, качество падает, проект замораживается․ Решение: Заложить 15-20% риск-буфера в FP или использовать T&M с лимитом (Cap)․
• Подписание актов «по факту» без тестирования: Заказчик подписывает акт, через месяц находит критические баги․ Решение: Четкий UAT-период, протокол расхождений, гарантийный период начинается от подписания акта․

Электронный документооборот (ЭДО) и подписание

С 2024 года для B2B практически обязателен ЭДО (Диадок, СБИС, Контур, Яндекс․ЭДО)․

• Договор и доп․ соглашения — КЭП (квалифицированная электронная подпись) генеральных директоров или доверенных лиц (с машиночитаемой доверенностью МЧД)․
• Акты приема-передачи — можно подписывать простой ЭП (внутри ЭДО) или КЭП, если требуется для бухучета/НДС․
• Спецификации/ТЗ/Планы спринтов, часто утверждаются через систему управления задачами (Jira/GitLab) с привязкой к аккаунту сотрудника (логин/пароль/2FA) + письмом на почте․ Для суда лучше оформить как приложение к доп․ соглашению с КЭП;

Качественный договор на разработку ПО — это не просто юридическая формальность, а инструмент управления проектом․ Он должен отражать реальную методологию работы (Waterfall, Agile, Kanban), технологический стек и бизнес-модель сторон․ Использование типовых шаблонов из интернета без адаптации под специфику проекта (SaaS, On-premise, Mobile, Embedded, ML/AI) несет риски потери ИП, финансовых потерь и судебных споров․ Рекомендуется привлечение IT-юриста на стадии превью договора и согласования приложений (ТЗ, DoD, Сметы)․

Данная статья носит информационный характер и не является правовой консультацией․ Для оформления конкретных правоотношений обратитесь к квалифицированному юристу, специализирующемуся на IT-праве и интеллектуальной собственности․