Не всегда заказчики получают мобильное приложение, которое они хотели получить, заключая договор на разработку с 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. Не включайте в список форс-мажоров санкции