Июнь 18

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

програма загалом як єдиний комплекс/продукт;
окремі елементи програми: виражені власне командами або рядками коду без очевидного виконуваного ефекту (класична англійська справа IBCOS Computers Ltd v Barclays Mercantile Highland Finance Ltd, де суддя визнав рядки data division у COBOL-програмі частиною, захищеною копірайтом; іншим прикладом є апаратний ключ (донгл) у справі Autodesk Inc v Dyason: копіювання таблиці кодів з програми донгла було визнано порушенням авторських прав);
специфікації;
схеми (зокрема, блок-схеми);
діаграми;
макети меню та інтерфейсу користувача (це працює не у всіх країнах. Наприклад, у США є судова практика, яка визначає інтерфейс користувача методом роботи, що виводить ці об’єкти з-під парасольки авторського права, як-от у Lotus Development Corp v Borland International Inc);
командні рядки;
зображення на дисплеях екранів;
бази даних;
протоколи (але досі не всюди чітко визначено, чим вважати протокол — ідеєю, принципом чи захищеним втіленням ідеї);
звіти тощо.

Крім того, досі відбуваються дебати щодо того, кому мають належати створені програмою твори мистецтва (згенеровані картинки або музика) і чи підлягають такі об’єкти захисту загалом. Мови програмування і функціонал, а також формат файлів з даними не підлягають захисту в межах авторського права. Принаймні у ЄС, що підтверджується рішенням у справі 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 у деяких країнах), тобто не з метою отримати прибуток, зазвичай дозволене.

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

використовувати лише невелику, необхідну для навчання частину програми, якщо при такому цитуванні вказано автора і джерело запозичення;
видавати та відтворювати випущені у світ програми рельєфно-крапковим шрифтом для сліпих та аудіотвори, а також поповнювати ними бібліотеки, спеціалізовані заклади і центри реабілітації для осіб з інвалідністю, громадські організації і підприємства, де працюють люди з порушеннями зору (якщо програми не використовують з комерційною метою);
це тифлокоментування (аудіодискрипція) для осіб з порушеннями зору.
використовувати правомірно оприлюднені твори для створення іншого твору у формі пародії, попурі або карикатури;
відтворювати під час судового чи адміністративного провадження і в обсязі, виправданому метою використання (винятково для розв’язання питань, що вирішуються у цьому провадженні, у жодному разі не поза його межами);
створювати тільки одну копію комп’ютерної програми за умови, що ця копія призначена лише для архівних цілей або для заміни раніше законно надбаної програми у разі її втрати (стаття 24 Закону України «Про авторське право і суміжні права»).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Закон України «Про авторське право і суміжні права»	Цивільний кодекс
Службовий твір визначається як «твір, створений автором у порядку виконання службових обов’язків відповідно до службового завдання чи трудового договору (контракту) між ним і роботодавцем» (абз. 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 можна продавати, але з деякими обмеженнями для збереження «свобод», проголошених ліцензією.

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

повідомлення про авторське право (copyright notice);
предмет ліцензії (license grant);
умови ліцензії (license conditions);
відмова від гарантій (warranty disclaimer)
положення про обмеження відповідальності (limitation of liability clause).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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