За законом власником вихідного коду, створеного аутсорс-командою, первинно є сам підрядник (фізична особа-розробник або IT-компанія). Факт повної оплати виставленого рахунку не означає автоматичного переходу інтелектуальної власності до замовника. Майнові права переходять клієнту лише тоді, коли в письмовому договорі прямо передбачено їх повне відчуження, а сторони підписали акт приймання-передачі із детальною ідентифікацією переданого коду.
Серед фаундерів стартапів та керівників бізнесу поширена небезпечна ілюзія: якщо команда підрядників отримує щомісячну оплату за погодинною ставкою чи фіксованим бюджетом, створене програмне забезпечення за замовчуванням стає власністю бізнесу. На практиці судові зали переповнені позовами інвесторів, які виявили, що вклали сотні тисяч доларів у чужу інтелектуальну власність. Без правильних формулювань у контракті ви ризикуєте отримати лише тимчасовий доступ до софту, тоді як розробник зберігає юридичне право перепродати це ж ядро вашим прямим конкурентам.
- Оплата інвойсу «за розробку ПЗ» дає лише факт оплати послуг, але не передає виключні майнові права інтелектуальної власності.
- У договорі підряду обов’язково має бути зафіксовано відчуження прав (assignment), а не надання невиключної ліцензії (license).
- Ланцюжок прав повинен бути безперервним: замовник має отримати документальні гарантії переходу прав від залучених субпідрядників та фрілансерів до аутсорс-агенції.
- Використання сторонніх бібліотек під вірусними ліцензіями (GPL, AGPL) створює ризик примусового відкриття вихідного коду комерційного продукту.
- Фінальним юридичним підтвердженням є двосторонній акт приймання-передачі прав інтелектуальної власності, синхронізований із отриманням ролі Owner у Git-репозиторії.
Хто володіє кодом аутсорсу за законом
Розвіюємо найпопулярніший міф у сфері цифрового бізнесу та переходимо до юридичної площини авторського права. Багато підприємців проводять хибну аналогію між матеріальним підрядом (як-от будівництво офісу) та створенням нематеріальних активів. Проте у сфері IT діють спеціальні презумпції, детально сформульовані законодавством про інтелектуальну власність та міжнародними стандартами, які підтримує WIPO (World Intellectual Property Organization).
Ці правила логічно продовжують базові принципи прав на вихідний код, за якими юридичне закріплення прав завжди вимагає окремої фіксації розпорядження правами. Щоб гарантувати правову чистоту активів компанії та уникнути суперечок із розробниками, бізнесу необхідна своєчасна передача прав інтелектуальної власності та внесення змін, оформлена за всіма стандартами чинного законодавства.
Презумпція авторства: оплата не гарантує права
Відповідно до цивільного законодавства та законів про авторське право, первинним суб’єктом завжди визнається фізична особа, творчою працею якої створено твір. Комп’ютерна програма в юридичному сенсі охороняється як літературний твір. Це означає, що програміст, який написав алгоритм, архітектуру чи рядки коду, отримує весь комплекс прав автоматично у момент створення.
Права поділяються на дві категорії:
- Особисті немайнові права (право на визнання авторства, право на ім’я, право на недоторканність твору). Вони невідчужувані: розробник назавжди залишається автором створеного коду, ці права не можна продати, подарувати чи відібрати за договором.
- Майнові права (право дозволяти чи забороняти використання, копіювання, модифікацію, розповсюдження та монетизацію). Саме ці права мають комерційну цінність і підлягають відчуженню на користь замовника.
Класична «пастка інвойсів» полягає в тому, що платіжне доручення з формулюванням на кшталт «оплата за послуги програмування згідно з інвойсом №42» підтверджує лише факт компенсації витраченого часу. Воно не містить волевиявлення щодо передачі виключних майнових прав на створені об’єкти інтелектуальної власності. Без прямого договору відчуження права залишаються у виконавця, а замовник отримує лише мовчазний дозвіл на базове використання результату без права його повноцінного захисту чи самостійної модифікації сторонніми фахівцями.
Штатний програміст проти підрядника: головні відмінності
Правовий статус коду суттєво різниться залежно від моделі залучення спеціалістів. Якщо штатний працівник створює софт у межах виконання службових обов’язків (службовий твір), розподіл прав частково регулюється трудовим договором та посадовою інструкцією. Але під час роботи з незалежними ФОП-підрядниками або зовнішніми IT-компаніями діють виключно норми цивільно-правових договорів.
| Критерій | Штатний працівник | ФОП-підрядник | Аутсорс-агенція |
|---|---|---|---|
| Суб’єкт прав за замовчуванням | Права розподіляються за трудовим договором чи законом | ФОП (автор-розробник) | Юридична особа підрядника (якщо викупила права у своїх кодерів) |
| Момент переходу прав | Створення твору в межах робочих завдань | Визначається договором (зазвичай після оплати й акту) | Після підписання акту приймання-передачі прав |
| Обов’язкові документи | Трудовий договір, посадова інструкція, службове завдання | Договір підряду/замовлення, техзавдання, акт передачі прав | Master Services Agreement (MSA), SOW, акти на кожен реліз |
| Головний ризик замовника | Розмиті обов’язки в інструкції, створення коду в позаробочий час | Відсутність умов про відчуження у договорі або рахунку | Розрив ланцюжка передачі прав від залучених розробників до агенції |
З’ясувавши презумпцію авторства, перейдемо до конкретних юридичних конструкцій, які замовник повинен закріпити у контракті ще до написання першого рядка коду.
Обов’язкові умови договору на розробку софту
Договір на розробку програмного забезпечення (найчастіше оформлений як договір підряду або Master Services Agreement) є основним щитом вашого бізнесу. Нечіткі формулювання умов відчуження створюють простір для маніпуляцій, блокування роботи та недобросовісної конкуренції.
Відчуження прав чи ліцензія на софт
Критично важливо розрізняти дві принципово різні правові моделі:
- Відчуження (assignment) виключних майнових прав: замовник стає повноправним та єдиним власником софту. Виконавець втрачає будь-які майнові права на переданий результат і не має права повторно використовувати цей код без окремої згоди замовника.
- Надання ліцензії (license): виконавець залишається власником коду, а клієнту надається лише право користуватися ним на обумовлених умовах (строк, територія, типи систем). Навіть «виключна ліцензія» не робить вас власником коду — вона лише забороняє розробнику видавати аналогічні дозволи іншим особам протягом дії угоди.
Для повного комерційного контролю у контракті має фігурувати однозначне формулювання: «Виконавець беззастережно передає (відчужує) Замовнику всі виключні майнові права інтелектуальної власності на створене програмне забезпечення у повному обсязі для використання будь-якими способами на території всіх країн світу без обмеження строком».
Момент переходу прав на вихідний код
Не менш важливим є момент, коли саме права переходять до вашої компанії. У договірній практиці зустрічаються три основні підходи:
- У момент створення коду: найбільш вигідний варіант для замовника, проте більшість аутсорсерів відхиляють цю умову, побоюючись неоплати виконаних робіт.
- Після повної оплати всього проєкту: ризикована умова для замовника. Якщо виникає конфлікт на фінальному етапі (наприклад, суперечка щодо 10% фінального траншу), виконавець формально утримує 100% прав на всю попередньо розроблену систему.
- Поетапний перехід (Milestone-based): збалансоване та рекомендоване рішення. Права на кожну ітерацію, модуль або спринт переходять до замовника в повному обсязі негайно після прийняття результатів та оплати відповідного етапу згідно з актом.
Ланцюжок передачі прав від залучених субпідрядників
Більшість IT-компаній не тримають усіх розробників у штаті за трудовими договорами. Зазвичай до проєкту залучають ФОПів, контрактників або сторонніх фрілансерів. Якщо агенція не підписала договір про повне відчуження прав зі своїм розробником, вона просто не має права передати ці права замовнику — діє класичний юридичний принцип: ніхто не може передати більше прав, ніж має сам.
Щоб захистити компанію від раптових претензій авторів коду, включіть до контракту обов’язкові запевнення та гарантії (representations & warranties):
- Підрядник гарантує, що володіє всіма майновими правами на результати робіт у повному обсязі та отримав їх від кожного залученого співробітника або субпідрядника на законних підставах.
- Підрядник бере на себе повну відповідальність за захист замовника від будь-яких позовів чи вимог третіх осіб щодо авторських прав (пункт про відшкодування збитків — indemnification clause).
Навіть бездоганно оформлений ланцюжок прав на оригінальний код може втратити силу, якщо розробники некоректно використали готові зовнішні модулі та відкриті бібліотеки.
Сторонні бібліотеки та ліцензії Open Source
Сучасна програмна інженерія рідко створює проєкти з чистого аркуша. Розробники постійно використовують готові фреймворки, пакети та сторонні бібліотеки. Проте вільне використання коду у мережі не означає відсутність правових обмежень.
Ризики вірусних копілефт-ліцензій для комерційного ПЗ
Усі ліцензії відкритого програмного забезпечення поділяються на дві основні групи:
- Пермісивні (Permissive): MIT, Apache 2.0, BSD. Дозволяють вільно використовувати, змінювати та вбудовувати бібліотеки в закрите комерційне ПЗ без зобов’язання відкривати весь власний код. Головна вимога — збереження повідомлення про авторство та копірайт первинного автора.
- Копілефт (Copyleft / Вірусні): GPL v2/v3, AGPL, LGPL (з обмеженнями). Вимагають, щоб будь-яке програмне забезпечення, яке містить цей код або скомпільоване разом із ним, публікувалося з повністю відкритим вихідним кодом під тією ж ліцензією.
Для замовника SaaS-рішень, мобільних застосунків або внутрішніх бізнес-систем наявність копілефт-модулів у комерційних бізнес-алгоритмах є неприпустимим ризиком.
Гарантії юридичної чистоти створеного програмного коду
Для нейтралізації цих ризиків до технічного завдання (SOW) та основного договору включаються конкретні запобіжники:
- Попередня згода: виконавець зобов’язаний узгоджувати повний перелік використовуваних компонентів третьої сторони (Third-Party Code) та їхні типи ліцензій до моменту інтеграції в проєкт.
- Пряма заборона вірусних ліцензій: фіксація вимоги, що у проєкті категорично заборонено застосування модулів під ліцензіями сімейства GPL/AGPL без письмового дозволу замовника.
- Звітність SBOM (Software Bill of Materials): зобов’язання підрядника надати вичерпний реєстр залежностей разом із релізом.
Коли умови договору узгоджені, а ліцензійна чистота гарантована, вирішальним етапом стає практичне та юридичне приймання результатів розробки.
Порядок приймання розробки та передачі репозиторію
Юридичний захист прав без технічного контролю перетворюється на фікцію. Замовник може мати ідеально складений договір, але якщо доступи до хостингу та вихідного коду залишаються в особистих облікових записах програмістів, компанія опиняється у вразливому становищі. Якщо на цьому етапі підрядник блокує репозиторій або шантажує припиненням підтримки, перегляньте детальний алгоритм дій, якщо виконавець блокує репозиторій.
Замовник відкриває організаційний обліковий запис у GitHub/GitLab на власну корпоративну пошту, а не дозволяє виконавцю вести розробку в його особистому просторі.
Повний трансфер репозиторію разом з архітектурною документацією, CI/CD конфігураціями та повною історією змін для збереження авторського сліду.
Тестування білду, верифікація контрольних сум (hash) коду та перевірка сторонніх бібліотек на відповідність ліцензійним умовам.
Юридичне оформлення переходу прав із зазначенням комерційного найменування, версії та технічних ідентифікаторів переданого ПЗ.
Зниження ролей розробників підрядника або їхнє повне видалення з організації, ротація API-ключів до бази даних та продакшн-серверів.
Акт передачі прав як ключовий документ
Стандартний первинний бухгалтерський документ — акт надання послуг — підтверджує лише виконання робіт та їхню вартість. Для захисту інтелектуальної власності потрібен Акт приймання-передачі (відчуження) майнових прав інтелектуальної власності.
Цей документ обов’язково повинен містити:
- Точну назву програмного забезпечення, його цільове призначення та номер версії/релізу;
- Посилання на конкретний Git-репозиторій та унікальний хеш коміту (Commit SHA) чи контрольну суму архіву вихідного коду;
- Пряме підтвердження відчуження майнових прав у повному обсязі з переліком дозволених способів використання;
- Розмір авторської винагороди за відчуження прав (вона може бути включена до загальної суми робіт або виділена окремим рядком, що критично для податкового обліку нематеріальних активів).
Отримання доступу до Git репозиторію замовником
Передача репозиторію — це передача ролі Owner (Власник) в організації GitHub або GitLab. Якщо виконавець надає вам лише роль Admin чи Developer, ви перебуваєте в зоні ризику: справжній власник акаунта може в будь-яку мить видалити команду замовника, змінити паролі або заблокувати доступ до проєкту.
Усі права доступу аутсорс-команди після завершення робіт або закриття Milestone мають бути обмежені або переведені у статус Read-only, якщо договір не передбачає подальшої платної підтримки та maintenance.
Судові ризики та типові помилки замовників
Аналіз конфліктів у сфері інформаційних технологій показує, що більшість спорів спалахують у моменти кризи комунікації: під час зміни технічних вимог, зриву термінів релізу або несподіваного підвищення вартості проєкту.
1. Фінансове непорозуміння: виникнення суперечки щодо оплати за додаткові зміни чи оцінки витрачених годин за моделлю Time & Materials.
2. Технічний демарш: аутсорсер блокує доступ до Git-репозиторію, серверів тестування або відмовляється видавати паролі під приводом «захисту своїх інтересів».
3. Юридичний конфлікт: направлення досудових претензій або позовів про стягнення боргу з одного боку та зустрічних вимог про порушення прав чи витребування результатів робіт — з іншого.
Конфлікти через оплату та утримання репозиторію
Коли виникає фінансова суперечка, розробники нерідко застосовують тактику притримання результатів робіт (retention of code), відмовляючись передавати вихідний код до сплати спірних сум. У цивільному праві право притримання речі існує, проте у сфері комп’ютерних систем такі дії можуть мати ознаки протиправного блокування доступу до інформації (стаття 361 Кримінального кодексу України), якщо репозиторій був створений на потужностях замовника.
Щоб уникнути подібного шантажу, замовник повинен з першого дня вести розробку на власних серверах, регулярно робити бекапи баз даних і вихідних кодів та чітко розмежовувати процедуру приймання етапів у договорі.
Запобігання повторному продажу коду іншим клієнтам
Підрядники прагнуть оптимізувати власну роботу, тому використовують готові напрацювання між різними проєктами. Тут замовнику важливо розуміти різницю між двома категоріями коду:
- Background IP (вихідна інтелектуальна власність підрядника): базові утиліти, стандартні коннектори, бібліотеки та фреймворки, створені виконавцем до початку вашого проєкту або незалежно від нього. На ці компоненти замовник зазвичай отримує безстрокову безвідкличну невиключну ліцензію.
- Foreground IP (створена інтелектуальна власність): унікальна бізнес-логіка, алгоритми, призначений для користувача інтерфейс та інтеграції, розроблені спеціально під ваше замовлення. Ця частина повинна відчужуватися клієнту на 100%.
Закріплення в угоді умов про конфіденційність (NDA) та неконкуренцію (Non-Compete) дозволяє притягнути підрядника до фінансової відповідальності у разі спроби клонувати ваш сервіс для іншого замовника.
Часті запитання (FAQ)
Як захистити інвестиції у розробку коду
Для бізнесу вихідний код — це не просто набір символів на диску, а ключовий матеріалізований актив компанії, що визначає її ринкову оцінку та інвестиційну привабливість. Формула вашої юридичної безпеки складається з чотирьох простих складових: договір із прямою умовою про повне відчуження прав, безперервний ланцюжок прав від усіх розробників, контроль над Git-інфраструктурою та юридично оформлений акт приймання-передачі.
Щоб уникнути типових підводних каменів, детально вивчіть наш детальний гайд про правовий статус коду сайту. Якщо ж ви плануєте масштабувати проєкт або залучати партнерів, своєчасна кваліфікована передача прав інтелектуальної власності та внесення змін силами профільних юристів гарантує чистоту цифрових активів та захистить ваш стартап від будь-яких правових ризиків.
