Договор разработки мобильного приложения

В чем секрет успеха в XXI веке? Авторы книги «50 бизнес-моделей новой экономики. Уроки компаний-единорогов» считают, что будущее за теми предпринимателями, которые выстраивают свой бизнес на основе платформ, соединяющих производителей, дистрибьютеров и конечных клиентов.

«Vivino, Substuck, GetTransfer не производят вино, не пишут статьи и не владеют автомобилями. Они являются платформами и зарабатывают на комиссии. Чем больше клиентов, тем выше прибыль платформы, потому ее стараются сделать максимально удобной и клиентам, и поставщикам», — пишет один из соавторов книги Михаил Иванов

Это объясняет резкий рост количества договоров на разработку мобильного приложения. А вслед за ними – и судебных споров между заказчиками и разработчиками. На основе нашего опыта и судебной практики, расскажем, что учесть при подписании договора на разработку приложения.

Договор разработки мобильного приложения с точки зрения ГК РФ

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

Наш подкаст «Договор с разработчиком: зачем и какой?»

В части создания и модификации программы этот договор регулируется правилами о возмездном оказании услуг (гл. 39 ГК РФ). Иногда создание приложения может быть сопряжено с воздействием на материальный носитель (улучшение функций компьютера, мобильного устройства). В этом случае дополнительно применяются нормы о договоре подряда (гл. 37 ГК).

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

Модель договора по способу оплаты может быть fix price, time&material или их смесь – fix budget.

Стороны договора

Стороны договора на разработку мобильного приложения – заказчик и исполнитель (разработчик, IT компания). Закон не предъявляет какие-либо требования к сторонам такого договора. Любое лицо может заниматься разработкой мобильных приложений. Никакие лицензии и аккредитация не требуется.

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

Раздел 1 «Предмет договора»

Данный раздел должен четко определить два главных момента в отношениях с IT компанией — объем работы разработчика и описание будущего приложения.

Объем работы разработчика

Это перечисление действий, которые исполнитель обязан выполнить по договору. Например:

• разработка приложение для заказчика
• внедрение мобильного приложения в систему заказчика
• тестирование приложения
• интеграция ПО с другими системами заказчика или иными Интернет-ресурсами
• техническая поддержка
• обновление программы
• обучение нейросетей
• размещение приложения в магазине и прохождение модерации

Создание нового исходного кода, который является самой ценной частью программы, осуществляется только в рамках договора с предметом «разработка приложения» или «создание программы». Напротив, внедрение подразумевает выбор оптимального, но уже существующего программного продукта.

Для примера посмотрим на договор, где прописали: «Исполнитель обязуется выполнить работы по внедрению мобильного приложения, а Заказчик обязуется принять их и оплатить». Очевидно, заказчик здесь «в уме» предполагал, что внедрить нужно собственную разработку исполнителя, созданную специально для этого проекта. Исполнитель понял иначе и нашел приложение с «открытой лицензией», которое и предложил внедрить в систему заказчика. Как думаете, сможет ли заказчик по суду обязать исполнителя разработать новое приложение и внедрить именно его? Нет. Такой кейс реально рассматривался в Суде по интеллектуальным правам. Суд отказал заказчику в расторжении договора и возврате аванса, указав следующее:

«Предметом договора являются работы по внедрению программного продукта, что не является эквивалентом создания программы».

Постановление СИП от 19.04.2021 по делу № А40-18422/2019

Описание будущего приложения

Обычно выносят в Техническое задание. Оно является неотъемлемой частью договора разработки приложения. Техническое задание обычно составляется самим исполнителем по результатам диалога с заказчиком. Заказчик объясняет, для чего ему нужно приложение и как он его видит, какие функции в нем должны быть. На основе пожеланий заказчика исполнитель составляет ТЗ, исходя из своих технических возможностей. Если стороны достигли соглашения, подписывается ТЗ.

Разделы технического задания на разработку мобильного приложения:

Пример. Бизнес-логика процесса по покупке авиабилета через мобильное приложение:

Раздел 2 «Исключительное право»

Условия договоров на разработку приложения в части исключительного права зависят от двух факторов: 1) статус исполнителя, 2) объем передаваемого права.

Исполнитель – IT компания

В этом случае договор регулируется правилами о программе, созданной по заказу (ст. 1296 ГК). По умолчанию, исключительное право на созданное и принятое по акту приложение возникает у заказчика. Но договором можно специально предусмотреть обратный случай.

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

Исполнитель – физическое лицо (несколько программистов, соавторы)

Когда приложение разрабатывает физическое лицо, действуют правила о договоре авторского заказа (ст. 1288 ГК). Особенность – по умолчанию исключительное право на приложение возникает у разработчика. Поэтому в договорах с физ.лицами обязательно нужно прописывать, что правообладателем становится заказчик.

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

В таком случае договор разработки приложения «смешивается» с договором об отчуждении исключительного права. В результате приложение становится интеллектуальной собственностью заказчика.

Исключительное право передается в оговоренных пределах

Тогда сторонам нужно заключить лицензионное соглашение. Его можно оформить разными способами: раздел в договоре разработки, дополнительное соглашение или отдельный договор (образец можно приложить к договору разработки).

Лицензионный договор дает заказчику возможность использовать программу, но с ограничениями:

• по территории
• по сроку
• по способам

Если в договоре на разработку приложения ограничения не прописаны, это не значит, что их нет. Тогда они определяются по ГК, то есть заказчик-лицензиат может использовать приложение в любом регионе России, но не более 5 лет.

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

Гарантии «чистоты» исключительного права

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

1. разработанное приложение не нарушает исключительные права третьих лиц
2. при разработке приложения не использовались «вирусные» лицензии
3. исполнитель не использовал собственные разработки, выполненные в рамках других проектов

Раздел 3 «Сроки»

Фиксация сроков позволит защитить заказчика от растягивания проекта.

Начальный срок обычно связывают с датой подписания договора. При этом, исполнители настаивают на включении в договор условия о переносе сроков, если заказчик не передает необходимую документацию. Исключить переносы можно следующим способом. В техническом задании приведите весь перечень исходной документации. В сам договор включите такое условие: «Подписанием договора Подрядчик подтверждает, что исходных данных, указанных в Техническом задании, достаточно для оказания услуг».

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

Промежуточные сроки фиксируются в отдельном приложении – график (при необходимости). Промежуточные сроки выделяют этапы разработки. За их нарушение договором также предусматривается ответственность.

Однако есть проекты, для которых оптимально выбрать модель Time&Material:

• разработка уникального приложения с нетипичными бизнес-процессами
• масштабные проекты с IT-компаниями (привлекаются минимум 25 разработчиков) на долгосрочную перспективу
• мини-проекты на пол года (команда из 5 программистов и тестировщиков)
• добавление в приложение новых функций, которые пока слабо очерчены в запросе потребителя, но помогут превзойти конкурентов
• тестирование приложений

Договор T&M предполагает оплату не за результат, а за часы работы программистов. Причина – нет сроков завершения проектов, никто не знает, когда разработчики сгенерируют тот самый исходный код. В перечисленных выше проектах Time&Material выгоден для заказчика. Вспомним фильм «Безос. Человек, создавший Amazon». Два программиста круглыми сутками создавали сайт по продаже книг, не имевший аналогов в то время. Если бы это были сторонние разработчики, идеально бы подошел договор Time&Material. Но если заказчику нужно стандартное приложение точно в срок, лучше остановиться на модели fix price с указанием начального и конечного срока.

Пример договора Time&Material из устной консультации Дело чести:

Раздел 4 «Приемка услуг»

Раздел о приемке крайне важен обеим сторонам. Для исполнителя приемка подтвердит право на оплату услуг. А для заказчика приемка обозначит переход исключительного права на приложение.

В договоре следует прописать, что приемка знаменует собой переход исключительного права к заказчику. Хотя этот момент перехода можно привязать к другим фактам, например, оплата услуг.

Обратите внимание на дело № А55-20118/2017. В нем стороны связали переход исключительного права с подписанием акта приема-передачи и полной оплатой. Супер-выгодно для разработчика. А заказчик в итоге оказался без приложения, за которое почти полностью заплатил (и доплатил по суду). Это произошло из-за того, что заказчик увидел на последнем этапе тестирования шероховатости в продукте (речь идет о сайте) и вместо направления мотивированного отказа от приемки сам стал вносить изменения. Это неверная стратегия, из-за которой заказчик проиграл суд. Он должен был сообщить разработчику о неполадках и потребовать их устранения. После этого сторонам следовало подписать приемочный акт.

Что предусмотреть в договоре для сдачи-приемки приложения?

Акт приемки. Он должен подписываться обеими сторонами. Но нужно предусмотреть ситуацию, когда заказчик отказывается от приемки и не подписывает акт. Например, включите формулировку, что услуги считаются выполненными надлежащим образом, если заказчик в установленный срок не возвратил подписанный со своей стороны акт и не направил мотивированный отказ.

Поэтапная приемка. Договор разработки мобильного приложения может быть разбит на этапы. Особенно поэтапная работа характерна для Time&Material. В договоре требуется указать ожидаемый результат по каждому этапу. Закрытие этапа подтверждается промежуточным актом приемки.

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

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

Обмен актами. Укажите, куда нужно направить акт приемки (электронная почта, мессенджер, корпоративные каналы, бумажный акт по почте России).

Сопроводительная документация. Для бухгалтерии и сотрудников будет недостаточно только акта приемки. Дополнительно пропишите обязанность исполнителя направить счет, счет-фактуру (при применении НДС), перечень результатов интеллектуальной деятельности, инструкцию.

Раздел 5 «Цена и порядок оплаты»

Цена в обязательном порядке должна содержать два компонента:

1. стоимость услуг
2. вознаграждение за исключительное право

Для фиксации порядка расчетов нужно указать следующие пункты:

• сроки оплаты
• допустимость авансирование
• валюта платежа
• первичные документы (акты, счета)

Раздел 6 «Права и обязанности сторон»

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

Раздел 7 «Ответственности сторон»

Еще один принцип: каждая обязанность обеспечивается ответственностью. Здесь стороны вольны определять сами, кто и за что ответит рублем.

Наиболее распространенный вид договорной ответственности – неустойка. Она позволяет потерпевшей стороне не доказывать убытки, а в упрощенном порядке компенсировать свой ущерб.

Виды неустоек:

Раздел 8 «Порядок изменения и расторжения»

Обычно, прописывают 3 варианта прекращения контракта на разработку приложения:

1. По соглашению сторон

2. Расторжение в суде из-за нарушения

3. Односторонний отказ:

Договор разработки ПО, являясь по своей сути договором оказания услуг, дает как заказчику, так и исполнителю в одностороннем внесудебном порядке отказаться от дальнейшего сотрудничества (ст. 782 ГК РФ)

Односторонний отказ по договору оказания услуг может быть не мотивирован и осуществляется исключительно по усмотрению стороны

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

Раздел 9 «Форс-мажор»

Назначение раздела – освободить стороны от обязательств по договору, когда наступили чрезвычайные обстоятельства вне власти контрагентов. Важное условие: эти обстоятельства должны создавать непреодолимое препятствие для продолжения проекта.

Этот раздел должен содержать:

1. Перечень обстоятельств непреодолимой силы. Примеры: пожар, наводнения, землетрясения, иные стихийные бедствия, военные действия, санкции, блокировка платформы в государстве, неполадки у хостинг-провайдера, хакерские атаки.
2. Порядок фиксации форс-мажора. Например, справка торгово-промышленной палаты, комиссии по чрезвычайным ситуациям.
3. Алгоритм действия сторон. Можно продлить срок договора, изменить другие условия либо подписать соглашение о расторжении.

Раздел 10 «Разрешение споров»

Во-первых, раздел определяет порядок направления претензии и срок ответа. До истечения этого срока сторона не вправе пойти в суд.

Во-вторых, здесь определяется суд, где будет рассматриваться спор заказчика и исполнителя. Если суд не выбран, дело рассмотрят по месту жительства ответчика.

Стороны вправе передать свой спор также в третейский суд. В этом случае следует внимательней отнестись к фиксации арбитражной оговорки. Учитывая, что договор разработки приложения часто заключается с иностранными IT-компаниями, передача спора в негосударственный суд может быть очень актуальной. Президент поручил ТПП до 01.12.2024 разработать рекомендации для предпринимателей по включению в контракты оговорки о передаче дела в МКАС при ТПП:

Раздел 11 «Заключительные положения»

Этот раздел носит технический характер и содержит информацию о вступлении договора в силу, адресах, реквизитах сторон, порядке направления уведомлений, а также включает перечень приложений.