Редакция Romanov Lab · Опубликовано
Фраза «сайт принадлежит компании» может означать несколько разных вещей. Компания оплачивает хостинг, имеет доступ к панели управления, получила копию кода или вправе использовать дизайн. Эти обстоятельства связаны, но не заменяют друг друга. Даже работающий сайт может оказаться трудным для передачи, если исходники лежат в личном аккаунте исполнителя, а порядок использования отдельных материалов неясен.
Поэтому до старта проекта полезно составить реестр активов и определить, как подтверждаются доступ, права использования и передача. Ниже — организационный чек-лист для разговора с подрядчиком и юристом. Он не определяет права сторон в конкретном споре: для этого нужны договоры, сведения об авторах, условия сервисов и применимое законодательство.
Разделите четыре разных вопроса
Для каждого актива выясните, кто может им технически управлять, на каком основании его используют, кто оплачивает дальнейшее обслуживание и как проект продолжит работу при смене команды. Один человек может выполнять несколько функций, но фиксировать их лучше отдельно.
- Контроль: у кого есть административный доступ и возможность восстановить его.
- Правовое основание: договор, лицензия или другое применимое основание использования.
- Эксплуатация: кто продлевает услугу, получает уведомления и следит за ограничениями.
- Передача: какие файлы, инструкции и действия нужны новому исполнителю.
Пароль от аккаунта не доказывает объём прав на размещённые материалы. И наоборот, наличие необходимых прав не гарантирует, что компания технически сможет собрать и опубликовать сайт. Проверка должна охватывать обе стороны.
Домен: проверьте данные регистрации и управление
Для домена запишите регистратора, указанного в аккаунте администратора или регистранта, контакт для восстановления, плательщика и ответственного сотрудника. Названия ролей и процедуры зависят от доменной зоны и регистратора. Не предполагайте, что правила одного сервиса автоматически применимы к другому.
Информация ICANN о правах и обязанностях регистрантов относится к соответствующим отношениям с аккредитованными регистраторами; она не заменяет правила конкретной национальной зоны. Для вашего домена проверьте актуальное соглашение и порядок изменения данных у обслуживающего регистратора.
Практический вопрос звучит так: сможет ли уполномоченный сотрудник компании войти в аккаунт, увидеть регистрационные данные, получить уведомление и обратиться в поддержку без личного участия подрядчика? Проверять это стоит заранее, не дожидаясь окончания сотрудничества. Порядок продления отдельно разобран в статье о домене и TLS-сертификате.
Если домен уже зарегистрирован на другое лицо, не меняйте записи поспешно. Сначала выясните фактические отношения, необходимые документы и последствия процедуры. В некоторых случаях потребуется юридическая проверка и согласованная передача, а не простая замена адреса электронной почты.
Код: копии файлов недостаточно для продолжения работы
Попросите определить состав передаваемого кода: исходные файлы, конфигурация сборки, описание среды, миграции базы, инструкции запуска и перечень зависимостей. Готовая папка опубликованного сайта может не содержать исходников, из которых он собирается. Для статического сайта и сложного сервиса комплект будет разным.
Отдельно выясните, что разработано специально для проекта, а что существовало раньше или получено от третьих лиц. Не ожидайте, что подрядчик может передать исключительные права на любую библиотеку, которую использует. Нужно понять условия её применения и то, какие обязанности останутся у компании.
WIPO объясняет, что авторские права, лицензирование и допустимые способы использования зависят от характера произведения и применимых правил. Для проекта это основание проверить документы, а не вывод «оплатили работу — получили все права». Конкретные формулировки о передаче и объёме использования стоит согласовать с юристом.
Попросите независимого от автора специалиста воспроизвести запуск по инструкции в разрешённой тестовой среде. Такая проверка не устанавливает юридические права, зато показывает, достаточно ли технических материалов для передачи. Если сборка требует неизвестного приватного пакета, проблема обнаружится до смены команды.
Дизайн: уточните исходники и состав сторонних материалов
Обсудите передачу редактируемого дизайн-файла, используемых компонентов, экспортированных изображений и правил работы с ними. Снимки экранов помогают просмотреть результат, но не всегда позволяют удобно продолжить проектирование. Если макеты находятся в аккаунте студии, заранее определите, как компания получит устойчивый доступ или копию в своём пространстве.
В дизайне могут быть шрифты, иконки, фотографии и платные наборы. Для каждого важен источник и разрешённый способ использования. Лицензия для рабочего компьютера дизайнера и лицензия для публикации шрифта на сайте могут предусматривать разные условия; проверять нужно конкретный документ, а не общее название продукта.
Составьте список: материал, источник, версия или название лицензии, кто приобрёл, где хранится подтверждение, какие ограничения требуют внимания. Не публикуйте материалы с неизвестным происхождением только потому, что они уже вставлены в макет. Если основание не подтверждено, предусмотрите замену.
Аккаунты: обеспечьте управляемую преемственность
Перечислите хостинг, репозиторий, CMS, аналитику, почтовый сервис, формы, CDN, сервисы отправки сообщений и другие зависимости. Для каждого укажите владельца аккаунта, административные роли и способ восстановления. Не храните пароли и секретные ключи в общем реестре; достаточно ссылки на защищённое хранилище и ответственного за доступ.
По возможности используйте организационные пространства и персональные роли сотрудников вместо одного общего логина. Давайте исполнителю только нужные полномочия. При этом у компании должен оставаться проверенный путь управления критическим ресурсом. Полный административный доступ не следует раздавать всем «на всякий случай».
Например, GitHub рекомендует обеспечивать преемственность владения организацией и иметь более одного владельца, чтобы недоступность единственного человека не блокировала проект. Это конкретная рекомендация для GitHub; в других сервисах проверьте поддерживаемые роли и безопасный порядок восстановления.
Для конструктора и SaaS отдельно проверьте выход из сервиса
Если сайт работает на облачной платформе, выясните, какие результаты можно выгрузить и в каком виде. Экспорт материалов, выгрузка базы и получение самостоятельного работающего приложения — разные возможности. Не предполагайте переносимость по одному наличию кнопки «экспорт».
Попросите показать процедуру на учебном содержимом: что входит в файл, сохраняются ли связи, изображения и нужные поля, какой программой это можно открыть. Уточните по актуальным условиям платформы, что произойдёт после прекращения подписки и какие действия нужно выполнить заранее. Универсального ответа для всех сервисов нет.
Если самостоятельный перенос не предусмотрен, это не обязательно делает платформу непригодной. Но ограничение должно быть осознанным: компания понимает, какие материалы сохранит, какую часть придётся создавать заново и кто отвечает за подготовку перехода. Такие сведения полезно записать рядом с другими активами проекта до выбора окончательного решения.
Вопросы, которые стоит вынести в договорное обсуждение
Организационный реестр помогает подготовить конкретные вопросы специалисту по договорам. Он не заменяет текст соглашения. Покажите юристу состав работ и активов, чтобы обсуждение не ограничилось расплывчатым словом «сайт».
- Какие результаты создаются специально, а какие предоставляются по лицензии?
- Какие способы использования нужны компании: изменение, передача другому подрядчику, размещение на другой инфраструктуре?
- Когда и при каких условиях происходит предусмотренная передача?
- Как подтверждаются полномочия подрядчика в отношении работ его сотрудников и привлечённых исполнителей?
- Какие сторонние ограничения сохраняются?
- Что передаётся при досрочном прекращении работы?
- Как оформляются обновления и дополнительные материалы?
Не используйте универсальный шаблон без проверки контекста. Компаниям в разных юрисдикциях, проектам с несколькими авторами и продуктам со сторонними лицензиями могут требоваться разные решения. Особенно внимательно обсуждайте материалы, которые заказчик сам передаёт исполнителю: их происхождение тоже необходимо знать.
Проверьте передачу как рабочий сценарий
В день передачи недостаточно получить письмо со ссылками. Уполномоченный сотрудник должен проверить вход, актуальность файлов, доступность документации и возможность выполнить согласованные действия. Доступы выдаются через штатные механизмы сервисов, без публикации секретов в переписке или документе.
После подтверждения преемственности пересмотрите старые разрешения и согласуйте отзыв ненужного доступа. Не отключайте исполнителя до завершения действий, которые ещё требуют его участия. Для рабочих интеграций отдельно проверьте, не привязаны ли они к личным токенам уходящего сотрудника; замену проводите управляемо, с проверкой результата.
Условный пример и итоговый реестр
Представим сайт, где домен зарегистрирован компанией, код лежит в организации подрядчика, а дизайн использует приобретённый дизайнером шрифт. Сайт работает, но передача пока неполная. Команда отдельно согласует техническую передачу репозитория, проверяет документы на код и условия шрифта. Нельзя решить все три вопроса одним архивом.
В итоговом реестре для каждого актива должны быть название, местонахождение, уполномоченный владелец управления, основание использования, ответственный за обслуживание и результат проверки передачи. Открытые вопросы сохраняйте явно. Управляемый проект — тот, который компания может законно использовать и технически продолжать, понимая реальные ограничения каждого элемента.
Нужен план для вашего проекта? Напишите нам в Telegram или по электронной почте. Обсудим разработку, продвижение или поддержку сайта.
