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

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

Чем качественнее договор, тем меньше вероятность оказаться в суде по спору с разработчиком.

Виды договоров с разработчиками ПО:

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

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

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

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

>>> Как выиграть спор о признании договора трудовым?

  1. Договор Time&Material.

По своей сути, договор T&M – разновидность договора оказания услуг. Почвой для появления этого особого договора послужили проекты в сфере IT, для которых на начальном этапе невозможно определить точный перечень задач. В целом, выделяют четыре случая, когда договор Time&Material будет оптимальной моделью для работы над программным обеспечением: 1) проект направлен на испытание программы, 2) договор заключается с целью обновления ПО на постоянной основе, 3) мини-проекты, рассчитанные на команду из 2 – 5 человек, со сроком выполнения до полугода, 4) напротив, проекты-гиганты, рассчитанные на команду минимум из 25 человек, со сроком выполнения более года.

Такой договор позволяет максимально пространно сформулировать основную обязанность разработчика: «исполнитель обязуется разработать программное обеспечение для системы». Конкретные задачи формулируются в спецификации, которая подлежит периодической актуализации (сроки актуализации фиксируются в контракте). Возможность актуализации задач делает невозможным зафиксировать твердую цену, поэтому соглашение Time&Material – это договор с почасовой оплатой; заранее определяется только стоимость часа и максимальное количество часов для выполнения задачи из спецификации.

>>> Заказать разработку договора Time&Material

  1. Договор подряда.

От услуг этот договор отличается наличием овеществленного результата. В сфере IT обнаружить овеществленный результат крайне трудно. Максимум –  информационный носитель. Но очевидно, что сама по себе флешка или диск не представляют ценности для заказчика. Однако и стороны, и суды используют «подрядные» формулировки. Это абсолютно правомерно, так как закон прямо допускает смешанные договоры (услуги + подряд). Если это делает отношения сторон более понятными, почему нет?

  1. Лицензионный договор.

Данный договор регулирует вопросы передачи исключительного (интеллектуального) права на ПО. Сама программа разрабатывается по вышеперечисленным соглашениям. В некоторых случаях договор на услуги и лицензионный договор идут в связке. Например, в деле № А40-45539/2013 IT-компания разрешила использовать свое ПО заказчику по лицензионному договору, а также обязалась внедрить это ПО в систему заказчика. Суды квалифицировали эту связку как договор на разработку нового ПО путем переработки исходного. Важный вывод из этого дела: передача прав на продукт по лицензии не считается состоявшейся без передачи самого продукта. Поэтому заказчику удалось взыскать с разработчика аванс.

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

На практике встречаются различные названия договоров на разработку ПО, даже сам их текст иногда не содержит слово «услуги» (к примеру, «договор на внедрение информационной системы»). Но все они по своей сути, квалифицируются как договоры возмездного оказания услуг (гл. 39 ГК РФ) или подряда (гл. 37 ГК РФ). Например, Арбитражный суд г. Москвы рассматривал спор из договора, по которому «продавец обязуется передать в собственность Комплект Системы, а также право на пользование сервисом «Горячая Линия», а Покупатель обязуется принять этот Комплект Системы и оплатить в соответствии с условиями настоящего Договора». Суд подчеркнул, что собственность – это последнее, что могут придумать заказчик разработчик; договор на самом деле представляет собой договор на информационные услуги.

Если стороны не потрудились заключить письменный договор, то их будущие отношения по поводу создания программы будут регулироваться непосредственно Гражданским кодексом РФ. А если соглашение подписано, то положения Гражданского кодекса будут применяться к вашим отношениям только в той части, в которой они не урегулированы договором. В силу прямой нормы закона к услугам применяются правила о подряде (ст. 702 – 729, ст. 779- 782 ГК РФ). Если по какой-то причине заказчик и разработчик не заключают письменный договор, они должны иметь в виду, что закон допускает немотивированный отказ от договора услуг как со стороны заказчика, так и со стороны разработчика. Договором нельзя лишить этого права, но можно регламентировать порядок и сроки отказа, определить размер убытков за отказ от контракта. Закон также предполагает личное исполнение договора разработчиком; в то время как на практике используются договоры с правом привлечения субисполнителей. Кроме того, закон закрепляет обязанность заказчика предоставить всю необходимую документацию для создания ПО. В данном случае формулировка «вся необходимая информация» является крайне неопределенной, а разработчик может воспользоваться ей, чтоб максимальной продлить срок выполнения заказа. В договоре можно прямо перечислить, какие сведения понадобятся заказчику, тем самым исключить подобные риски.

Акт приемки

При избрании любого договора фактическое выполнение задания подтверждается отдельным документом – акт приемки. Заказчик подписывает этот важнейший документ только в том случае, если его полностью устраивает программа. Если в ПО есть недочеты, то акт возвращается разработчику неподписанным вместе с письмом, где изложен мотивированный отказ от подписания акта. Неправильный вариант действий со стороны заказчика: проигнорировать акт, то есть не направить мотивированный отказ от подписания. Обычно в договоры включается пункт по поводу последствий неподписания акта, например: «если по истечении N дней от заказчика не поступило мотивированного отказа от подписания акта, услуги считаются оказанными в полном объёме с надлежащим качеством». Даже если такой пункт не включен в договор, суды придерживаются того же мнения: бывает достаточно доказать, что акт направлен заказчику по правильному адресу.

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

Однако даже при наличии подписанного акта заказчик может доказывать суду, что услуги оказаны в меньшем объеме, чем зафиксировано в акте (п. 12 Информационного письма ВАС № 51 от 24.01.2000).

Претензия к разработчику

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

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

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

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

Отказ от договора с разработчиком

Договор оказания услуг дает право любой стороне на безусловный и немотивированный отказ от его исполнения. Единственное условие – другой стороне возмещаются все ее затраты на исполнение договора. Закон запрещает включать в такие договоры условия о недопустимости одностороннего отказа или устанавливать штраф за отказ. Но допускается устанавливать в договоре денежную компенсацию за отказ (п. 3 ст. 310 ГК РФ).

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

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

Иски разработчиков и заказчиков: вариации судебных споров

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

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

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

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

  1. Активная позиция заказчика

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

На случай пассивного поведения стороны в АПК РФ есть п. 3.1 ст.70: если одна сторона ссылается на определенные факты, а вторая сторона ничего не высказывает против этих фактов, то они считаются признанными.

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

Иначе получится, как в деле № А07-4176/2019. Разработчик вышел с иском об оплате  лендинга для сайта. В качестве доказательства выполненных работ он представил неподписанный заказчиком акт, который однако последним получен. Заказчик не явился ни в одно судебное заседание и даже не потрудился написать коротенький отзыв. В результате суд полностью удовлетворил иск программистов, расценив процессуальное бездействие заказчика как признание обстоятельств дела.

  1. Настаивайте на экспертизе некачественного ПО

Экспертиза – почти единственный способ отыскать правду, так как судьи и представители – это правоведы, а не специалисты в сфере IT.

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

>>> Как составить качественное ходатайство об экспертизе в арбитраж?

Ходатайство нужно заявлять своевременно и в соответствии со всеми процессуальными требованиями. Иначе в его удовлетворении могут отказать, сочтя позднее заявление ходатайства, да еще и без согласия эксперта и  внесения денег на депозит, затягиванием судебного процесса (дело № А47-17870/2019).

Для начала нужно определить, какие вопросы задать эксперту. Вопросы должны касаться сути спора, то есть качества ПО. В то же время, нельзя ставить перед экспертом вопросы права, к примеру «оказал ли разработчик услуги надлежащим образом?».

Примеры вопросов можно увидеть в деле № А57-4773/2020, которое разрешилось в пользу заказчика благодаря экспертному заключению:

– Установить, пригоден ли для использования по назначению в соответствии с условиями договора и техническим заданием функционал программного продукта?

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

– Каковы объем и стоимость качественно выполненных разработчиком  работ в соответствии с условиями договора?

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

В деле № А40-91171/2015 исход тоже определила экспертиза. Разработчик вплоть до кассации пытался оправдать свои разработки по двум этапам и просил заплатить хотя бы за них. Но эксперт заключил, что объем выполненных работ лишь 23,4%, но программное обеспечение не способно корректно выполнять операции. Поэтому внесенный заказчиком аванс был полностью ему возвращен.

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

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

В деле № А40-121450/2016 суды неправильно истолковали договор на разработку сайта и пришли к неверному выводу о необходимости оплаты каждого этапа. Московская кассация отправила дело на пересмотр, обязав суды провести экспертизу по делу, чтобы установить, имеет ли часть работ потребительскую ценность для заказчика. Другими словами, можно ли использовать результат выполненных исполнителем работ вне результата работ, на достижение которого был направлен договор в целом. К слову, это дело завершилось победой разработчика тоже благодаря экспертизе, которая установила, что эскизы страниц, дизайн-макеты и верстка сайта могут быть использованы заказчиком, хотя только с привлечение другого IT-специалиста.

  1. Используйте нестандартные доказательства.

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

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

Можно заявить об обеспечении доказательств судом (ст. 72 АПК РФ). Это требуется в тех случаях, когда контрагент после подачи иска в суд может внести изменения в программу или удалить ее. Суд своим определением запрещает разработчику совершать такие действия. Если запрет будет нарушен, то это будет расцениваться против разработчика.

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