ІТ-розробки, код і дизайн: кому належать майнові права та як їх передати

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

Маєте Телеграм? Два кліки - і ви не пропустите жодної важливої юридичної новини. Нічого зайвого, лише #самасуть. З турботою про ваш час!

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

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

• штатні працівники (регулюється КЗпП);
• ФОП-контрактори (взаємодія в межах цивільно-правових договорів про надання послуг / виконання робіт);
• гіг-спеціалісти (унікальна модель у межах правового та податкового режиму Дія.City).

Для кожної з цих категорій законодавство встановлює кардинально різні правила «дефолтного» (автоматичного) володіння правами.

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

Щоб змінити цей «дефолт», у трудовому договорі (контракті) чи посадовій інструкції обов’язково мають бути:

• чіткий і релевантний опис обов’язків. Якщо програміст написав унікальний код, а за посадовою інструкцією він значиться як «адміністратор мереж» або «технік», такий код навряд чи буде визнано службовим твором. Якщо створення об'єкта ІВ не входило в коло прямих обов’язків, права залишаються за працівником;
• пряма презумпція відчуження прав. Формулювання має бути імперативним: «Усі майнові права на об’єкти інтелектуальної власності, створені Працівником у зв’язку з виконанням службових обов'язків, переходять (належать) Роботодавцю з моменту їх створення в повному обсязі»;
• розподіл виплат. Щоб уникнути майбутніх позовів про «безоплатне привласнення», у структурі заробітної плати або окремим внутрішнім положенням варто чітко ідентифікувати частину доходу як винагороду за передачу майнових прав (авторську винагороду);

У відносинах із ФОП-підрядниками жодного автоматизму не існує в принципі. Якщо в цивільно-правовому договорі прямо не прописано, що майнові права переходять до замовника, вони за законом залишаються у розробника.

Ключові елементи договору з ФОП:

• момент переходу прав. Рекомендується використовувати формулу «на випередження»: «Права переходять у повному обсязі з моменту створення об’єкта (внесення першого символу коду чи створення першого елементу дизайну)». Це захищає компанію від ризику, коли розробник посеред проєкту зникає, а компанія не може легально використовувати вже написану ним частину софту через відсутність фінального акта;
• географія та строки. Права мають передаватися на територію всього світу (без обмеження країною замовника чи розробника) та на весь строк дії авторського права;
• тріада «Invoice-Act». Навіть за наявності ідеального договору, кожен регулярний платіж має супроводжуватися актом, де чітко зазначено: «Виконавець передає, а Замовник приймає майнові права на результати робіт/послуг, визначені у цьому Акті та створені за звітний період».

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

Це найбільш наближена до західних стандартів (зокрема, до англо-американської доктрини work for hire) модель, яка мінімізує внутрішні юридичні ризики. Проте, навіть за такої презумпції, фіксація завдань (через таск-менеджери) та підписання звітів є обов'язковими для підтвердження того, що об'єкт був створений саме «у зв'язку з виконанням контракту».

Юристу важливо розуміти природу того, що саме створює команда, адже правовий режим цих об’єктів різний:

• код (Software)  — охороняється законом як літературний твір. Об'єктом охорони є саме текст коду (вихідний та об'єктний), а не алгоритм чи ідея. Тому важливо фіксувати у документах передачу прав не лише на «фінальний реліз», а й на всі проміжні версії, архітектуру баз даних, підсистем та бібліотек, що створювалися у процесі;
• дизайн (UI/UX, графіка) — може охоронятися подвійно: і як об’єкт авторського права (графічний/ілюстративний твір), і як промисловий зразок (зовнішній вигляд виробу). При передачі прав на дизайн критично зафіксувати обов'язок передачі вихідних файлів (Figma-проєкти, робочі шари, вектори, шрифтові ліцензії). Без вихідних файлів компанія юридично володітиме «картинкою», але не зможе її технологічно адаптувати та змінювати.

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

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

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

Для юриста фраза в акті «написав код» або «надав послуги з розробки за травень» має нульову юридичну цінність. Акт приймання-передачі прав повинен максимально деталізувати об’єкт, щоб його можна було однозначно ідентифікувати в суді чи під час IP-аудиту.

В ідеалі акт має містити:

• посилання на конкретні завдання в трекінгових системах (наприклад, Task ID у Jira) або унікальні ідентифікатори комітів (вказівка на репозиторій та SHA-код коміту в GitHub);

• прямі гарантії (Warranties & Representations) Виконавця про те, що створений об’єкт є оригінальним і не порушує прав третіх осіб;

• підтвердження, що підписанням акта та отриманням оплати виконавець вважає свої майнові претензії повністю задоволеними.

Жоден сучасний софт не пишеться повністю з нуля. Розробники масово використовують готові Open Source компоненти та бібліотеки. Самі по собі відкриті ліцензії (як-от MIT або Apache 2.0) є безпечними для комерційного використання. Проте існує категорія так званих copyleft (або вірусних) ліцензій — наприклад, GPL (General Public License).

Якщо розробник інтегрував у комерційну закриту систему компонент під ліцензією GPL, за її умовами весь ваш продукт (увесь пропрієтарний код) може бути визнаний таким, що має «відкритися» для публічного доступу. Для комерційного продукту це катастрофа.

У договори з розробниками необхідно включати жорсткі запевнення про те, що вони не мають права використовувати Open Source-компоненти з жорсткими або вірусними ліцензіями без попереднього письмового погодження, а в разі порушення — зобов’язані відшкодувати всі збитки.

Якщо компанія планує масштабування, залучення раунду інвестицій чи продаж, юридична служба має превентивно перевірити три ключові речі:

• суцільне покриття договорами. Чи підписані IP-угоди або NDA з належними клаузулами абсолютно з усіма контриб’юторами? Сюди належать не лише lead-програмісти, а й дизайнери логотипів, фрилансери, які малювали іконки, та QA-інженери, які пишуть скрипти для автоматизованого тестування;

• формулювання про відчуження. Чи містять абсолютно всі документи формулювання про «повне відчуження майнових прав», а не просто пропонують «дозвіл на використання» (ліцензію);

• хронологічний збіг. Чи збігаються дати фактичного створення коду в репозиторії з періодами дії договорів та актів? (Поширена проблема: розробник почав писати код 1 березня, а ФОП чи договір з ним оформили лише 15 квітня. Права на перші 1,5 місяця розробки підвисають у повітрі).

Оформлення IP в IT — це не разовий юридичний акт під час реєстрації компанії, а безперервний гігієнічний процес. Юридична безпека та інвестиційна привабливість технологічного продукту тримаються на системній синергії трьох елементів: деталізованому договорі, регулярних індивідуальних актах та суворій внутрішній політиці контролю за використанням Open Source. В умовах жорсткої глобальної конкуренції чистота прав на код є такою ж фундаментальною вимогою до продукту, як і його працездатність.