О чём договариваться с разработчиком?

О чём договариваться с разработчиком?

О чём договариваться с разработчиком?

О чём договариваться с разработчиком?

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


Сайт и мобильное приложение: правовая характеристика

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

И сайт, и мобильное приложение - это охраняемые результаты интеллектуальной деятельности. Сайт является составным объектом авторского права. Это означает, что охраняется и программа, на основе которой создан сайт, и контент сайта (дизайн, изображения, текст). На мобильные приложения распространяется схожий правовой режим - это и программа для ЭВМ, и элементы дизайна с контентом.

Ядро договора на разработку сайта или приложения

На практике заказчик и разработчик зачастую заключают “договоры подряда на создание сайта” или “договоры оказания услуг по разработке приложения”. Действительно, в ряде случаев элементы этих договоров задействованы. Например, в случаях, когда заказчика интересует не только разработка и верстка дизайн-макета сайта или приложения, но и технические характеристики (к примеру, требования к движку сайта, внедрение криптозащиты, обеспечение единообразного отображения во всех веб-браузерах), а также предоставление дополнительных услуг (тестирование и последующая доработка, SEO продвижение).

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

Как заключают договор с разработчиком: сканы и переписка

Договор на разработку сайтов и приложений зачастую заключается в электронной форме: путём обмена сканами документов и путем обмена сообщениями.

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

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

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

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

Если же договор заключается без обмена скан-копиями, просто в электронной переписке, то стороны находятся в еще более уязвимом положении. Суды крайне критически относятся к заключению договора на разработку сайта конклюдентными действиями. К примеру, в Московском городском суде в 2018 году рассматривалось дело, в котором заказчик сайта вёл электронную переписку с разработчиком, внес аванс за оплату доменного имени, а также получил доступ к частично выполненному сайту. Однако у сторон возникли разногласия о дальнейших взаимоотношениях между ними, о судьбе сайта. Заказчик пытался в судебном порядке доказать, что между сторонами фактически сложились договорные отношения по исполнению договора на разработку сайта. Тем не менее, суд отказал в удовлетворении иска, мотивируя свое решение тем, что “предоставленная истцом в качестве подтверждения согласования условий договора подряда переписка представляет собой свободный текст, не имеющий отсылки к источнику опубликования, с которого данный текст был распечатан, не содержит какого-либо заверения, что не исключает произвольное внесение в него изменений и, следовательно, не может быть признано относимым и допустимым доказательством по настоящему делу”. Суд также отметил, что “предоставленные истцом чеки по операциям с его карты не подтверждают оплаты истцом именно в пользу ответчика денежных средств по договору подряда”.

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

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


Условия договоров с разработчиками

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

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

С точки зрения заказчика, в большинстве случаев наилучшим вариантом будет структурировать сделку таким образом, чтобы исключительные права на сайт автоматически переходили ему. Ведь только в таком случае заказчик сможет в полной мере использовать свой сайт и свободно распоряжаться им. Тем не менее, с точки зрения разработчика, наоборот, зачастую существует заинтересованность не передавать заказчику исключительные права на сайт или приложение, а лишь предоставить права использования. Например, в случаях, если реализуется «коробочный» продукт, который перепродается сразу нескольким заказчикам с незначительными изменениями и производством технических работ по настройке. Кроме того, компания-разработчик в ряде случаев просто не может позволить себе полностью передать исключительные права на сайт или приложение заказчику, так как такое действие в последующем «заблокирует» весь бизнес компании, в основе которого лежит определённая программа для ЭВМ и ряд дизайнерских решений. Таким образом, разработчики обычно предпочитают передачу прав на использование конечного продукта (сайта или приложения) на основе лицензии.

Зачастую в результате столкновения интересов заказчика и разработчика в этой части фактически возникает dead-lock, препятствующий заключению договора. Варианты его преодоления зависят от конкретных фактических обстоятельств, силы переговорных позиций сторон. Но в любом случае стоит помнить, что правовые механизмы могут позволить сторонам найти компромисс и прийти к взаимовыгодному соглашению. В ряде случаев достаточно будет включать в договор условия о передаче заказчику только прав на конкретный индивидуализированный объект, созданный по договору, с сохранением исключительного права на “коробочные” решения за разработчиком. Также возможно использовать конструкцию совместного обладания исключительными правами, которая позволяет как разработчику, так и заказчику являться правообладателями тех или иных IT-разработок и совместно распоряжаться ими. Ещё более эффективным будет данный вариант в случае, если рассматриваемый ныне законопроект о возможности выделения долей в исключительном праве.

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

Например, в деле, рассмотренном Судом по интеллектуальным правам в 2018 году, разработчик-истец доказывает нарушение его исключительных прав на сайт, созданный и переданный заказчику. Обосновывает свои требования разработчик тем, что заказчик оплатил только ⅘ от суммы, а в договоре между сторонами прописано, что исключительные права на сайт переходят заказчику в момент их полной оплаты. Суды первой и апелляционной инстанции отказали в иске, ссылаясь на использование истцом ненадлежащего способа защиты нарушенного права (компенсация за нарушение исключительных прав, а не требование оплаты выполненной работы в полном объеме при доказанности выполнения работ по пятому этапу). Однако СИП отправил дело на новое рассмотрение, отметив, что ГК РФ содержит диспозитивные нормы, предоставляет сторонам договора самим определять момент перехода исключительного права. Кроме того, СИП указал, что фактическая передача экземпляра произведения не свидетельствует сама по себе о переходе исключительного права в случае, если договором между сторонами установлено иное условие. Рассматривая дело повторно, суд первой инстанции удовлетворил исковые требования разработчика. На настоящий момент подана апелляционная жалоба, окончательное разрешение спора только ожидается. Данный кейс наглядно показывает, что важно учитывать, как согласован момент перехода исключительных прав в договоре. Интересам разработчика отлично соответствует привязка такого перехода к моменту полной оплаты, в то же время для заказчика включение такого условия в договор более чем рискованно.

Чистота прав

При заключении договоров на разработку сайтов или приложений сторонам необходимо удостовериться, что контрагент обладает всеми правами как на конечный продукт, так и на отдельные объекты, используемые при его разработке. Для заказчика хорошим вариантом является включение в договор соответствующих гарантий со стороны разработчика и соответствующих санкций за нарушения гарантий “чистоты прав”. Разработчику (особенно если речь идёт об организации), в свою очередь, требуется обеспечить реальное наличие у него исключительных прав на все объекты ИС, создаваемые работниками и/или третьими лицами, то есть заключить соответствующие договоры с каждым из них, да и в целом, наладить систему управления ИС в компании.

Ответственность за нарушение чужих исключительных прав

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

Детализация технического задания

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

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

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

Проблемные места договоров с разработчиками

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

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





Позвоните нам
или оставьте нам заявку