Чий софт? Спір Rambler і Nginx розкрив часті помилки бізнесу і розробників

Марія Ортинська

Патентний повірений, адвокат, керуючий партнер патентно-юридичної компанії IPStyle



 

Минулого тижня в компанії Nginx здійснювали обшуки. Співробітники правоохоронних органів прийшли в московський офіс розробників програмного забезпечення в пошуках доказів, пов’язаних зі спором про інтелектуальну власність.

Приводом для обшуків стали претензії Rambler Group. На її думку, веб-сервер Nginx – це службовий твір його колишнього співробітника – Ігоря Сисоєва, співзасновника Nginx. Зокрема, в минулому він працював у Rambler і нібито розробляв софт у робочий час, на робочому комп’ютері. Відповідно, на думку компанії, софт є службовим твором і будь-яке його використання без згоди Rambler порушує виключні права компанії.

У представників IT-ком’юніті і прихильників Nginx така позиція Rambler викликає ряд питань. Наприклад, чому претензії пред’явлено лише через 15 років? Чому в посадові обов’язки системного адміністратора (не програміста) входила розробка софта?
Насправді, такі суперечки – не виняток і в Україні. Часто роботодавець думає, що при прийомі працівника на роботу, він автоматично «купує» авторські права на всі його розробки та винаходи. Тобто помилково вважає, що розроблений і впроваджений працівником софт або пристрій, буде належать тільки компанії.

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

1. Якщо запрошуєте працівника на роботу, знайшли партнера або, навпаки, приймаєте офер компанії – обговоріть вже існуючі розробки двох сторін: компанії та працівника. Кому належать права нині? Хто, за чий рахунок продовжуватиме розробку? Звісно, такі домовленості слід зафіксувати в письмовому вигляді.

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

3. Службові завдання. Часто бізнес протиставляє діджіталізацію бюрократії або виправдовує безлад у документах і бізнес-процесах курсом на діджіталізацію компанії. Отже службові завдання компанія працівникам не ставить або ставить в усній формі, не контролює результати таких завдань і, відповідно, не має потім доказів, що співробітник створив твір, винахід під час виконання службових обов’язків.

4. Робота з підрядниками. Дуже часто, особливо при створенні винаходів, виникає необхідність передати розробку, креслення сторонній компанії – наприклад, науковому інституту або клієнту. Обов’язково фіксуйте таку передачу прав, правильно формулюйте предмет договору – результати тестів вашого обладнання. І прописуйте, кому вони належать. Здається, це очевидно, але на практиці стався конфлікт, коли науковий інститут подав заявку на патентування винаходу на своє ім’я, керуючись тим, що зробив найголовніше – дав висновок, що створений замовником винахід працює і відповідає заявленим технічним даним. Цей спір було вирішено мирним шляхом, але ризики судових розглядів були чималі.

5. Група авторів, винахідників. Важливо в командній роботі визначити – хто і за що відповідає, яка робота призводить до створення IP-прав, а яка – всього лише технічна. Наприклад, обробка фотографій призводить до співавторства на фотографію? Або підготовка сервера, на якому буде розгорнуто програмне забезпечення? Інакше кажучи, важливо чітко розмежувати технічні функції і ті, що призводять до створення IP-об’єкта, проговорити з усіма учасниками процесу, а бажано – ще й зафіксувати письмово. В такий спосбі можна зменшити ризики для бізнесу та нівелювати претензії: тестувальника – на співавторство комп’ютерної програми, асистента художника – на ілюстрацію.

НАПИСАТИ ВІДПОВІДЬ

Коментуйте, будь-ласка!
Будь ласка введіть ваше ім'я