Коротка відповідь: Оплата розроблення не означає, що ви автоматично отримуєте вихідний код або необмежене право змінювати застосунок і передавати його іншому постачальнику. Вирішальне значення має те, хто створив програму, на яких умовах він працював і що передбачає договір. Крім прав на код, забезпечте собі доступ до репозиторію, документації, облікових записів і даних, а також перевірений порядок розгортання.
Спочатку розмежуйте права, файли та експлуатацію
Фраза «код належить замовнику» може означати кілька різних речей:
- хто здійснює майнові авторські права на програму;
- яку ліцензію та в якому обсязі отримав замовник;
- хто має доступ до вихідних файлів та історії змін;
- на кого зареєстровані хмарні, доменні та розробницькі облікові записи;
- хто може змінювати, розгортати застосунок і передавати його іншій команді;
- хто може експортувати робочі дані та відновлювати систему з резервної копії.
Ці питання не є взаємозамінними. Компанія може мати широку ліцензію, але не мати актуального вихідного коду. Вона може володіти копією репозиторію, але не мати права передати її новому постачальнику. А може мати і те, й інше, проте без бази даних, ключів і документації усе одно не зможе запустити застосунок.
Тому практична мета полягає не в тому, щоб «володіти ZIP-архівом». Потрібно мати юридичну й технічну можливість експлуатувати, змінювати, резервувати та безпечно приймати систему без залежності від однієї людини.
Що встановлює autorský zákon
Станом на 2 жовтня 2026 року e-Sbírka для zákona č. 121/2000 Sb. наводить редакцію, чинну з 1 липня 2025 року. Для програмного забезпечення, створеного на замовлення, особливо важливі § 58, § 61 a § 66 autorského zákona, zákona č. 121/2000 Sb..
Автором програми є фізична особа, яка її створила. Тому з юридичного погляду недостатньо написати, що замовник «стає автором» або що йому передається авторство. Договір має точно визначати здійснення майнових прав, ліцензію та обов’язок передати вихідний код.
Початковий правовий режим залежить від того, хто фактично створює програму:
| Хто створює програму | Початкова правова ситуація |
|---|---|
| Працівник замовника | Якщо працівник створив програму для виконання обов’язків, що випливають із трудових або службових відносин, замовник як роботодавець може здійснювати майнові права на службовий твір відповідно до § 58 odst. 1, якщо не погоджено інше. |
| Автор як фізична особа безпосередньо на замовлення | Комп’ютерна програма, яка не є колективним твором і яку автор створив на замовлення, відповідно до § 58 odst. 7 вважається службовим твором, а замовник — роботодавцем; майнові права в такому разі здійснює замовник, якщо не погоджено інше. |
| Працівники компанії-розробника | Якщо вони створили програму для виконання обов’язків, що випливають із трудових або службових відносин, їхній роботодавець, тобто компанія-постачальник, може здійснювати майнові права на службовий твір відповідно до § 58 odst. 1, якщо не погоджено інше. Замовнику потрібні права, погоджені з постачальником. |
| Позаштатні фахівці та інші субпідрядники | Постачальник повинен належним чином оформити права на кожну отриману частину та мати можливість надати замовнику погоджений обсяг прав. |
До комп’ютерних програм, створених автором на замовлення, відповідно до § 58 odst. 7 не застосовується § 61 autorského zákona. Тому не можна покладатися на загальне регулювання твору, створеного на замовлення, як на заміну точному договору щодо програмного забезпечення.
Ще одна особливість стосується передання права здійснювати майнові права. Відповідно до § 58 odst. 1 роботодавець може передати це право третій особі лише за згодою автора, за винятком передання під час відчуження комерційного підприємства. Якщо замовник вимагає саме передання права здійснювати майнові права, постачальник повинен перевірити, чи має він усі необхідні згоди. На практиці доцільнішою може бути точно сформульована ліцензія; правильне рішення залежить від відносин між авторами, постачальником і замовником.
Відповідно до § 66 odst. 1 autorského zákona правомірний користувач примірника програми не порушує авторського права, якщо змінює програму настільки, наскільки це необхідно для її впровадження та експлуатації, або виправляє її помилки. Він також може створити резервну копію, якщо вона необхідна для використання програми. Однак це положення саме по собі не забезпечує передання читабельного вихідного коду, історії репозиторію, документації чи доступу до інфраструктури.
Це загальний огляд, а не юридична оцінка конкретного договору. Перед підписанням перевірте документ разом з адвокатом, який спеціалізується на авторському праві та ІТ.
Що має врегулювати договір
1. Обсяг прав на програму
Фрази «замовник може використовувати застосунок» недостатньо. Договір має відповісти щонайменше на такі запитання:
- Чи може замовник експлуатувати застосунок у власній або орендованій інфраструктурі?
- Чи може він змінювати його силами власних працівників або іншого постачальника?
- Чи може він створювати середовища для розроблення, тестування, резервування та навчання?
- Чи може він надати доступ до вихідного коду аудитору, адміністратору або покупцеві компанії?
- Чи поширюються права також на модулі й оновлення, замовлені пізніше?
- Ліцензія є виключною чи невиключною?
- Чи діє вона без обмежень у часі, за територією або кількістю примірників?
- Чи збережуться права після припинення договору на обслуговування?
Обсяг прав має відповідати запланованому способу використання. Для внутрішньої облікової системи однієї компанії потрібні одні права, а для платформи, яку замовник пропонуватиме своїм клієнтам, — інші.
2. Постійно доступний репозиторій
Вихідний код не варто передавати лише наприкінці роботи у вигляді архіву без історії. Безпечніше від самого початку зберігати його в організації замовника на GitHub, GitLab або Azure DevOps. Замовник повинен мати адміністративний доступ, а постачальник — лише права, необхідні для розроблення.
Репозиторій має містити все необхідне для складання й розгортання погодженої частини системи:
- фронтенд і бекенд;
- міграції бази даних;
- автоматизовані тести;
- декларації залежностей та зафіксовані версії;
- скрипти складання й розгортання;
- конфігурацію CI/CD;
- визначення контейнерів або інфраструктури;
- зразок конфігурації без справжніх паролів і ключів.
Обліковим даним не місце в репозиторії. Договір має окремо визначати, де зберігаються секретні ключі, хто ними керує та як відбудеться їх безпечне передання або заміна.
3. Походження коду та права субпідрядників
Постачальник не обов’язково пише всю систему з нуля. Застосунок зазвичай поєднує:
- код, створений безпосередньо для замовника;
- раніше створені модулі постачальника;
- пакети з відкритим вихідним кодом;
- платні компоненти та послуги третіх сторін;
- частини, створені позаштатними фахівцями або генеративними інструментами.
Договір або технічний додаток має розмежовувати ці групи. Щодо субпідрядників вимагайте підтвердження, що постачальник отримав права, необхідні для надання погодженої ліцензії. Для раніше створених модулів постачальника має бути зрозуміло, чи зможете ви після завершення співпраці й надалі експлуатувати й змінювати їх, а також доручити їх обслуговування іншому фахівцеві.
Автоматично створений код не є підставою послаблювати вимоги до перевірки. Відповідальність за інтеграцію, безпеку та походження результату має залишатися частиною процесу розроблення, як ми пояснюємо у статті Код від ШІ: хто його прочитав до того, як він потрапив до користувачів?.
4. Перелік бібліотек і ліцензій
Для переліку залежностей недостатньо лише файлу package.json, requirements.txt або composer.json. Вам також потрібні фактично використані версії, включно з транзитивними залежностями, і відомості про їхні ліцензії.
MIT, Apache License 2.0, GPL та AGPL встановлюють різні умови. Постачальник не може надати замовнику більше прав, ніж сам отримав від автора компонента. Тому передання має включати актуальний перелік компонентів і ліцензій, а за потреби — машиночитаний список складових програмного забезпечення.
Окремо позначте платні шаблони, шрифти, картографічні матеріали, конектори, зовнішні API та хмарні служби. Вихідного коду може бути недостатньо, якщо ключова функція залежить від непереносної ліцензії або облікового запису, зареєстрованого лише на постачальника.
5. Документація, перевірена запуском
Документація не повинна описувати лише екрани. Новій команді щонайменше потрібні:
- огляд архітектури й окремих служб;
- підтримувані версії середовища виконання;
- порядок складання й розгортання;
- схема бази даних і міграції;
- перелік інтеграційних інтерфейсів;
- конфігураційні змінні без їхніх секретних значень;
- порядок резервного копіювання та відновлення;
- експлуатаційні перевірки, журналювання й усунення відомих помилок;
- порядок відновлення після збою.
Найнадійніше приймальне випробування проводять у чистому середовищі. Розробник, який не брав участі в проєкті, отримує лише погоджений репозиторій, документацію та доступи. За ними він повинен зібрати застосунок, запустити тести, розгорнути тестовий екземпляр і відновити копію даних.
Відновлення варто справді виконати, а не лише перевірити наявність файлів резервних копій. Той самий принцип розглянуто у статті Перевірка відновлення резервної копії: як її провести й задокументувати.
6. Облікові записи під контролем замовника
На замовника мають бути зареєстровані насамперед:
- домен і керування DNS;
- хмарний обліковий запис і платіжні дані;
- репозиторій і реєстр контейнерів;
- робоче та резервне середовища;
- служба для надсилання електронних листів;
- моніторинг і централізовані журнали;
- облікові записи в магазинах мобільних застосунків;
- сертифікати, резервні копії та засоби керування ідентифікацією.
Постачальник має отримати іменний обліковий запис із відповідною роллю. Спільний пароль без можливості простежити дії та без багатофакторної автентифікації ускладнює як аудит, так і припинення доступу.
Якщо постачальник експлуатує застосунок у власному середовищі, договір має описувати експорт, міграцію та його сприяння під час переходу. Саме лише формулювання «хостинг забезпечує постачальник» не пояснює, як замовник прийме систему.
7. Дані та план виходу
Права на вихідний код автоматично не охоплюють робочі дані. Тому в договорі визначте:
- які дані передаються;
- у якому форматі та структурі;
- чи містить експорт вкладення, метадані та зв’язки;
- як передаються ключі шифрування;
- як перевіряється повнота й читабельність експорту;
- хто сприяє проведенню міграції;
- коли буде скасовано облікові записи попереднього постачальника;
- що станеться із залишковими копіями даних.
План виходу слід готувати на початку співпраці, а не лише після виникнення спору. Практичні кроки щодо облікових записів, паролів і документації також підсумовано у статті Ваш ІТ-фахівець пішов? Як прийняти й передати корпоративну ІТ-інфраструктуру.
Неналежне передання та система, яку можна прийняти
| Неналежне налаштування | Система, яку можна прийняти |
|---|---|
| Репозиторієм керує лише постачальник | Замовник має адміністративний доступ |
| Наприкінці передається ZIP-архів без історії | Код постійно зберігається у спільному репозиторії |
| Договір дозволяє лише «використання» | Права прямо охоплюють експлуатацію, зміни та передання |
| Залежності не обліковуються | Передання включає версії компонентів і їхні ліцензії |
| Порядок розгортання знає один програміст | Порядок задокументований і перевірений у чистому середовищі |
| Хмарні облікові записи належать постачальнику | Обліковими записами володіє замовник і сам призначає ролі |
| Експорт — це таблиця без вкладень | Експорт охоплює дані, зв’язки, файли й метадані |
| Резервна копія лише існує | Відновлення виконано й задокументовано |
Нижча ціна пропозиції не обов’язково означає менші сукупні витрати. Відновлення міграцій бази даних, пошук неврахованих залежностей або ручне перенесення даних можуть суттєво здорожчити подальшу зміну постачальника.
Тривожні сигнали перед підписанням
Будьте обережні, якщо постачальник:
- вважає репозиторій суто внутрішньою справою;
- відмовляється описати використані бібліотеки та ліцензії;
- пропонує експлуатацію лише у власному обліковому записі без процедури експорту;
- обіцяє надати документацію лише після завершення робіт;
- не хоче називати субпідрядників або походження отриманих модулів;
- стверджує, що оплата рахунка автоматично вирішує всі питання;
- не може продемонструвати розгортання з вихідного коду;
- передає дані лише як таблицю без файлів і зв’язків.
Усне запевнення «код, звичайно, ваш» не замінює конкретних положень договору та технічного приймання.
Якщо перед підписанням договору або під час зміни постачальника вам потрібно перевірити репозиторій, доступи, резервні копії та можливість розгортання, в ITHOPE ми виконуємо це в межах ІТ-аудиту малої компанії. Якщо ви замовляєте застосунок безпосередньо в нас, діють умови, наведені на сторінці розроблення застосунків на замовлення: ми постачаємо рішення без залежності від одного постачальника, код і дані залишаються вашими, а систему можемо експлуатувати також локально в Брно. Завдання можна надіслати через форму запиту без зобов’язань. Результатом має бути конкретний перелік відсутніх прав, файлів, облікових записів і кроків для безпечного приймання, а не лише загальна оцінка.
Що перевірити під час приймання
Перед оплатою останньої частини варто перевірити щонайменше таке:
- замовник має адміністративний доступ до репозиторію;
- репозиторій містить актуальну робочу версію;
- договір дозволяє погоджену експлуатацію, внесення змін і залучення іншого постачальника;
- постачальник підтвердив права на зовнішні компоненти;
- відомі версії та ліцензії всіх залежностей;
- із вихідного коду можна зібрати й розгорнути чистий екземпляр;
- тести можна запустити за документацією;
- міграції бази даних відповідають робочій схемі;
- повний експорт містить дані, вкладення й метадані;
- резервну копію можна відновити;
- домени, хмарні ресурси та ключові облікові записи контролює замовник;
- секретні ключі не зберігаються у вихідному коді;
- підготовлено порядок скасування доступу попередньої команди.
Поширені запитання
Чи належить нам вихідний код, якщо ми оплатили рахунок?
Самої оплати рахунка недостатньо. Вирішальне значення мають спосіб створення програми, відносини автора з постачальником, договірні права замовника та умови передання вихідних файлів. Рахунок підтверджує оплату, але не визначає автоматично обсяг ліцензії чи повноту передання.
Чи достатньо передати вихідний код у ZIP-файлі?
Ні. Архів зазвичай не містить історії змін, налаштувань гілок, автоматизації розгортання або переліку використаних версій. Без документації, міграцій бази даних, доступів і перевіреного процесу складання така копія може бути практично непридатною.
Чи може постачальник використовувати власні раніше створені модулі?
Так, якщо він має необхідні права на їх використання. Договір має відрізняти їх від частин, створених для замовника, і визначати, чи може замовник після завершення співпраці продовжувати їх експлуатувати й змінювати, а також надати до них доступ новому адміністратору.
Що робити, якщо застосунок містить бібліотеки з відкритим вихідним кодом?
Кожна бібліотека регулюється власною ліцензією. Вимагайте перелік компонентів, використаних версій і ліцензій. Так само перевірте шрифти, шаблони, карти, платні пакети та зовнішні служби.
Як переконатися, що систему справді зможе прийняти інша команда?
Доручіть незалежному розробникові створити тестове середовище, використовуючи лише передані репозиторій, документацію та доступи. Одночасно виконайте відновлення резервної копії, повний експорт даних і перевірте договірне право надати новому постачальнику доступ до коду.
Де нас знайти
ITHOPE — компанія з Брно, Чехія: ми робимо відновлення даних з дисків, RAID і NAS, сервіс ПК та ноутбуків та IT для бізнесу, усе у власній лабораторії за адресою Viniční 3587/216, 615 00 Brno.
Телефон +420 775 556 063 (цілодобово). Пристрій можна привезти особисто або надіслати курʼєром (Zásilkovna, PPL).