00

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

Стоимость услуги: 25 000 рублей.

Срок исполнения услуги: 3 рабочих дня.

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


Что включает в себя услуга по разработке договора на обслуживание компьютеров:

  1. изучение ситуации и документов;
  2. подготовка договора на разработку мобильного приложения;
  3. передача договора на разработку мобильного приложения;
  4. отчет перед клиентом.

 

Какие документы необходимы от Вас для оказания услуги:

  1. документы и сведения, регулирующие правоотношения;
  2. реквизиты сторон договора;
  3. юридические и экономические условия договора.

 

Что нужно сделать, чтобы заказать услугу:

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

Стоимость услуги

25 000 рублей

Статьи по теме

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Термины, определения и сокращенияПредназначен облегчить восприятие текста
2. Цель разработки ПОИсполнитель должен понимать, для чего заказчику нужно приложение, в какой сфере оно будет использоваться и какие потребности заказчика должно закрыть
3. Функции приложенияДля пользователя:    
— сообщение информации, выдача контента
— помощь в совершении процесса
— подключение услуг
— продажи и расчеты

Для заказчика:
— систематизация клиентской базы
— рассылки
— переход на сайт заказчика
4. Технические требование— IOS и/или Android
— совместимость с версиями IOS, Android
— поддержка устройств (актуально для айфонов)
— сервер
5. Описание операций (бизнес-логика)Потребность пользователя разбивается на конкретные шаги, которые выполняются через приложение. Сколько потребностей клиента хочется закрыть приложением, столько должно быть описано бизнес-процессов
6. Интерфейс— изображение приложения (прорисовка, макеты экранов)
— референсы
— фирменная атрибутика заказчика (товарные знаки, коммерческие обозначения)
— палитра
— анимация
— звуки
7. Нормативная документацияЗакрепляет правовую базу, которой должна соответствовать разработка: — Закон о защите персональных данных
— Закон о рекламе
— Правила платформы

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

Раздел 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 «Права и обязанности сторон»

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

Основные обязанности сторон по договору на разработку приложения
Обязанности исполнителя
1. Оказать услуги качественно и в срок
2. Оказать услуги в объеме ТЗ
3. Обеспечить «чистоту» исключительного права
4. По требованию Заказчика предоставлять информацию о ходе разработки
Обязанности заказчика
1. Передать необходимую информацию
2. Принять результат работ
3. Оплатить услуги исполнителя  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Юристы Дело чести помогут разработать проект договора разработки мобильного приложения, включая модель Time&Material.

ПОДРОБНЕЕ
В суд на разработчика приложения

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

Подробнее о том, как составить договор на разработку ПО, читайте в нашей статье Договор разработки бота

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

Подробнее о том, как судиться с разработчиком, — в нашей статье В суд на разработчика

Ошибка № 1: договор расплывчато описывает ожидаемый результат

Раздел «Предмет договора» должен быть максимально конкретным. Обе стороны и даже другие люди, которые будут читать договор (включая судью), должны одинаково понимать, что там написано. Хорошая практика – детальное описание характеристик приложения в техническом задании. Иначе заказчик не получит то, ради чего заключал договор (исходный код, рабочее приложение, заявленный интерфейс и т.д.).

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

Постановление Пленума ВС РФ от 23.04.2019 № 10, п. 47

Пример из судебной практики:

Арбитражный суд Московского округа, дело № А40-225970/18
Суть дела:   Заказчик и исполнитель заключили договор на услуги по внедрению программного продукта. Работы выполнены и частично оплачены. Однако заказчик подал иск на разработчика, чтоб тот передал ему исходный код программы.
Условие договора:   «1.1. Заказчик поручает и обязуется оплатить, а исполнитель принимает на себя обязательство выполнить работы по внедрению программного продукта»
Позиция суда:   Предметом договора являются работы по внедрению программного продукта, что не является эквивалентом создания исходного кода программы для ЭВМ. Внедрение ПО подразумевает процесс обследования исполнителем бизнес-процессов заказчика, выбора оптимального программного продукта, настройки программного продукта в соответствии с требованиями заказчика и подготовки обучающих инструкций по использованию.
Итог дела:   Заказчик не получил исходный код программы

Как избежать ошибки?

1. Сформулируйте предмет договора четко и понятно. Исполнитель обязан:

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

Возможно, что исполнитель должен совершить все эти действия на разных этапах.

2. Подготовьте подробное техническое задание в качестве обязательного приложения. В ТЗ пишут, например, такие требования:

  • интерфейс
  • взаимодействие с клиентом
  • функционал

Ошибка № 2: в договоре некорректно прописан порядок приема-передачи продукта

Мобильное приложение – это объект интеллектуальной собственности, программа для ЭВМ. Пользоваться им вправе только правообладатель, то есть обладатель исключительного права. У кого же по закону возникает исключительное право на приложение, созданное по договору оказания услуг, — у заказчика или исполнителя? Ответ в ст. 1296 ГК РФ: правообладателем ПО, созданного по заказу, является заказчик, если иное не предусмотрено договором.

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

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

Пример из судебной практики:

Суд по интеллектуальным правам, дело № А55-20118/2017
Суть дела:   Заказчик и исполнитель заключили договор на разработку сайта. Работа поделена на 5 этапов. Последний этап – тестирование. Каждый этап оплачивается отдельно по его завершении. После 4 этапа разработчик передал заказчику электронные ключи для тестирования сайта. Заказчику сайт не понравился. Он сам его доработал и начал использовать. А исполнитель так и не получил оплату за 5 этап. Исполнитель пошел в суд, чтоб взыскать с заказчика долг за 5 этап и компенсацию за нарушение исключительного права на сайт.
Условие договора:   «6.1. Заказчик приобретает права на Сайт и его части, после передачи Сайта по Акту приема-передачи и при отсутствии задолженности за последний этап работ».
Позиция суда:   ГК дает право сторонам договора определять по собственному усмотрению как факт, так и момент перехода исключительного права на программу от исполнителя к заказчику. При этом фактическая передача экземпляра программы не свидетельствует сама по себе о переходе исключительного права в случае, если договором между сторонами установлено иное условие. Здесь момент перехода исключительного права на сайт связан с выполнением всех 5 этапов работ и их полной оплатой.
Итог дела:   Разработчик выиграл суд. В его пользу взыскан и долг, и компенсация.

Как избежать ошибки?

1. Укажите, что приемка осуществляется по каждому этапу работ и на каждом этапе подробно опишите ожидаемый результат

2. Обозначьте, по каким каналам связи передается результат работ заказчику

3. Способ подписания акта приема-передачи, в том числе условия и последствия отказа от приемки со стороны заказчика

4. Пропишите сроки тестирования приложения, прохождения валидации и порядок устранения неполадок

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

Ошибка № 3: в договоре авторского заказа не решен вопрос о переходе исключительного права на приложение

Когда договор на разработку приложения заключается с физическим лицом, такое соглашение регулируется статьей 1288 ГК о договоре авторского заказа. Главный нюанс – исключительное право на программу возникает у автора, то есть разработчика-физлица. Для того, чтобы исключительное право перешло к заказчику нужно заключить отдельный договор отчуждения исключительного права, либо включить эти условия в договор авторского заказа. Если такого договора нет, заказчик не вправе использовать разработанное для него приложение.

Как избежать ошибки?

1. Решите вопрос о переходе исключительного права к заказчику одним из следующих способов:

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

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

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

Ошибка № 4: допустимость использования Open source

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

Очевидно, что использование Open source создает для заказчика риски:

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

Пример из судебной практики:

Суд по интеллектуальным правам, дело № А40-18422/2019
Суть дела:   Заказчик и исполнитель заключили договор на услуги по внедрению программного продукта. Заказчик обнаружил, что исходный код идентичен программе Opigno LMS, доступной неограниченному кругу лиц открыто и безвозмездно. Заказчик решил вернуть аванс, так как фактически заплатил за бесплатный Open source.
Условие договора:   «1.1. Заказчик поручает и обязуется оплатить, а исполнитель принимает на себя обязательство выполнить работы по внедрению программного продукта»
Позиция суда:   Предметом договора являются работы по внедрению программного продукта, что не является эквивалентом создания программы. В рамках выполнения дополнительного соглашения исполнителем собраны и описаны все требования к бизнес-процессам, произведен анализ существующих программных продуктов с целью найти готовый программный продукт, наиболее удовлетворяющий требованиям заказчика. На основе проведенного анализа, в качестве программного продукта было предложено использовать Opigno. Данный выбор неоднократно обсуждался, был согласован с заказчиком и отражен в рабочей спецификации.
Итог дела:   Заказчику не удалось вернуть деньги с разработчика.

Как избежать ошибки?

1. Обсудить с разработчиком необходимость использования Open source.

2. Если такой необходимости нет, зафиксируйте в договоре, что использование Open source не допускается.

3. Если свободное ПО понадобится, пропишите, что допустимо использование библиотек, распространяемых под пермиссивными лицензиями, а использование копилефт-программ запрещено.

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

Ошибка № 5: договор предусматривает оплату процесса разработки вне зависимости от достигнутого результата

Есть несколько ситуаций, когда классический договор fix price не будет отвечать потребностям заказчика. Тогда с IT-компанией подписывают договор Time&Material:

  1. сложный проект с большой командой разработчиков (от 25 человек) и длительным периодом осуществления (свыше 1 года)
  2. слишком короткие проекты (до 6 месяцев), с которыми справится команда из 5 человек
  3. договоры на обновление функционала приложения и разработку новых технических решений
  4. тесты приложения

Посмотрите на классический договор T&M с разработчиком (в данном случае он оформлен как приложение к рамочному договору на разработку приложения):

Этот пример наглядно показывает особенности договора Time&Material:

  • не сформулировано конкретное задание, а имеется лишь порядок постановки задач со стороны заказчика
  • оплата производится соразмерно затраченным часам на разработку приложения
  • определен порядок учета времени работы

Договор T&M позволяет экономить в тех проектах, где результат заранее неизвестен, равно как неизвестно, сколько времени и сил придется потратить разработчику. Заказчику приходится платить за неизвестность в модели fix price. А в договоре Time&Material нужно заплатить лишь за факт:

Акт выполненных работ по договору Time&Material

Однако в проектах, где заказчик может сформулировать конечные требования к результату и приложение не требует принципиально нового исходного кода, модель Time&Material может сыграть против заказчика. Обратите внимание на п. 4.2 в примере выше. «Все повторные итерации, доработки и исправления выполняются за счет заказчика». А также на п. 3.1: «стоимость задания определяется исходя из стоимости затраченного на его выполнение количества рабочих часов специалистов и менеджмента».

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

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

Как избежать ошибки?

1. Прежде чем заключать договор Time&Material, определите цель проекта. Попадает ли ваш проект под критерии, когда выгоднее выбрать модель TM?

2. Возможно, вас устроит цена по договору fix price, предложенная разработчиком?

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

4. Пропишите максимальное количество часов, которые может затратить разработчик по этапу и по всему проекту.

Ошибка № 6: слишком длинный перечень форс-мажоров

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

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

Арбитражный суд Московского округа, дело № А40-112940/2023
Суть дела:   Между российским заказчиком и иностранным вендором заключен договор о предоставлении услуг технической поддержки. Заказчик перечислил оплату 1 824 доллара США. С 01.04.2022 иностранный правообладатель отказался от оказания услуг технической поддержки. В этой связи заказчик потребовал вернуть аванс за услуги, которые фактически не оказаны.
Позиция суда:   Правовое основание сбережения денежных средств отсутствует, поскольку в период с 1 апреля по 31 декабря 2022 разработчик не исполнял свои обязательства по технической поддержке. Поскольку ответчиком не представлено доказательств возврата денежных средств, требование истца о взыскании неосновательного обогащения и процентов подлежит удовлетворению.
Итог дела:   Суд взыскал неосновательное обогащение в пользу заказчика.

Как избежать ошибки?

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

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

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

1. Выберите тип договора:
— договор оказания услуг/подряда
— договор авторского заказа
2. Выберите модель взаимодействия:
— fix price
— Time&Material
— fixed budget
3. Определите предмет договора и опишите требования к приложению в тех.задании
4. Поделите работу на этапы и создайте график разработки
5. Укажите цену договора, выделив в ней вознаграждение за исключительное право
6. Определите момент, с которым связан переход исключительного права. В договор авторского заказа включите обязанность разработчика заключить в будущем договор о передаче исключительного права на приложение или пропишите порядок перехода исключительного права в отдельном разделе.
7. Включите условие, что разработчику запрещено использовать чужие исходные коды. За все претензии со стороны правообладателей несет ответственность разработчик.
8. Ограничьте использование подрядчиком собственных исходных кодов, созданных не в рамках вашего договора. Иначе нельзя избежать претензий самого подрядчика, когда вы внедрите приложение в свою коммерцию.
9. Запретите разработку на основании исходных кодов, имеющихся в открытом доступе и предоставляемых по непермиссивным и копилефт лицензиям.
10. Детально пропишите раздел про приемку.
11. Не включайте в список форс-мажоров санкции
ПОДРОБНЕЕ
Договор разработки бота

В XXI веке успешные бизнес модели не могут обойтись без новейших IT-технологий. Поэтому наблюдается бум запросов на приложения, сайты, маркетплейсы и чат-боты. В этой статье расскажем, как составить договор разработки бота, чтобы виртуальный собеседник принес ожидаемый результат и заказчику не пришлось исправлять чужую работу. Наша статья будет полезна как заказчикам, так и разработчикам чат-ботов.

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

Договор разработки бота

Бот – это объект интеллектуальной собственности, программа для ЭВМ. У разработчика сразу возникают авторские и исключительные права на бот. Именно поэтому важно правильно составить договор на разработку чат-бота, чтобы заказчик смог его использовать по своему усмотрению, не нарушая при этом права автора.

Мы подготовили таблицу с различными вариантами оформления отношений с разработчиком чат-бота. Далее в статье подробно опишем преимущества и недостатки той или иной модели, а также поговорим об условиях must have.

Предмет договора

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

Исполнитель обязуется выполнить работы по созданию/ запуску/ поддержанию работоспособности/ обучению  бота, а заказчик обязуется принять и оплатить эти работы.

Требования к боту и процессу его разработки лучше вынести в Техническое задание, которое является приложением к договору. А в разделе «Предмет договора» сделайте оговорку, что чат-бот должен соответствовать техническому заданию.

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

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

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

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

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

(пункты 2 и 3 – это альтернативные условия, в договор включается только одно)

2. Исключительное право в полном объеме переходит к заказчику

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

«Исполнитель обязуется передать исключительное право на чат-бот в полном объеме Заказчику»

Разработчик может по своему желанию зарегистрировать чат-бот как программу для ЭВМ в Роспатенте. Тогда смена правообладателя подлежит обязательной государственной регистрации. Правообладателем признается лицо, указанное в Реестре программ для ЭВМ (ст. 1262 Г РФ).

3. Заказчик использует бот в объеме предоставленной лицензии

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

При определении этих пределов нужно согласовать следующие моменты:

  • территория, на которой допускается использование бота (по умолчанию, Российская Федерация)
  • срок использования, который не может превышать срок исключительного права (по умолчанию, 5 лет)
  • способы использования; лицензиат не может использовать бот способами, которые не указаны в лицензионном договоре.

Лицензионный договор бывает двух видов:

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

Лицензионный договор презюмируется не исключительным. Поэтому если хотите, чтоб больше никто не использовал уникальный чат-бот, включая заказчика, прямо пропишите, что бот предоставляются на условиях исключительной лицензии. Разумеется, за эту опцию придется доплатить.

Обязанности заказчика

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

1. Предоставлять необходимые документы по запросу исполнителя:

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

    2. Лицензионное использование возлагает на заказчика обязанность предоставлять отчеты об использовании бота в установленные сроки или по требованию лицензиара. Эту обязанность можно исключить, если прямо указать в договоре, что предоставление отчетов не требуется.

    3. Если контент чат-бота формируется заказчиком, то предусмотрите обязанность исключить материалы, противоречащие законодательству о рекламе, кибербезопасности, персональных данных, а также нарушающие авторские права.

    Обязанности исполнителя

    Важно исключить затягивание сроков и риск претензий со стороны третьих лиц. Для этого отразите в договоре обязанности исполнителя:

    1. Установите обязанность исполнителя закончить работу к определенному сроку.

    2. Исполнитель обязан использовать только те объекты интеллектуальной собственности, в отношении которых ему предоставлено согласие правообладателя, и только в объеме, согласованном с правообладателем.

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

      4. Определите гарантийный срок, в течение которого исполнитель будет за свой счет восстанавливать работоспособность бота.

      Цена договора

      Цена договора складывается из двух составляющих.

      1. Стоимость работ

      Стоимость работ исполнителя определяется по соглашению сторон. Смета не требуется.

      Она может быть фиксированной. Также часто в договорах на разработку ПО встречается оплата по модели Time&Material. Такая модель подойдет для создания новых уникальных ботов, «каких ранее свет не видывал», то есть когда нужны исследования, проверка вариантов, добавление функций по ходу пьесы, опробирование разных идей. В рамках договора T&M заказчик и исполнитель в самом договоре предельно широко формулируют представление о конечном результате, а этапы формируются в ходе исполнения договора. По каждому этапу последовательно определяется фронт работ. После выполнения этапа исполнитель предоставляет отчет, где зафиксировано, сколько часов потратили его программисты на работу. Оплата производится по количеству потраченных часов.

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

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

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

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

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

      Приемка услуг

      Детально пропишите порядок сдачи-приемки работ по разработке бота. Это повлияет на право исполнителя требовать оплату и на ее размер. Отсутствие акта приемки говорит о том, что разработчик не сделал работу.

      Договор должен отвечать на все приведенные ниже вопросы:

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

      • Акт приемки, подписанный обеими сторонами
      • Акт приемки, подписанный исполнителем, если исполнитель в установленном порядке вызвал заказчика на приемку, но заказчик на приемку не явился

      2. Когда работы считаются выполненными надлежащим образом?

      • соответствие техническому заданию
      • соответствие договору
      • соответствие требованиям платформы
      • успешное прохождение испытаний

      3. По каким каналам связи сообщается о результате и направляются приемочные документы?

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

      • электронная почта
      • мессенджер
      • корпоративные каналы
      • бумажное уведомление, направленное по конкретному адресу

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

      4. Какие сопроводительные документы должен направить исполнитель для приемки?

      • акт приемки
      • счет
      • счет-фактура
      • отчет о созданных результатах интеллектуальной деятельности
      • инструкция

      5. Как заказчику заявить о недостатках бота?

      • направление мотивированного отказа с перечнем выявленных замечаний в n-дневный срок

      Форс-мажор

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

      • отключение электроснабжения
      • отключение Интернета
      • блокировка платформы в государстве
      • неполадки у хостинг-провайдера
      • хакерские атаки

      Техническое задание

      Здесь максимально подробно описываются ожидания заказчика от чат-бота. Можно выделить следующие разделы Технического задания:

      1. Функции чат-бота:

      Для клиентаДля заказчика
      1) сообщение информации, интересующей пользователя
      2) помощь в совершении процесса
      3) отключение или подключение услуги
      4) продажиигры и квесты
      5) обучение  
      1) систематизация клиентской базы
      2) рассылки
      3) обработка заявок
      4) подписка на канал заказчика
      5) поиск клиентов
      6) поиск сотрудников
      7) прием оплаты

      2. Требования к боту

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

      3. Нормативные акты, которым должен соответствовать чат-бот

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

      4. Язык программирования

      5. Этапы работы с указанием сроков

      • Программирование сценария бота
      • Запуск бота на платформе (мессенджер, сайт, приложение, голосовой ассистент)
      • Техническая поддержка
      • Обновление

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

      ПОДРОБНЕЕ
      Договор на разработку мобильного приложения

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

      А задумывались ли Вы когда-нибудь над юридической стороной вопроса? О том, как важно и сложно составлять договор на разработку мобильного приложения? И нужно ли это вообще?

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

      Вы можете заказать нашу услугу по разработке мобильного приложения по этой ссылке.

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

      Предлагаем для начала ответить на вопрос, а для чего вообще такой договор нужен и нужен ли вообще?

      Нужен. Юристы вошли в сферу IT не как самозванцы, а как необходимое звено по пути к достижению цели.

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

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

      Когда Вы заказываете торт на День Рождения друга, то, разумеется, показываете кондитеру фотографию результата. И в случае, если цвет не тот, форма не та, Вам будет, как говорится, за что «предъявить», поскольку перед кондитером была поставлена четкая задача – сделать торт именно той формы и именно того вида, что были представлены на картинке.

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

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

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

      Итак, каким же должен быть этот договор на приложение, составленный юристом?

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

      Многие из таких рамочных договоров имеют трехступенчатую структуру, это:

      1. Заказ на проектирование – тут стороны договариваются о том, а что вообще нужно сделать, «притираются» друг к другу, формируют макет.
      2. Заказ на разработку – непосредственно создание самого приложения.
      3. Заказ на сопровождение – приложение не будет вечно функционировать само по себе, нужен контроль за его работой со стороны IT-специалиста. Конечно, лучше, чтобы результат контролировал сам создатель.

      Структура договора на создание мобильного приложения

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

      • Предмет договора

      Условие о предмете – существенное условие для любого договора. Тем не менее, здесь не стоит усердствовать и стремиться расписать все, что будет входить в обязанности программиста.

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

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

      • Материалы

      «Какие тут могут быть материалы?» — спросите Вы. Все просто: в данном договоре материал = информация.

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

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

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

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

      • Порядок сдачи-премки

      Чтобы принять продукт, он должен соответствовать установленному заказчиком заданию. В случае, если заказчик по каким-то причинам отказывается принять приложение, то этот отказ должен быть мотивирован и письменно оформлен.

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

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

      На практике нередко бывает и так, что заказчик по каким-то причинам вовсе отказывается принимать работы, без объяснения причин. Поэтому исполнителю лучше подстраховаться и включить в договор условие о том, что в случае, в течение N дней после сдачи работы, отчета и актов работ, работы считаются автоматически принятыми.

      • Интеллектуальные права

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

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

      • Конфиденциальность

      Казалось бы, кому, от кого и что скрывать. НО:

      — разработка договора на мобильное приложение с юристом и оплата труда программиста – это дорого: не особо захочется делиться результатом плодотворных работ и способом его достижения с конкурентами, согласитесь?

      — мобильное приложение – это уникальный продукт, который предназначен для оптимизации тех или иных процессов, он связан со стратегиями развития и продвижения бизнеса;

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

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

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

      • Ответственность сторон

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

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

      • Порядок оплаты и определения стоимости

      Коли уж начали говорить про шум волн, давайте и про само море.

      Существует два варианта оценки и оплаты работ:

      1. Оценивается и оплачивается сразу весь объем работ по ТЗ.
      2. Оценивается и оплачивается объем затраченных человеко-часов на выполнение каждого этапа разработки приложения.

      Второй вариант представляется наиболее удобным и часто встречающимся. Такая договорная конструкция оплаты называется Time and Material. Мы даже записывали видео на эту тему.

      Однако оба варианта имеют свои подводные камни.

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

      -> Во втором случае никто не даст гарантий заказчику в том, что все оплаченные часы действительно были отработаны, а не «накручены» себе программистами ;). Поэтому рекомендуем почитать отзывы про работу того или иного разработчика. Если увидите жалобы на то, что приходилось платить, когда еще даже не было хоть какого-то видимого результата, то, возможно, стоит задуматься.

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

      В любом случае, не стоит забывать, что в договоре:

      — у сторон должны быть равные права;

      — формулировки не должны быть двусмысленными, неоднозначными, размытыми;

      — должна быть учтена специфика бизнеса и проанализированы его основные особенности и потребности.

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

      ПОДРОБНЕЕ
      Договор на разработку мобильного приложения
      Очень просто показать, насколько это актуальной вопрос. Вспомните любую компанию, у которой вы что-то заказывали или покупали, наверняка у них есть приложение и для телефона. Работу с людьми в мобильном приложении запустили очень многие, и бизнес, и органы власти, и малые предприниматели. В этой статье мы расскажем вам про договор на разработку мобильного приложения, все аспекты его составления и дадим практические советы от юристов.

      Вы можете заказать нашу услугу по разработке мобильного приложения по этой ссылке.

      Стоит сказать, что в нашем случае мало найти просто юриста, умеющего составить договор. Нужно, чтоб специалист знал практику и понимал, как разрабатывается то или иное приложение.
      Наше преимущество в знании практики разработки мобильных приложений. Также наши юристы знают английский, и, если ваш разработчик будет не из России (или вы разрабатываете приложение зарубежной компании) — это не проблема для нас.

      Немного о самом договоре

      Можно сказать, что договор на разработку мобильного приложения — это вид договора разработки ПО. Как показывает судебная практика, договор на разработку программы заключается как договор возмездного оказания услуг, договора подряда или смешанный договор. То есть у нас есть две стороны — заказчик и разработчик. Первый создает задание на мобильное приложение и оплачивает результат. Второй создает приложение и передает заказчику.
      Особенность этого договора — это предмет, а именно мобильное приложение. Это комплексная вещь, которая разрабатывается на языке программирования специалистом. Мобильное приложение состоит, как минимум, из трех компонентов: -дизайн — код — аналитика данных. Исходя из этого мы и будем составлять наш договор. Отличие от обычного договора на разработку ПО, то, что мобильное приложение должно поддерживаться на Android, IOS, Windows phone (последнее не всегда). Это мы и будем указывать в будущем в техническом задании.

      Этапы создания мобильного приложения

      Многие заказчики начинают поиск разработчика с составления брифа о себе и своей компании — это короткое описание на 1-2 листах данных о вас, о том, какое приложение вам нужно, какие сроки и вообще любой нужный вам вопрос.  Бриф обычно заменяет долгие встречи и собеседования с разработчиками.
      Изображение взято с платформы SMMplanner
      Как правило, мобильное приложение создается в несколько этапов.
          1. Проект приложения;
          1. Проект дизайна;
          1. Создание дизайна;
          1. Создание приложения (программирование);
          1. Проверочные испытания;
          1. Запуск приложения. (Помним, что приложение еще должно разместиться в App store или Google play и скачиваться без ошибок).
        Этот вопрос мы указываем в техническом задании. То, что несколько этапов и по итогам каждого стороны подписывают акт.

        Как составить договор на разработку мобильного приложения

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

        Предмет договора

        Предмет в нашем договоре необычный, это не вещь, которую можно потрогать. Это приложение, то есть комплексное программа для мобильных устройств. В пункте о предмете договора мы только указываем, что:
            • Была достигнута согласованность о том, что Поставщик принимает на себя обязательства перед Клиентом по [разработке мобильного приложения Системы].
            • Само приложение мы будет описывать в техническом задании немного позже.

          Цена договора

          Здесь вы должны решить, как будете оплачивать труд разработчиков. Есть несколько вариантов:
              1. Фиксированная цена;
              1. Договор time and material (в этом случае заказчик платит за количество часов и потраченного времени);
              1. Фиксированная цена и проценты.
            https://www.youtube.com/watch?v=Bofe67-RO6c
            Помним, что разработка приложения это несколько этапов. Об этом мы писали выше. Обычно договор time and material выгоднее разработчикам, а фиксированный заказчику. Также договор time and material вполне подойдет для приема этапов мобильного приложения. И если разработчик почему-то не закончит работу, то вы уже оплатите сделанное и никаких претензий не возникнет. Вы можете выбрать любой из вариантов и согласовать с разработчиком. Юристы же просто помогут вам правильно составить такой договор.

            Прием и передача мобильного приложения

            Здесь все также имеет особенности, потому что этапов разработки несколько. Каждый этап — это труд айтишника, вы должны оценить его, сделать свои пометки или попросить что-то исправить, если надо. В сфере IT такие этапы еще называются спринты.

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

            Давайте на примере. Мы прошли этапы дизайна приложения и теперь разработчик должен начать программировать. Мы указываем в договоре, что разработчик имеет 30 дней с момента подписания акта и полной оплаты по этапу. Вы можете сами выбрать сроки, здесь важно помнить несколько моментов:
                1. Каждый этап заканчивается подписанием акта-приема передачи;
                1. Каждый этап оплачивается, если вы выбрали договор time and material;
                1. Отказ от приема этапа тоже должен быть мотивированным;
                1. Допускается исправления или доработка приложения на этапах. (приложение может получиться не с первого раза написания кода. Поэтому надо согласовать с разработчиком как будут исправляться ошибки и кто за это заплатит).
              Также важно помнить и про приемочные испытания. Мы платим деньги специалистам, а значит должны быть уверены, что приложение будет работать без ошибок. Во время испытаний приложение тестируется. Если программа не пройдет приемное испытание, то в договоре указываем, что IT специалисты даются разумные время и средства для внесения изменений в программу. Все расходы по исправлениям может нести разработчик.

              Авторские права

              В договоре также нужно решить у кого будут исключительные права на мобильное приложение. Здесь есть два варианта. Права на программу 1) у разработчика или 2) у заказчика. По закону автор приложения может пользоваться им на безвозмездной основе. Для этого необходимо составить лицензионное соглашение. В этом случае само исключительное будет у заказчика. Во втором варианте исключительное право будет у разработчика. А вы уже будете использовать приложение по лицензионному соглашению. Предоставить лицензию можно дополнением к договору. Стороны подписывают договор, значит соглашаются на такой порядок работы. Стоит отметить, что пока заказчик не примет программу и не оплатит работу, программист не может пользоваться программой.

              Гарантии разработчика

              Мы уже говорили, что приложение, написанное на языке программирования сложная вещь. Даже после всех тестов и испытаний могут возникнуть ошибки. Например, у клиентов может что-то не работать через время или не будет совместимости с новой версией IOS или Android. Поэтому нам важно установить гарантийный срок в договоре и обязать разработчика устранять ошибки приложения. Если же они, конечно, возникли по его вине. Существует установленный законом срок — 2 года. Однако, вы можете договориться с разработчиком уменьшить или увеличить срок. Лучше, конечно, увеличить, это в ваших интересах.

              Техническое задание

              Техническое задание — одна из самых важных частей нашего соглашения. В нем мы рассказываем разработчику, какое приложение нам нужно. Кроме того, техническое задание должно содержать требования к приложению:
                  1. Область применения (Например приложение должно принимать заказы клиентов по доставке еды);
                  1. Требования к обеспечению надежного (устойчивого) функционирования приложения (без вылетов, багов и так далее) ;
                  1. Требования к исходным кодам и языкам программирования;
                  1. Требования к программной совместимости (Android, IOS);
                  1. Требования к защите информации и программ (безопасность и
                  1. конфиденциальности, закон о защите персональных данных);
                  1.  Требования к документации приложения.
                CMS — это система управления контентом. Эта система даст вам возможность самим менять контент приложения без помощи разработчика. Вы также можете в техническом задание про эту систему, и чтобы мобильное приложение работало с CMS системой.

                Еще несколько условий договор

                Помним про конфиденциальность. Стороны не могут разглашать данные вашего договора, переписку и другую информацию. Также многие мобильные приложения работают с персональными данными пользователей. А это означает что:
                    1. Приложение должно спрашивать разрешение у клиента на обработку персональных данных;
                    1. Если разработчик работает с данными клиентов, то он не имеет права их распространять.
                  Также важна и ответственность сторон. Здесь важно помнить несколько моментов:
                      1. Ответственность должна дисциплинировать, а не обременять;
                      1. Ответственность должна быть справедливой и направлена к обеим сторонам договора;
                      1. Ответственность может быть не только по нарушениям сроком. Это также может быть некачественная работа, нарушение авторских прав, нарушение конфиденциальности;
                      1. Если случился форс-мажор сторона освобождается от ответственности (стихийное бедствие, война и так далее.
                    Не забываем про реквизиты сторон, порядок расторжения и изменения договора, применимое право и место для подписей.

                    Вывод

                    Главный вывод этой статьи — это то, что каждое мобильное приложение индивидуально. Оно может иметь разные функции, разные этапы и порядок разработки. Именно поэтому каждый договор должен подстраиваться под ваш индивидуальный заказ. Обычный юрист может не понимать специфику этого договора, нужен именно специалист, знающий практику.
                    ПОДРОБНЕЕ