Питання звучить банально, поки не настає due diligence. Тоді юристи інвестора починають запитувати про кожен рядок: хто його написав, у якому статусі, за яким договором і чи є документ, що переносить права на компанію. І часто виявляється, що продукт, на який залучають раунд, юридично належить не тій особі, яка його продає.
Код — це твір
Комп’ютерна програма охороняється авторським правом як літературний твір. Права виникають автоматично з моменту створення, без реєстрації. Це зручно — і водночас саме тут криється проблема: якщо права виникають автоматично, то виникають вони в конкретного розробника, а не в юрособи. Далі все залежить від того, як оформлені відносини.
Штатний працівник
Тут ситуація найпростіша. За чинним Законом України «Про авторське право і суміжні права» (№ 2811-IX, діє з 2023 року) майнові права на службовий твір переходять до роботодавця з моменту створення твору в повному складі — якщо інше не передбачено трудовим договором або окремою угодою. Особисті немайнові права залишаються за автором, і працівник має право на винагороду.
Це помітна зміна порівняно з попереднім законом, за яким права належали роботодавцю й автору спільно. Але «за замовчуванням на користь компанії» не означає «можна не оформлювати». Ключова умова — щоб твір був службовим: створеним у зв’язку з виконанням обов’язків за трудовим договором. Якщо в посадовій інструкції розробника немає ані слова про розробку конкретного модуля, зв’язок доведеться доводити.
Підрядник на ФОП — головний ризик
Більшість українських продуктових команд працює через договори з ФОП. За загальним правилом майнові права на твір, створений за замовленням, також переходять до замовника з моменту створення — якщо договір не передбачає іншого. Здавалося б, безпечно.
На практиці ризики зосереджені в деталях:
- Дизайн і графіка. Для творів образотворчого мистецтва, створених на замовлення, закон встановлює зворотне правило: права залишаються в автора, якщо договором не передбачено інше. Виняток — елементи, спеціально створені як частина комп’ютерної програми. Тобто ілюстрації, брендинг і частина UI-графіки потребують прямого застереження в договорі.
- Рамкові договори без актів. Якщо в договорі немає опису результату, а акти виконаних робіт формулюються як «послуги з програмування за березень», ідентифікувати переданий об’єкт складно.
- Робота до підписання договору. Код, написаний на етапі «спробуємо тиждень, потім оформимо», формально залишається у розробника.
- Іноземні підрядники. Тут діє право іншої країни, і презумпції можуть бути протилежними — у багатьох юрисдикціях contractor за замовчуванням зберігає права.
Що перевіряють на due diligence
Стандартний перелік: ланцюжок договорів з усіма, хто торкався кодової бази, включно з тими, хто вже пішов; акти з ідентифікацією результату; положення про службові твори й винагороду; NDA; реєстр open source компонентів з ліцензіями; права на дизайн, тексти й зображення в продукті. Розрив у будь-якій ланці — привід знизити оцінку або відкласти угоду до усунення.
Найдорожче обходяться саме «історичні» розробники: людина, яка написала ядро на етапі MVP за усною домовленістю, через три роки формально володіє майновими правами на ключовий модуль. Домовитися з нею постфактум можна — але вже на її умовах.
Мінімальна гігієна
Для команди до 20 осіб робочий набір документів невеликий: типовий договір з розробником з чітким блоком про перехід майнових прав і винагороду, шаблон акта з описом результату, положення про службові твори, NDA та реєстр залежностей з ліцензіями. Один раз опрацьовані договори у сфері інтелектуальної власності закривають більшість питань інвестора наперед.
Юристи IP EYE проводять такі аудити для IT-компаній і стартапів — зазвичай до раунду, іноді, на жаль, під час нього. Різниця у вартості між цими двома моментами велика.
