Спори за ІТ-продукти та програмний код: хто є власником?

Програмний код як об’єкт права

Відповідно до Закону України «Про авторське право і суміжні права» від 01.12.2022 № 2811-IX (далі — Закон), комп’ютерна програма — це набір інструкцій у вигляді слів, цифр, кодів, схем, символів, виражених у формі, придатній для зчитування комп’ютером. Стаття 20 Закону прямо встановлює, що комп’ютерні програми охороняються як літературні твори. Авторське право виникає з моменту створення і не потребує реєстрації чи будь-яких формальностей (ч. 2 ст. 11). Це підтверджено у п. 17 постанови пленуму ВСУ від 04.06.2010 № 5, де зазначено, що охорона поширюється на комп’ютерні програми незалежно від способу або форми їх вираження, а у п. 18 — що твір вважається створеним з моменту надання йому будь-якої об’єктивної форми.

Принципово: охороняється форма вираження програми — вихідний та об’єктний код. Ідеї, алгоритми, концепції та функціональність авторським правом не охороняються. Це прямо підтвердив Верховний Суд у постанові від 22.05.2023 у справі № 760/16961/19, витлумачивши ст. 10 Угоди ТРІПС та ст. 18 Закону: «охороні підлягає лише форма виразу програм, тобто вихідний та об’єктний коди, а їхні структура, алгоритми й ідеї — охороні не підлягають». Конкурент може створити програму з аналогічним функціоналом, написавши власний код.

Водночас перелік захищених об’єктів ширший за сам код: специфікації, блок-схеми, бази даних, інтерфейси. З інтерфейсами не все однозначно. У справі Lotus Development Corp. v. Borland International, Inc. (Апеляційний суд США, Перший округ, 1995 р.; підтверджено Верховним Судом США) суд визнав інтерфейс меню методом роботи (method of operation), що не підлягає авторсько-правовій охороні. У справі Oracle America, Inc. v. Google LLC (Верховний Суд США, 2021 р.) копіювання 11 500 рядків Java API було визнано добросовісним використанням (fair use). Суд зазначив, що Google скопіював лише ту частину API, яка була необхідна для забезпечення сумісності з платформою Java, і таке використання мало трансформативний характер. Рішення не означає, що API загалом не охороняється авторським правом — Суд свідомо залишив це питання відкритим, вирішивши справу виключно на підставі доктрини fair use.

Хоча рішення американських судів не є джерелом права в Україні, ці справи мають значення з двох причин. По-перше, Україна є учасницею Бернської конвенції та Угоди ТРІПС, які формують спільну міжнародну рамку охорони авторських прав, і українські суди вже послуговуються положеннями ТРІПС при тлумаченні національного законодавства (зокрема, у згаданій вище постанові ВС від 22.05.2023 у справі № 760/16961/19). По-друге, принцип відмежування ідеї від форми вираження, на якому побудовані обидві справи, прямо закріплений у ст. 18 Закону та ст. 9(2) Угоди ТРІПС, тож висновки Lotus та Oracle можуть використовуватись як переконливий доктринальний аргумент в українських судах при вирішенні питання охороноздатності інтерфейсів та API.

Для виявлення непрямого копіювання у справі Computer Associates International, Inc. v. Altai, Inc. (Апеляційний суд США, Другий округ, 1992 р.) було сформульовано триетапний тест «абстрагування — фільтрації — порівняння» (Abstraction-Filtration-Comparison Test): абстрагування (відновлення порядку створення від коду до головної функції), фільтрація (відділення захищених елементів від ідей та scène à faire) та порівняння залишкового захищеного ядра — так званого «золотого злитка» (golden nugget).

Цей тест став міжнародним стандартом аналізу нелітерального копіювання програмного забезпечення і був сприйнятий судами ЄС, Великої Британії, Австралії та інших юрисдикцій. В Україні судді, як правило, не досліджують код особисто — цим займаються судові експерти з комп’ютерно-технічної експертизи. Методологія Altai-тесту може бути використана експертами як науково обґрунтований інструмент дослідження при проведенні комп’ютерно-технічної експертизи, а сторонами — як аргумент у процесуальних документах при обґрунтуванні факту або відсутності копіювання нелітеральних елементів програми.

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

Автор і правовласник

Автором комп’ютерної програми завжди є фізична особа. Їй належать невідчужувані немайнові права (ст. 11 Закону): авторство, ім’я, недоторканність твору.

Майнові права (ст. 12 Закону) — відтворення, розповсюдження, переробка, публічне сповіщення та інші форми використання — визначають, хто може комерційно використовувати код, ліцензувати його третім особам або заборонити таке використання. Майнові права можуть належати не автору, а іншій особі — роботодавцю, замовнику або набувачу за договором. В ІТ-спорах предметом конфлікту є саме майнові права: хто має право використовувати, модифікувати та комерціалізувати програмний продукт. Особисті немайнові права автора-програміста при цьому зберігаються, але на розподіл комерційних правомочностей не впливають.

Важливий нюанс для стартапів: співавторство на первісну програму не поширюється автоматично на її модифікації. У справі № 760/16961/19 співавтор оригінальної програми програв спір у трьох інстанціях, бо не зміг довести творчий внесок у кожну наступну версію продукту.

Службовий твір: коли код створює працівник

Стаття 14 Закону визначає службовий твір як твір, створений працівником у зв’язку з виконанням обов’язків за трудовим договором (контрактом). Для визнання коду службовим твором необхідне одночасне виконання кількох умов: наявність трудових відносин, створення програми протягом строку дії трудового договору, за рахунок роботодавця та у межах обов’язків або за письмовим службовим завданням.

Закон встановив: майнові права на службовий твір належать роботодавцю з моменту створення, якщо інше не передбачено договором. Це усунуло багаторічну колізію між ст. 429 ЦК (спільні права) та попередньою редакцією Закону. Наскільки гострою була ця колізія, ілюструє справа № 760/18303/14-ц: працівники держпідприємства зареєстрували на себе авторське право на програму, створену за державним замовленням. Суд першої інстанції відмовив роботодавцю, помилково застосувавши ст. 429 ЦК. Київський апеляційний суд (постанова від 06.02.2024) скасував рішення, визнав програму службовим твором та свідоцтво працівників недійсним, застосувавши ст. 16 Закону «Про авторське право і суміжні права» у редакції 1993 року, чинній на момент виникнення спірних правовідносин. Ключовий висновок: стан фінансування та невиплата авторської винагороди не змінюють статус службового твору.

На практиці роботодавці допускають типові помилки: не зазначають розробку програмного забезпечення у посадових обов’язках програміста, не оформлюють службові завдання, не фіксують акти створення результатів. Якщо у трудовому договорі відсутній чіткий опис обов’язків зі створення коду, програміст у спорі може стверджувати, що конкретна розробка виходила за межі його трудових функцій, а отже — не є службовим твором.

Окремий ризик — робота на корпоративному обладнанні. У справі № 756/960/15-ц Апеляційний суд м. Києва відмовив визнати авторство підрядника без свідоцтва про авторське право. У справі № 2-6118/11 Солом’янський районний суд міста Києва підкреслив: об’єктний модуль сам по собі не є доказом авторства. Висновок: пет-проєкти — у вільний час і на особистій техніці.

Замовник і підрядник: найризикованіший сценарій

Аутсорсинг розробки, включаючи поширену в Україні співпрацю з ФОП-розробниками, є найризикованішою моделлю визначення правовласника. Стаття 15 Закону встановлює, що майнові права на твір, створений за замовленням, переходять до замовника з моменту створення у повному складі, якщо інше не передбачено договором замовлення. Це нова норма, яка суттєво покращила становище замовників порівняно з попереднім регулюванням.

Важливо розрізняти передачу (відчуження) майнових прав та ліцензування. Передача означає повний перехід усіх майнових прав до набувача. Ліцензія лише надає дозвіл на використання у визначений спосіб і на визначений строк. Якщо договір містить лише формулювання про «виконання робіт», суд може кваліфікувати відносини як підряд: замовник отримує матеріальний результат, але не інтелектуальну власність. Це підтверджено у постанові ВС у справі № 910/2683/19 щодо змішаної природи договору розробки ПЗ (елементи підряду та ст. 1112 ЦК).

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

Технічний контроль не гарантує права власності

Доступ до GitHub-репозиторію, хмарної інфраструктури чи ключів — це фактичний контроль, а не правовий титул. Платформи GitHub та GitLab фіксують авторство комітів та історію змін, що може бути доказом. Проте контроль над репозиторієм не означає права на код — як зберігання картини не робить зберігача власником. Суд оцінює технічні докази в сукупності з договірними відносинами та актами передачі прав.

Сторона, що контролює інфраструктуру, може заблокувати доступ до продукту, не маючи прав, — це породжує окремі позови про надання доступу.

Навіть завантаження програми у RAM може бути копіюванням: у п. 31 постанови пленуму ВСУ від 04.06.2010 № 5 зазначено, що зберігання копії програми в пам’яті комп’ютера є порушенням майнового авторського права.

Open-source як прихований фактор

Сучасна розробка неможлива без open-source компонентів — до 80-90% кодової бази комерційного продукту може складатися з бібліотек із відкритим кодом. Ліцензії (MIT, BSD, Apache 2.0, GPL, LGPL, MPL) мають принципово різні умови. Використання GPL-компонентів без дотримання умов може зобов’язати відкрити код усього продукту. Несумісність ліцензій може унеможливити легальне розповсюдження — кожен компонент слід перевіряти на сумісність.

Доктрина «нечистих рук» (unclean hands) позбавляє судового захисту того, хто сам порушував ліцензії. Цей принцип було застосовано у справі Lasercomb America, Inc. v. Reynolds (Апеляційний суд США, Четвертий округ, 1990 р.), де суд відмовив позивачу у захисті авторських прав через зловживання — включення до ліцензійного договору умов, що обмежували конкуренцію.

Доктрина unclean hands як така не є частиною українського законодавства, однак її логіка кореспондує із загальними засадами цивільного права України. Зокрема, ч. 6 ст. 13 ЦК України забороняє дії, що вчиняються з наміром завдати шкоди іншій особі або у спосіб, що є зловживанням правом, а ч. 3 ст. 16 ЦК надає суду право відмовити у захисті права особі, яка зловживає своїми цивільними правами. Тому аргумент про «нечисті руки» контрагента, який сам порушував ліцензійні умови open-source компонентів, може бути релевантним і в українському судовому процесі — через механізм зловживання правом.

Open-source аудит може змінити розстановку сил у спорі: якщо «авторський» код виявиться запозиченим з відкритих бібліотек, обсяг спірних прав значно зменшиться.

Як доводити копіювання коду

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

Для непрямого копіювання у справі Computer Associates v Altai сформульовано триетапний тест: абстрагування (відновлення порядку створення від коду до головної функції), фільтрація (відділення захищених елементів від ідей та scène à faire) та порівняння. Результат фільтрації — «золотий злиток» (golden nugget): захищене ядро програми.

В Україні судді, як правило, не досліджують код особисто. Цим займаються судові експерти з комп’ютерно-технічної експертизи. Якість висновку експерта часто є вирішальним фактором. У тій же справі № 760/16961/19 фрагмент вихідного коду, доданий до реєстраційного свідоцтва, виявився недостатнім для ідентифікації програми — і суд констатував неможливість встановити факт переробки. Урок очевидний: зберігайте повний вихідний код кожної версії продукту, інакше навіть безспірне авторство буде неможливо довести.

Рекомендації для бізнесу

In-house: посадова інструкція програміста повинна чітко включати створення програмного забезпечення; кожен проєкт має супроводжуватися письмовим службовим завданням; результати роботи слід фіксувати актами із зазначенням переходу майнових прав. Окремо варто передбачити застереження про конфіденційність (NDA). Щодо обмеження конкуренції після звільнення (non-compete) — ефективність таких застережень в українській юрисдикції обмежена через відсутність прямого законодавчого врегулювання, тому на практиці захист забезпечується насамперед через NDA та угоди про нерозголошення комерційної таємниці.

Аутсорсинг/ФОП: договір повинен містити вичерпне IP-застереження: пряму вказівку на перехід усіх майнових прав до замовника, визначення моменту переходу, перелік конкретних прав. Рекомендується включати зобов’язання підрядника щодо передачі вихідного коду, технічної документації та всіх доступів, а також відповідальність за порушення прав третіх осіб через неліцензійне використання open-source компонентів.

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

Висновки

Власником ІТ-продукту є не той, хто оплатив розробку, не той, хто має доступ до репозиторію, і навіть не той, хто написав код. Власником є той, хто має правовий титул — належним чином оформлену підставу набуття майнових прав. Після набрання чинності Законом правила розподілу прав стали значно чіткішими, проте працюють лише за належного договірного оформлення.

Договірна та доказова база важливіші за технічний контроль над кодом. Контроль над GitHub-акаунтом чи хмарним сервером дає фактичну владу, але не правову. Профілактика спорів значно дешевша за судовий процес — витрати на якісне юридичне оформлення ІТ-відносин становлять частку від потенційних втрат бізнесу, що ризикує залишитися без прав на свій основний продукт.