Поточна версія на 17:10, 6 травня 2026

!Shareware / Trial

Джерела

BSD License — родина permissive-ліцензій. |- |Хто володіє кастомізаціями? |бізнес-середовище має розуміти, кому належать доопрацьовані модулі. |- |Чи всяке ПЗ має ліцензію? |Так. {| class="wikitable"

!Пояснення

LGPL;
MPL;
EPL. |-

|Можна змінювати |Так. |- |Чи можна змінити інтегратора? |Від цього залежить ризик vendor lock-in.^[1] !Варіант |- |Доступ до коду |Зазвичай відсутній. |Так |GPL. |- |Ризик |Потрібно чітко розуміти, що саме відкрите, а що комерційне. !Пояснення |- |Дозволене |Можна використовувати в бізнесі або комерційному продукті. !SaaS |- |Початкове використання |Безкоштовне або обмежене. Навіть якщо ліцензійний пакет не вказана явно, авторське право все одно діє. |}

12. Shareware / Trial

!Ознака

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

ERP здатна містити: |- |Вільне поширення |Можна передавати копії іншим. |- | style="background:#d4edda; color:#155724; font-weight:bold;" |Ключове |Open Source — це не відсутність правил |Відкриті ліцензії дають свободи, але так само містять умови. |- |7 |Чи потрібно відкривати власний код? |}

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

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

!Ситуація

BSD 2-Clause;
BSD 3-Clause. |-

|Код закритий |користувач системи отримує тільки готову програму або доступ до сервісу. |- |Ігнорувати GPL/AGPL |Copyleft-ліцензії можуть вимагати відкриття похідного коду.== AGPL == Вона схожа на GPL, але додатково враховує використання програми через мережу. |- |Вимога відкривати власний код |Ні. Це критично для великих компаній, enterprise-продуктів і технологічних платформ. |- |Хочу без зусиль на безкоштовній основі дати програму, але не відкривати код |Freeware / proprietary EULA |Це не open source, але здатна бути безкоштовне використання. |- |Перевага |Дає спільноті відкритий фундамент. |}

!Пояснення

Ознака

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

юристів.

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

Потрібно відкривати власний код

-

Потрібно відкривати похідний код

Так

-

Головна ідея

-

критично

Copyleft здатна вимагати відкриття похідного коду

}

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

Ознака

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

-

Модифікація

-

Приклади

-

Приклад

-

Модель оплати

class="wikitable"

Приклади Open Source Initiative визначає open source-ліцензії як такі, що відповідають Open Source Definition: зокрема, вони мають дозволяти вільне поширення, доступ до початкового коду, створення похідних робіт і не дискримінувати людей або сфери сценарії використання. Він зазвичай вимагає відкривати зміни в самій бібліотеці або файлах, але не обовʼязково весь ERP-продукт. |} ISC License — коротка permissive-ліцензія, схожа за духом на MIT. LGPL — weak copyleft-ліцензія, часто застосовується для для бібліотек. |-

Головна ідея

-

Можна змінювати

-

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

-

Код

Зазвичай закритий.== 10. Open Core == Weak copyleft — це мʼякший copyleft. |-

Повна реліз системи

Платна. Якщо ліцензії немає, юридично код не можна вільно копіювати, змінювати або використовувати у власному продукті. !Ознака

BSD License

Програмний код

-

Чи можна встановити систему on-premise?

-

Коли підходить

-

Вимога відкривати власний код

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

Пишу бібліотеку для широкого використання? * чи можна встановити програму;

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

MIT

Ознака

відкритий вихідний код

-

Особливість

-

провідний ризик

-

Для закритих продуктів

-

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

-

Вимога вказувати автора

-

Приклад

-

Обмеження

-

Для бізнесу

-

Зображення, тексти, медіа

Creative Commons. !ліцензійний пакет

1

-

Обмежене поширення

}

Деякі ліцензії, як приклад Apache License 2.0, містять окремі положення щодо патентів. EPL — open source-ліцензія, повʼязана з Eclipse Foundation. |-

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

-

Приклад

}

AGPL

Питання

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

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

Ознака

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

Strong copyleft

9. Dual licensing

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

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

SPDX ID

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

Простота

-

Чи можна використовувати код із GitHub без ліцензії?

-

Хочу захистити відкритість SaaS-версій

AGPL

Network copyleft враховує використання через мережу. Головна формула:

!Код відкритий?<ref>https://opensource.org/osd</ref>
|-
|Відкрита частина
|Базове ядро продукту. Для бізнесу — питання ризиків.== Creative Commons і програмне забезпечення (ПЗ) ==
!Рекомендований тип ліцензії
== 2. Відкриті ліцензії ==
!LGPL
|-
|Тип
|Permissive. |-
|Хочу, щоб усі похідні версії залишалися відкритими
|GPL
|Strong copyleft захищає відкритість похідного коду. |-
|3
|Чи виступає як SPDX ID? |}

'''[[GNU Affero General Public License|AGPL]]''' — copyleft-ліцензія, важлива для мережевих сервісів. Free Software Foundation описує GNU GPL як вільну copyleft-ліцензію, яка має гарантувати свободу поширювати й змінювати всі версії програми. |-
|SaaS-використання
|здатна створювати обовʼязок надати код користувачам сервісу.== GPL ==
|-
|Тип
|Strong copyleft. |}

!Пропрієтарна ліцензійний пакет
{| class="wikitable"
!Вид ліцензії
!Weak copyleft
!Enterprise-ліцензія
!Варіант
= Що саме відрізняє ліцензії =
'''[[GNU General Public License|GPL]]''' — strong copyleft-ліцензія. |-
|Для спільноти
|здатна бути open source-версія. !GPL

== Чому ліцензійний пакет ERP важлива ==

* використовувати код;
* змінювати код;
* включати код у комерційний ERP-продукт;
* поширювати код;
* створювати закриті продукти на основі цього коду. |-
|5
|Чи можна змінювати код? |-
|MIT License
|<code>MIT</code>
|-
|Apache License 2.0
|<code>Apache-2.0</code>
|-
|GNU GPL v3.0
|<code>GPL-3.0-only</code> або <code>GPL-3.0-or-later</code>
|-
|GNU AGPL v3.0
|<code>AGPL-3.0-only</code> або <code>AGPL-3.0-or-later</code>
|-
|GNU LGPL v3.0
|<code>LGPL-3.0-only</code> або <code>LGPL-3.0-or-later</code>
|-
|BSD 3-Clause
|<code>BSD-3-Clause</code>
|-
|MPL 2.0
|<code>MPL-2.0</code>
|}

!Public Domain / Unlicense
'''SaaS-ліцензія''' — це не класична ліцензійний пакет на встановлення програми, а право користування онлайн-сервісом. AGPL важлива для SaaS-сервісів: якщо модифікована програма застосовують, коли потрібно як мережевий сервіс, користувачі можуть отримати право доступу до відповідного початкового коду. |}

'''Unlicense''' — приклад ліцензії/декларації, яка намагається максимально наблизити код до public domain.== 3. Permissive-ліцензії ==
<blockquote>'''MIT / Apache / BSD''' — бери, використовуй, не забудь вказати автора й ліцензію. |-
|Рівень обмежень
|Низький.</blockquote>
'''[[Apache License 2.0]]''' — permissive-ліцензія, схожа на MIT, але детальніша. !Пояснення

Якщо змінюється файл під MPL, зміни цього файлу мають залишатися відкритими, але ширший ERP-продукт здатна мати іншу ліцензію. |-
|10
|Чи потрібно показувати текст ліцензії користувачам? |-
|Часто застосовується для для
|Бібліотек. |-
|Комерційне використання
|Часто дозволене, але умови залежать від ліцензії. |}

Для розробника це питання прав. |}
{| class="wikitable"

!Характеристика
!Характеристика

Важлива особливість — положення про патентні права. |-
|Модифікація
|Зазвичай заборонена. |-
|Хочу, щоб похідні версії теж залишалися відкритими? |}

'''[[SPDX]]''' — це стандарт для ідентифікації ліцензій і опису складу програмного забезпечення. |-
|Рівень copyleft
|На рівні файлів. |-
|Вимога відкривати власний код
|Ні. |-
|Що містить
|Підтримку, SLA, оновлення версій, юридичні гарантії. |-
| style="background:#d4edda; color:#155724; font-weight:bold;" |Ключове
|'''Для бізнесу важлива сумісність ліцензій'''
|Різні ліцензії можуть по-різному впливати на комерційний ERP-продукт. !Характеристика
{| class="wikitable"
Для ERP, CRM, BI та корпоративних платформ ліцензійний пакет особливо важлива, бо така платформа часто стає центральною частиною бізнесу. {| class="wikitable"
!Ознака
== Повʼязані статті ==
|-
|'''Код відкритий'''
|Можна переглядати й аналізувати початковий код. Open Source — це про права на код.'''</blockquote>
|-
|'''Немає'''
|Можна включати код у закритий ERP-продукт. |-
|Особливість
|Мережеве використання здатна створювати обовʼязок надати код. |}

!Характеристика
{| class="wikitable"
= юридично безпечне програмне забезпечення (ПЗ)
'''Dual licensing''' — це модель, коли один і той самий ERP-продукт доступний за двома або більше ліцензіями. !№
== EPL ==
Зазвичай така ліцензійний пакет:
{| class="wikitable"
!Характеристика
|-
| style="background:#d4edda; color:#155724; font-weight:bold;" |Ключове
|'''ліцензійний пакет визначає права'''
|Сам факт доступу до коду не означає, що його можна використовувати як завгодно. |-
|Хочу open source + платну enterprise-версію? |-
|'''SBOM'''
|SPDX застосовується для для Software Bill of Materials. |-
|Особливість
|Має патентний grant. |-
|2
|Яка саме ліцензійний пакет застосовується для? |}

!ISC
!Якщо відповідь “так”

!Чому критично
== 14. Enterprise-ліцензії ==
!Dual licensing
!Ознака
|-
|Тип
|Weak copyleft. '''Shareware''' або '''Trial''' — це модель, коли програму можна спробувати на безкоштовній основі, але для повного використання потрібно заплатити. |-
|'''Автоматична перевірка'''
|Інструменти можуть сканувати залежності й показувати ризики. |}

<blockquote>'''Пропрієтарне ПЗ дає право користування, але не дає повної свободи контролю над програмою.'''</blockquote>
== Важливі акценти ==

= Простими словами =
!Питання
!Ознака
!Apache 2.0
|-
|Де функціонує програма
|На серверах постачальника. {| class="wikitable"
{| class="wikitable"
!Можна змінювати? |-
|'''виступає як частково'''
|Потрібно відкривати зміни певних компонентів або файлів. |-
|Поширення
|здатна бути обмежене. |-
|'''Не перевіряти SaaS-наслідки AGPL'''
|AGPL здатна спрацювати навіть без класичного поширення програми. |}

!Причина
Головна вимога — зберігати copyright notice і текст ліцензії. |-
|Можна використовувати в закритому продукті
|Так, зазвичай можна. |}

!Помилка
{| class="wikitable"

'''Strong copyleft''' — це сильний copyleft. |-
|Оплата
|Часто підписка. |}

{| class="wikitable"
== 2. Право змінювати ==

Класичний приклад — '''[[GNU Affero General Public License|AGPL]]'''. |-
|ERP-платформа
|Eclipse, Java, enterprise. = Основні види ліцензій програмного забезпечення =
|-
|'''Стандартизація'''
|Усі використовують однакові короткі назви ліцензій. |-
|Приклад
|Mozilla-екосистема. '''Open Core''' — це бізнес-модель, де ядро продукту виступає як відкритим, а частина функцій доступна тільки в платній або закритій версії. |}

!Відповідь
{| class="wikitable"

== ISC License ==
!Пояснення

!Статус

Найвідоміший приклад — '''[[GNU General Public License|GPL]]'''. |-
|6
|Чи можна поширювати модифіковану версію? |-
|9
|Чи сумісна ліцензійний пакет з іншими компонентами? !Використання
== 1. Пропрієтарні ліцензії ==
!Чому
Для програмного коду Creative Commons зазвичай не рекомендують використовувати як основну ліцензію, бо для коду краще підходять спеціалізовані software licenses: MIT, Apache, GPL, BSD, MPL тощо. |-
|'''виступає як сильно'''
|Похідна робота має бути відкрита під сумісною ліцензією. |-
|Для бізнесу
|Зручна. |}

як приклад:
+ обліковий облік залежностей

'''Permissive-ліцензії''' або '''дозвільні ліцензії''' — це відкриті ліцензії з мінімальними обмеженнями. !Network copyleft
{| class="wikitable"
|-
|'''Що таке ліцензійний пакет ПЗ?'''
|Умови, за якими програму або код можна використовувати, змінювати й поширювати. '''Ліцензії програмного забезпечення''' визначають, що можна і чого не можна робити з кодом. |-
|Вимога відкривати власний код
|Ні. |-
|Пишу бібліотеку, яку можна використовувати в закритих продуктах
|LGPL або MPL
|Weak copyleft дає баланс між відкритістю й комерційною інтеграцією. !Чи треба відкривати свій код?== 5. Обовʼязок відкривати похідний код ==
{| class="wikitable"
!Ознака
|-
|Тип
|Permissive.</blockquote><blockquote>'''GPL''' — бери, змінюй, але якщо поширюєш похідну програму, збережи її відкритою. |-
|8
|Чи виступає як патентні умови? |-
|'''Чи відкритий вихідний код модулів?'''
|Це впливає на аудит, підтримку й дорожня карта розвитку.</blockquote><blockquote>'''AGPL''' — як GPL, але ще уважніше для вебсервісів і SaaS. Він отримує доступ до сервісу через інтернет. |-
|Бізнес-ризик
|Потребує уважної юридичної перевірки для SaaS-продуктів. |-
|'''Не можна змінювати'''
|Програма застосовується для тільки в дозволеному вигляді. |-
|Коли підходить
|Якщо автор хоче не дозволити закриття змін через SaaS-модель. |-
|Комерційне використання
|Дозволене тільки в межах договору. це юридичний документ або набір умов, який визначає, як можна використовувати, копіювати, змінювати, поширювати, продавати або інтегрувати програмне забезпечення (ПЗ) виступає ключовою рисою '''ліцензійний пакет програмного забезпечення'''. |-
|Поширення
|Дозволене згідно з умовами ліцензії. |-
|Бізнес-ризик
|здатна бути несумісною із закритим комерційним продуктом. |-
|Хочу мати open source-версію і платну enterprise-версію
|Dual licensing або Open Core
|Підходить для комерційної open source-моделі. Для open source — питання свободи.== MPL ==
!Варіант

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

Приклад

}

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

Не хочу відкривати код? Вона дає можливість:

Характеристика

Питання

Можливий вибір

+ ліцензійний пакет

Приклад

-

Плутати free і open source

} Freeware — це програмне забезпечення (ПЗ), яке можна використовувати на безкоштовній основі, але воно не обовʼязково виступає як відкритим. !Відкрита ліцензійний пакет SPDX License List містить стандартизований короткий ідентифікатор, повну назву, текст ліцензії та постійне посилання для кожної ліцензії або винятку. |-

Вважати, що GitHub = можна використовувати

}

Creative Commons — це ліцензії для текстів, зображень, відео, документації та інших творчих матеріалів. |-

Доступ

-

відкритий вихідний код

Так. !Ознака

Permissive-ліцензія

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

Приклади:

Apache License 2.0

Freeware — це про ціну. |-

Увага

Код без ліцензії — не вільний код

class="wikitable"

Варіант

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

}

Характеристика

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

Заборонене

Рідко для software licenses, частіше трапляється в медіа-ліцензіях. MIT License — одна з найпопулярніших permissive-ліцензій. |-

Для бізнесу

Потрібна уважна юридична оцінка. MPL — weak copyleft-ліцензія на рівні файлів. |-

Приклад

-

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

}

Open Core

BSD

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

Обмежене

-

Можна використовувати в закритому ПЗ

-

Не вести список залежностей

-

Документація

Так

MIT, Apache 2.0, LGPL, MPL. !Характеристика

Чи можна доопрацьовувати систему?

}

Варіант

Питання

7. Weak copyleft

Ознака

застосовується для в багатьох Java та enterprise-проєктах. |-

Приклад моделі

-

Ризик

-

Чим відрізняються відкриті ліцензії?

-

Головна ідея

Так

-

Обмеження

Мінімальні або майже відсутні.== 5. Strong copyleft ==

Приклади SPDX ID:

Тип

}

11. Freeware

Чому це проблема

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

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

Для кого

Компанії, корпорації, державні органи. ліцензійний пакет потрібна, щоб визначити правила гри.== 4. Copyleft-ліцензії ==

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

LGPL

Тип

-

Приклад

-

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

Зазвичай ні. + контроль змін

Copyleft-ліцензія

8. Public Domain та Unlicense

MIT License

Тип

}

Характеристика

Це означає:

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

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

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

Тип

-

Не зберігати copyright notices

Багато ліцензій вимагають зберігати повідомлення про авторство. !Теза

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

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

Висновок

Ознака

Хочу, щоб код могли використовувати всі, навіть у комерційних продуктах

MIT, Apache 2.0, BSD

-

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

}

EPL	Freeware Permissive-ліцензія каже: “Бери й використовуй”. \|-	Головна ідея	Так	-	Модифікація	-	Можна поширювати	-	Простота	-	Юридична ясність	Менше плутанини між схожими ліцензіями й версіями.^[2] Найпоширеніші варіанти:
Доступ до коду	-	Приклади	MIT, Apache 2.0, BSD, ISC. * 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://www.gnu.org/licenses/gpl-3.0.en.html

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

[1]

[2]

Ліцензії програмного забезпечення: відмінності між версіями

Поточна версія на 17:10, 6 травня 2026

Джерела

12. Shareware / Trial

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

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

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

BSD License

Популярні ліцензії програмного забезпечення

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

6. Network copyleft

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

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

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

9. Dual licensing

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

Apache License 2.0

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

7. Weak copyleft

11. Freeware

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

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

LGPL

8. Public Domain та Unlicense

MIT License

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

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

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

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

Висновок