Кому належить ваш сайт: домен, код, дизайн і пункти договору, які це вирішують

«Ми заплатили, отже, це наше» — найпоширеніше уявлення про права на сайт, і в більшій частині Європи воно хибне. Оплата рахунку купує передачу речі. Вона за замовчуванням не передає прав на цю річ, а розрив між цими двома фактами стає видимим лише в момент, коли ви хочете піти, переробити сайт або віддати його іншому підряднику.

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

Шість речей, які називають словом «сайт»

АктивУ кого зазвичайЧого це коштує вам
Доменне імʼяУ того, хто вказаний реєстрантомПовний важіль. Якщо тут помилка, решта не має значення
Акаунти хостингу й інфраструктуриЧасто в агенції, «щоб було зручно»Переїзд стає переговорами замість задачі
Кастомний вихідний кодВ автора, якщо права не передані письмовоУ вас може бути ліцензія на використання, але не право змінювати
Вихідні файли дизайнуУ дизайнера, у його робочому просторіПереробка починається зі скріншотів
Контент і фотографіїВ автора або ліцензіара стокуЛіцензії, які не переїжджають на новий сайт чи до нового власника
Аналітика, реклама, дані клієнтівУ того, хто створював акаунтиІсторія втрачається; обовʼязки щодо персональних даних однаково лишаються на вас

Чому оплата не передає авторське право

За європейською доктриною авторського права первинним власником прав є автор, і автор — це фізична особа: розробник, дизайнер, копірайтер. Загального європейського аналога американського «work made for hire», який автоматично закріплює права за замовником, не існує. Передача вимагає письмового договору про відчуження прав, а усної чи такої, що «мається на увазі», зазвичай недостатньо.

У програмного забезпечення є один важливий виняток. Директива 2009/24/ЄС про правову охорону компʼютерних програм встановлює: якщо програму створив працівник під час виконання службових обовʼязків, майнові права належать роботодавцю, якщо не домовлено інакше. Зверніть увагу на слово «працівник». Фрилансер під цю норму не підпадає, і, за більшістю прочитань, не підпадають і стосунки агенції з її клієнтом. Тобто агенція може володіти правами на код, написаний її ж співробітниками, і водночас протиставляти ці права вам.

Практичний наслідок: без пункту про передачу прав у вас зазвичай є неявна ліцензія на використання сайту за тим призначенням, для якого його замовляли. Цього, як правило, вистачає, щоб сайт працював. Часто цього не вистачає, щоб дати змінювати його комусь іншому, повторно використати код у другому проєкті або продати бізнес разом із сайтом як активом.

Друге ускладнення — особисті немайнові права. У більшості європейських юрисдикцій вони взагалі не відчужуються, а лише можуть бути обмежені в межах, дозволених місцевим законом. Комерційною проблемою це буває рідко, але саме тому грамотний договір окремо описує авторство й право на переробку, а не заявляє, що купує «всі права».

Чого не можна отримати у власність за жодним договором

Три категорії назавжди лишаються поза будь-яким пунктом про власність, і підрядник, який обіцяє інше, або недбалий, або вводить вас в оману.

  • Код під GPL. Ядро WordPress, а через успадкування — більшість тем і плагінів, поширюються за ліцензією GPL. Ви можете володіти кастомним кодом, написаним для вас, але отримати виключні права на похідне від GPL не можете ні ви, ні ваша агенція. Це варто розуміти до того, як платити преміальну ціну за «ексклюзивність» будь-чого, зробленого на WordPress.
  • Ліцензовані компоненти. Комерційні плагіни, преміальні теми, шрифти й стокові зображення ліцензуються, а не продаються. Ліцензії на шрифти особливо часто привʼязані до домену або діапазону переглядів і не переходять до нового власника автоматично.
  • Сторонні сервіси. Усе, що працює на чужій платформі, живе за її умовами — це той самий клас ризику, що описаний у чек-листі оцінки постачальників.

Отже, хороший результат — це не «нам належить усе». Це опис: ось це передано вам, ось це ліцензовано вам і ось на яких умовах, ось це відкритий код і ось його ліцензія.

Домен: пункт, що важливіший за всі інші

Домен не належить вам так, як належить майно. Він зареєстрований на строк на названого реєстранта. Хто вказаний у цьому полі, той ним і керує, а все інше є похідним від цього факту.

  1. Перевіряйте реєстранта, а не адміністративний контакт. Бути адміністративним чи технічним контактом не дає нічого. Реєстрантом має бути ваша організація.
  2. Знайте, що зміна реєстранта має ціну. За Transfer Policy ICANN зміна реєстранта може ввімкнути 60-денне блокування перенесення домену до іншого реєстратора. Це переживається, якщо заплановано, і болить, якщо виявляється посеред переїзду.
  3. Національні домени живуть за власними правилами. Зони .ua і .bg адмініструються за політиками національних реєстрів, які відрізняються від правил gTLD, зокрема щодо документів і процедури передачі. Дивіться правила реєстру, а не довідку реселера.
  4. Тримайте продовження у власному білінгу. Домен, втрачений через несплачене продовження на картці, яку ніхто не контролює, — поширена й цілком уникна аварія, що особливо погано поєднується з запланованим переїздом домену.

Акаунти й тихе накопичення залежності

Хостинг — очевидний випадок. Менш очевидні накопичуються роками: DNS-провайдер, CDN, видавець сертифікатів, сервіс транзакційної пошти, властивість аналітики, Search Console, рекламні кабінети, репозиторій, робочий простір дизайну, ліцензії плагінів.

Правило, яке вирішує їх усі, одне: акаунт створюється на вашу організацію і ваш білінг, а підрядника додають користувачем. Для підрядника це трохи менш зручно, а для вас — драматично дешевше в момент розставання. Це також важливо для безперервності даних: історія аналітики між акаунтами не переноситься, і нова властивість починається з нуля, скільки б років сайту не було.

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

Дані клієнтів — це взагалі не питання власності

Персональні дані, зібрані через сайт, лежать поза дискусією про авторське право. За GDPR ви майже завжди є контролером, а ваша агенція — процесором, що вимагає письмового договору про обробку. Ці обовʼязки не переміщуються від того, що договір називає дані чиєюсь власністю. Дані не мають власника — вони обробляються законно або незаконно. Що з цього випливає практично, розібрано в матеріалі про те, що можна збирати, а що ні.

Пункти, які варто мати, простими словами

Складних формулювань не потрібно. Потрібні пʼять речей, сказаних однозначно.

  1. Передача прав після оплати. Майнові права на створене на замовлення переходять клієнту після отримання остаточної оплати, без обмеження територією, безвідклично, включно з правом змінювати й дозволяти змінювати іншим. Привʼязка до оплати захищає обидві сторони.
  2. Перелік того, що не передається. Названі сторонні компоненти з їхніми ліцензіями і власний доробок підрядника, який ліцензується вам безстроково, а не відчужується.
  3. Визначені вихідні матеріали. Не «файли», а конкретний список: доступ до репозиторію, дизайн у редагованому форматі, експорт бази, передані доступи.
  4. Власність на акаунти. Усі сервісні акаунти оформлені на клієнта, підряднику надано доступ як користувачу.
  5. Процедура виходу зі строком. Що передається, у якому форматі й протягом скількох робочих днів після запиту. Без строку цей обовʼязок декоративний.

Саме ці пункти відрізняють підрядника, який робив це раніше, від того, хто імпровізує, — тому вони й входять до питань, які варто поставити до підпису.

Десятихвилинна перевірка сайту, який у вас уже є

Якщо сайт уже існує, а договір розмитий, чотири перевірки покажуть ваше сьогоднішнє становище.

  • Зробіть WHOIS-запит за своїм доменом. Якщо реєстрант не ваша організація, це перше, що треба виправити, і зазвичай це виправляється мирно.
  • Увійдіть в акаунт хостингу самостійно. Не через підрядника. Якщо не виходить — хостинг ви не контролюєте.
  • Попросіть посилання на репозиторій і відкрийте його. Якщо у відповідь надсилають zip-архів на запит, історії змін немає, і безпечно передати проєкт другому підряднику реалістично неможливо.
  • Запитайте, хто реєстрант, платник і ліцензіат за кожним платним компонентом. Запишіть відповіді в одну таблицю. Ця таблиця і є вашим фактичним становищем, що б не було написано в договорі.

Нічого з цього не свідчить про недобросовісність. Більшість таких конструкцій виникає як зручність під час запуску і просто ніколи не розплітається. Проблемою вони стають лише в момент зміни — тобто саме тоді, коли ні в кого немає часу їх розплутувати.

Що робити, якщо права вже не у вас

Найчастіша ситуація не конфліктна: договору про передачу прав просто ніколи не було, підрядник нічого не приховує, і всі про це дізнаються одночасно. Розплутується це в три кроки й зазвичай без юристів.

  1. Спершу перенесіть акаунти, потім говоріть про права. Домен і хостинг переоформлюються швидко й майже завжди безболісно, поки стосунки нормальні. Права можна врегулювати й пізніше, а от домен у чужому володінні під час конфлікту перетворює будь-яку розмову на заручницьку.
  2. Підпишіть окрему угоду про передачу прав заднім числом. Це звичайна практика: короткий документ, який відчужує майнові права на вже виконану роботу. Підрядники зазвичай підписують без заперечень, бо для них це не втрата, а закриття питання.
  3. Якщо підрядник відмовляється — фіксуйте, що саме у вас є. Неявна ліцензія на використання майже напевно є, і сайт можна далі експлуатувати. Проблемою стане переробка й перепродаж, тож рішення тут комерційне: домовлятися, викуповувати права або планувати заміну коду при наступному оновленні.

Ціна питання майже завжди нижча до конфлікту, ніж під час нього. Це той рідкісний випадок, коли одна година адміністративної роботи сьогодні економить квартал переговорів через два роки.

Коротко

Оплата сайту не передає авторського права в більшій частині Європи: права належать автору, і потрібне письмове відчуження. Директива про програмне забезпечення віддає майнові права роботодавцю щодо коду, написаного працівниками, — тому агенція може законно тримати права проти клієнта, який заплатив. Власність розпадається на шість активів, і вони розповзаються по різних руках: домен, інфраструктурні акаунти, кастомний код, вихідні файли дизайну, ліцензії на контент і акаунти з даними. Дещо не може належати нікому — насамперед похідне від GPL, а також ліцензовані шрифти, плагіни та зображення, тож правильний результат — це опис, а не загальна заява. Домен важливіший за все інше, а зміна реєстранта може заблокувати перенесення на 60 днів за політикою ICANN. Персональні дані не є майном — це обовʼязок контролера, який лишається на вас. Решту закривають пʼять пунктів: передача після оплати, перелік винятків, визначені вихідні матеріали, акаунти на ваше імʼя і процедура виходу зі строком.

Latest News

Жовта попереджальна стрічка й оранжевий дорожній конус натягнуті через розбитий тротуар із щебеню та зірваного асфальту

Накладки для доступності не є відповідністю: що вирішило рішення у справі Carrefour

Французький суд відкинув показник 71% і дав Carrefour шість місяців під 500 євро за день, а FTC стягнула з найбільшого продавця накладок 1 млн доларів за твердження, що віджет забезпечує відповідність. Чому скрипт цього не виправить і що виправить насправді.

П'ять чорних міжнародних перехідників для розеток, складених пірамідою на однотонному тлі, кожен із різним розташуванням штирів

MCP для бізнесу: що стандарт вирішує, а що ви все одно будуєте самі

MCP тепер вендор-нейтральний під егідою Linux Foundation, публічних серверів понад 10 000, а липнева специфікація зробила його звичайною вебінфраструктурою. Але готовність до корпоративного використання — журнали аудиту, єдиний вхід, шлюзи — є найменш визначеним пріоритетом самої дорожньої карти.

Двоє сусідніх вхідних дверей на вулиці — темно-червоні й коричневі — у фасадах будинків різного кольору

Passkey і пароль, який залишається: що насправді змінилося до 2026 року

П’ять мільярдів passkey в обігу, 90% споживачів знають цей термін — і при цьому 57% організацій досі заводять власний персонал у систему паролем. Чому passkey виграють як додаток і програють як заміна, і п’ять кроків, які варто зробити на бізнесовому сайті.

View all news

Зв’яжіться з нами
для обговорення проєкту

Заповніть форму — ми зв’яжемося з вами,
щоб обговорити деталі проєкту.

    Виберіть зручний спосіб зв'язку з нами:

    Telegram
    Viber
    E-mail