Ліцензія програмного забезпечення — це юридичний документ або набір умов, який визначає, як можна використовувати, копіювати, змінювати, поширювати, продавати або інтегрувати програмне забезпечення.

Простими словами:

Ліцензія відповідає на питання: що саме користувач, розробник або компанія має право робити з програмою чи її кодом.

Ліцензія важлива не тільки для юристів. Вона напряму впливає на бізнес, розробку, інтеграції, open source, ERP-системи, SaaS-продукти, комерційні рішення та безпеку компанії.

Коротко про суть

Питання	Відповідь
Що таке ліцензія ПЗ?	Умови, за якими програму або код можна використовувати, змінювати й поширювати.
Чи всяке ПЗ має ліцензію?	Так. Навіть якщо ліцензія не вказана явно, авторське право все одно діє.
Чи можна використовувати код із GitHub без ліцензії?	Ні. Якщо ліцензії немає, юридично код не можна вільно копіювати, змінювати або використовувати у власному продукті.
Чим відрізняються відкриті ліцензії?	Вони дозволяють використовувати, змінювати й поширювати код на умовах, визначених ліцензією.
Чим відрізняються закриті ліцензії?	Вони зазвичай забороняють доступ до коду, модифікацію й вільне поширення.
Головний ризик	Неправильне використання ліцензії може створити юридичні, комерційні або репутаційні проблеми.

Повʼязані статті

Для чого потрібні ліцензії

Ліцензія потрібна, щоб визначити правила гри.

Вона відповідає на практичні питання:

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

Важливі акценти

Статус	Теза	Пояснення
Ключове	Ліцензія визначає права	Сам факт доступу до коду не означає, що його можна використовувати як завгодно.
Ключове	Open Source — це не відсутність правил	Відкриті ліцензії дають свободи, але також містять умови.
Ключове	Для бізнесу важлива сумісність ліцензій	Різні ліцензії можуть по-різному впливати на комерційний продукт.
Важливо	Copyleft може вимагати відкриття похідного коду	Деякі ліцензії зобовʼязують поширювати похідні роботи під такою ж або сумісною ліцензією.
Увага	Код без ліцензії — не вільний код	Якщо автор не дав ліцензії, за замовчуванням права залишаються за автором.

Основні види ліцензій програмного забезпечення

1. Пропрієтарні ліцензії

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

Зазвичай така ліцензія:

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

Ознака	Пропрієтарна ліцензія
Доступ до коду	Зазвичай відсутній.
Модифікація	Зазвичай заборонена.
Поширення	Обмежене або заборонене.
Комерційне використання	Дозволене тільки в межах договору.
Приклад	Microsoft Windows, Adobe Photoshop, багато комерційних ERP/CRM-систем.

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

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

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

Open Source Initiative визначає open source-ліцензії як такі, що відповідають Open Source Definition: зокрема, вони мають дозволяти вільне поширення, доступ до початкового коду, створення похідних робіт і не дискримінувати людей або сфери застосування.^[1]

Ознака	Відкрита ліцензія
Доступ до коду	Є.
Модифікація	Дозволена.
Поширення	Дозволене згідно з умовами ліцензії.
Комерційне використання	Часто дозволене, але умови залежать від ліцензії.
Приклад	MIT, Apache 2.0, GPL, LGPL, MPL, BSD.

3. Permissive-ліцензії

Permissive-ліцензії або дозвільні ліцензії — це відкриті ліцензії з мінімальними обмеженнями.

Вони зазвичай дозволяють:

використовувати код;
змінювати код;
включати код у комерційний продукт;
поширювати код;
створювати закриті продукти на основі цього коду.

Головна вимога зазвичай — зберегти повідомлення про авторські права й текст ліцензії.

Ознака	Permissive-ліцензія
Відкритий код	Так.
Можна використовувати в закритому продукті	Так, зазвичай можна.
Потрібно відкривати власний код	Зазвичай ні.
Рівень обмежень	Низький.
Приклади	MIT, Apache 2.0, BSD, ISC.

4. Copyleft-ліцензії

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

Free Software Foundation описує GNU GPL як вільну copyleft-ліцензію, яка має гарантувати свободу поширювати й змінювати всі версії програми.^[2]

Ознака	Copyleft-ліцензія
Відкритий код	Так.
Можна змінювати	Так.
Можна поширювати	Так, але з умовами.
Потрібно відкривати похідний код	Часто так, якщо продукт поширюється.
Приклади	GPL, AGPL, LGPL, MPL.

Permissive-ліцензія каже: “Бери й використовуй”. Copyleft-ліцензія каже: “Бери, змінюй, але збережи свободу для наступних користувачів”.

5. Strong copyleft

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

Найвідоміший приклад — GPL.

Ознака	Strong copyleft
Приклад	GPL.
Головна ідея	Похідна робота має залишатися відкритою.
Бізнес-ризик	Може бути несумісною із закритим комерційним продуктом.
Коли підходить	Коли автор хоче гарантувати, що всі похідні версії залишаться відкритими.

6. Network copyleft

Network copyleft — це тип copyleft-ліцензії, який враховує використання програми через мережу.

Класичний приклад — AGPL.

AGPL важлива для SaaS-сервісів: якщо модифікована програма використовується як мережевий сервіс, користувачі можуть отримати право доступу до відповідного початкового коду.

Ознака	Network copyleft
Приклад	AGPL.
Головна ідея	Не дозволити обійти copyleft через SaaS-модель.
Особливість	Мережеве використання може створювати обовʼязок надати код.
Бізнес-ризик	Потребує уважної юридичної перевірки для SaaS-продуктів.

7. Weak copyleft

Weak copyleft — це мʼякший copyleft. Він зазвичай вимагає відкривати зміни в самій бібліотеці або файлах, але не обовʼязково весь продукт.

Приклади:

LGPL;
MPL;
EPL.

Ознака	Weak copyleft
Приклад	LGPL, MPL, EPL.
Головна ідея	Зберегти відкритість певної частини коду.
Можна використовувати з закритим ПЗ	Часто так, за виконання умов ліцензії.
Коли підходить	Для бібліотек і компонентів, які мають бути відкритими, але можуть інтегруватися в ширші системи.

8. Public Domain та Unlicense

Public Domain означає, що автор відмовляється від авторських прав настільки, наскільки це дозволяє закон.

Unlicense — приклад ліцензії/декларації, яка намагається максимально наблизити код до public domain.

Ознака	Public Domain / Unlicense
Обмеження	Мінімальні або майже відсутні.
Комерційне використання	Зазвичай дозволене.
Вимога вказувати автора	Може бути відсутня.
Ризик	У різних юрисдикціях відмова від авторських прав може працювати по-різному.

9. Dual licensing

Dual licensing — це модель, коли один і той самий продукт доступний за двома або більше ліцензіями.

Наприклад:

відкрита ліцензія для спільноти;
комерційна ліцензія для бізнесу;
GPL-версія плюс enterprise-версія;
open core плюс платні модулі.

Ознака	Dual licensing
Головна ідея	Один продукт — різні юридичні режими використання.
Для спільноти	Може бути open source-версія.
Для бізнесу	Може бути платна комерційна ліцензія.
Приклад моделі	Community Edition + Enterprise Edition.

10. Open Core

Open Core — це бізнес-модель, де ядро продукту є відкритим, а частина функцій доступна тільки в платній або закритій версії.

Ознака	Open Core
Відкрита частина	Базове ядро продукту.
Закрита частина	Enterprise-функції, модулі, підтримка, інтеграції.
Перевага	Дає спільноті відкритий фундамент.
Ризик	Потрібно чітко розуміти, що саме відкрите, а що комерційне.

11. Freeware

Freeware — це програмне забезпечення, яке можна використовувати безкоштовно, але воно не обовʼязково є відкритим.

Ознака	Freeware
Ціна	Безкоштовно.
Доступ до коду	Зазвичай ні.
Модифікація	Зазвичай заборонена.
Поширення	Може бути обмежене.
Приклад	Безкоштовні утиліти із закритим кодом.

Freeware — це про ціну. Open Source — це про права на код.

12. Shareware / Trial

Shareware або Trial — це модель, коли програму можна спробувати безкоштовно, але для повного використання потрібно заплатити.

Ознака	Shareware / Trial
Початкове використання	Безкоштовне або обмежене.
Повна версія	Платна.
Доступ до коду	Зазвичай ні.
Обмеження	Час, функції, кількість запусків або водяні знаки.

13. SaaS-ліцензії

SaaS-ліцензія — це не класична ліцензія на встановлення програми, а право користування онлайн-сервісом.

Користувач не отримує програму як файл. Він отримує доступ до сервісу через інтернет.

Ознака	SaaS
Де працює програма	На серверах постачальника.
Доступ	Через браузер або API.
Оплата	Часто підписка.
Код	Зазвичай закритий.
Приклад	CRM, ERP, пошта, хмарні сервіси, AI-сервіси.

14. Enterprise-ліцензії

Enterprise-ліцензія — це ліцензія для компаній, яка часто включає не тільки право використання, а й підтримку, SLA, оновлення, інтеграції, аудит, безпеку й юридичні гарантії.

Ознака	Enterprise-ліцензія
Для кого	Компанії, корпорації, державні органи.
Що включає	Підтримку, SLA, оновлення, юридичні гарантії.
Модель оплати	За користувачів, сервери, модулі, обсяг, контракт.
Приклад	Enterprise ERP, CRM, BI, security-рішення.

Порівняльна таблиця видів ліцензій

Вид ліцензії	Код відкритий?	Можна змінювати?	Можна використовувати комерційно?	Чи треба відкривати свій код?	Приклади
Пропрієтарна	Ні	Зазвичай ні	Так, за договором	Ні	Windows, Photoshop, багато ERP
Freeware	Зазвичай ні	Зазвичай ні	Залежить від умов	Ні	Безкоштовні закриті утиліти
Shareware / Trial	Ні	Ні	Обмежено	Ні	Пробні версії програм
Permissive open source	Так	Так	Так	Ні	MIT, Apache 2.0, BSD
Strong copyleft	Так	Так	Так	Часто так, при поширенні похідного продукту	GPL
Network copyleft	Так	Так	Так	Може вимагатися навіть при SaaS-використанні	AGPL
Weak copyleft	Так	Так	Так	Частково, для змінених компонентів	LGPL, MPL, EPL
Public Domain / Unlicense	Так або фактично так	Так	Так	Ні	Unlicense, CC0 для деяких матеріалів
Dual licensing	Залежить від варіанту	Залежить від варіанту	Так	Залежить від обраної ліцензії	Community + Commercial
SaaS	Зазвичай ні	Ні	Так, за підпискою	Ні	Хмарні сервіси

Що саме відрізняє ліцензії

1. Доступ до коду

Варіант	Пояснення
Код відкритий	Можна переглядати й аналізувати початковий код.
Код закритий	Користувач отримує тільки готову програму або доступ до сервісу.

2. Право змінювати

Варіант	Пояснення
Можна змінювати	Користувач або компанія може адаптувати код.
Не можна змінювати	Програма використовується тільки в дозволеному вигляді.

3. Право поширювати

Варіант	Пояснення
Вільне поширення	Можна передавати копії іншим.
Обмежене поширення	Поширення дозволене тільки за договором або заборонене.

4. Комерційне використання

Варіант	Пояснення
Дозволене	Можна використовувати в бізнесі або комерційному продукті.
Обмежене	Потрібна окрема ліцензія або договір.
Заборонене	Рідко для software licenses, частіше трапляється в медіа-ліцензіях.

5. Обовʼязок відкривати похідний код

Варіант	Пояснення
Немає	Можна включати код у закритий продукт.
Є частково	Потрібно відкривати зміни певних компонентів або файлів.
Є сильно	Похідна робота має бути відкрита під сумісною ліцензією.

6. Патентні умови

Деякі ліцензії, наприклад Apache License 2.0, містять окремі положення щодо патентів. Це важливо для великих компаній, enterprise-продуктів і технологічних платформ.

7. Гарантії та відповідальність

Більшість open source-ліцензій прямо зазначають, що ПЗ надається “as is” — тобто без гарантій.

Це означає:

автор не гарантує, що програма працюватиме без помилок;
автор не несе відповідальності за збитки;
користувач сам оцінює ризики.

Практичні приклади вибору ліцензії

Ситуація	Рекомендований тип ліцензії	Чому
Хочу, щоб код могли використовувати всі, навіть у комерційних продуктах	MIT, Apache 2.0, BSD	Мінімум обмежень, зручно для поширення.
Хочу, щоб усі похідні версії залишалися відкритими	GPL	Strong copyleft захищає відкритість похідного коду.
Хочу захистити відкритість SaaS-версій	AGPL	Network copyleft враховує використання через мережу.
Пишу бібліотеку, яку можна використовувати в закритих продуктах	LGPL або MPL	Weak copyleft дає баланс між відкритістю й комерційною інтеграцією.
Хочу мати open source-версію і платну enterprise-версію	Dual licensing або Open Core	Підходить для комерційної open source-моделі.
Хочу просто безкоштовно дати програму, але не відкривати код	Freeware / proprietary EULA	Це не open source, але може бути безкоштовне використання.

Ліцензії в ERP та бізнес-системах

Для ERP, CRM, BI та корпоративних платформ ліцензія особливо важлива, бо така система часто стає центральною частиною бізнесу.

ERP може містити:

фінансові дані;
складський облік;
продажі;
закупівлі;
виробництво;
зарплату;
документообіг;
інтеграції з банками;
інтеграції з РРО;
інтеграції з сайтами;
API для інших систем.

Чому ліцензія ERP важлива

Питання	Чому важливо
Чи можна доопрацьовувати систему?	ERP майже завжди потребує адаптації під процеси компанії.
Хто володіє кастомізаціями?	Бізнес має розуміти, кому належать доопрацьовані модулі.
Чи можна змінити інтегратора?	Від цього залежить ризик vendor lock-in.
Чи відкритий код модулів?	Це впливає на аудит, підтримку й розвиток.
Чи можна встановити систему on-premise?	Важливо для контролю даних і безпеки.

SPDX та облік ліцензій

SPDX — це стандарт для ідентифікації ліцензій і опису складу програмного забезпечення.

SPDX License List містить стандартизований короткий ідентифікатор, повну назву, текст ліцензії та постійне посилання для кожної ліцензії або винятку.^[3]

Приклади SPDX ID:

Ліцензія	SPDX ID
MIT License	`MIT`
Apache License 2.0	`Apache-2.0`
GNU GPL v3.0	`GPL-3.0-only` або `GPL-3.0-or-later`
GNU AGPL v3.0	`AGPL-3.0-only` або `AGPL-3.0-or-later`
GNU LGPL v3.0	`LGPL-3.0-only` або `LGPL-3.0-or-later`
BSD 3-Clause	`BSD-3-Clause`
MPL 2.0	`MPL-2.0`

Навіщо потрібен SPDX

Причина	Пояснення
Стандартизація	Усі використовують однакові короткі назви ліцензій.
Автоматична перевірка	Інструменти можуть сканувати залежності й показувати ризики.
SBOM	SPDX використовується для Software Bill of Materials.
Юридична ясність	Менше плутанини між схожими ліцензіями й версіями.

Як вибирати ліцензію для власного проєкту

Питання	Якщо відповідь “так”	Можливий вибір
Хочу, щоб код використовували максимально вільно?	Так	MIT, Apache 2.0, BSD.
Хочу, щоб похідні версії теж залишалися відкритими?	Так	GPL.
Хочу захистити код у SaaS-моделі?	Так	AGPL.
Пишу бібліотеку для широкого використання?	Так	MIT, Apache 2.0, LGPL, MPL.
Хочу open source + платну enterprise-версію?	Так	Dual licensing або Open Core.
Не хочу відкривати код?	Так	Пропрієтарна ліцензія / EULA.

Практичний чекліст перед використанням чужого коду

№	Питання
1	Чи є в проєкті файл `LICENSE`?
2	Яка саме ліцензія використовується?
3	Чи є SPDX ID?
4	Чи дозволене комерційне використання?
5	Чи можна змінювати код?
6	Чи можна поширювати модифіковану версію?
7	Чи потрібно відкривати власний код?
8	Чи є патентні умови?
9	Чи сумісна ліцензія з іншими компонентами?
10	Чи потрібно показувати текст ліцензії користувачам?

Типові помилки

Помилка	Чому це проблема
Вважати, що GitHub = можна використовувати	Публічний репозиторій без ліцензії не дає права вільного використання.
Плутати free і open source	Безкоштовне ПЗ може бути закритим.
Ігнорувати GPL/AGPL	Copyleft-ліцензії можуть вимагати відкриття похідного коду.
Не вести список залежностей	У великому продукті можна випадково порушити ліцензії бібліотек.
Не зберігати copyright notices	Багато ліцензій вимагають зберігати повідомлення про авторство.
Не перевіряти SaaS-наслідки AGPL	AGPL може спрацювати навіть без класичного поширення програми.

Простими словами

MIT / Apache / BSD — бери, використовуй, не забудь вказати автора й ліцензію.

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

AGPL — як GPL, але ще уважніше для вебсервісів і SaaS.

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

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

Висновок

Ліцензії програмного забезпечення визначають, що можна і чого не можна робити з кодом.

Для розробника це питання прав. Для бізнесу — питання ризиків. Для open source — питання свободи.

Головна формула:

код
+ ліцензія
+ права використання
+ облік залежностей
+ контроль змін
= юридично безпечне програмне забезпечення

Найнебезпечніша ліцензія — це та, яку ніхто не прочитав.

Джерела

Open Source Initiative — Licenses: https://opensource.org/licenses
The Open Source Definition: https://opensource.org/osd
GNU General Public License v3.0: https://www.gnu.org/licenses/gpl-3.0.en.html
SPDX License List: https://spdx.org/licenses/
SPDX Project: https://spdx.dev/

[1] ttps://opensource.org/osd

[2] ttps://www.gnu.org/licenses/gpl-3.0.en.html

[3] ttps://spdx.org/licenses/

[1]

[2]

[3]

Характеристика	MIT
Тип	Permissive.
Простота	Дуже проста.
Для бізнесу	Зручна.
Вимога відкривати власний код	Ні.

Характеристика	GPL
Тип	Strong copyleft.
Комерційне використання	Дозволене.
Вимога відкривати похідний код	Так, при поширенні похідної роботи.
Для закритих продуктів	Потребує обережності.

Характеристика	AGPL
Тип	Network copyleft.
SaaS-використання	Може створювати обовʼязок надати код користувачам сервісу.
Для бізнесу	Потрібна уважна юридична оцінка.
Коли підходить	Якщо автор хоче не дозволити закриття змін через SaaS-модель.

Характеристика	LGPL
Тип	Weak copyleft.
Часто використовується для	Бібліотек.
Можна використовувати в закритому ПЗ	Часто так, за виконання умов.
Вимога відкривати весь продукт	Зазвичай ні.

Характеристика	MPL
Тип	Weak copyleft.
Рівень copyleft	На рівні файлів.
Для бізнесу	Часто зручніша за GPL.
Приклад	Mozilla-екосистема.

Використання	Ліцензія
Програмний код	MIT, Apache 2.0, GPL, LGPL, MPL, BSD.
Документація	Creative Commons, GNU FDL, інші документаційні ліцензії.
Зображення, тексти, медіа	Creative Commons.