Перейти до вмісту

Ліцензії програмного забезпечення

Матеріал з K2 ERP Wiki
Версія від 17:10, 6 травня 2026, створена R (обговорення | внесок)
(різн.) ← Попередня версія | Поточна версія (різн.) | Новіша версія → (різн.)

!Shareware / Trial

Джерела

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

!Пояснення

|Можна змінювати |Так. |- |Чи можна змінити інтегратора? |Від цього залежить ризик 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 Питання

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

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

 Пояснення

+ права використання

Тип } MPL

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

4 - Вимога відкривати похідний код - Можна використовувати з закритим ПЗ - Вимога відкривати весь ERP-продукт - Поширення Обмежене або заборонене. код
Ціна - Приклад }

6. Network copyleft

користувач системи не отримує програму як файл. |}
Ознака

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

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

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

Коли підходить - Комерційне використання - Закрита частина - Чим відрізняються закриті ліцензії? - Для бізнесу - Пропрієтарна Ні Зазвичай ні Так, за договором Ні 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 Зазвичай ні Ні Так, за підпискою Ні Хмарні сервіси

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
  1. ↑ https://www.gnu.org/licenses/gpl-3.0.en.html
  2. ↑ https://spdx.org/licenses/
Отримано з https://wiki.kyiv.ua/index.php?title=Ліцензії_програмного_забезпечення&oldid=921