Відкритий вихідний код є основою сучасних технологій — від бібліотек і фреймворків до операційних систем і серверних рішень. У матеріалі видання GALERA розглянемо, які бувають типи ліцензій, у чому їх різниця, які з них найпоширеніші та як вони впливають на бізнес і розробку.
Відкритий код як фундамент технологій
Сьогодні відкритий вихідний код є основою розвитку IT-індустрії. Приблизно до 90% сучасного програмного забезпечення створено з використанням відкритих компонентів — фреймворків, бібліотек, баз даних, операційних систем чи окремих застосунків.
Переваги відкритого ПЗ очевидні: прозорість, спільнотна підтримка, гнучкість, безпечність та можливість кастомізації. Проте водночас між прихильниками відкритого коду та розробниками пропрієтарного (закритого) ПЗ триває вічна боротьба. Багато компаній обирають закриті рішення, щоб захистити свої бізнес-інтереси, а в центрі цих дискусій — питання ліцензування.
Типи відкритих ліцензій
За визначенням Open Source Initiative (OSI), існує два основні типи ліцензій, які відповідають формальним критеріям відкритого коду:
- Дозвільні (permissive) — дозволяють змінювати та поширювати код практично без обмежень. Такі ліцензії приваблюють компанії, котрі використовують відкриті рішення у комерційних продуктах.
- Копілефт (copyleft) — також гарантують свободу використання, але вимагають, щоб усі похідні продукти залишалися під тією ж відкритою ліцензією.
Обидва підходи мають переваги та недоліки. Перший дає максимум свободи, другий — захищає відкритість і справедливість у спільноті.
Дозвільні ліцензії
Ліцензія MIT
MIT License — одна з найстаріших і найвідоміших у світі. Вона з’явилася в Массачусетському технологічному інституті у 1980-х роках і нині є найпопулярнішою ліцензією на GitHub.
MIT використовується у величезній кількості проєктів, зокрема у React (JS-бібліотека для фронтенду) та Ruby (мова програмування загального призначення).
Ця ліцензія дозволяє робити практично все: змінювати, копіювати, продавати та інтегрувати програму. Єдина вимога — залишати повідомлення про авторські права та сам текст ліцензії.
Як і більшість дозвільних ліцензій, MIT не гарантує відсутності помилок чи відповідальності за збитки (наприклад, втрату даних). Однак є один недолік: у ліцензії не прописано патентні положення. Це означає, що якщо проєкт базується на запатентованій технології, може виникнути правова невизначеність.
З іншого боку, саме простота — перевага MIT. Її текст містить близько 200 слів, що робить документ максимально зрозумілим і гнучким. Вона ідеальна для високорівневих мов програмування, бібліотек чи веб-фреймворків, де патентні спори малоймовірні. Та в проєктах, які взаємодіють з апаратним забезпеченням, як-от Android, така відкритість може стати ризиком.
Ліцензія Apache 2.0
У 2004 році Apache Software Foundation представила Apache License 2.0, що замінила попередню версію. Головне нововведення — наявність патентного пункту, який забезпечує юридичний захист користувачів.
Якщо розробник передає у відкритий проєкт частину коду чи алгоритм, що підпадає під патент, усі користувачі цього ПЗ автоматично отримують право на його використання. Це дозволяє уникнути судових позовів.
Яскравий приклад застосування — Android Open Source Project (AOSP). Компанія Google у 2008 році зробила Android відкритим під Apache 2.0, щоб конкурувати з Apple та Symbian. Це рішення сприяло стрімкому поширенню системи серед виробників смартфонів — Samsung, HTC, LG та інших.
Однак Apache 2.0 набагато довша за MIT — приблизно у п’ять разів — через патентні положення та додаткові деталі. Але цей компроміс виправданий: він забезпечує ширший юридичний захист. Таким чином, MIT і Apache 2.0 — два головних приклади дозвільних, але різних за підходом ліцензій.
Інші дозвільні варіанти
- BSD 2-Clause License схожа на MIT, але зобов’язує додавати текст ліцензії не лише до вихідного, а й до двійкового файлу.
- BSD 3-Clause License має додатковий пункт «без схвалення» — забороняє використовувати імена авторів для реклами похідних продуктів.
- MIT-0 (No Attribution) дозволяє навіть не зазначати авторів. Така форма максимально наближена до публічного надбання, хоча право власності за автором зберігається.
Копілефт-ліцензії
GNU General Public License (GPL) v2.0 / v3.0
GNU GPL, створена Free Software Foundation (FSF) у 1989 році, стала першою масовою копілефт-ліцензією. Вона вимагає, щоб усі модифікації ПЗ залишалися відкритими для всіх.
GPL 3.0 (2007 рік) принесла нові положення:
- захист від патентних позовів;
- кращу сумісність з іншими відкритими ліцензіями;
- боротьбу з «тівоізацією» (обмеженням можливості встановлення модифікованого ПЗ на апаратному рівні).
GPL 3.0 займає третє місце серед найпопулярніших ліцензій GitHub.
Linux — яскравий приклад успішного GPL-проєкту. Його ядро поширюється під GPL 2.0, адже Лінус Торвальдс не погодився з деякими змінами у 3.0.
WordPress, натомість, дозволяє використовувати GPL 2.0 «або будь-яку новішу версію».
GNU Affero General Public License (AGPL) 3.0
AGPL — ще одна «сильна» копілефт-ліцензія, створена FSF у 2007 році. Її головна відмінність від GPL полягає у фокусі на вебсервісах і SaaS-застосунках.
Якщо модифіковане програмне забезпечення працює на сервері (і не поширюється фізично), автор зобов’язаний все одно надати вихідний код. Цим AGPL закриває «лазівку» GPL 3.0. AGPL стала особливо актуальною в епоху хмарних технологій і сьогодні входить у п’ятірку найпоширеніших відкритих ліцензій.
GNU Lesser General Public License (LGPL)
LGPL — «слабша» копілефт-ліцензія. Її створено для бібліотек, які можуть використовуватися у комерційному ПЗ без обов’язку відкривати увесь код. Якщо хтось змінює саму бібліотеку, зміни мають бути оприлюднені під LGPL. Проте продукт, який лише використовує її, може залишатися закритим. Це компроміс між бізнес-інтересами та відкритістю коду.
Mozilla Public License (MPL) 2.0
MPL 2.0, розроблена Mozilla Foundation у 2012 році, також є «слабким» копілефтом і входить до топ-10 ліцензій GitHub. Головна особливість MPL — її дію поширено на рівень окремих файлів. Тобто лише змінені відкриті файли потрібно поширювати разом із кодом. Решта може залишатися пропрієтарною. Це дозволяє створювати комерційні продукти з відкритими компонентами.
Публічне надбання і Creative Commons
Відкрита ліцензія — це завжди певні умови. Але якщо автор хоче повністю відмовитися від прав, існують спеціальні механізми.
Unlicense — інструмент для передачі ПЗ у публічне надбання. Вона входить у топ-10 найуживаніших ліцензій на GitHub. Однак через юридичні особливості (наприклад, у Німеччині неможливо повністю відмовитися від авторського права) її статус залишається спірним.
Creative Commons CC0 1.0 — універсальніший інструмент для передачі робіт у публічне надбання, зокрема програмного коду. Однак OSI не схвалила її як відкриту ліцензію, оскільки вона не охоплює питання патентів.
Також існують інші спрощені варіанти, наприклад Zero-Clause BSD, що використовує ще коротший текст. Але єдиної позиції, який інструмент найкраще підходить для передачі всіх прав, поки що немає.
Інші моделі та альтернативні підходи
Світ ліцензування значно ширший, ніж здається. Деякі компанії застосовують подвійну модель ліцензування — відкриту для некомерційного використання та платну для комерційного. Інші використовують open-core-модель, де базовий код відкритий, а додаткові функції чи сервіси — платні.
Іноді до відкритих ліцензій додають спеціальні комерційні умови, котрі обмежують використання.
У 2018 році компанія MongoDB перейшла з AGPL на власну Server Side Public License (SSPL), що передбачає серйозні обмеження для комерційних користувачів. Через це OSI не визнала її «справжньою» відкритою ліцензією.
Компанія MariaDB пішла подібним шляхом, створивши Business Source License (BUSL), яка через певний час автоматично стає відкритою. Інший сучасний варіант — Functional Source License (FSL), яка прагне бути більш простою альтернативою BUSL.
З’являються навіть етичні ліцензії, як-от Hippocratic License, котра забороняє використання ПЗ у проєктах, що порушують права людини.
А легендарна ліцензія JSON завершується жартівливою фразою: «Програмне забезпечення має використовуватися на благо, а не на зло.»
Простір відкритого коду надзвичайно різноманітний. Вибір ліцензії — це не просто юридичне рішення, а стратегічний крок, що впливає на розвиток проєкту, його спільноту та майбутнє. MIT чи Apache, GPL чи AGPL, MPL чи BUSL — кожна має своє призначення. Головне — розуміти баланс між свободою, відкритістю та захистом інтересів.
