Усе, що ви хотіли знати про авторські права в ІТ

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

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

Однак до візиту в юридичну компанію можна підготуватися. Сподіваюсь, після цієї статті ві уявлятимете, який простір для творчості має юрист для ІТ :)

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

Ілюстрації Уляни Патоки

Авторські права != патент

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

Право інтелектуальної власності охоплює і патенти і авторські права. Воно захищає можливість автора контролювати частину результату своєї праці. Це виражається у правах: тільки автор програми або треті особи, яким автор передав свої права повністю чи частково, можуть дозволяти публікувати її, встановлювати плату за її використання, поширювати під власним іменем, псевдонімом чи взагалі анонімно. Ви можете бути власником авторських прав на програму та/або власником патенту — як водночас, так і окремо, бо патент і авторські права не є ні тотожніми, ні взаємовиключними.

За загальним правилом авторські права захищає конкретно втілення певної ідеї (скажімо, алгоритму, записаного у вигляді коду), альо не поширюється далі — на конкретно технічне рішення, що лежить в основі програмного забезпечення. Наприклад, власне програму чи її складову як код буде захищено, але інноваційне рішення, сам алгоритм — ні. Якщо основний намір — завадити іншим використовувати аналогічний метод роботи, то теоретично вам у цьому допоможе патент, що містить комп'ютерній ютерну програму як складову у країні, де комп'ютерні програми можна патентувати і ця практика прижилася, але не авторські права.

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

Однак спроба включити ПЗ до складу винаходу не завжди потрібна чи навіть корисна. Інколи захистити програмне забезпечення, що використовується лише всередині компанії і було розроблене самостійно задля збереження режиму конфіденційності, можна як комерційну таємницю. Для випадків, коли немає бажання передавати розробки широкому загалу, альтернативним шляхом захисту є угода про нерозголошення конфіденційної таємниці (NDA). Робота під NDA є поширеною практикою, і про різні аспекти її укладання написано багато, тому зупинятися на цьому у статті буде зайвим. Якщо ж хочете знати більше, почніть своє ознайомлення, наприклад, зі статті моєї колежанки Юлі Підодвірної .

Що розробник може закріпити як авторські права

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

З певними обмеженнями та уточненнями перерахуємо фрази об'єкти , які можливо захистити як свою власність :

Крім того, досі відбуваються дебати щодо того, кому мають належати створені програмою твори мистецтва (згенеровані картинки або музика) і чи підлягають такі фрази об'єкти захисту загалом. Мови програмування і функціонал, а також формат файлів з даними не підлягають захисту в межах авторського права . Принаймні у ЄС, що підтверджується рішенням у справі SAS Institute Inc. v. World Programming Ltd. (C-406/10).

Що дає спеціалісту авторські права

Перш ніж читати далі, згадаймо: авторські права поділяються на майнові (tangible) та немайнові , інколи моральні (intangible, moral).

До майнових прав належать виключне право на використання твору і заборони його використання іншими особами. Тобто тільки автор може дозволяти іншим особам використовувати твір, хоча і з певними обмеженнями. Наприклад, через добросовісне використання (fair use) або якщо програма була написана на замовлення чи в співавторстві:

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

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

Як отримати права на програму

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

Інколи можна почути, що у США програмне забезпечення має обов'язково записуватись на матеріальний носій, як вимагає федеральний закон. Однак судова практика зазвичай здатна захистити і ті роботи, які не були зафіксовані. Фахівці, що регулярно працюють із правом США, повторюють, що реєстрація у Copyright Office може знадобитись, наприклад, якщо правовласник планує подавати до суду та просити компенсувати й стягнути statutory damages і вартість юридичного супроводу. Хоча траплялося, що суд погоджувався це зробити і без реєстрації, оскільки Бернська конвенція не передбачає потреби у формальностях.

В Україні фіксація на матеріальному пристрої потрібна для реєстрації ЛЗ у Департаменті інтелектуальної власності. Однак авторські права не прив'язана зобов'язані до моменту викладення комп'ютерній комп'ютерної програми на папері. У ч. 2 ст. 11 Закону України «Про авторські права і суміжні права» вказано, що для виникнення і здійснення авторського права не вимагається реєстрація твору чи будь-яке інше спеціальне його оформлення, а також виконання будь-яких інших формальностей. Цю думку підтримує і судова практика: у постанові пленуму Верховного Суду України «Про застосування судами норм законодавства у справах про захист авторського права і суміжних прав» від 04.06.2010 року № 5 у п. 17 зазначено, що охорона застосовується до комп'ютерній комп'ютерних програм незалежно від способу або форми їх вираження, а у п. 18 — що твір вважається створеним з моменту первинного надання йому будь-якої об єктивної форми з урахуванням суті твору. Створений, а отже, захищений.

«Мені ж цю програму лише студентам показати. У розрізі. Можна?»

Некомерційне і помірне добросовісне використання (і схожа доктрина fair use у деяких країнах), тобто не з метою отримати прибуток, зазвичай дозволене.

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

Чи можна код захистити від плагіату

Комп'ютерні програми підлягають захисту як літературні твори . Якщо відкрити Бернську конвенцію 1891 року (так, це ХІХ століття), то комп'ютерній комп'ютерних програм і баз даних там з очевидних причин не знайте, тому їх зарахували до літературних творів. Хоча фактично законодавство кожної країни містить особливе регулювання у цій сфері.

Маленьке завдання: перевірте свій договір з іноземною компанією. Яке право там вказано?

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

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

В англійському праві актом копіювання може бути навіть завантаження комп'ютерній комп'ютерної програми у volatile memory (RAM) комп'ютера . А копіювання — виражатися у різних формах:

В Україні неправомірне зберігання копії комп'ютерній комп'ютерної програми в пам'яті комп'ютера є порушенням майнового авторського права (п. 31 вже згаданої постанови пленуму ВСУ від 04.06.2010 № 5).

Певної обережності вимагає аргументація. Авторським правом не захищаються ідеї: створення програми, яка виконує ту ж функцію, що і вже випущена раніше аналогічна програма, без інших «підозрілих» факторів не має вважатися порушенням прав інтелектуальної власності . Форма вираження комп'ютерній комп'ютерної програми, до якої і належатимуть згадані фрази об'єкти непрямого копіювання, все-таки підлягає захисту.

Варто зауважити, що встановити факт копіювання не так легко . Наприклад, судові органи США часто з метою виявити і підтвердити факт порушення авторського права на програму використовують сформовані судовою практикою тести. У справі Computer Associates International Inc v Altai Inc. суддя Волкер виокремив такі критерії копіювання :

  1. Абстрагування — відновлення порядку створення непрямо скопійованого елементу з кінця, від коду програми позивача до головної функції програми.
  2. Фільтрація — відділення захищених авторським правом матеріалів від таких, що захищаються іншими інститутами права інтелектуальної власності або не захищаються зовсім: елементи, що були взяті зі суспільного надбання (загальновідомі спосібі «витягування» даних з файлів чи сортування даних за абеткою тощо), є ідеями або становлять так звані sc?ne ? faire. У доктрині США це частини твору, які є типовими та очікуваними для певного жанру і тому ймовірно будуть втілені у кожному творі цього жанру. Наприклад, перерахування змінних на початку кодом, визначення типу змінних тощо. У результаті залишаються елементи, які становлять «золотий злиток» (golden nugget), або захищене авторським правом втілення ідеї.
  3. Порівняння : встановлення, чи відбулось копіювання у програму відповідача і чі становив скопійований елемент суттєву частину твору-донора.

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

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

Саме через бажання спертись на плечі гігантів і використати вже готові рішення у формі, зокрема так званих «вільних» ліцензій на кшталт GNUv3, розробник модифікованої програми може залишитися розгубленим. Основна мета подібних ліцензій — унеможливити деякі дії, які обмежують використання програми-донора (тобто порушують «свободи» програм у розумінні GNU GPL). Однак якщо брати безкоштовно, то можна несподівано виявити, що за це доведеться платити власними розробками. Зокрема тому, що це не суспільне надбання, а твір, який свідомо поширюється за умови, що всі наступні похідні будуть також передані світу для дослідження та удосконалення (як при деяких копілефт-ліцензіях). Тому важливо уважно обирати ліцензію для поширення своїх розробок: наприклад, попри циркуляцію міфів про вартість ПЗ і вартість виготовлення копії офіційно GNU GPL дозволяє на власний розсуд монетизувати ліцензовані твори, але зобов'язує розробника залишати письмову пропозицію надати вихідний текст при поширенні двійкових файлів.

Кому належать права на код

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

Майнові права на твір можна передати кількома способами:

  1. Договір про надання послуг або трудовий контракт. Найімовірніше, розробник стикнеться саме з цією формою передачі прав інтелектуальної власності: в процесі виконання роботи чи надання послуг всі програми чи їх елементи, що захищені авторським правом, будуть передаватися роботодавцю чи замовнику, а сам працівник чі виконавець отримуватиме плату за виконану роботу чи надані послуги з урахуванням компенсації за передані фрази об'єкти. Я раніше писала статті про договори і згадувала про перехід інтелектуальної власності , але залишила і кілька слів про це на ДОУ .
  2. Ліцензія. Їх можна поділити на кілька підвидів залежно від умов, на яких інші можуть користуватися програмою:
    • ті, що надають можливість користувачам вільно використовувати й далі поширювати твір;
    • комерційні ліцензії, зокрема умовно-безоплатні.

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

Щодо майнових прав, то між Цивільним кодексом і Законом України «Про авторські і суміжні права» є колізія. На практиці вона ускладнює розуміння законодавства, оскільки кожен з правових актів претендує на перевагу: Цивільний кодекс як «основний акт цивільного законодавства» і Закон «Про авторські права і суміжні права» як спеціальний акт порівняно з більш загальним правопорядком, описаним у ЦК.

Закон України «Про авторські права і суміжні права» Цивільний кодекс
Службовий твір визначається як «твір, створений автором у порядку виконання службових обов'язків відповідно до службового завдання чи трудового договору (контракту) між ним і роботодавцем» (абз. 51 ст. 1 Закону). Окремого визначення об'єкта авторського договору немає, є лише згадка про умови його укладання (ч. 6 ст. 33 Закону). Службовий твір визначається як «об'єкт, створений у зв'язку з виконанням трудового договору» (ст. 429 ЦК) і відділяється від «об'єкта, створеного за замовленням» (ст. 430 ЦК).
Немайнові права належать виключно автору (ч. 1 ст. 16 Закону). Немайнові права належать працівникові. Однак окремі немайнові права можуть належати юридичній чи фізичній особі, де або у якої працює працівник (ч. 1 ст. 429 ЦК).
Виключне майнове право на службовий твір (тобто такий, який був створений на підставі трудового договору) належить роботодавцю, якщо інше не передбачено трудовим договором (контрактом) та (або) цивільно-правовим договором між автором і роботодавцем (тобто якщо створення програмного забезпечення не входило в обов'язки працівника, але стало побічним продуктом виконання завдань роботодавця) (ч. 2 ст. 16 Закону); первинним є правовласником не працівник, а його роботодавець. Майнові права на об'єкт, створений у зв'язку з виконанням трудового договору, належать працівникові-автору та юридичній або фізичній особі, де або у якої він працює, спільно (якщо інше не встановлено договором) (ч. 2 ст. 429 ЦК). Первинний правовласник — працівник, роботодавець може бути похідним співвласником.
Невідчужувані від творця. Ім'я автора ПЗ можна не вказувати тільки в тому випадку, якщо у договорі на послуги чи передання прав на об'єкт інтелектуальної власності зазначено, що автор бажає залишитись анонімом. Особисті немайнові права на програму, створену за замовленням (договір про надання послуг з розробки, наприклад) належать творцеві об'єкта. Однак в окремих випадках, передбачених законом, немайнові права можуть належати замовникові (ч. 1 ст. 430 ЦК).
Передаються авторським договором (ст. 31 Закону і ч. 6 ст. 33 Закону). Майнові права на програму, створену за замовленням, належать розробнику і замовникові спільно, якщо інше не встановлено договором (ч. 2 ст. 430 ЦК).

Звичайним підходом залишається «автоматична» передача прав на створене ПЗ роботодавцю.

Аналогічні підходи діють і в інших країнах: відповідно до доктрини work for hire у праві США, якщо будь-який твір був створений під час виконання трудових обов'язків, роботодавець чи інша особа вважається автором та правовласником авторських прав на цей твір, якщо інше не погоджене сторонами прямо і не закріплене письмово. Головна умова — щоб та робота, яка виконується на work for hire, підпадала під одну з дев'яті яті підстав , тому читати договір треба уважно, враховувати контекст судової практики штату і характер робіт.

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

Ліцензії на вільне програмне забезпечення — як це працює

Ліцензії потрібні програмістам з багатьох причин:

Програмне забезпечення може поширюватися на умовах різних ліцензій. Наприклад, MIT, BSD, Apache, AFL, GPL, LGPL, MPL, Qt License, Artistic License, Creative Commons License, Sun Community Source License and Commercial Use Supplement, Microsoft Shared Source Initiative тощо. Деякі з них є небезпечними для недосвідчених розробників, які бажають потім продавати ліцензії на свої програми. Для прикладу необережно додана підпрограма на умовах GNU GPL. Тому перш ніж використовувати програмне забезпечення, що поширюється на умовах GPL, варто уточнити, чи всі інші ліцензії у структурі інтелектуальної власності компанії поєднувані (compatible) одна з одною .

Наприклад, для GPL-ліцензій інформація про поєднувані ліцензії є на сайті Free Software Foundation . Це необхідно, щоб уникнути поширення ліцензії з найбільшими обмеженнями, що стосуються лише невеликої частини продукту, на весь продукт. Але будьте уважні: вимоги GPL можна читати і трактувати таким чином, що вони будуть непоєднувані навіть з тімі ліцензіями, що згадуються на Free Software Foundation. Під час роботи з ліцензіями досить неприємно готувати пропрієтарний продукт продаж і бути зрештою змушеним поширювати його безкоштовно і з відкритим кодом. Це залежить від конкретної ліцензії: наприклад, ПЗ під GPL можна продавати, але з деякими обмеженнями для збереження «свобод», проголошених ліцензією.

Звичайними елементами вільної чи відкритої ліцензії є такі:

Також ліцензії можуть містити інші пункти: визначення термінів, умови одержання, взаємні зобов'язання (наприклад, copyleft) тощо.

Будьте уважні! У деяких країнах, де людина перебуває і працює або права яких підпорядкований її договір із замовником, може існувати низка правил щодо форми і змісту ліцензій, які не виконуються при використанні відкритих чі вільних ліцензій . Хоча у багатьох державах законодавство про авторські права адаптувалось до цього явища: наприклад, США давно вважає відкриті ліцензії дійсними та такими, що зобов'язання язують сторони, проте з доказуванням юридичної сили ліцензії у суді можуть виникнути проблеми .

Зокрема, в Україні стає на заваді пряме тлумачення судом припису ст. 33 Закону України «Про авторські права і суміжні права» про обов'язкову письмову форму ліцензії та небажання визнавати стандартну копію умів договором приєднання або договором, укладеним у електронною формі. А також відсутність оплати за таким договором (що є істотною, а отже, обов'язковою частиною ліцензії відповідно до ст. 33(2) Законом України «Про авторські права і суміжні права»). Водночас визнавати необхідність платити за використання чи модифікування деяких опенсорс-продуктів суперечить філософії вільного програмного забезпечення per se.

Замовник вимагає додати пункт про передачу йому всього софту на GNUv3. Що робити

Вісь кілька стартові точок, які можуть наштовхнути вас на вибір шляху перемовин:

  1. Передусім прочитати текст ліцензії GNU GPLv3, особливо якщо раніше ви з нею не малі справ. Уточнити у замовника, чи він має на увазі саме цю ліцензію, а не, скажімо, LGPL.
  2. Подумати, чи пропонували вам за договором із замовником роялті з продажу цього продукту як оплату за послуги. Якщо так, краще оцінити імовірні юридичні наслідки додавання власного пропрієтарного або копілефт-компоненту до фінального продукту, бо інакше вам доведеться серйозно переговорити із замовником щодо оплати послуг.
  3. Запропонувати внести у договір деякі правки. Насамперед відмову від гарантії власного авторства і тому застереження про неможливість передання будь-яких прав на використані GPL-рішення, оскільки у вас як у користувача вже поширеної версії не може бути прав ліцензіара. Треба буде встановити весь ланцюжок співавторства і зв'язку язатися з усіма, хто робив внески (contributions) до використаного ПЗ.
  4. Переконатися, що створений вами продукт на лінцензованому ПЗ — незалежний і його можна ліцензувати без дозволу правовласника інструмента (ПЗ).
  5. Перевіряти кожен використаний опенсорс-інструмент на поєднуваність ліцензій з фінальною, а також на наявність у них принципом копілефту — ліцензій, що вимагають безкоштовного поширення всіх похідних творів. Ну й закласти ці ризики та процедури у договорі із замовником, звісно.
  6. Не допускати поєднання переданого GPL-продукту зі своїми або іншими клієнтськими пропрієтарними розробками, які згодом плануєте монетизувати.

Ще варто подумати про ті, як обґрунтовувати наявність опенсорс-елементу у фінальному продукті . Щоб підготувати пакет документів про структуру власності на певний застосунок чі сайт, може знадобитися купити необхідний інструмент чи елемент у компанії-постачальника за номінальною ціною або як частинку послуг. Метою цього є отримати договір, рахунок, акт приймання-передачі як докази легальності використання в програмному продукті «вільного» ПЗ.

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

Чим загрожує ігнорування ліцензій

Уявімо, що Company LLC зі штабом розробки і підтримки в Україні продає за 12,99 долара своє програмне забезпечення. У компанії під час розробки є два шляхи:

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

Тепер чи допустима, що компанія пішла першим шляхом. І наразі в антивірусі деякі з його важливих функцій побудовані за допомогою ліцензованого за умовами GPL опенсорс-матеріалу. Цілком імовірно, що в результаті розробки програма від «Компанії» буде справді надзвичайно ефективною і прибутковою. Найімовірніше, розробникі не будуть вказувати і прикріплювати всі необхідні застереження та умови ліцензій у файли програми, щоб заплющити очі на порушення умов ліцензії. Компанії може пощастити, і ніхто кілька років не помітить цього порушення.

Однак якщо одного жахливого дня компанія помітить, що новий конкурент містить ті самі або ж навіть ефективніші функції і код конкурента підозріло схожий на код компанії, у неї може не залишитися жодних юридичних засобів захисту. Доктрина «нечистих рук» (unclean hands в авторському праві США) не дозволить компанії поскаржитись до суду: відповідач у судовому провадженні може вказати, що вона використала опенсорс. Суд дослідить це і підтвердить, що компанія ще й при цьому поширювала свій продукт з порушенням умов ліцензії GPL. Внаслідок цього компанія втрачає права на використання коду, оскільки не виконала умови GPL. І в результаті опиняється у ще гіршому становищі : компанія не тільки де-факто не завадила конкуренту процвітати, а й може стати відповідачем у позові ліцензіара кодом, який виклав його у загальний доступ на умовах GPL.

Переконання, що несправедливо набуте право не може бути захищене у суді, стало підґрунтям для прецеденту: у справі Lasercomb Am., Inc. v. Reynolds компанія-позивач не розказала державний орган, що її програма містить чимало запозичень з програми у суспільному надбанні, і суд відмовив їй у підтримці покличу. Попри те, що згодом це рішення було переглянуте, ймовірність відмови суду захищати несправедливо набуте право міцно укорінена в практиці.

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

Права на код та власні проєкти, робота над якими велася на корпоративному комп'ютерній комп'ютері

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

У разі використання апаратури замовника підрядником у власних цілях останній може зіткнутися з неочікуваними наслідками. Імовірно, доступ до техніки матимете не лише ви, а й компанія, або ви цілком можете повернути техніку, на якій розробляли проєкти, компанії-замовнику в обмін на іншу техніку. Зокрема, у випадку судового процесу з власником техніки суд може відмовити визнати авторство підрядника без зареєстрованого свідоцтва про авторські права на комп'ютерній ютерну програму або аналогічного доказу (ухвала Апеляційного суду м Києва від 18.02.2015 р., справа № 756/960/15-ц ). Окрім того, з проблемою відсутності доказів може стикнутися група розробників, що бажає змусити роботодавця згадати їхні імена у файлах про авторів і правовласника програми. І наявність об єктного модуля не допоможе, навіть якщо він залишиться у вас (рішення Солом'куп'янського районного суду м Києва від 31.10.2011 р., справа № 2-6118/11 ).


Якщо коротко:

  1. Авторські права відокремлене від патентом. В Україні програмне забезпечення захищається як літературний твір, права на програму виникають автоматично і не потребують реєстрації.
  2. Автор програмного забезпечення може захистити лише свій власний творчий внесок.
  3. Переважно автор передає тільки майнові права, які дозволяють правовласнику отримувати певний прибуток з продажу чи використання ПЗ. Моральні права — бути згаданим як автор, здебільшого невіддільні від особи автора. Водночас у законодавстві є винятки, за яких роялті платити необов'язково. Наприклад, під час використання ПЗ для освітніх потреб.
  4. При розробці варто уважно читати умови ліцензій, якщо запозичується опенсорс-ПЗ. Цілком імовірно, що вони можуть бути непоєднуваними з вашими цілями та умовами договору, за яким ви створюєте нове ПЗ.
  5. Пет-проєкти краще робити у вільний час і на особистій техніці :)

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

Поділіться зі мною історіями з цеху: вам чи вашим знайомим надходили претензії щодо порушення умов використання ліцензій? І чим усе це закінчилося? :)

Опубліковано: 17/06/20 @ 10:00
Розділ Різне

Рекомендуємо:

Зменшення годині релізів, розширення команди, автоматизація. Як тестувати проєкт, що масштабується
Технології заради технологій: чому Front-end не розв'язків язує завдань Back-end
iOS дайджест #38: iOS — 13 років, вразливість у Sign in with Apple, джейлбрейк в 2020
8 основних причин, чому у зростаючому проекті падає якість
Кейс: Розкрутка мобільного додатку в Google Play