ИТ-індустрія складає все більшу частину економіки України. За даними Мінекономрозвитку, в цій сфері працює більше 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 не розділяє виконавців на співробітників і підрядників, автором такого твору у будь-якому випадку є працедавець (чи замовник). Чекаючи інвестицій в ИТ-індустрію, нам не перешкодить узяти приклад з США, де більше усіх у світі заробляють на інтелектуальній власності.
Микита Полатайкокоординатор групи ИТ Sayenko Kharenko
