Вероятнее всего никто никого обманывать и не собирается, но в отношениях между разработчиком сайта и заказчиком может накопиться такой ряд неточностей, что иначе как обманом ситуацию и не назовешь. Хотели одно, а получили другое. Итак, что нужно определить сначала?
Дизайн сайта
При взаимодействии с крупными платформами (on-line площадки или продающие коробочные версии продукта) дизайн представлен шаблонами оформления и выбирается самим заказчиком при настройке своего сайта. Если возникает вопрос платного оформления (пользовательский дизайн), разработчик предлагает дополнительную услугу с дополнительной оплатой и в этом случае все ясно — отдельная работа, отдельный договор.
Если разработчик — один специалист или небольшая группа лиц, сдающая заказчику проект в целом, то о выполнении дизайнерской работы нужно договориться отдельно. Оформление сайта может быть отражено в едином договоре или закреплено самостоятельным документом. Следует понимать, что начинается разработка дизайна на основании требований заказчика выраженного в техническом задании и заканчивается сдачей утвержденного оригинал-макета, согласно которому будет произведена верстка страниц сайта. Дизайн, как способ оформления интернет-страницы является отдельным объектом авторского права и передается заказчику на основании договора.
Договор на разработку программного обеспечения сайта
Современные требования к сайтам подразумевают наличие какой-нибудь системы управления содержимым (контентом) — CMS-системы. Здесь и возникает первый вопрос: какая CMS используется для создания сайта заказчика? Возможны варианты:
- платная или бесплатная CMS третьих лиц — разработчик собирает сайт из модулей, возможно, дорабатывает свои, но при передаче результата заказчику он руководствуется лицензионным соглашением самой платформы. В основном, разработчик осуществляет услуги по настройке и доработке существующей системы.
- CMS разработчика или создание персональной системы для заказчика — в этом случае разработчик может передавать права на программный продукт (сайт) по договору отчуждения или лицензионному соглашению. В чем разница?
По договору отчуждения разработчик передает заказчику исключительные права в полном объеме и сам уже пользоваться копией своей платформы права не имеет. В этом случае уместно использовать такую формулировку: «Разработчик передает заказчику исключительные права на программный продукт свободный от прав третьих лиц в полном объеме и на весь срок их защиты».
По лицензионному соглашению разработчик передает набор прав, ограниченный в пространстве, по времени, по количеству копий или как-нибудь иначе. В этом случае нужно поинтересоваться ограничениями:
- использование на отдельной территории;
- срок пользования правом владения продуктом;
- количество копий продукта (также, количество одновременно работающих копий);
- право передачи продукта третьим лицам (передача права лицензии или сублицензирование).
Разница между передачей прав на продукт и сублицензией заключается в том, что передавая продукт владелец отказывается от его использования, а сублицензия — это распространение продукта с передачей неисключительного права пользования третьим лицам самим заказчиком.
Существуют исключительные лицензии согласно которым, разработчик не имеет права передавать продукт кому-нибудь еще, кроме заказчика в течение срока действия исключительной лицензии. Процесс использования продукта немного похож на индивидуальную разработку — в обоих случаях никто, кроме заказчика, не использует продукт.
В лицензионном соглашении, также следует подробно изучить права и обязанности сторон, отказ от ответственности и механизм передачи прав на продукт. При индивидуальной разработке продукта для заказчика (вероятно, это будет договор отчуждения) передача прав происходит после подписания акта сдачи-приемки работ — как правило, это страховка разработчика, чтобы заказчик не обманул с оплатой.
Использование сторонних сервисов
Если разработчик использует сервис-модули третьих лиц, то он должен предупредить об этом заказчика, потому что использование сторонних модулей, как правило, регулируется отдельными соглашениями. Если сервис общедоступный: информер (курсы валют, погода), системы анти-бот (captcha), калькуляторы, опросы, on-line помощник, то в его соглашении может быть отказ от ответственности в случае сбоев в работе и иных экстренных ситуациях, а отвечать за аварийную ситуацию перед посетителем сайта будет заказчик.
Известны случаи когда посетитель интернет-магазина не мог сделать заказ через неработающий on-line консультант. Недавняя ситуация с сайтом Почты России: когда Роскомнадзор заблокировал некоторые адреса Google и на сайте Почты России несколько часов не работал модуль Captcha.
Если заказчику позволяет бюджет, нужно заказывать разработчику создание подобных сервис-модулей, чтобы как можно меньше зависеть от внешних обстоятельств.
Также, разработчик может использовать модули для системы, взятые из общедоступных библиотек решений, а у них может быть установлено ограничение использования (например, не для коммерческого использования). Чтобы оставить ответственность на разработчике используется вышесказанная формулировка, что разработчик передает свободное от прав третьих лиц программное обеспечение.
Итог
Нужно всегда помнить, что требования к разработке программного обеспечения оформляются письменно в виде технического задания, также возможен свободный перечень требований в письменном виде. Эти требования являются основополагающими в процессе разработки и являются неотъемлемой частью договора на создание сайта.
Вот основные вопросы и ситуации, которые могут быть полезны в начале переговоров с разработчиками сайтов.
В скором времени я планирую создать нарратив с тезисами и основными вопросами к разработчику, чтобы его можно было использовать как помощник во время переговоров и при заключении договора.
