Если платный плагин или шаблон сайта куплен на почту подрядчика, бизнес рискует потерять обновления, доступ к настройкам и подтверждение права использования. В статье разберём, как проверить лицензии на сайт, какие документы запросить у разработчика и что делать, если подрядчик перестал отвечать. Эти шаги помогут владельцу сайта собрать понятный реестр программ и заранее заменить спорные компоненты.
Почему лицензия на плагин важна владельцу сайта?
Плагин добавляет сайту конкретную функцию: форму заказа, оплату, интеграцию с CRM, защиту от спама или другой модуль. У платного расширения обычно есть лицензионный ключ, личный кабинет покупателя и условия использования. Если покупателем указан подрядчик, бизнес может пользоваться результатом работы сайта, но не всегда получает самостоятельное право обновлять сам компонент.
Проблема проявляется не сразу. Сайт продолжает работать, пока не выйдет обновление CMS, не изменится версия PHP или не появится уязвимость в старом модуле. После этого администратор видит уведомление об окончании лицензии, а письмо с ключом приходит на адрес, к которому у компании нет доступа.
Такая ситуация встречается с премиум-темами, конструкторами форм, модулями эквайринга, резервного копирования и аналитики. Лицензия может быть оформлена на личный аккаунт специалиста, агентство или бывшего сотрудника. Поэтому проверять нужно не только файлы сайта, но и сведения о покупателе.
Какие сведения нужно проверить в первую очередь?
Начните с инвентаризации. Составьте список всех платных компонентов, которые работают на сайте, и внесите туда название, версию, назначение, дату покупки, срок обновлений и адрес личного кабинета. Отдельной строкой укажите, кто указан владельцем лицензии.
- CMS и её редакция, если она оплачивается отдельно.
- Платный шаблон или тема.
- Плагины для форм, оплаты, доставки и интеграций.
- Расширения для резервного копирования, безопасности и оптимизации.
- Шрифты, изображения и другие материалы с ограничениями использования.
- Облачные сервисы, без которых перестают работать отдельные функции сайта.
Затем попросите подрядчика передать не только архив сайта. Нужны счета или иные подтверждения покупки, лицензионные ключи, данные о сроке подписки и инструкция по продлению. Если продукт привязан к домену, проверьте, зарегистрирован ли в аккаунте именно домен вашей компании.
Полезно заранее проверить и саму модель лицензирования. Одни продукты разрешают использовать компонент на одном домене, другие включают несколько сайтов, а третьи требуют отдельной подписки для каждого проекта. Разобраться в назначении программ до покупки помогает проверка нужности ПО до покупки лицензии: это снижает риск оплаты модуля, который фактически не используется.
Как оформить передачу сайта и лицензий от подрядчика?
Передачу лучше закрепить отдельным актом или приложением к договору на разработку и поддержку сайта. В документе перечисляют домен, сервер, CMS, плагины, шаблон, аккаунты и доступы. Для каждого платного компонента указывают владельца лицензии и способ восстановления доступа.
В договоре полезно разделить три вещи: код, контент и права на сторонние продукты. Подрядчик может написать часть кода специально для сайта, но установить вместе с ним сторонний плагин по собственной подписке. Такой плагин нельзя автоматически считать переданным бизнесу. Условия нужно проверить по правилам конкретного правообладателя.
| Что передают | Что проверить | Какой результат нужен |
|---|---|---|
| Исходный код и файлы сайта | Есть ли полный архив и инструкция по запуску | Компания может восстановить сайт без подрядчика |
| Платные плагины | На кого оформлена покупка и к какому домену привязан ключ | У владельца есть законный способ продления и обновления |
| Шаблон или тема | Разрешает ли лицензия коммерческое использование и перенос | Условия использования сохранены в реестре |
| Облачные сервисы | Кто администратор и кто оплачивает подписку | Компания контролирует тариф, оплату и доступы |
Пароли лучше передавать через отдельный защищённый канал, а не включать в общий акт или письмо. После получения доступа владелец меняет пароль, включает двухфакторную защиту, если она доступна, и удаляет бывших пользователей. В реестре фиксируют дату проверки, чтобы через несколько месяцев не искать эти данные заново.
Что делать, если подрядчик исчез?
Сначала определите, какие компоненты критичны для работы сайта. Если лицензия закончилась у модуля оплаты или формы заказа, приоритет выше, чем у расширения, которое влияет только на внешний вид. Не удаляйте плагин сразу: его отключение способно нарушить структуру страниц или удалить настройки.
- Сделайте резервную копию файлов и базы данных.
- Снимите перечень установленных компонентов и их версий.
- Проверьте уведомления CMS и письма от разработчиков продуктов.
- Найдите официальный аккаунт правообладателя и выясните, можно ли перенести лицензию.
- Если перенос невозможен, выберите замену и протестируйте её на копии сайта.
- Зафиксируйте новый порядок доступа в договоре с текущим специалистом.
Если подрядчик оставил рабочий сайт, но не передал лицензии, можно временно ограничить изменения и не обновлять всё одновременно. Перед обновлением делают копию, проверяют совместимость компонентов и записывают результат теста. Для интернет-магазина отдельно проверяют создание заказа, расчёт стоимости, отправку уведомлений и оплату.
Когда правообладатель предлагает купить новую лицензию, сравните этот вариант с переносом аккаунта и заменой плагина. Иногда дешевле приобрести компонент на имя компании и получить поддержку напрямую. В других случаях замена требует доработки темы, поэтому итоговую стоимость нужно оценивать вместе с работами разработчика.
Как распределить ответственность между бизнесом и разработчиком?
Владелец бизнеса отвечает за то, чтобы у компании был доступ к критичным аккаунтам и действующим подпискам. Разработчик отвечает за корректную установку, настройку и передачу сведений, которые предусмотрены договором. Эти роли лучше записать до начала работ.
В договоре на поддержку сайта укажите, кто продлевает лицензии, кто получает уведомления об окончании подписки и кто оплачивает замену устаревшего модуля. Если подрядчик использует собственную лицензию, попросите его письменно подтвердить срок работы сайта и условия после окончания договора.
Для облачных продуктов проверьте отдельно поставщика и схему закупки. Важно знать, кто выставляет счёт, на кого оформлен аккаунт и что произойдёт с доступом при прекращении обслуживания. Подход к такой проверке описан в материале о том, как проверить поставщика сублицензий на SaaS.
Типичные ошибки при работе с лицензиями
- Считать, что передача файлов сайта автоматически передаёт права на платные плагины.
- Оформлять все покупки на личную почту разработчика.
- Хранить ключи и счета только в переписке с подрядчиком.
- Обновлять CMS и расширения без резервной копии.
- Продлевать подписку, не проверив, используется ли функция плагина.
- Удалять старый компонент до тестирования замены на копии сайта.
3 шага, которые можно сделать на этой неделе:
- Соберите реестр CMS, шаблонов, плагинов и облачных сервисов сайта.
- Проверьте владельца каждой платной лицензии и сохраните подтверждение покупки.
- Закрепите в договоре передачу доступов, порядок продления и замену компонентов.
Если часть лицензий оформлена на подрядчика, сначала восстановите управляемость: получите список продуктов, проверьте условия переноса и отделите критичные модули от второстепенных. Для закупки офисного ПО и облачных сервисов тот же принцип работает на уровне всей компании: лицензия, аккаунт и платежные документы должны быть доступны владельцу бизнеса, а не одному исполнителю.
