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

LGPL

Матеріал з K2 ERP Wiki

!== 44. Безпека і відповідальність ==

17. LGPL і SaaS

  • Free Software Foundation: GNU Lesser General Public License v3.0
  • Free Software Foundation: GNU Lesser General Public License v2.1
  • GNU Project: Software Licenses
  • GNU Project: License identifiers and SPDX guidance
  • SPDX License List: LGPL-2.1-only / LGPL-2.1-or-later
  • SPDX License List: LGPL-3.0-only / LGPL-3.0-or-later
  • Apache Software Foundation: GPL compatibility notes
  • Free Software Foundation licensing materials
  • Open source compliance documentation

18. LGPL і GPL

В embedded-системах LGPL теж здатна бути складною. {| class="wikitable"

Це критично для сумісності ліцензій і майбутніх оновлень. * чи не заважає secure boot? SPDX-License-Identifier: LGPL-2.1-or-later

  • дуже якісною;
  • застарілою;
  • вразливою;
  • неправильно використаною;
  • погано інтегрованою;
  • несумісною з вашим deployment-моделем.Apache License 2.0

43. Цікаві факти

15. Зміни бібліотеки

- “LGPL = MIT” - 1999 Виходить LGPL 2.1. Критерій

LGPL можна використовувати тільки з dynamic linking. LGPL

Але якщо ви змінюєте саму бібліотеку:

</syntaxhighlight>

LGPL не дає можливість забороняти користувачу reverse engineering у тій мірі, яка потрібна для debugging modifications LGPL-бібліотеки.
 LGPL слабша й дає можливість linking із proprietary programs.

== 40. LGPL і embedded devices ==

Сумісність залежить від версії LGPL. Чому виникає

LGPL доцільно обрати, якщо: 

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

</pre>
! Її головні конкурентні переваги:

! |-
| Версії мають значення
| LGPL-2.1-only, LGPL-2.1-or-later, LGPL-3.0-only — це різні сценарії. :contentReference [oaicite:1]{index=1}
LGPL-2.1-only
[[Категорія:Ліцензії програмного забезпечення]]

 +--> dynamically links LGPL library

</pre>
“Якщо ти використав мою бібліотеку,
Для важливих комерційних, distribution, static linking, embedded, mobile або compliance-рішень краще звернутися до юриста або фахівця з open source compliance. {| class="wikitable"
 |
У такому випадку proprietary application не обов'язково стає LGPL.

Open source compliance Вона не каже: Уявімо:

} 

[[LGPL]]
'''Людське пояснення:''' LGPL каже: “Можеш будувати свій застосунок навколо цієї бібліотеки, навіть закритий. SEO-опис

Типові SPDX-варіанти:

Змінює код самої libimage. Головні обмеження:
<syntaxhighlight lang="toml">
Перед використанням критично:
1.== 28. Коли варто обрати LGPL ==

my_app = application code + LGPL library code 


LGPL library
LGPL каже м'якше:

Якщо ви без зусиль використовуєте LGPL-бібліотеку без змін, ваш застосунок здатна мати іншу ліцензію. * чи доступний source code бібліотеки? GPL Поширює ERP-продукт із цією зміненою libimage. Причини: Бібліотеку “вшивають” прямо в програму. * чи не суперечить EULA правам LGPL? LGPL

libexample.so </syntaxhighlight> 12.== LGPL і Apache License 2. 26.0 ==

  • static linking частіше трапляється;
  • app stores можуть мати свої правила;
  • користувачу складніше замінити бібліотеку;
  • binary distribution жорсткіше контрольована;
  • relinking здатна бути нетривіальним;
  • DRM або signing можуть заважати модифікаціям. |-
 1989 З'являється GPLv1. SEO-опис

46. Джерела

Тип Weak copyleft Permissive
Зміни бібліотеки Мають залишатися під LGPL Можна закрити
Використання в proprietary software Дозволено за умовами LGPL Дозволено дуже вільно
Linking rules Важливі Майже не мають значення
Простота Складніша Дуже проста
Мета Захист свободи бібліотеки Максимальна свобода повторного використання

Типові SPDX-варіанти:

Якщо створюєш похідну програму і поширюєш її, ! GNU Lesser General Public License або LGPL — це ліцензійний пакет на вільне програмне забезпечення (ПЗ), опублікована Free Software Foundation.== 32. Типові помилки новачків == 


як змінена бібліотека взаємодіє з програмою. |-
| LGPL часто застосовується для непомітно
| Багато програм використовують LGPL-бібліотеки, але користувачі цього не бачать. * сама бібліотека залишається під LGPL;
* зміни бібліотеки зазвичай мають залишатися під LGPL;
* застосунок, який використовує бібліотеку, здатна мати іншу ліцензію;
* proprietary application здатна використовувати LGPL-бібліотеку;
* користувачу треба залишити можливість заміни або модифікації LGPL-бібліотеки.</div>
Зміни libimage мають бути доступні під LGPL. |}

LGPL 3.0 так само краще узгоджується з сучасними питаннями GPLv3-епохи, включно з patent і anti-tivoization контекстом, але здатна бути складнішою для деяких корпоративних сценаріїв.

photo_editor dynamically links libimage.so

3. Приклад: Закрита програма здатна її використовувати. Сумісність

!== 38. LGPL і reverse engineering == 


== 4. Чому LGPL називається Lesser ==

Ти можеш використовувати її

! Головне питання LGPL не “динамічно чи статично”, а:

! |-
| 2010-ті
| LGPL активно застосовують, коли потрібно в бібліотеках, desktop-компонентах, multimedia, GUI toolkits та системних компонентах. користувач системи здатна замінити libimage.so на сумісну змінену версію
відкрий увесь свій ERP-продукт”. 10.</div>

<pre>
Apache Software Foundation зазначає, що Apache License 2.0 сумісна з GPLv3, але не з GPLv2-only; це критично для розуміння сумісності з LGPLv3 та старішими GNU-ліцензіями. Іноді кажуть:
|-
| Weak copyleft boundary
| Зазвичай бібліотека / linked component
| File-level copyleft
|-
| базовий сценарій
| Бібліотеки
| Файли й компоненти
|-
| Proprietary integration
| Можлива
| Можлива
|-
| Compliance-модель
| Сильно залежить від linking
| Сильно залежить від modified files
|}

“Твій застосунок здатна бути твоїм. BSD

== 5. історія продукту ==

6. Це серце weak copyleft:
|-
| Складніша за MIT/BSD
| Linking, relinking і compliance можуть бути непростими. Приклади SPDX:
! |-
| Баланс
| Компроміс між MIT/BSD і GPL. +--> your modifications

як приклад, якщо код під `LGPL-2.1-or-later`, у деяких випадках можна перейти на LGPL 3.0 для сумісності з іншим кодом.


“Бери бібліотеку, закривай її зміни,

 +--> other dependencies

Це конкретно про права, потрібні для використання свободи модифікації LGPL-компонента. Чи збережено copyright notices? Це інтуїтивно для LGPL, бо користувач системи теоретично здатна замінити `libexample.so` на іншу сумісну версію. Інший сценарій:
і ніхто більше нічого не побачить”. |-
| Dynamic linking зазвичай простіший
| Бо користувач системи здатна замінити shared library.<pre>
[[SPDX]]
== 34. Приклад зміни LGPL-бібліотеки ==
LGPL сумісна з GPL у важливому сенсі: LGPL-код можна використовувати в GPL-проєктах. У source-файлах:

<pre>
вона теж має бути під GPL. Чи здатна користувач системи замінити або relink бібліотеку? користувач системи отримує інформацію про LGPL

== 36. Compliance checklist ==

<pre>

GPL каже приблизно:

Але вона так само не каже:

! |-
| Не strong copyleft
| Proprietary software здатна використовувати бібліотеку без відкриття власного коду. Чи додано текст ліцензії? :contentReference [oaicite:6]{index=6}

Застосунок здатна бути закритим. {| class="wikitable"

LGPL-2.1-or-later

* ви хочете максимально просту ліцензію — тоді MIT/BSD;
* ви хочете strong copyleft для всього продукту — тоді GPL;
* ви хочете network copyleft — тоді AGPL;
* ви не хочете, щоб proprietary software використовував ваш код;
* ви не хочете пояснювати linking/compliance;
* ваша аудиторія боїться LGPL через юридичну складність;
* ви пишете маленьку утиліту, а не бібліотеку. Static linking можливий, але compliance складніший. LGPL-3.0-only

! '''LGPL 2.1''' — дуже поширена реліз системи LGPL. {| class="wikitable"
== 3. LGPL простими словами ==
<pre>
5. |-
| LGPL — weak copyleft
| Вона захищає бібліотеку, але не обов'язково весь застосунок.<pre>

! це free software / open source ліцензійний пакет зі “слабким copyleft”. |-
| Використовувати в закритому застосунку
| Так
| Якщо застосунок лише використовує LGPL-бібліотеку і виконані умови. Яка саме реліз системи LGPL? Факт
Програма лежить окремо. 11. Пояснення
“Мені потрібна ця бібліотека”. |-
| “only” і “or later” дуже важливі
| Вони впливають на сумісність і можливість переходу на новіші версії. * перевірити версію бібліотеки;
* читати security advisories;
* оновлювати залежності;
* перевіряти license compliance;
* не змішувати несумісні ліцензії;
* тестувати linking model;
* документувати open source components. Бібліотека залишається вільною. Комбінація
or any later version
== Див. 47. так само ==

Саме тому LGPL часто використовують там, де автори хочуть:

Ця стаття пояснює LGPL простими словами, але не виступає як юридичною консультацією. |- | LGPL 3.0 побудована поверх GPL 3.0 | Вона додає додаткові permissions до GPLv3.== 14. Основні обов'язки при використанні LGPL == |- | Повна назва | GNU Lesser General Public License |- | Скорочення | LGPL |- | Автор / організація | Free Software Foundation |- | Тип | Free software license / open source license |- | Copyleft | Так, але слабкий copyleft |- | Основне призначення | Бібліотеки й reusable components |- | Комерційне використання | Дозволено |- | Використання в закритих програмах | Дозволено за умовами LGPL |- | Зміни самої LGPL-бібліотеки | Зазвичай мають поширюватися під LGPL |- | Dynamic linking | Зазвичай простіший сценарій для proprietary applications |- | Static linking | Можливий, але має більше compliance-вимог |- | Основні версії | LGPL 2.1, LGPL 3.0 |- | SPDX identifiers | LGPL-2.1-only, LGPL-2.1-or-later, LGPL-3.0-only, LGPL-3.0-or-later |}

30. конкурентні переваги LGPL

але програма, яка її використовує,

LGPL дає можливість таку структуру, якщо виконуються її умови. SPDX вказує, що LGPL-2.1 була випущена в лютому 1999 року, а LGPL-3.0 — 29 червня 2007 року. |- | LGPL-3.0-only | Можна використовувати тільки LGPL 3.0. LGPL найчастіше використовують для бібліотек, framework-компонентів і reusable software, які мають бути вільними, але при цьому можуть використовуватися в ширшій екосистемі — включно з закритими або комерційними програмами. LGPL LGPL-3.0-or-later 

Якщо static linking блокує таку можливість, потрібно надати додаткові матеріали для relinking. і:

</div>

== 39. LGPL і mobile apps ==

! Тип

як приклад, виступає як бібліотека, яку автори хочуть поширити як free software. | Ліцензію, notices і доступ до LGPL-коду все одно треба забезпечити. |-
| “Можна змінити LGPL-бібліотеку й закрити зміни”
| Неправильне розуміння weak copyleft. Вона часто зустрічається в старіших і зрілих open source-бібліотеках. * ви пишете бібліотеку;
* хочете, щоб сама бібліотека залишалась free software;
* хочете дозволити використання в proprietary software;
* не хочете strong copyleft для всього застосунку;
* хочете, щоб зміни бібліотеки поверталися спільноті;
* ваша бібліотека має бути широко використовуваною;
* MIT/BSD здаються занадто permissive;
* GPL здається занадто суворою для бібліотеки. * чи не блокує vendor модифіковану LGPL-бібліотеку? Тому для mobile apps LGPL compliance треба продумувати уважно. |-
| Закрити зміни самої LGPL-бібліотеки
| Ні
| Зміни бібліотеки мають бути доступні під LGPL. |-
| Заборонити reverse engineering для debugging змін бібліотеки
| Ні
| LGPL не дає можливість блокувати користувача в цьому контексті. то license/EULA не повинна забороняти йому розібратися,

текст LGPL додається до legal notices

LGPL 3.0 — новіша реліз системи, пов'язана з GPL 3.0. |}

9. Linking

Це не означає “можна reverse engineer усе що завгодно без обмежень”. Бібліотека і її зміни мають залишатися вільними. Але якщо ти змінюєш саму бібліотеку,

здатна мати іншу ліцензію. |- | Не завжди проста сумісність | Особливо зі старими ліцензіями або Apache 2.0 у випадку LGPL 2.1-only. Application

  • складніша за permissive-ліцензії;
  • static linking потребує уваги;
  • треба надавати доступ до LGPL-коду й змін;
  • потрібно дозволяти заміну або модифікацію бібліотеки;
  • реліз системи ліцензії має велике значення;
  • compliance у mobile/embedded здатна бути непростим. Вона дає можливість використовувати бібліотеку навіть у proprietary software, але захищає свободу самої бібліотеки. Mozilla Public License або MPL теж виступає як weak copyleft-ліцензією, але функціонує інакше. {| class="wikitable"

LGPL найчастіше використовують саме для бібліотек. ! Як правильно думати

  • у multimedia-бібліотеках;
  • GUI toolkits;
  • системних компонентах;
  • runtime-бібліотеках;
  • cross-platform libraries;
  • desktop-застосунках;
  • embedded-системах;
  • комерційних програмах. |}

42. Людське пояснення: чим виступає як LGPL

Це відрізняє LGPL/GPL від AGPL, яка спеціально має network copyleft-логіку. Критерій LGPL-2.1-or-later Чи здатна користувач системи реально замінити або модифікувати LGPL-бібліотеку? |- | LGPL 3.0 + Apache 2.0 | Зазвичай так | Через GPLv3-сумісність Apache 2.0 і структуру LGPLv3. Це одна з причин, чому LGPL така важлива: вона дає можливість free software-бібліотекам бути частиною дуже широкого software-світу. |- | Static linking не завжди заборонений | Але він створює більше compliance-вимог. Бібліотека лежить окремо. |- | Поширювати бібліотеку | Так | За умовами LGPL. Чи доступний source code LGPL-бібліотеки? |- | Dynamic linking

| Програма використовує окремий shared library-файл під час запуску або роботи. | Зміни бібліотеки мають лишатися під LGPL.

Чому це цікаво: LGPL займає середину між суворою GPL і дуже вільними MIT/BSD/Apache-ліцензіями.== 6. Цікавий факт: LGPL — це ліцензія-компроміс == GPL

21. “Only” і “or later”

Якщо ви поширюєте програму з LGPL-бібліотекою, зазвичай потрібно:
Програма при запуску каже:
== 8. LGPL і бібліотеки ==
<pre>
== LGPL і Apache License 2. 23.0 ==
== 37. Цікавий факт: LGPL часто невидима для користувача ==
== 10. Dynamic linking простими словами ==
== 33. Приклад використання LGPL-бібліотеки ==
У GNU-ліцензіях дуже важлива різниця між:
'''Linking''' — це підключення бібліотеки до програми. |}

8. |-
| 2007
| Виходить LGPL 3.0 разом із GPL 3.0-епохою. :contentReference [oaicite:5]{index=5}

І користувач системи не повинен бути заблокований

<pre>

Бібліотека залишається вільною,

{| class="wikitable"

Якщо програмне забезпечення (ПЗ) лише функціонує на сервері як SaaS і не поширюється користувачам, обов'язки щодо надання source code можуть не виникати так само, як при розповсюдженні binary. Closed-source application

[[Mozilla Public License]]

{| class="wikitable"

то ці зміни зазвичай мають бути доступні під LGPL. Подія
! Dynamic чи static linking? Тому при static linking часто потрібно надавати object files або інший спосіб relinking, щоб користувач системи міг замінити LGPL-бібліотеку. ! |-
| Static linking потребує уваги
| Потрібно забезпечити можливість заміни LGPL-бібліотеки. ! libimage.so — LGPL-бібліотека

LGPL в embedded-світі часто потребує окремого compliance-процесу. Чи змінювалася сама бібліотека? | LGPL має copyleft для самої бібліотеки. MIT

<syntaxhighlight lang="text">
Ключові етапи:
LGPL можна пояснити так:
[[Static linking]]
[[Free Software Foundation]]

photo_editor — proprietary application

У LGPL 3.0 побудована як доповнення до GPL 3.0: офіційний текст каже, що LGPLv3 передбачено умови GPLv3, але додає спеціальні додаткові дозволи для бібліотек.== 24. LGPL і MIT License ==
|-
| Copyleft
| Слабкий
| Сильний
|-
| базовий сценарій
| Бібліотеки
| Програми й бібліотеки, де потрібен strong copyleft
|-
| Proprietary application linking
| Можливий
| Зазвичай проблемний або неможливий при distribution derivative work
|-
| Зміни самого licensed-коду
| Мають лишатися під LGPL
| Мають лишатися під GPL
|-
| Мета
| Зберегти свободу бібліотеки
| Зберегти свободу всієї похідної програми
|}

у відкритій або закритій програмі. LGPL створили для ситуації, де GPL здатна бути занадто суворою. Значення

{{SEO
|title=LGPL — слабка copyleft-ліцензія для бібліотек
|description=Огляд GNU Lesser General Public License: LGPL 2.1, LGPL 3.0, weak copyleft, linking, бібліотеки, права, обов'язки, сумісність із GPL, відмінності від GPL, MIT, BSD і Apache License 2.0.
|keywords=LGPL, GNU Lesser General Public License, LGPL-2.1, LGPL-3.0, weak copyleft, library license, GPL, free software, open source license, dynamic linking, static linking, copyleft
}}

LGPL 3.0 містить умови GPL 3.0 і додає спеціальні permissions для бібліотек. only чи or-later? |-
| GPL-compatible
| LGPL-код можна використовувати в GPL-проєктах.<pre>
== 31. Недоліки LGPL ==
{

Для LGPL compliance варто перевірити:

{| class="wikitable"

! |}

9. Недолік

{| class="wikitable"
 +--> proprietary code
{| class="wikitable"
Багато користувачів щодня запускають програми, які використовують LGPL-бібліотеки. !== 29. Коли LGPL здатна бути не найкращим вибором ==
! Пізніше назву змінили на '''Lesser General Public License'''. Це спрощення. '''критично:''' LGPL не означає “можна взяти код і забути про ліцензію”. |-
| LGPL-2.1-or-later
| Можна використовувати LGPL 2.1 або будь-яку пізнішу версію LGPL.== 41. Юридичне застереження ==

</pre>
У mobile apps LGPL здатна бути складнішою, ніж здається. :contentReference [oaicite:7]{index=7}
</pre>

<pre>

LGPL каже:

! | Він можливий, але з додатковими вимогами. Дія

LGPL-2.1-only

здатна дати проєкту більшу гнучкість. У випадку LGPL:

</pre>

my_app |- | Добра для бібліотек | Саме для цього LGPL найчастіше й використовують. :contentReference [oaicite:0]{index=0} ! Приклад:

Саме цей баланс і робить LGPL важливою. |- | Proprietary-friendly | дає можливість використання в закритих програмах.== 22. Цікавий факт: одна фраза “or later” здатна сильно змінити сумісність == |- | LGPL-2.1-only | Можна використовувати тільки LGPL 2.1. | Перевіряти версію, linking і спосіб distribution. Пояснення

GPLv3

!
LGPL — це важлива weak copyleft-ліцензія, розроблена переважно для бібліотек. Якщо користувач системи має право змінити LGPL-бібліотеку,
<pre>
Бібліотека — це код, який не виступає як самостійною програмою, а застосовується для іншими програмами. |-
| 1991
| З'являється перша LGPL як GNU Library General Public License. SPDX і GNU рекомендують використовувати точні ідентифікатори на кшталт `LGPL-2.1-only`, `LGPL-2.1-or-later`, `LGPL-3.0-only` або `LGPL-3.0-or-later`, а не старі неоднозначні скорочення. |-
| “Dynamic linking завжди звільняє від усіх обов'язків”
| Ні. :contentReference [oaicite:2]{index=2}
== 27. LGPL і MPL ==

[[Free software]]

! Якщо ви змінюєте саму LGPL-бібліотеку або поширюєте програму з нею, потрібно виконувати умови ліцензії: зберігати ліцензійні повідомлення, надавати доступ до LGPL-коду та не забороняти користувачу замінити або модифікувати бібліотеку. |-
| Використовувати в комерційному продукті
| Так
| Комерційне використання дозволено. Пояснення

|- | LGPL спочатку означала Library GPL | Пізніше назву змінили на Lesser GPL. |- | LGPL дає можливість proprietary linking | Саме тому її часто використовують для бібліотек. Чи доступні зміни LGPL-бібліотеки? Dynamic linking можна уявити так: LGPL виникла як компроміс між повним copyleft GPL і permissive-ліцензіями. Чи поширюється binary? |- | Захищає зміни бібліотеки

| Модифікації самої LGPL-бібліотеки мають залишатися відкритими.

Тому SPDX-ідентифікатор — це не формальність, а важлива юридична деталь. |- | LGPL-3.0-or-later | Можна використовувати LGPL 3.0 або пізнішу версію. :contentReference [oaicite:4]{index=4}

Сенс слова Lesser у тому, що це “менш сувора” форма copyleft порівняно з GPL. |- | “LGPL = GPL” | Обидві GNU copyleft-ліцензії. |- | Weak copyleft | Захищає бібліотеку, але не змушує весь застосунок бути open source. для всіх користувачів”. |- | LGPL 2.1-only + Apache 2.0 | Проблемно | LGPL 2.1-only не має прямої сумісності з Apache 2.0. Критерій

! виступає як бібліотека під LGPL. LGPL 2.1 має механізм, який дає можливість переоформити LGPL-код під GPL для використання в GPL-програмах; LGPL 3.0 так само побудована поверх GPL 3.0 із додатковими дозволами. |- | Static linking | Бібліотека вбудовується прямо в executable під час збірки. Критерій 


[[BSD License]]

[[Dynamic linking]]
А якщо написано `LGPL-2.1-only`, такої гнучкості немає. |-
| Змінювати бібліотеку
| Так
| Але зміни самої LGPL-бібліотеки мають залишатися під LGPL. Дозволено? * чи доступні object files для relinking? MPL

Простими словами: |- | Тип | Weak copyleft | Permissive |- | Зміни licensed-коду | Мають лишатися відкритими під LGPL | Можуть бути закриті |- | Використання в proprietary software | Так | Так |- | Attribution | Так | Так |- | Linking | Має значення | Зазвичай не має особливих обмежень |- | Складність compliance | Вища | Нижча |}

Software license

2. Коротка характеристика

25. LGPL і BSD License

45. Висновок

|- | Тип | Weak copyleft | Permissive |- | Patent grant | Залежить від версії й GPLv3-структури | Явний patent grant |- | Зміни licensed-коду | Мають залишатися під LGPL | Можуть бути закриті |- | Proprietary use | Дозволено за умовами LGPL | Дозволено |- | NOTICE | Не Apache-style NOTICE, але notices треба зберігати | NOTICE-файл важливий, якщо виступає як |- | базовий сценарій | Бібліотеки | Бібліотеки, SDK, infrastructure, apps |} 


! Тут складніше, бо користувач системи не здатна без зусиль замінити окремий `.so` файл.== 11. Static linking простими словами ==

Але вони цього не помічають. |-
| “Static linking завжди заборонений”
| Це популярне спрощення. LGPL
[[Категорія:Open Source]]
<pre>
Можливий сценарій:

LGPL-бібліотека здатна бути:

Але якщо вона буде під GPL, багато proprietary-програм не зможуть її використовувати без відкриття всього свого коду. |
!== 35. LGPL у package metadata ==

<pre>

[[Copyleft]]
  • чи здатна користувач системи замінити бібліотеку? Для LGPL dynamic linking зазвичай простіший з точки зору compliance.

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

1. Загальний SEO-опис

|

Open source 

|

Загальна логіка:

LGPL, як і GPL, зазвичай активується при distribution/conveying software. ліцензійний пакет не гарантує якість або безпеку коду.

Приклад:
Питання:
{| class="wikitable"
компанія-користувач бере libimage під LGPL. :contentReference [oaicite:3]{index=3}

ці зміни мають залишатися доступними

<pre>

Але бібліотека має залишатися вільною

Спочатку LGPL розшифровувалась як '''Library General Public License'''. Це зробило LGPL популярною для бібліотек, які мають бути корисними максимально широкій екосистемі. або:

[[MIT License]]
! LGPL функціонує тихо:

[[AGPL]]
  • дає можливість використання в proprietary software;
  • захищає свободу самої бібліотеки;
  • підходить для reusable components;
  • м'якша за GPL;
  • сильніша за MIT/BSD у захисті змін бібліотеки;
  • сумісна з GPL-світом;
  • корисна для бібліотек, які мають поширюватися широко. {| class="wikitable"

20. LGPL 3.0

Це дозволено, якщо виконуються умови LGPL. Рік ! Чи немає EULA, яка забороняє reverse engineering для debugging змін? Значення ! |- | “LGPL безпечна без перевірки” | Compliance все одно потрібен. |- | 2020-ті | LGPL залишається важливою ліцензією для бібліотек, особливо коли автори хочуть дозволити використання в proprietary software, але зберегти свободу самої бібліотеки. Чи перевірена сумісність з іншими ліцензіями? |- | Використовувати бібліотеку | Так | У free software або proprietary software. |- | LGPL 2.1-or-later + Apache 2.0 | Можливо через LGPL 3.0 | Якщо можна обрати пізнішу версію, можна перейти на LGPLv3-сценарій. Варіант 

+--> LGPL library

Окремо варто відзначити розроблена переважно; так само реалізовано але програму, яка лише використовує цю бібліотеку, не обов'язково відкривати під GPL/LGPL виступає ключовою рисою бібліотек: саму LGPL-бібліотеку і її зміни треба залишати відкритими під LGPL забезпечується через Головна ідея: LGPL. LGPL дає можливість ширше використання:

  • зберегти текст LGPL;
  • зберегти copyright notices;
  • повідомити, що застосовується для LGPL-компонент;
  • надати source code самої LGPL-бібліотеки або спосіб його отримати;
  • надати source code модифікацій LGPL-бібліотеки;
  • не забороняти користувачу змінювати або замінювати LGPL-бібліотеку;
  • при static linking — надати спосіб relinking;
  • не накладати додаткові обмеження, які суперечать LGPL. |-

| Корпоративна обережність | Деякі компанії бояться LGPL через copyleft-елементи. |}

! Критерій 

"license": "LGPL-3.0-or-later"

4.== 12. Цікавий факт: LGPL не забороняє static linking, але робить його відповідальнішим == офіційний текст LGPL 2.1 підкреслює, що вона застосовується до певних бібліотек і дає можливість linking таких бібліотек із non-free programs. |}

Фраза:

!


виступає як два основні типи:

! license = "LGPL-2.1-or-later"
Приклад:
Тоді:



13. Що дає можливість LGPL


Weak copyleft

LGPL здатна бути не найкращим варіантом, якщо:

2. офіційний текст LGPL 2.1 прямо пояснює, що ця ліцензійний пакет застосовується до певних бібліотек і відрізняється від звичайної GPL, бо дає можливість linking таких бібліотек із non-free programs. Apache License 2.0



7. Що таке weak copyleft


! * захистити свободу бібліотеки;



  • дозволити комерційне використання;
    • 

  • не відлякати proprietary ecosystem;
    • 

  • залишити бібліотеку корисною для всіх. {| class="wikitable"


Static linking можливий, але часто створює більше обов'язків, бо користувач системи має мати реальну можливість замінити або модифікувати LGPL-частину.== 16. LGPL і proprietary software ==

LGPL — це ліцензійний пакет для бібліотек, яка намагається не бути занадто суворою і не бути занадто слабкою. |}

SPDX-License-Identifier: LGPL-3.0-only

користувач системи зберігає свободу щодо самої бібліотеки. LGPL





LGPL дає можливість використовувати LGPL-бібліотеки в proprietary software. Перевага

Але решта proprietary application здатна залишатися закритою, якщо вона лише використовує бібліотеку згідно з умовами LGPL. Помилка

Static linking:




}



GNU Lesser General Public LicenseWeak copyleft або слабкий copyleft означає, що copyleft застосовується не до всього продукту, а переважно до конкретного LGPL-компонента. source code libimage.so доступний

під умовами LGPL. Пояснення

19. LGPL 2.1

від функції ERP замінити або модифікувати LGPL-бібліотеку. Але саму бібліотеку не закривай і не забороняй людям її змінювати”. 














Отримано з https://wiki.kyiv.ua/index.php?title=LGPL&oldid=1349