Open Source ліцензії

Про програмне забезпечення з відкритим кодом і вільні ліцензії. Які open source ліцензії підходять для комерційних продуктів? GPL, LGPL, Apache License, Unlicense, BSD, MIT, SIL OFL, Creative Commons license

Open Source ліцензії

Публічні open source ліцензії та комерційні продукти – чи можливо поєднати ці речі? Наприклад, якщо мова йде про framework, який розповсюджується на умовах MIT, та пропрієтарний програмний продукт, який розроблений з використанням відповідної програмної інфраструктури? Це найпростіший приклад з чіткою відповіддю. Але ж існує чимало інших open source ліцензій. Тож, як розробнику ПЗ чи замовнику розробки напевно знати про придатність тієї чи іншої програмної бібліотеки для розробки кінцевого комерційного продукту? Ця стаття допоможе зняти чимало запитань.

Про програмне забезпечення з відкритим кодом і вільні ліцензії. Які open source ліцензії підходять для комерційних продуктів? GPL, LGPL, Apache License, Unlicense, BSD, MIT, SIL OFL, Creative Commons license
Які open source ліцензії підходять для комерційних продуктів? Розглядаємо MIT, BSD, LGPL та інші вільні публічні ліцензії.

Open source ліцензії в IT.

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

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

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

Питання про open source ліцензії та їх використання у комерційних продуктах.

Робота юристів об’єднання Legal Support пов’язана з розглядом багатьох цікавих питань, які виникають у розробників у процесі створення програмного забезпечення. У числі таких практичних запитань:

  • Чи можна використовувати, як складову частину нашого продукту, елементи, поширювані під ліцензією SIL OFL 1.1?
  • Якщо фреймворк «супроводжують» 2 ліцензії, то чи можливо вибрати будь-яку?
  • Що робити якщо той, хто відкрив через репозиторій доступ до певного програмного пакету, сам порушує умови обраної ліцензії?
  • Чи повинні тексти вільних ліцензій зберігатись у кореневій папці проекту або місце розташування тексту ліцензії не важливо?
  • Продукт складається з декількох частин (сервісів), які тісно взаємодіють один з одним. З юридичної точки зору це все один продукт або ж окремі? І чи можна у такому разі запозичувати для кожної частини елементи, що розповсюджуються на умовах “несумісних” між собою ліцензій?
  • Чи можемо ми для нашого проекту і наших задач використовувати Apache License 2.0, GPL 2+, LGPL-2.1+, Unlicense, GPL-3, MIT, BSD?
  • У процесі роботи трапляється, що встановлюючи якусь бібліотеку та, у свою чергу, залежить від інших бібліотек і тягне їх у проект у якості вже своїх “залежностей”. Чи необхідно перевіряти всі залежності бібліотек та умови ліцензування або це вже відповідальність того, хто надав “бібліотеку зі своїми залежностями”, і те що він для неї використовує не зачіпає наші інтереси?
  • У бібліотеці “НX_tables” зазначено що з версії 1.6 розповсюдження відбувається на умовах GPL і якщо я хочу на умовах MIT то маю придбати підписку. Чи правильно я розумію, що можу використовувати версію бібліотеки за номером 1.5 з MIT ліцензією та нічого не купувати?

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

Які публічні ліцензії підходять для комерційних продуктів?

Що ми розуміємо під використанням у комерційних продуктах? Запозичення окремих напрацювань та бібліотек, які розповсюджуються на умовах вільних публічних ліцензій? Побудова пропрієтарного ПЗ на основі “open source складових”? Можливість продажу копій програмного продукту або монетизації SaaS продуктів з open source складовими? Уточнення кінцевої мети використання запозичень, деталей проекту, термінів конкретної ліцензії і правильного їх розуміння, наприклад, розуміння “похідного ПЗ”, – важливе для вичерпної відповіді на головне питання.

Практично всі вільні публічні ліцензії не забороняють продаж фізичних копій програмних продуктів, використання напрацювань у SaaS продуктах з наступною монетизацією технічної та/або консультативної підтримки тощо. Але чи можна використовувати бібліотеки і напрацювання на умовах open source ліцензій у складі пропрієтарних комерційних продуктів? Головна “проблема” класичних вільних відкритих ліцензій – необхідність поширення похідного програмного забезпечення на тих самих умовах і розкриття вихідного коду похідного ПЗ. Наприклад, така вимога положень GPL (General Public License). Саме тому ці ліцензії і іменуються “open source”.

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

Open source ліцензії “лояльні” до комерційних продуктів.

До відкритих публічних ліцензій, які сумісні з комерційними програмними продуктами, тобто напрацювання, які поширюються на умовах таких ліцензій, можуть використовуватись у складі комерційних продуктів, відносяться: LGPL та Mozilla Public License (обидві придатні в частині використання бібліотек), Apache License, SIL OFL, Unlicense, окремі ліцензії Creative Commons, BSD, MIT. Це, звісно, не вичерпний перелік. Крім того, слова “можуть використовуватись” супроводжуються унікальними для кожної ліцензії застереженнями.

Загальні риси і положення open source ліцензій “лояльних” до комерційних продуктів:

  • відсутність вимог щодо розкриття коду кінцевого (похідного) програмного продукту;
  • відсутність вимог щодо надання кінцевим напрацюванням статусу суспільного надбання (public domain);
  • відсутність заборон щодо реєстрації, патентування похідного ПЗ, здійснення його правового захисту в інший подібний спосіб;
  • відсутність інших умов, що унеможливлюють комерційне використання похідного ПЗ та/або надання йому статусу пропрієтарного;
  • лаконічність умов ліцензії (не завжди).

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

LGPL, окремі програмні бібліотеки та комерційні продукти на їх основі.

Ліцензія LGPL, порівняно з класичною GPL, краще підходить для комерційних програмних продуктів та частково сумісна з подальшим можливим ліцензуванням у складі пропрієтарного програмного забезпечення. Звісно, якщо мова йде про використання на умовах LGPL лише програмних бібліотек. Не забувайте, за виключенням згаданого “послаблення”, це все ж таки GPL, з усіма обмеженнями і обов’язками.

Додатково зазначимо – є декілька версій LGPL. Це слід враховувати і на це слід звертати увагу при аналізі можливості використання відповідних бібліотек і напрацювань для конкретного комерційного продукту. Хоча, зазвичай, використовується LGPL-2.1. Ніколи не варто ігнорувати доцільність індивідуального підходу та аналізу.

Apache License 2.0 – чіткі вимоги атрибутування та можливість використання у похідних продуктах.

Чи “підходить” Apache License, зокрема версії 2.0, для використання з комерційними продуктами? Умовно так. Необхідно вказувати на авторство розробників програмних напрацювань які використовуються Вами. Є вимоги стосовно атрибутування але, на щастя, чітко сформульовані. В іншому ж, напрацювання, які розповсюджуються на умовах Apache License 2.0, можуть бути використані у складі комерційного продукту а похідне програмне забезпечення може бути у подальшому ліцензоване як пропрієтарне.

І оскільки Apache License чітко формулює вимоги щодо атрибутування – коротко про це. Кожний примірник ПЗ супроводжується текстом Apache License. При розповсюдженні ПЗ необхідно помістити до кореневого каталогу такі файли: «LICENSE» (файл з копією тексту ліцензії Apache) та «NOTICE» (файл з переліком усіх бібліотек, які ліцензовані на умовах Apache License, разом із іменами їх розробників). Також, в частині ліцензованих на умовах Apache License напрацювань має бути збережена вихідна інформація про всі патенти, а у разі внесення змін необхідно додати інформацію про такі зміни.

BSD, MIT і мінімум обмежень для розробників комерційних IT продуктів.

Чи можна використовувати при створенні комерційних продуктів фреймворки і бібліотеки, що розповсюджуються на умовах ліцензій BSD та MIT? Звісно, це найлаконічніші ліцензії, які містять широкий за змістом дозвіл а не обов’язки. Оцінити лаконічність цих ліцензій можна на прикладі офіційного тексту MIT ліцензії – the MIT License.

Положення BSD та MIT ліцензій мінімалістичні, зрозумілі та не потребують додаткових роз’яснень. Є інші, схожі за змістом до MIT, ліцензії, наприклад, the Unlicense. З положеннями цих ліцензій і бібліотек, які розповсюджуються на їх умовах, проблем не виникає, тож, приділимо час іншим публічним open source ліцензіям. Так, на особливу увагу заслуговують ліцензії від Creative Commons.

SIL OFL, Creative Commons license та інші публічні ліцензії.

SIL OFL – ще одна цікава і відносно поширена ліцензія, яка, забігаючи наперед, “сумісна” з комерційними продуктами. Звісно, є важливі застереження, про які слід знати. SIL OFL переважно використовується разом із специфічними об’єктами права інтелектуальної власності. Зокрема, авторськими шрифтами.

Ви можете використовувати, припустимо, набір тих самих шрифтів, що розповсюджується на умовах SIL OFL, у складі комерційного продукту. Єдине суттєве обмеження – Ви не маєте права продавати похідні (змінені) елементи запозичених напрацювань окремо від комплексного кінцевого продукту. Йдеться про шрифт, отриманий на умовах ліцензії SIL OFL 1.1 та доопрацьований Вами. Інша справа – продаж комп’ютерної гри, у заголовному меню якої використовується набір шрифтів ліцензованих на умовах SIL OFL. Тоді жодних проблем.

До речі, цікаве трактування окремих термінів, як от “похідний твір” або “похідне ПЗ” – від ліцензії до ліцензії трактування неоднакове. В контексті SIL OFL трактування має місце у вузькому значенні, тобто “похідним” буде змінений шрифт, а не front-end частина веб-сайту, до складу якої включено запозичений шрифт.

Що можна сказати про ліцензії від Creative Commons? Вони різноманітні за формою і змістом. Часто використовують для поширення графічних творів. Завжди супроводжуються офіційною спрощеною версією ліцензії та графічними позначеннями. Розробники, які бажають знати справжній зміст та умови ліцензій, вивчають саме повноцінні версії текстів ліцензій Creative Commons.

Аналіз ключових особливостей ліцензій Creative Commons залишимо для наступних консультацій і публікацій. Зараз буквально тезисно: ліцензії Creative Commons неоднорідні та суттєво відрізняються за змістом; є чіткі вимоги щодо вказівки на авторство творця контенту; Creative Commons напрацювали цікавий юридичний інструмент, що фундаментально відрізняється від open source ліцензій – це CC0. Цей інструмент не є ліцензією, а є формою повідомлення автором про свою відмову від усіх своїх прав на користь суспільства. CC0, так би мовити, “переводить” твір у статус public domain. Ураховуючи неможливість відчуження особистих немайнових прав автора за законодавством чималої частини юрисдикцій, CC0 не повністю узгоджується з вимогами законодавства України та багатьох інших країн.

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

4 правила безпечного використання напрацювань на умовах open source ліцензій:

  1. Накреслити кінцеву мету використання необхідних напрацювань і цільового (похідного) програмного продукту.
  2. Переглядати і вивчати повний текст ліцензії, за якою розповсюджуються необхідні напрацювання.
  3. Співставляти вимоги open source ліцензії з обов’язками та гарантіями за договором із замовником, а також метою використання похідного програмного продукту.
  4. Моделювати розвиток ситуації, зокрема пред’явлення регресних вимог (претензій) з боку замовника. Оцінювати наслідки.

В додаток до 4 правил безпечного використання радимо підходити індивідуалізовано до кожного окремого проекту. Щоб 100% упевнитись у можливості використання у комерційному продукті тієї чи іншої бібліотеки, доступної на GitHub, Ви можете замовити правовий висновок з рекомендаціями юриста. Також, наполегливо рекомендуємо ознайомитись з попередньою статтею-консультацією з розділу “Блог і Консультації”. У статті розкрито практичні аспекти виникнення, оформлення і переходу майнових прав інтелектуальної власності на ПЗ за законодавством України.

Що наступного разу? У найближчій публікації розкажемо про блокчейн і сучасне мистецтво, а також їх комерційний симбіоз, який користується все більшою увагою, як з боку митців так і з боку інвесторів, а також бізнесу, який не втрачає нагоди пропіаритись на новомодній темі. Ми не станемо робити жодних суб’єктивних оцінок, а розкажемо про юридичну сторону тенденцій і процесів, пов’язаних з “цифровими творами мистецтва” та їх “фіксацією” за допомогою технології розподіленого реєстру.

+38 050 643 79 03

юрист Євгеній Мовчун