Захист коду та IP: передача майнових прав у IT

Код як об’єкт права інтелектуальної власності

Комп’ютерна програма охороняється як твір — об’єкт авторського права за Законом «Про авторське право і суміжні права» № 2811-IX, чинним з 1 січня 2023 року. Із цього випливають три базові наслідки, які варто засвоїти до будь-яких договорів.

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

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

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

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

Працівники: що змінив Закон № 2811-IX

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

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

Тепер для творів діє спеціальне правило. Частина 2 статті 14 Закону № 2811-IX встановлює: майнові права на службовий твір переходять до роботодавця з моменту створення службового твору у повному складі, якщо інше не передбачено цим Законом, трудовим договором (контрактом) або іншим договором щодо майнових прав на службовий твір, укладеним між працівником (автором) і роботодавцем. Аналогічне правило закріплене в статті 440 ЦК.

Три практичні висновки з цієї норми.

Перехід відбувається в силу закону, а не внаслідок волевиявлення сторін. Окремого правочину про відчуження прав на службовий твір не потрібно: норма прямо визначає момент переходу.

Поняття службового твору ширше, ніж здається. Пункт 55 частини 1 статті 1 Закону визначає службовий твір як твір, створений працівником у зв’язку з виконанням обов’язків за трудовим договором (контрактом). Окреме завдання, наказ або технічне завдання на конкретний об’єкт не є обов’язковими: зв’язок із трудовими обов’язками встановлюється не формальним документом, а змістом самої трудової функції. Отже, код, написаний розробником у межах його роботи, є службовим твором навіть без окремого наказу.

Особисті немайнові права залишаються в автора. Частина 1 статті 14 Закону прямо це закріплює, тому роботодавець має дотримуватися права на авторство та права на ім’я. Водночас частина 3 статті 14 обмежила недоторканність службового твору: роботодавець має право доручити іншій особі завершити незавершений службовий твір, вносити зміни у завершений твір, супроводжувати його ілюстраціями, передмовами та післямовами.

Що з цього випливає для IT-компанії: для штатних розробників за трудовим договором ситуація сьогодні значно безпечніша, ніж була до 2023 року. Але це не привід нічого не писати. У трудовому договорі та посадовій інструкції варто чітко описати трудову функцію (щоб не виник спір, чи створено твір «у зв’язку з виконанням обов’язків»), прямо підтвердити перехід майнових прав у повному складі та врегулювати питання винагороди. Для резидентів Дія.City діє ще й стаття 24 Закону № 1667-IX: майнові права на об’єкт, створений гіг-спеціалістом у зв’язку з виконанням гіг-контракту, належать резиденту і переходять автоматично в момент створення об’єкта, якщо інше не передбачено договором.

Підрядники і ФОП: інше правило

А тут — головна зона ризику українського IT, бо значна частина розробників працює не за трудовим договором, а як ФОП або підрядник.

Для твору, створеного за замовленням, спеціальної норми на кшталт статті 14 Закону № 2811-IX немає. Тому діє загальне правило статті 430 ЦК: майнові права інтелектуальної власності на об’єкт, створений за замовленням, належать спільно творцеві та замовникові, якщо інше не встановлено договором.

Різниця між двома режимами вирішальна:

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

Що має бути в договорі з підрядником:

• передання (відчуження) майнових прав у повному складі із зазначенням, що права переходять до замовника в момент створення відповідної частини результату або приймання робіт;
• перелік способів використання, щоб уникнути тлумачення договору як обмеженої ліцензії;
• територія і строк — без обмежень, на весь строк чинності майнових прав;
• право замовника змінювати, допрацьовувати і створювати похідні твори, а також передавати права третім особам без додаткової згоди;
• обов’язок підрядника забезпечити відчуження прав від своїх субпідрядників і працівників — найчастіша прогалина в ланцюгу;
• гарантії щодо відсутності прав третіх осіб і щодо походження використаного стороннього коду;
• акти приймання з фіксацією переданого результату — без них довести обсяг переданого складно.

Англомовні шаблони work-for-hire потребують адаптації: прямої презумпції на користь замовника, як у деяких іноземних системах, українське право для робіт за замовленням не встановлює. Формулювання «all work product shall be deemed work made for hire» в українському суді саме собою прав не передає — потрібне положення про відчуження за статтею 49 Закону № 2811-IX.

AI-асистенти і право sui generis

Окремий ризик, який з’явився нещодавно і майже не врахований у стандартних договорах.

Стаття 33 Закону № 2811-IX запровадила право особливого роду (sui generis) на неоригінальні об’єкти, згенеровані комп’ютерною програмою — тобто об’єкти, утворені в результаті функціонування програми без безпосередньої участі фізичної особи. Твори, створені фізичними особами з використанням комп’ютерних технологій, до цієї категорії не належать.

Практично це означає розмежування всередині одного репозиторію:

• код, який розробник написав сам, зокрема з використанням AI як інструмента, залишається твором з охороною на весь строк дії авторського права;
• код, згенерований моделлю без творчого внеску людини в конкретні рядки, є об’єктом sui generis за статтею 33 — з охороною 25 років і лише майновими правами, без особистих немайнових.

Ключовий ризик: правила про службові твори на об’єкти sui generis автоматично не поширюються. Частина 2 статті 14 Закону говорить саме про службовий твір, а неоригінальний об’єкт твором не є. Суб’єктами права sui generis за частиною 2 статті 33 є автори комп’ютерної програми, їх спадкоємці, особи, яким передали майнові права на програму, або правомірні користувачі програми, причому договором можуть визначатися умови належності цього права.

Отже, якщо команда використовує AI-асистента, частина створеного може формально не належати компанії за тією самою логікою, що й решта коду. Закрити цей розрив можна лише прямо: передбачити в посадовій інструкції, трудовому договорі та в договорах з підрядниками, що обов’язки включають використання ліцензованих компанією AI-інструментів і що всі результати такого використання, зокрема об’єкти sui generis за статтею 33 Закону № 2811-IX, належать компанії.

Додатково варто перевірити умови самих AI-сервісів: що вони говорять про права на вихідні дані, чи використовують введені вами дані для навчання і які гарантії щодо відсутності порушення прав третіх осіб надає постачальник. Ширший контекст — у матеріалі про регулювання штучного інтелекту.

Чистота прав під час due diligence

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

Що саме перевіряє покупець або інвестор:

1. Повний ланцюг від кожної особи, яка торкалася коду, до компанії: працівники, ФОП, аутсорс-команди, фрилансери, субпідрядники, засновники на ранньому етапі.
2. Період до створення компанії. Код, написаний засновниками «на старті», часто ніколи формально не передавався юридичній особі — класична знахідка due diligence.
3. Іноземний елемент. Якщо розробники в інших юрисдикціях, перевіряється, за яким правом передавалися права і чи дійсні ці положення.
4. Open source у залежностях і сумісність ліцензій.
5. Торговельні марки й домени — чи зареєстровані на компанію, а не на засновника особисто.
6. Спори та претензії щодо прав на продукт.

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

Що робити зараз, не чекаючи на due diligence:

• провести внутрішній IP-аудит: список усіх, хто писав код, і документ, яким передавалися права від кожного;
• підписати підтверджувальні договори (confirmatory assignment) з тими, щодо кого документів немає, поки стосунки добрі;
• перевести права від засновників на компанію окремим договором відчуження;
• перевірити, чи всі договори з підрядниками містять відчуження, а не ліцензію;
• зафіксувати походження коду: історія репозиторію, акти, технічні завдання.

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

Open source і чужий код

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

Орієнтовний поділ ліцензій за рівнем ризику для пропрієтарного продукту:

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

Що має бути в компанії:

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

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

Захист бренду та ноу-хау

Авторське право покриває лише код. Решту цінності продукту захищають інші інструменти, і їх варто використовувати паралельно.

Торговельна марка. Назва продукту, логотип, а іноді й характерний елемент інтерфейсу реєструються як торговельні марки. Ключові правила: реєструвати на компанію, а не на засновника; обрати класи МКТП, що відповідають реальній діяльності (для IT це зазвичай 9, 42, іноді 35 і 38); подумати про міжнародну реєстрацію за Мадридською системою, якщо є ринки за межами України; і не забути про домен — його належність компанії перевіряється в кожному due diligence.

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

NDA і NCA. Для резидентів Дія.City стаття 26 Закону № 1667-IX дає окрему конструкцію договору про нерозголошення, а стаття 25 — компенсацію як заздалегідь оцінені збитки. Для компаній поза режимом ці питання врегульовуються загальними нормами, і тоді особливо важливо прописати розмір відповідальності, бо доводити фактичні збитки від витоку надзвичайно складно.

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

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

Чек-лист і типові помилки

Найпоширеніші помилки, які коштують компаніям прав на власний продукт:

1. «Я заплатив, отже код мій». Для підрядників за статтею 430 ЦК права спільні, поки договір прямо не передбачає відчуження.
2. Ліцензія замість відчуження. Договір дає право використовувати, але не робить компанію власником прав — і при продажу бізнесу це виявляється одразу.
3. Розрив у ланцюгу субпідрядників. Підрядник передав права, але не отримав їх від своїх виконавців.
4. Код засновників до створення юрособи, який формально нікому не передавався.
5. Ігнорування об’єктів sui generis, створених AI-асистентами.
6. Невраховані open source залежності, зокрема під AGPL у SaaS-продукті.
7. Торговельна марка й домен на фізичній особі замість компанії.
8. Відсутність режиму комерційної таємниці при спробі захистити алгоритми.
9. Опора на свідоцтво про реєстрацію авторського права як на підставу виникнення прав — Верховний Суд прямо вказав, що воно лише засвідчує авторство.

Чек-лист для компанії:

• трудові договори й посадові інструкції описують трудову функцію та підтверджують перехід майнових прав, включно з об’єктами sui generis;
• усі договори з ФОП і підрядниками містять відчуження майнових прав у повному складі, без обмеження території й строку, з правом на похідні твори;
• підрядники зобов’язані забезпечити відчуження від своїх виконавців;
• права від засновників передані компанії окремим договором;
• ведеться облік open source залежностей і діє політика допустимих ліцензій;
• торговельні марки та домени оформлені на компанію;
• діє режим комерційної таємниці з реальними заходами охорони;
• підписані NDA з усіма, хто має доступ до коду й даних;
• є акти приймання та історія репозиторію як докази створення й передання.

Окремо варто перевіряти питання прав разом із мотиваційними програмами: спеціаліст, який отримує частку, і спеціаліст, який не передав права на код, — це дві різні проблеми, які зазвичай виявляються одночасно. Про другу частину — у матеріалі про ESOP для IT.

ІТ-юристи практики IT-права LEGIUS проводять IP-аудит, готують договори з відчуженням прав для працівників і підрядників та супроводжують компанії під час due diligence. Щоб перевірити чистоту прав на ваш продукт до розмови з інвестором, запишіться на консультацію.