Гайди

Відкриті ліцензії на ПЗ: повний гайд

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

Це завдання здається простим — почистити вихідні джерела та історію версій перед тим, як залити свій репозиторій на GitHub… Все так, поки не спливає питання про ліцензію. Виявляється, їх багато і всі вони мають різний рівень обмежень.

Яку ліцензію вибрати? І чи потрібна вона взагалі?

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

Пам’ятайте: ви вступаєте на територію нескінченних суперечок!

Що таке відкрита ліцензія на ПЗ?

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

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

Трохи теорії. Випускаючи власну роботу, ліцензіаром є саме ви. А ліцензіатом — будь-яка особа, яка використовує ваш код.

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

Які бувають відкриті ліцензії на ПЗ

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

Ліцензія Copyleft — практика, що надає людям право вільно поширювати копії та змінені версії роботи, з умовою збереження тих самих прав у похідних роботах.
Permissive (дозвільна ліцензія) — надає більше свободи для повторного використання, модифікації та розповсюдження.

Відкриті ліцензії copyleft

Найпопулярніші опенсорсні копілефт ліцензії (за порядком обмеження): AGPL, GPL, LGPL, EPL і Mozilla. Далі, детальніше про них:

Загальна публічна ліцензія GNU (GPL) підходить для комерційного, патентного та приватного використання. Будь-яке програмне забезпечення, яке використовує GPL, має поширювати весь вихідний код за тією самою ліцензією.

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

Існує дві основні версії ліцензії GPL: GPLv2 та GPLv3. І вони несумісні одна з одною.
Affero GPL (AGPL). Оскільки ліцензія GPL активується лише під час розповсюдження ПЗ, існує лазівка для програмного забезпечення, яке стає доступним лише через мережу. Ліцензія AGPL закриває її, бо включає положення про віддалену мережеву взаємодію.
Менша загальнодоступна публічна ліцензія (LGPL) забезпечує той самий рівень умов, що й ліцензії AGPL і GPL. Основна відмінність: менші проєкти, доступ до яких здійснюється за допомогою більших ліцензованих робіт, не потребують розповсюдження більшого проєкту. Крім того, модифіковане джерело не повинно розповсюджуватися на тих самих умовах, які застосовуються до більшого проєкту.
Публічна ліцензія Eclipse (EPL) зазвичай використовується для бізнесового ПЗ. За допомогою EPL програмне забезпечення можна об’єднувати та субліцензувати. За умови, що елементи, які не належать до EPL, розташовуються незалежно як окремі модулі або об’єкти.
Публічна ліцензія Mozilla (MPL) має найменше обмежень на опенсорсне програмне забезпечення із копілефтом. Вона дозволяє модифікувати та використовувати код у закритому та/або пропрієтарному ПЗ.

Відкриті ліцензії permissive

Найпопулярніші дозвільні ліцензії з відкритим кодом: Apache, MIT, BSD і Unlicense.

Ліцензія Apache вважається ліберальною, оскільки не вимагає випускати якісь похідні роботи на тих самих умовах, що й великі проєкти. Вона зручна для бізнесу та набула далеко поширення за межами Apache Software Foundation.
Ліцензія MIT має назву Массачусетського технологічного інституту, де вона виникла. Вона дуже коротка та зрозуміла. Дозволяє будь-кому робити з оригінальним кодом усе, що завгодно. Є одна умова: оригінальне повідомлення про авторські права та ліцензію треба включати до вихідного коду або ПЗ, що розповсюджується.
Ліцензія Berkeley Source Distribution (BSD) зберігає повідомлення про ліцензію та авторські права, але дозволяє розповсюджувати більші проєкти на інших умовах. Спрощена ліцензія BSD (2 пункти) та ліцензія MIT не мають істотних відмінностей. Ліцензії BSD із 3 та 4 пунктів додають трохи більше вимог щодо повторного використання найменувань та реклами. Це корисно врахувати, якщо вам треба захистити назву вашого продукту.
Unlicense має найменше обмежень з усіх ліцензій з відкритим кодом. Проєкти тут можна поширювати без вихідного коду та на інших умовах.

Як обрати відкриту ліцензію для свого ПЗ і чи треба?

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

Пам’ятайте, що ліцензія регулює права та обов’язки. Ви коли-небудь замислювалися, чому в тексті багатьох ліцензій ВЕЛИКИМИ ЛІТЕРАМИ написане попередження про гарантії (або їх відсутність)? Це все для того, щоб захистити власника роботи від очікувань користувача. Бо останнє, що вам потрібно — це позов до суду на ваш відкритий код!

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

Наприклад, БД MariaDB використовує GPL v2, а MySQL — GPL та комерційну ліцензію. Для бібліотеки елементів графічного інтерфейсу GTK+ обрали LGPLv2.1. Для мови програмування Clojure та фреймворку JUnit — EPL.

LibreOffice використовують MPL 2.0, а ОС Android — ASL 2.0, щоправда, з деякими винятками (особливо щодо ядра Linux). Для середовища node.js обрали MIT, а для мови Ruby та вебсерверу Nginx — BSD із 2-х пунктів.

Отже, тут все залежить від ваших потреб.

Ось найпопулярніші опенсорсні ліцензії:

Тези, про які слід пам’ятати під час вибору ліцензій:

Якщо ви хочете зробити код максимально придатним для повторного та спільного використання, обирайте серед дозвільних ліцензій.
Якщо ви розробляєте ПЗ, яке використовується через мережу — зверніть увагу на AGPL. Типовим прикладом цього є опенсорсні бази даних. Якщо не залучити таку ліцензію, то будь-який хмарний постачальник зможе покращити ваш продукт і монетизувати його, без розповсюдження своїх модифікацій.
Якщо ви використовуєте опенсорсні проєкти з різними ліцензіями, розгляньте MIT. Вона сумісна з багатьма іншими та доволі зрозуміла. До того ж тут немає обмежень щодо розповсюдження чи монетизації проєкту.
Якщо ви хочете створити бізнес-проєкт на основі своєї опенсорсної роботи — ознайомтеся з поняттям подвійне ліцензування. Бо, швидше за все, ви його випустите і під ліцензією FOSS, і під комерційною ліцензією.
Якщо ви хочете покращити сумісність проєкту — розгляньте мультиліцензування. Воно допоможе поєднувати вашу роботу з іншими та задовольнить запити користувачів. Але попереджаємо, не всі ліцензії сумісні між собою.

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

>> В ITEDU стартує набір на курси системного адміністрування та DevOps. Обирайте необхідну програму та шліфуйте знання разом з нами 🎓

Післяслово

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

Окрім ліцензій, про які ми тут коротко розказали, існує безліч інших. Якій надаєте перевагу ви й чому? Пишіть у коментах 👇