Договор на разработку мобильного приложения
Стоимость услуги: 25 000 рублей.
Срок исполнения услуги: 3 рабочих дня.
Стоимость услуги, срок исполнения зависят от объема представленных документов и сведений.
Что включает в себя услуга по разработке договора на обслуживание компьютеров:
- изучение ситуации и документов;
- подготовка договора на разработку мобильного приложения;
- передача договора на разработку мобильного приложения;
- отчет перед клиентом.
Какие документы необходимы от Вас для оказания услуги:
- документы и сведения, регулирующие правоотношения;
- реквизиты сторон договора;
- юридические и экономические условия договора.
Что нужно сделать, чтобы заказать услугу:
Позвонить нам по телефону, указанному на сайте, а лучше написать на наш адрес электронной почты, описать Вашу потребность и сложившуюся ситуацию, и мы ответим Вам в течение 10 минут, либо просто кликнув кнопку заказать.
Стоимость услуги
25 000 рублей
Статьи по теме
- Договор разработки мобильного приложения с точки зрения ГК РФ
- Стороны договора
- Раздел 1 «Предмет договора»
- Раздел 2 «Исключительное право»
- Раздел 3 «Сроки»
- Раздел 4 «Приемка услуг»
- Раздел 5 «Цена и порядок оплаты»
- Раздел 6 «Права и обязанности сторон»
- Раздел 7 «Ответственности сторон»
- Раздел 8 «Порядок изменения и расторжения»
- Раздел 9 «Форс-мажор»
- Раздел 10 «Разрешение споров»
- Раздел 11 «Заключительные положения»
В чем секрет успеха в 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 лет.
У лицензионного договора есть минус. Разработчик может еще раз продать свою разработку, и на рынке появится конкурент с таким же приложением. Чтобы этого не произошло договор нужно подписывать на условиях исключительной лицензии. В такой конструкции исполнителю запрещается разглашать исходный код кому бы то ни было.
Гарантии «чистоты» исключительного права
Для договоров разработки крайне важно, чтобы разработчик гарантировал «чистоту» интеллектуальной собственности. Иначе правообладатель запретит использование приложения по мотиву нарушения исключительных прав. Разработчик должен гарантировать:
- разработанное приложение не нарушает исключительные права третьих лиц
- при разработке приложения не использовались «вирусные» лицензии
- исполнитель не использовал собственные разработки, выполненные в рамках других проектов
Раздел 3 «Сроки»
Фиксация сроков позволит защитить заказчика от растягивания проекта.
Начальный срок обычно связывают с датой подписания договора. При этом, исполнители настаивают на включении в договор условия о переносе сроков, если заказчик не передает необходимую документацию. Исключить переносы можно следующим способом. В техническом задании приведите весь перечень исходной документации. В сам договор включите такое условие: «Подписанием договора Подрядчик подтверждает, что исходных данных, указанных в Техническом задании, достаточно для оказания услуг».
Конечный срок крайне важно прописать прямо в контракте: указание конкретной даты или периода, в течение которого должна быть завершена разработка.
Промежуточные сроки фиксируются в отдельном приложении – график (при необходимости). Промежуточные сроки выделяют этапы разработки. За их нарушение договором также предусматривается ответственность.
Однако есть проекты, для которых оптимально выбрать модель Time&Material:
- разработка уникального приложения с нетипичными бизнес-процессами
- масштабные проекты с IT-компаниями (привлекаются минимум 25 разработчиков) на долгосрочную перспективу
- мини-проекты на пол года (команда из 5 программистов и тестировщиков)
- добавление в приложение новых функций, которые пока слабо очерчены в запросе потребителя, но помогут превзойти конкурентов
- тестирование приложений
Договор T&M предполагает оплату не за результат, а за часы работы программистов. Причина – нет сроков завершения проектов, никто не знает, когда разработчики сгенерируют тот самый исходный код. В перечисленных выше проектах Time&Material выгоден для заказчика. Вспомним фильм «Безос. Человек, создавший Amazon». Два программиста круглыми сутками создавали сайт по продаже книг, не имевший аналогов в то время. Если бы это были сторонние разработчики, идеально бы подошел договор Time&Material. Но если заказчику нужно стандартное приложение точно в срок, лучше остановиться на модели fix price с указанием начального и конечного срока.
Пример договора Time&Material из устной консультации Дело чести:
Раздел 4 «Приемка услуг»
Раздел о приемке крайне важен обеим сторонам. Для исполнителя приемка подтвердит право на оплату услуг. А для заказчика приемка обозначит переход исключительного права на приложение.
В договоре следует прописать, что приемка знаменует собой переход исключительного права к заказчику. Хотя этот момент перехода можно привязать к другим фактам, например, оплата услуг.
Обратите внимание на дело № А55-20118/2017. В нем стороны связали переход исключительного права с подписанием акта приема-передачи и полной оплатой. Супер-выгодно для разработчика. А заказчик в итоге оказался без приложения, за которое почти полностью заплатил (и доплатил по суду). Это произошло из-за того, что заказчик увидел на последнем этапе тестирования шероховатости в продукте (речь идет о сайте) и вместо направления мотивированного отказа от приемки сам стал вносить изменения. Это неверная стратегия, из-за которой заказчик проиграл суд. Он должен был сообщить разработчику о неполадках и потребовать их устранения. После этого сторонам следовало подписать приемочный акт.
Что предусмотреть в договоре для сдачи-приемки приложения?
Акт приемки. Он должен подписываться обеими сторонами. Но нужно предусмотреть ситуацию, когда заказчик отказывается от приемки и не подписывает акт. Например, включите формулировку, что услуги считаются выполненными надлежащим образом, если заказчик в установленный срок не возвратил подписанный со своей стороны акт и не направил мотивированный отказ.
Поэтапная приемка. Договор разработки мобильного приложения может быть разбит на этапы. Особенно поэтапная работа характерна для Time&Material. В договоре требуется указать ожидаемый результат по каждому этапу. Закрытие этапа подтверждается промежуточным актом приемки.
Критерии качества. Определите, когда услуги по разработке приложения оказаны надлежащим образом: а) соответствие условиям договора, техническому заданию, б) соблюдение требований законодательства, в) успешный запуск на платформе.
Мотивированный отказ. Полезно прописать перечень ситуаций, когда заказчику позволено отказаться от приемки и потребовать доработку приложения: несоответствие качеству, провал тестирования, непрохождение валидации.
Обмен актами. Укажите, куда нужно направить акт приемки (электронная почта, мессенджер, корпоративные каналы, бумажный акт по почте России).
Сопроводительная документация. Для бухгалтерии и сотрудников будет недостаточно только акта приемки. Дополнительно пропишите обязанность исполнителя направить счет, счет-фактуру (при применении НДС), перечень результатов интеллектуальной деятельности, инструкцию.
Раздел 5 «Цена и порядок оплаты»
Цена в обязательном порядке должна содержать два компонента:
- стоимость услуг
- вознаграждение за исключительное право
Для фиксации порядка расчетов нужно указать следующие пункты:
- сроки оплаты
- допустимость авансирование
- валюта платежа
- первичные документы (акты, счета)
Раздел 6 «Права и обязанности сторон»
Договор должен строиться на принципе корреспондирующих прав и обязанностей. Другими словами, для реализации права одной стороны должна быть предусмотрена обязанность другой. Поэтому чтобы не повторяться, формулируют обязанности сторон, а на правах акцент не делают.
Основные обязанности сторон по договору на разработку приложения | |
Обязанности исполнителя 1. Оказать услуги качественно и в срок 2. Оказать услуги в объеме ТЗ 3. Обеспечить «чистоту» исключительного права 4. По требованию Заказчика предоставлять информацию о ходе разработки | Обязанности заказчика 1. Передать необходимую информацию 2. Принять результат работ 3. Оплатить услуги исполнителя |
Раздел 7 «Ответственности сторон»
Еще один принцип: каждая обязанность обеспечивается ответственностью. Здесь стороны вольны определять сами, кто и за что ответит рублем.
Наиболее распространенный вид договорной ответственности – неустойка. Она позволяет потерпевшей стороне не доказывать убытки, а в упрощенном порядке компенсировать свой ущерб.
Виды неустоек:
Раздел 8 «Порядок изменения и расторжения»
Обычно, прописывают 3 варианта прекращения контракта на разработку приложения:
1. По соглашению сторон
2. Расторжение в суде из-за нарушения
3. Односторонний отказ:
Договор разработки ПО, являясь по своей сути договором оказания услуг, дает как заказчику, так и исполнителю в одностороннем внесудебном порядке отказаться от дальнейшего сотрудничества (ст. 782 ГК РФ)
Односторонний отказ по договору оказания услуг может быть не мотивирован и осуществляется исключительно по усмотрению стороны
Отказавшийся заказчик должен оплатить исполнителю фактические расходы. А исполнитель, инициировавший разрыв соглашения, обязан полностью возместить убытки заказчика. В договоре нужно прописать порядок уведомления и дату, с которой договор считается прекратившимся.
Раздел 9 «Форс-мажор»
Назначение раздела – освободить стороны от обязательств по договору, когда наступили чрезвычайные обстоятельства вне власти контрагентов. Важное условие: эти обстоятельства должны создавать непреодолимое препятствие для продолжения проекта.
Этот раздел должен содержать:
- Перечень обстоятельств непреодолимой силы. Примеры: пожар, наводнения, землетрясения, иные стихийные бедствия, военные действия, санкции, блокировка платформы в государстве, неполадки у хостинг-провайдера, хакерские атаки.
- Порядок фиксации форс-мажора. Например, справка торгово-промышленной палаты, комиссии по чрезвычайным ситуациям.
- Алгоритм действия сторон. Можно продлить срок договора, изменить другие условия либо подписать соглашение о расторжении.
Раздел 10 «Разрешение споров»
Во-первых, раздел определяет порядок направления претензии и срок ответа. До истечения этого срока сторона не вправе пойти в суд.
Во-вторых, здесь определяется суд, где будет рассматриваться спор заказчика и исполнителя. Если суд не выбран, дело рассмотрят по месту жительства ответчика.
Стороны вправе передать свой спор также в третейский суд. В этом случае следует внимательней отнестись к фиксации арбитражной оговорки. Учитывая, что договор разработки приложения часто заключается с иностранными IT-компаниями, передача спора в негосударственный суд может быть очень актуальной. Президент поручил ТПП до 01.12.2024 разработать рекомендации для предпринимателей по включению в контракты оговорки о передаче дела в МКАС при ТПП:
Раздел 11 «Заключительные положения»
Этот раздел носит технический характер и содержит информацию о вступлении договора в силу, адресах, реквизитах сторон, порядке направления уведомлений, а также включает перечень приложений.
- Ошибка № 1: договор расплывчато описывает ожидаемый результат
- Ошибка № 2: в договоре некорректно прописан порядок приема-передачи продукта
- Ошибка № 3: в договоре авторского заказа не решен вопрос о переходе исключительного права на приложение
- Ошибка № 4: допустимость использования Open source
- Ошибка № 5: договор предусматривает оплату процесса разработки вне зависимости от достигнутого результата
- Ошибка № 6: слишком длинный перечень форс-мажоров
- Памятка по договору на разработку приложения
Не всегда заказчики получают мобильное приложение, которое они хотели получить, заключая договор на разработку с 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 создает для заказчика риски:
- использование приложения может быть заблокировано, если оно не соответствует условиям непермессивной лицензии
- заказчику придется сделать исходный код заказанной программы общедоступным, если использовалась копилефт-программа
Пример из судебной практики:
Суд по интеллектуальным правам, дело № А40-18422/2019 |
Суть дела: Заказчик и исполнитель заключили договор на услуги по внедрению программного продукта. Заказчик обнаружил, что исходный код идентичен программе Opigno LMS, доступной неограниченному кругу лиц открыто и безвозмездно. Заказчик решил вернуть аванс, так как фактически заплатил за бесплатный Open source. |
Условие договора: «1.1. Заказчик поручает и обязуется оплатить, а исполнитель принимает на себя обязательство выполнить работы по внедрению программного продукта» |
Позиция суда: Предметом договора являются работы по внедрению программного продукта, что не является эквивалентом создания программы. В рамках выполнения дополнительного соглашения исполнителем собраны и описаны все требования к бизнес-процессам, произведен анализ существующих программных продуктов с целью найти готовый программный продукт, наиболее удовлетворяющий требованиям заказчика. На основе проведенного анализа, в качестве программного продукта было предложено использовать Opigno. Данный выбор неоднократно обсуждался, был согласован с заказчиком и отражен в рабочей спецификации. |
Итог дела: Заказчику не удалось вернуть деньги с разработчика. |
Как избежать ошибки?
1. Обсудить с разработчиком необходимость использования Open source.
2. Если такой необходимости нет, зафиксируйте в договоре, что использование Open source не допускается.
3. Если свободное ПО понадобится, пропишите, что допустимо использование библиотек, распространяемых под пермиссивными лицензиями, а использование копилефт-программ запрещено.
Ниже пример, как правильно сформулировать условия договора о переходе исключительного права на приложение. Обратите внимание, что прописана обязанность разработчика передать исключительное право, определен момент его перехода, а также решен вопрос с вознаграждением.
Ошибка № 5: договор предусматривает оплату процесса разработки вне зависимости от достигнутого результата
Есть несколько ситуаций, когда классический договор fix price не будет отвечать потребностям заказчика. Тогда с IT-компанией подписывают договор Time&Material:
- сложный проект с большой командой разработчиков (от 25 человек) и длительным периодом осуществления (свыше 1 года)
- слишком короткие проекты (до 6 месяцев), с которыми справится команда из 5 человек
- договоры на обновление функционала приложения и разработку новых технических решений
- тесты приложения
Посмотрите на классический договор T&M с разработчиком (в данном случае он оформлен как приложение к рамочному договору на разработку приложения):
Этот пример наглядно показывает особенности договора Time&Material:
- не сформулировано конкретное задание, а имеется лишь порядок постановки задач со стороны заказчика
- оплата производится соразмерно затраченным часам на разработку приложения
- определен порядок учета времени работы
Договор T&M позволяет экономить в тех проектах, где результат заранее неизвестен, равно как неизвестно, сколько времени и сил придется потратить разработчику. Заказчику приходится платить за неизвестность в модели fix price. А в договоре 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. Не включайте в список форс-мажоров санкции |