ІТ-індустрія становить все більшу частину економіки України. За даними Мінекономрозвитку, в цій сфері працює більше 200 тис. Чоловік, а імпорт ІТ-послуг і продуктів в середньому зростає на 18% в рік. Тим не менш, вітчизняне авторське право мало враховує потреби виробників програмного забезпечення. Консервативність нормативного регулювання цього питання перетворює типовий процес розробки ПЗ в суцільне порушення копірайту.
Корінь проблеми в приналежності майнових прав на комп'ютерні програми, точніше, в моменті, з якого юридична особа може ними володіти. З цього і почнемо. Як відомо, ч. 2 ст. 16 Закону України «Про авторське право і суміжні права» (Закон) встановлює, що майнові права на службовий твір належать роботодавцю, якщо інше не передбачено договором. Але десятьма роками пізніше ч. 2 ст. 429 Цивільного кодексу України (ЦК) встановила, що майнові права на об'єкт інтелектуальної власності, створений у зв'язку з виконанням трудового договору, належать працівникові і роботодавцю спільно, якщо інше не передбачено договором. Деякі вважають, що норма Закону має перевагу як приватна, деякі, що ГК - як пізніша. Верховний суд віддав перевагу ГК, що було виражено в п. 24 Постанови Пленуму ВСУ №5 від 04.06.2010 р.
Як відступ, нагадаю, що ч. 4 ст. 181 Угоди про асоціацію ЄС зобов'язує Україну змінити регулювання - майнові права на комп'ютерні програми, створені як службові твори, повинні належати роботодавцю, якщо інше не передбачено договором. Але ввести цю норму в національне законодавство недостатньо, необхідно усунути системні суперечності. Причому, нижчевикладені протиріччя і проблеми стосуються не тільки службових творів, а й створених за замовленням (ст. 430 ЦК).
Колізії розбивають ілюзії
Наявність в ст. 16 Закону та ст.ст. 429, 430 ЦК слова «Належить» і можливості передбачити інше в договорі дає надію, що частину або всі майнові права належать роботодавцю з моменту створення службового твору і немає необхідності здійснювати передачу прав. І це начебто і не суперечить ст. 435 ЦК про те, що суб'єктами авторського права є автор і особи, які «Набуль» права відповідно до договору або закону. Але у авторів ст. 11 і ст. 7 Закону інша думка: (і) первинним суб'єктом, якому належить авторське право, є автор; (іі) авторське право має автор або особа, якій передано право; (ііі) суб'єктами авторського права є автори, їх спадкоємці та особи, яким вони передали свої авторські права.
Виходить, що навіть частину майнових прав на службовий твір не належить роботодавцю з моменту створення, повинна відбутися передача прав від автора роботодавцю. Тобто, момент створення службового твору і момент придбання роботодавцем прав на нього розділені в часі. Коли ж відбувається придбання прав роботодавцем? У наступну мить після створення? Після підписання акту прийому-передачі? Так як домовилися сторони? Шукаємо відповідь на це питання в юридичних виданнях, наприклад, у статті «Гарантійний урок» в газеті «Юридична практика» № 1 (838) від 07.01.2014 р І автори, і коментатори таких статей рекомендують підписувати акт прийому-передачі прав, а деякі - ще й окреме додаткову угоду по кожному твору. Тобто багато юристів вважають, що права переходять з моменту підписання акту, так само часто пишуть і в договорах.
Проблема в тому, що акти та іншу документацію неможливо підписувати кожен день, це робиться в кінці місяця, кварталу або в кінці чергової ітерації створення продукту. Так як момент створення твору і момент переходу прав істотно розділені в часі, то за цей час відбувається маса порушень.
Типове порушення №1: зміни без дозволу
Програміст створив невелику програмку, яка сподобалася його керівництву. Для її доопрацювання і перетворення в готовий продукт була створена команда з шести програмістів. Але ж, авторським правом захищається творіння програміста з моменту створення, навіть якщо воно не завершене (ч. 2 ст. 8 і ч. 2 ст. 11 Закону, ч. 2 ст. 433 і ст. 437 ЦК), а автор ще не підписав акт і не передав майнові права роботодавцю.
Виходить, що колеги порушують його авторське право, адже будь-які зміни твору - це використання, яке можна здійснювати тільки з дозволу нашого програміста (ст. 15 і ст. 32 Закону , ст. 440 і ст. 441 ЦК). А такий дозвіл мізерно, якщо воно не викладено у письмовій формі (ст. 33 Закону, ст. 1107 ЦК).
Типове порушення №2: завершене і похідне
При розробці програмне забезпечення проходить масу змін і доробок (прототип, альфа, бета, пре-реліз тощо), за цей час продукт, особливо гра, може змінюватися до невпізнання кілька разів. Функціонал, сценарії та інше не тільки переробляються по кілька разів за місяць, але іноді й відкидаються. Твір вже не завершується, а створюється похідне, а потім і похідне від похідного. Передаючи права в кінці періоду, є ризик передати права тільки на поточну версію. Кому тоді будуть належати права на первинні твори і на все те, що не увійшло в поточну версію?
Вирішувати ці проблеми, в ідеалі, потрібно внісши відповідні зміни до законодавства, щоб майнові права виникали у роботодавця або переходили до нього відразу після створення, без здійснення автором яких-небудь додаткових дій. Обидва варіанти цілком вписуються в концепцію «набуття» на підставі договору, згідно ст. 435 ГК, але вимагають зміни ряду перерахованих вище норм Закону.
На сьогодні ці проблеми вирішуються за допомогою практичних моментів розробки. Так, звичайно є своєрідний репозитарій, куди програмісти регулярно «зливають» свої напрацювання, він може бути технічно по-різному реалізований, знаходиться на сервері в офісі або в «хмарі», але зазвичай він фіксує хто, що і коли на нього «скинув» , а також може зберігати всі проміжні версії. Якщо підписувати договір про службові творах, можна передбачити в ньому такий репозитарії і пов'язувати перехід прав з моментом завантаження твори в репозитарій автором (надати значення такого конклюдентних дій).
Типове порушення №3: спосіб ідентифікації
Загальні вимоги законодавства (наприклад, ст. 638 ЦК), як і судова практика (наприклад, п. 30.2 Постанови Пленуму ВГСУ №12 від 17.10.2012 р), вимагають від нас чітко визначати конкретний твір (предмет договору). Ця вимога була б просто виконати, якби мова йшла про вже створеному творі. Створення твору також відрізняється від простого підряду, де результат робіт може бути заздалегідь описаний до найменших деталей. Даючи завдання співробітнику, ми ще не знаємо точно яким буде результат, робота адже творча. Роботодавець може тільки сформулювати призначення твору, загальні вимоги до нього та критерії якості виконання робіт - що і пропонується робити вже сьогодні.
Але створення службового твору за своєю природою - це виконання робіт, а не продаж майна. Так як предметом є саме роботи, то і результат робіт належить роботодавцю. Крім того, прогрес зробив крок далеко вперед і зараз метою замовлення таких творів як комп'ютерна програма є не матеріальний об'єкт, в якому втілено твір, а права на нього. Тому результатом робіт, в даному випадку, не можна назвати тільки твір у відриві від майнових прав інтелектуальної власності.
Тим не менш, багато на ринку займаються докладної ідентифікацією заднім числом, тобто готують службові завдання вже після створення творів, що, безумовно, є порушенням. Ще більша частина ринку робила формальне ідентифікацію, тобто з даних у службовому завданні неможливо однозначно встановити яке саме твір створено на його підставі.
Типове порушення №4: суцільне співавторство
Над створенням великих продуктів працюють десятки виконавців, залучаються зовнішні фахівці й цілі команди фірм підрядників. І якщо зовнішній фахівець створює музику, окреме відео або інший об'єкт, легко виділяється з усього ПО, то ідентифікувати його не буде проблемою. Практика ж створення програмних продуктів така, що учасники процесу працюють з кодом, графікою і версткою один одного, і виділити результат робіт кожного з них досить складно. Виникає проблема ідентифікації об'єктів, права на які передаються. В результаті в документах часто можна побачити передачу прав на об'єкти, які насправді не створював підписант, або передачу прав кількома особами на один і той же об'єкт без зазначення їх співавторства.
Ця проблема актуальна для українських ІТ- компаній, так як у них майже немає штатних співробітників, а є багато підрядників (фізичних осіб - підприємців), так вигідніше з економічної точки зору. У цій ситуації, команду проекту небажано відображати в документах як авторський колектив, що б їх згодом не визнали трудовим колективом.
Потенційне порушення №5: шлюб
Повертаючись до питання поділу в часі моменту створення твору (виникнення прав у співробітника) і переходу прав до роботодавця, варто згадати про сімейний стан автора. Якщо співробітник перебуває у шлюбі, а майнові права інтелектуальної власності є майном (ст. 190 ЦК), то чи не придбано чи це майно в шлюбі? Цілком можлива поява судової практики, яка визнає майнові права на службовий твір спільною сумісною власністю подружжя відповідно до ст. 60 Сімейного кодексу України (далі - СК), а значить, і передавати такі права можна тільки з дозволу другого з подружжя (ч. 2 ст. 65 СК).
Таке твердження здається неприродним як для службового твору, але воно цілком логічно випливає з сьогоднішнього законодавчого регулювання авторського права, описаного вище. Природно, це питання б не стояло, якби майнові права на службовий твір відразу належали роботодавцю, чого і вимагає від України ч. 4 ст. 181 угоди про асоціацію з ЄС.
У теж час, Україна зобов'язалася внести зміну тільки відносно приналежності прав на комп'ютерні програми, а це поняття охоплює лише код (ст. 1 Закону) . А як же бази даних і графічний інтерфейс, без яких складно уявити сучасне ПЗ, звуки та інші медіа, типові елементи ігор - сценарії, персонажі та інше? Кому належатимуть майнові права на такі службові твори і з якого моменту? Щоб створити сприятливий бізнес клімат для творців ПЗ, 3D-моделей та відеопродукції, краще доопрацювати всю систему авторського права, а не створювати виключення для комп'ютерних програм.
Вищеназвані зміна повинні також торкнуться системи прав на твори під замовлення, а не тільки на службовий твір. Це необхідно, адже ІТ-компанії ніколи не зможуть повністю відмовитися від ситуаційного найму незалежних підрядників. До речі, американська концепція
work for hire
не поділяє виконавців на співробітників і підрядників, автором такого твору в будь-якому випадку є працедавець (або замовник). Чекаючи інвестицій в ІТ-індустрію, нам не завадить взяти приклад з США, де найбільше у світі заробляють на інтелектуальної власності.
Микита Полатайко
, координатор групи ІТ