Давайте розберемося, кому належить ПО, написане на роботі, і які дії потрібні від роботодавця, щоб права на програму були закріплені за компанією.

Якщо лінь читати

Найняти програміста і платити йому зарплату недостатньо, щоб компанія отримала права на ПЗ. Потрібно обкластися паперами і дотримуватися певної процедури.

Якщо роботодавець цього не робить, він сидить на бомбі уповільненої дії. Вже багато співробітників відсудили кошти у колишнього роботодавця за використання своєї розробки.

А тепер про все по порядку.

ПО - об'єкт інтелектуальної власності

Будь-який результат творчої праці - об'єкт інтелектуальної власності. У тому числі програмний код. Це означає, що його захищає закон, а на використання потрібно дозвіл автора. Спеціальної реєстрації прав не вимагається. Написали код, права виникли автоматично.

Є нюанс. Код повинен бути оригінальний і створений творчою працею. 

А якщо ПО написано на роботі?

За замовчуванням нічого не змінюється. Автор володіє повним обсягом прав на розроблене програмне забезпечення.

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

Щоб права на ПЗ перейшли компанії, повинні бути дотримані наступні критерії :

1. Писати код - обов'язок співробітника.
2. Софт розроблений за завданням роботодавця.
3. Співробітник отримав авторську винагороду.

Зупинимося на кожному докладніше.

Писати код - обов'язок співробітника

Це означає, що функціональність по розробці ПО повинна бути прямо вказана в трудовому договорі або посадовій інструкції. Інакше написаний код належить працівнику і тільки йому.

З одного боку, це логічно. Припустимо, сейлу набридло вбивати реквізити клієнтів в шаблон договору, і він написав бота на Python, який сам підставляє дані компанії в документ.

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

Біда з справжніми програмістами, які розробляють сore-продукт. У багатьох компаніях використовують шаблони трудових договорів з інтернету, в яких змінюється тільки назва посади і зарплата.

У таких шаблонах обов'язки співробітника дублюють пункти Трудового кодексу, а значить, там немає ні слова про розробку ПО. З точки зору закону такі програмісти нічим не відрізняються від сейлів або бухгалтерів. Ні в тих ні в інших не прописаний обов'язок створювати ПО.

Як наслідок, все, що написано співробітником за кілька років роботи, - його власність. Якщо компанія захоче її використовувати, потрібно укладати з програмістом ліцензійний договір.

Можна заперечити: «У співробітника посада "програміст "! Чим, ви думаєте, він повинен займатися?». Це зрозумілий життєвий аргумент.

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

ПО розроблено за завданням роботодавця

Припустимо, трудовий договір складено правильно, в ньому прописана обов'язок писати код. Але як зрозуміти, що саме ця програма або її частина була написана конкретним співробітником?

Відповідь проста. Повинно бути складено службове завдання, в якому вказується, якого результату повинен досягти програміст. Грубо кажучи, це ТЗ на розробку ПО. Після виконання такого завдання співробітник звітує про це і передає результат своєї праці за актом.

Зверніть увагу! Службове завдання і акт в розумінні закону - папери, на яких стоять підписи роботодавця і працівника. Повідомлення в Telegram, усні вказівки начальства - все це не працює, потрібні папери.

Виникає питання: «Це що, по кожному співробітнику і по кожному завданню потрібні завдання та акти? А якщо у мене таких співробітників 10, 50, 100? »

Відповідь невтішна. Згідно із законом треба робити так, як написано вище, інакше ризикуєте залишитися без прав на ПО. Але процедуру можна спростити.

Як правило, управління розробкою відбувається в спеціальних системах (Jira, Trello). Можна зафіксувати у внутрішніх документах юридичну значимість завдань, які формуються в електронному вигляді в таких системах.

Чітко пропишіть момент створення завдання, процес визначення виконавця, момент завершення роботи і порядок передачі її результатів. В такому випадку ви знизите ризики.

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

Співробітник отримав авторську винагороду

Момент легкого здивування. Розробник вже отримує зарплату за те, що пише код, йому ще щось треба платити?

Згідно із законом виходить, що так. Авторський гонорар - окрема від заробітної плати виплата. Розмір винагороди за розробку ПО законом не встановлено, але він зафіксований для випадків створення службового винаходу.

Там два види гонорару:

1. За створення винаходу: разова премія 30% від зарплати.
2. За подальше використання винаходу: плюс одна зарплата в рік, а якщо винахід комусь продано, то 10-15% від суми угоди. Звільнення співробітника не впливає на обов'язок платити відсоток від продажів.

На практиці часто зустрічаються роботодавці, які вказують в договорі фіксовану невелику суму (наприклад, 200 грн), яку працівник отримує щомісяця разом із зарплатою в якості авторського гонорару.

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

Висновок

За замовчуванням права на все ПЗ, яке співробітник написав на роботі, належать тільки йому. Компанія може стати володарем таких прав, але для цього потрібно заморочитись.

Грамотний трудовий договір з описом функціональності по розробці, дотримання правил оформлення службових завдань, або ж передача авторських прав, - ось рецепт успішного використання програм, розроблених співробітниками.