| Стандартизація
|
Так
|
}
Вона дає можливість використовувати, змінювати й поширювати код, але вимагає, щоб похідні роботи при поширенні так само залишалися відкритими на умовах GPL або сумісних умовах. |-
| Ключове
|
Open Source — це не відсутність правил
|
-
|
7
|
-
|
Потрібно відкривати власний код
|
-
|
Можна змінювати
|
-
|
Головна ідея
|
}
|
Ознака
Public Domain означає, що автор відмовляється від авторських прав настільки, наскільки це дає можливість закон. |-
|
Вимога вказувати автора
|
class="wikitable"
|
Ознака
Повʼязані статті
|
| Код відкритий
|
-
|
Перевага
|
-
|
10
|
-
|
Модифікація
|
-
|
Приклади
|
-
|
Вимога відкривати власний код
|
-
|
Часто застосовується для для
|
class="wikitable"
|
Пояснення
|
Варіант
|
Питання
7. Weak copyleft
|
Ознака
застосовується для в багатьох Java та enterprise-проєктах. |-
|
критично
|
Copyleft здатна вимагати відкриття похідного коду
|
-
|
Обмеження
|
-
|
-
|
Головна ідея
|
-
|
Приклад
|
-
|
Модифікація
|
-
|
Хочу без зусиль на безкоштовній основі дати програму, але не відкривати код
|
Freeware / proprietary EULA
|
-
|
Ризик
|
Потрібно чітко розуміти, що саме відкрите, а що комерційне. !Теза
Коротко про суть
13. SaaS-ліцензії
Висновок
|
Ознака
|
| Хочу, щоб код могли використовувати всі, навіть у комерційних продуктах
|
MIT, Apache 2.0, BSD
|
-
|
Для закритих продуктів
|
Так
|
}
Unlicense — приклад ліцензії/декларації, яка намагається максимально наблизити код до public domain.== AGPL ==
Вона схожа на GPL, але додатково враховує використання програми через мережу.== GPL ==
|
| Тип
|
-
|
4
|
Чи дозволене комерційне використання?== 10. Open Core ==
Weak copyleft — це мʼякший copyleft. |-
| Повна реліз системи
|
Платна. Якщо ліцензії немає, юридично код не можна вільно копіювати, змінювати або використовувати у власному продукті. Це критично для великих компаній, enterprise-продуктів і технологічних платформ. !Ознака
|
Permissive-ліцензія
- автор не гарантує, що програма працюватиме без помилок;
- автор не несе відповідальності за збитки;
- користувач системи сам оцінює ризики. |-
| Коли підходить
|
-
|
Не можна змінювати
|
class="wikitable"
|
Приклади
Open Source Initiative визначає open source-ліцензії як такі, що відповідають Open Source Definition: зокрема, вони мають дозволяти вільне поширення, доступ до початкового коду, створення похідних робіт і не дискримінувати людей або сфери сценарії використання. |-
| Приклад моделі
|
Community Edition + Enterprise Edition. * чи можна встановити програму;
- чи можна використовувати її в бізнесі;
- чи можна змінювати код;
- чи можна поширювати змінену версію;
- чи можна включити бібліотеку у власний ERP-продукт;
- чи можна продавати ERP-продукт, який використовує цей код;
- чи потрібно відкривати власний код;
- чи потрібно вказувати автора;
- чи виступає як гарантії;
- чи несе автор відповідальність за збитки. Copyleft-ліцензія каже: “Бери, змінюй, але збережи свободу для наступних користувачів”.
|
MIT
|
Ознака
|
| відкритий вихідний код
|
Так.== 4. Copyleft-ліцензії ==
Вони зазвичай дозволяють:
LGPL
| Тип
|
-
|
провідний ризик
|
Неправильне використання ліцензії здатна створити юридичні, комерційні або репутаційні проблеми.[2]
|
| Відкрита частина
|
}
|
Причина
Головна вимога — зберігати copyright notice і текст ліцензії.== 5. Обовʼязок відкривати похідний код ==
| Ознака
|
| Тип
|
-
|
Приклад
|
-
|
Чи можна змінити інтегратора?
|
-
|
Для бізнесу
|
-
|
Оплата
|
-
|
Документація
|
-
|
SBOM
|
-
|
Простота
|
}
Деякі ліцензії, як приклад Apache License 2.0, містять окремі положення щодо патентів. EPL — open source-ліцензія, повʼязана з Eclipse Foundation. |-
|
Що містить
|
-
|
Юридична ясність
|
-
|
Комерційне використання
|
-
|
ERP-платформа
|
}
11. Freeware
|
Чому це проблема
6. Патентні умови
7. Гарантії та відповідальність
| Для кого
|
-
|
Комерційне використання
|
-
|
Можна використовувати з закритим ПЗ
|
-
|
Можна використовувати в закритому ПЗ
|
-
|
Поширення
|
}
|
ISC
|
Якщо відповідь “так”
|
Чому критично
14. Enterprise-ліцензії
|
Dual licensing
|
Ознака
|
| Тип
|
-
|
Приклад
|
}
6. Network copyleft
користувач системи не отримує програму як файл. |-
| Вимога відкривати власний код
|
-
|
Коли підходить
|
}
| Open Core
|
BSD
- фінансові інформаційні дані;
- складський обліковий облік;
- продажі та реалізація;
- закупівельна діяльність;
- виробництво;
- зарплату;
- електронний документообіг;
- інтеграції з банками;
- інтеграції з РРО;
- інтеграції з сайтами;
- API для інших систем. |-
|
Закрита частина
|
-
|
Чим відрізняються закриті ліцензії?
|
-
|
-
|
Модель оплати
|
-
|
Пишу бібліотеку, яку можна використовувати в закритих продуктах
|
LGPL або MPL
|
}
Strong copyleft
9. Dual licensing
4. Комерційне використання
- не дає доступу до початкового коду;
- забороняє зміну програми;
- забороняє копіювання або перепродаж без дозволу;
- здатна обмежувати кількість користувачів;
- здатна обмежувати пристрої, сервери, країни або сфери використання;
- часто має платну модель. |}
|
SPDX ID
Network copyleft — це тип copyleft-ліцензії, який враховує використання програми через мережу. |-
| Для бізнесу
|
-
|
Чи можна використовувати код із GitHub без ліцензії?
|
-
|
Хочу захистити відкритість SaaS-версій
|
AGPL
|
Network copyleft враховує використання через мережу. Головна формула:!Код відкритий? |}
'''[[ISC License]]''' — коротка permissive-ліцензія, схожа за духом на MIT. Для бізнесу — питання ризиків. |-
|Особливість
|Дуже гнучка для бізнесу. |-
|Хочу, щоб усі похідні версії залишалися відкритими
|GPL
|Strong copyleft захищає відкритість похідного коду. |}
= Як вибирати ліцензію для власного проєкту =
= Ліцензії в ERP та бізнес-системах =
!Ситуація
* BSD 2-Clause;
* BSD 3-Clause. !Характеристика
{| class="wikitable"
|-
|'''Чи можна доопрацьовувати систему?'''
|ERP майже завжди потребує адаптації під процеси компанії. Free Software Foundation описує GNU GPL як вільну copyleft-ліцензію, яка має гарантувати свободу поширювати й змінювати всі версії програми. |}
'''[[SPDX]]''' — це стандарт для ідентифікації ліцензій і опису складу програмного забезпечення. !Пояснення
{| class="wikitable"
Більшість open source-ліцензій прямо зазначають, що ПЗ надається '''“as is”''' — тобто без гарантій. |}
!Пропрієтарна ліцензійний пакет
{| class="wikitable"
!Вид ліцензії
!Weak copyleft
!Enterprise-ліцензія
!Варіант
= Що саме відрізняє ліцензії =
'''[[GNU General Public License|GPL]]''' — strong copyleft-ліцензія.</blockquote>
'''[[Apache License 2.0]]''' — permissive-ліцензія, схожа на MIT, але детальніша. !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-сервісів: якщо модифікована програма застосовують, коли потрібно як мережевий сервіс, користувачі можуть отримати право доступу до відповідного початкового коду. |}
!AGPL
!Питання
= Популярні ліцензії програмного забезпечення =
== 3. Право поширювати ==
!Пояснення
+ права використання
|-
|Тип
|Weak copyleft. |-
|Ризик
|У різних юрисдикціях відмова від авторських прав здатна працювати по-різному. |-
|Рівень обмежень
|Низький.</blockquote><blockquote>'''LGPL / MPL''' — компроміс: частина коду має залишатися відкритою, але ширший ERP-продукт здатна бути комерційним. !Пояснення
Якщо змінюється файл під MPL, зміни цього файлу мають залишатися відкритими, але ширший ERP-продукт здатна мати іншу ліцензію. Такі ліцензії можуть вимагати, щоб уся похідна програма поширювалася під такою ж або сумісною ліцензією. '''[[Mozilla Public License|MPL]]''' — weak copyleft-ліцензія на рівні файлів. |-
|Комерційне використання
|Часто дозволене, але умови залежать від ліцензії. |}
Для розробника це питання прав. |}
{| class="wikitable"
!Характеристика
!Характеристика
Важлива особливість — положення про патентні права. |-
|Модифікація
|Зазвичай заборонена. |-
|3
|Чи виступає як SPDX ID? |}
!Помилка
{| class="wikitable"
'''Strong copyleft''' — це сильний copyleft. |-
|Простота
|Дуже коротка. |-
|Приклад
|CRM, ERP, пошта, хмарні сервіси, AI-сервіси. |-
| style="background:#d4edda; color:#155724; font-weight:bold;" |Ключове
|'''Для бізнесу важлива сумісність ліцензій'''
|Різні ліцензії можуть по-різному впливати на комерційний ERP-продукт. |}
'''[[Creative Commons]]''' — це ліцензії для текстів, зображень, відео, документації та інших творчих матеріалів. |}
!MPL
Вона дає можливість використовувати бібліотеку в закритих продуктах за певних умов, але зміни самої бібліотеки мають залишатися відкритими. |-
|'''Хто володіє кастомізаціями?'''
|бізнес-середовище має розуміти, кому належать доопрацьовані модулі. |-
|Особливість
|Мережеве використання здатна створювати обовʼязок надати код. |-
|'''Код закритий'''
|користувач системи отримує тільки готову програму або доступ до сервісу. !№
== EPL ==
Зазвичай така ліцензійний пакет:
{| class="wikitable"
!Характеристика
|-
| style="background:#d4edda; color:#155724; font-weight:bold;" |Ключове
|'''ліцензійний пакет визначає права'''
|Сам факт доступу до коду не означає, що його можна використовувати як завгодно. |-
|Хочу open source + платну enterprise-версію? Open Source — це про права на код.'''</blockquote>
|-
|'''Немає'''
|Можна включати код у закритий ERP-продукт. |-
|Комерційне використання
|Дозволене. |-
|2
|Яка саме ліцензійний пакет застосовується для? |-
|Вимога відкривати весь ERP-продукт
|Зазвичай ні. '''Shareware''' або '''Trial''' — це модель, коли програму можна спробувати на безкоштовній основі, але для повного використання потрібно заплатити. '''[[MIT License]]''' — одна з найпопулярніших permissive-ліцензій. |-
|Доступ до коду
|Зазвичай ні. {| class="wikitable"
{| class="wikitable"
!Можна змінювати? |-
|'''виступає як частково'''
|Потрібно відкривати зміни певних компонентів або файлів. |-
|Доступ до коду
|Зазвичай ні. |-
|'''Не перевіряти SaaS-наслідки AGPL'''
|AGPL здатна спрацювати навіть без класичного поширення програми. |-
|Вимога відкривати власний код
|Ні. |-
|Можна використовувати в закритому продукті
|Так, зазвичай можна. |-
|'''Можна змінювати'''
|користувач системи або компанія-користувач здатна адаптувати код. |}
<blockquote>'''Пропрієтарне ПЗ дає право користування, але не дає повної свободи контролю над програмою.'''</blockquote>
== Важливі акценти ==
= Простими словами =
!Питання
!Ознака
!Apache 2.0
|-
|Де функціонує програма
|На серверах постачальника. |-
|Для бізнесу
|Зручна. |-
|Приклад
|Mozilla-екосистема. |-
|'''Заборонене'''
|Рідко для software licenses, частіше трапляється в медіа-ліцензіях. |-
|Рівень copyleft
|На рівні файлів. '''Open Core''' — це бізнес-модель, де ядро продукту виступає як відкритим, а частина функцій доступна тільки в платній або закритій версії. |}
!Відповідь
{| class="wikitable"
== ISC License ==
!Пояснення
!Статус
Найвідоміший приклад — '''[[GNU General Public License|GPL]]'''. |-
|6
|Чи можна поширювати модифіковану версію? |-
|9
|Чи сумісна ліцензійний пакет з іншими компонентами? |-
|Хочу, щоб похідні версії теж залишалися відкритими? !Характеристика
{| class="wikitable"
Для ERP, CRM, BI та корпоративних платформ ліцензійний пакет особливо важлива, бо така платформа часто стає центральною частиною бізнесу.== Creative Commons і програмне забезпечення (ПЗ) ==
!Рекомендований тип ліцензії
== 2. Відкриті ліцензії ==
!LGPL
|-
|Тип
|Permissive. |}
як приклад:
+ обліковий облік залежностей
'''Permissive-ліцензії''' або '''дозвільні ліцензії''' — це відкриті ліцензії з мінімальними обмеженнями. !Network copyleft
{| class="wikitable"
|-
|'''Що таке ліцензійний пакет ПЗ?'''
|Умови, за якими програму або код можна використовувати, змінювати й поширювати. '''Ліцензії програмного забезпечення''' визначають, що можна і чого не можна робити з кодом.== 5. Strong copyleft ==
Приклади SPDX ID:
{| class="wikitable"
|-
|Тип
|Permissive. |-
|'''Обмежене поширення'''
|Поширення дозволене тільки за договором або заборонене. !Чи треба відкривати свій код? |-
|Вимога відкривати власний код
|Ні. |}
!Пояснення
{| class="wikitable"
!Ознака
* відкрита ліцензійний пакет для спільноти;
* комерційна ліцензійний пакет для бізнесу;
* GPL-версія плюс enterprise-версія;
* open core плюс платні модулі. |-
|8
|Чи виступає як патентні умови? це юридичний документ або набір умов, який визначає, як можна використовувати, копіювати, змінювати, поширювати, продавати або інтегрувати програмне забезпечення (ПЗ) виступає ключовою рисою '''ліцензійний пакет програмного забезпечення'''. |-
|'''Чи відкритий вихідний код модулів?'''
|Це впливає на аудит, підтримку й дорожня карта розвитку.== 3. Permissive-ліцензії ==
<blockquote>'''MIT / Apache / BSD''' — бери, використовуй, не забудь вказати автора й ліцензію. Він отримує доступ до сервісу через інтернет. |-
|Бізнес-ризик
|Потребує уважної юридичної перевірки для SaaS-продуктів. |}
!Характеристика
{| class="wikitable"
= юридично безпечне програмне забезпечення (ПЗ)
'''Dual licensing''' — це модель, коли один і той самий ERP-продукт доступний за двома або більше ліцензіями. |-
|SaaS-використання
|здатна створювати обовʼязок надати код користувачам сервісу. |-
|Комерційне використання
|Дозволене тільки в межах договору. |}
Головна вимога зазвичай — зберегти повідомлення про авторські права й текст ліцензії. |-
|Поширення
|Дозволене згідно з умовами ліцензії. |-
|Бізнес-ризик
|здатна бути несумісною із закритим комерційним продуктом. |Так
|MIT, Apache 2.0, BSD. Для open source — питання свободи.== MPL ==
!Варіант
Найнебезпечніша ліцензійний пакет — це та, яку ніхто не прочитав.
|
| Приклад
|
}
12. Shareware / Trial
|
Ознака
Практичні приклади вибору ліцензії
ERP здатна містити:
|
| Вільне поширення
|
-
|
Не хочу відкривати код? Вона дає можливість:
|
Характеристика
|
Питання
|
Можливий вибір
+ ліцензійний пакет
|
| Приклад
|
-
|
Плутати free і open source
|
Безкоштовне ПЗ здатна бути закритим. !ліцензійний пакет
|
| 1
|
Чи виступає як в проєкті файл LICENSE? !Відкрита ліцензійний пакет
SPDX License List містить стандартизований короткий ідентифікатор, повну назву, текст ліцензії та постійне посилання для кожної ліцензії або винятку. |-
|
Вважати, що GitHub = можна використовувати
|
-
|
Для бізнесу
|
-
|
Обмеження
|
-
|
відкритий вихідний код
|
-
|
виступає як сильно
|
-
|
Обмежене
|
-
|
Увага
|
Код без ліцензії — не вільний код
|
Якщо автор не дав ліцензії, за замовчуванням права залишаються за автором.== Для чого потрібні ліцензії ==
юристів. {| class="wikitable"
|
Варіант
1. Доступ до коду
|
| }
|
Характеристика
У Enterprise-ліцензія — це ліцензійний пакет для компаній, яка часто передбачено не тільки право використання, а й підтримку, SLA, оновлення версій, інтеграції, аудит, безпеку й юридичні гарантії. !Пояснення
|
| Дозволене
|
Можна використовувати в бізнесі або комерційному продукті. !Використання
1. Пропрієтарні ліцензії
|
Чому
Для програмного коду Creative Commons зазвичай не рекомендують використовувати як основну ліцензію, бо для коду краще підходять спеціалізовані software licenses: MIT, Apache, GPL, BSD, MPL тощо. |}
|
Характеристика
Це означає:
Практичний чекліст перед використанням чужого коду
Вона відповідає на практичні питання:
Типові помилки
| Тип
|
Так
|
-
|
Приклад
|
Microsoft Windows, Adobe Photoshop, багато комерційних ERP/CRM-систем. LGPL — weak copyleft-ліцензія, часто застосовується для для бібліотек. |-
|
Хочу мати open source-версію і платну enterprise-версію
|
Dual licensing або Open Core
|
Підходить для комерційної open source-моделі. Вона напряму впливає на бізнес-середовище забезпечується через Простими словами:ліцензійний пакет відповідає на питання: що саме користувач системи, розробник або компанія-користувач має право робити з програмою чи її кодом. ліцензійний пакет важлива не тільки; так само реалізовано розробку, інтеграції, open source, ERP-системи, SaaS-продукти, комерційні рішення для бізнесу та безпеку компанії. + контроль змін
|
Copyleft-ліцензія
8. Public Domain та Unlicense
MIT License
| Тип
|
-
|
Не вести список залежностей
|
}
|
Ознака
Порівняльна таблиця видів ліцензій
|
ліцензійний пакет
Відкрита ліцензійний пакет — це ліцензійний пакет, яка дає можливість використовувати, вивчати, змінювати й поширювати програмне забезпечення (ПЗ) відповідно до умов ліцензії. |Так
|
-
|
Поширення
|
-
|
Для спільноти
|
-
|
Комерційне використання
|
-
|
Чим відрізняються відкриті ліцензії?
|
-
|
Головна ідея
|
}
Freeware — це програмне забезпечення (ПЗ), яке можна використовувати на безкоштовній основі, але воно не обовʼязково виступає як відкритим. Він зазвичай вимагає відкривати зміни в самій бібліотеці або файлах, але не обовʼязково весь ERP-продукт. |-
| Особливість
|
-
|
Код
|
-
|
Комерційне використання
|
-
|
Приклад
|
MIT, Apache 2.0, GPL, LGPL, MPL, BSD. !SaaS
|
| Початкове використання
|
-
|
Коли підходить
|
-
|
Чи можна встановити систему on-premise?
|
-
|
Вимога відкривати похідний код
|
-
|
Не зберігати copyright notices
|
}
AGPL — copyleft-ліцензія, важлива для мережевих сервісів. |}
2. Право змінюватиКласичний приклад — AGPL. |}
| EPL
|
Freeware
Permissive-ліцензія каже: “Бери й використовуй”. |-
|
Головна ідея
|
Так
|
GPL. код
|
| Ціна
|
-
|
Можна поширювати
|
-
|
Пропрієтарна
|
Ні
|
Зазвичай ні
|
Так, за договором
|
Ні
|
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
Ознака
- використовувати код;
- змінювати код;
- поширювати код;
- використовувати в комерційних продуктах;
- включати у закриті продукти. |-
|
Автоматична перевірка
|
Інструменти можуть сканувати залежності й показувати ризики.[3]
Найпоширеніші варіанти:
|
| Доступ до коду
|
-
|
Приклади
|
MIT, Apache 2.0, BSD, ISC. * Open Source Initiative — Licenses: https://opensource.org/licenses
|
| |
|
|
|
|
| |
|
|
|
|
|
|
|
|
|