LGPL

SEO title: LGPL — слабка copyleft-ліцензія для бібліотек SEO description: Огляд GNU Lesser General Public License: LGPL 2.1, LGPL 3.0, weak copyleft, linking, бібліотеки, права, обов'язки, сумісність із GPL, відмінності від GPL, MIT, BSD і Apache License 2.0. SEO 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 Alternative to:

Головна ідея: LGPL — це free software / open source ліцензія зі “слабким copyleft”, створена переважно для бібліотек: саму LGPL-бібліотеку та її зміни треба залишати відкритими під LGPL, але програму, яка лише використовує цю бібліотеку, не обов'язково відкривати під GPL/LGPL.

Чому це цікаво: LGPL займає середину між суворою GPL і дуже вільними MIT/BSD/Apache-ліцензіями. Вона дозволяє використовувати бібліотеку навіть у proprietary software, але захищає свободу самої бібліотеки.

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

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

GNU Lesser General Public License або LGPL — це ліцензія на вільне програмне забезпечення, опублікована Free Software Foundation.

LGPL найчастіше використовують для бібліотек, framework-компонентів і reusable software, які мають бути вільними, але при цьому можуть використовуватися в ширшій екосистемі — включно з закритими або комерційними програмами.

Офіційний текст LGPL 2.1 прямо пояснює, що ця ліцензія застосовується до певних бібліотек і відрізняється від звичайної GPL, бо дозволяє linking таких бібліотек із non-free programs. :contentReference[oaicite:0]{index=0}

LGPL 3.0 побудована як доповнення до GPL 3.0: офіційний текст каже, що LGPLv3 включає умови GPLv3, але додає спеціальні додаткові дозволи для бібліотек. :contentReference[oaicite:1]{index=1}

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

Характеристика	Значення
Повна назва	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

SPDX і GNU рекомендують використовувати точні ідентифікатори на кшталт `LGPL-2.1-only`, `LGPL-2.1-or-later`, `LGPL-3.0-only` або `LGPL-3.0-or-later`, а не старі неоднозначні скорочення. :contentReference[oaicite:2]{index=2}

3. LGPL простими словами

LGPL можна пояснити так:

Є бібліотека під LGPL.

Ти можеш використовувати її
у відкритій або закритій програмі.

Але якщо ти змінюєш саму бібліотеку,
ці зміни мають залишатися доступними
під умовами LGPL.

І користувач не повинен бути заблокований
від можливості замінити або модифікувати LGPL-бібліотеку.

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

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

Спочатку LGPL розшифровувалась як Library General Public License.

Пізніше назву змінили на Lesser General Public License.

Сенс слова Lesser у тому, що це “менш сувора” форма copyleft порівняно з GPL.

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

Якщо створюєш похідну програму і поширюєш її,
вона теж має бути під GPL.

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

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

5. Історія

LGPL виникла як компроміс між повним copyleft GPL і permissive-ліцензіями.

Ключові етапи:

Рік	Подія
1989	З'являється GPLv1.
1991	З'являється перша LGPL як GNU Library General Public License.
1999	Виходить LGPL 2.1.
2007	Виходить LGPL 3.0 разом із GPL 3.0-епохою.
2010-ті	LGPL активно використовується в бібліотеках, desktop-компонентах, multimedia, GUI toolkits та системних компонентах.
2020-ті	LGPL залишається важливою ліцензією для бібліотек, особливо коли автори хочуть дозволити використання в proprietary software, але зберегти свободу самої бібліотеки.

SPDX вказує, що LGPL-2.1 була випущена в лютому 1999 року, а LGPL-3.0 — 29 червня 2007 року. :contentReference[oaicite:3]{index=3}

6. Цікавий факт: LGPL — це ліцензія-компроміс

LGPL створили для ситуації, де GPL може бути занадто суворою.

Наприклад, є бібліотека, яку автори хочуть поширити як free software.

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

LGPL дозволяє ширше використання:

Бібліотека залишається вільною.
Закрита програма може її використовувати.
Користувач зберігає свободу щодо самої бібліотеки.

Це зробило LGPL популярною для бібліотек, які мають бути корисними максимально широкій екосистемі.

7. Що таке weak copyleft

Weak copyleft або слабкий copyleft означає, що copyleft застосовується не до всього продукту, а переважно до конкретного LGPL-компонента.

У випадку LGPL:

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

8. LGPL і бібліотеки

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

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

Приклад:

Application
   |
   +--> LGPL library
   |
   +--> proprietary code
   |
   +--> other dependencies

LGPL дозволяє таку структуру, якщо виконуються її умови.

9. Linking

Linking — це підключення бібліотеки до програми.

Є два основні типи:

Тип	Пояснення
Dynamic linking	Програма використовує окремий shared library-файл під час запуску або роботи.
Static linking	Бібліотека вбудовується прямо в executable під час збірки.

Для LGPL dynamic linking зазвичай простіший з точки зору compliance.

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

10. Dynamic linking простими словами

Dynamic linking можна уявити так:

Програма лежить окремо.
Бібліотека лежить окремо.

Програма при запуску каже:
“Мені потрібна ця бібліотека”.

Приклад:

my_app
libexample.so

Це зручно для LGPL, бо користувач теоретично може замінити `libexample.so` на іншу сумісну версію.

11. Static linking простими словами

Static linking:

Бібліотеку “вшивають” прямо в програму.

Приклад:

my_app = application code + LGPL library code

Тут складніше, бо користувач не може просто замінити окремий `.so` файл.

Тому при static linking часто потрібно надавати object files або інший спосіб relinking, щоб користувач міг замінити LGPL-бібліотеку.

12. Цікавий факт: LGPL не забороняє static linking, але робить його відповідальнішим

Іноді кажуть:

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

Це спрощення.

Static linking можливий, але compliance складніший.

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

Чи може користувач реально замінити або модифікувати LGPL-бібліотеку?

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

13. Що дозволяє LGPL

Дія	Дозволено?	Пояснення
Використовувати бібліотеку	Так	У free software або proprietary software.
Змінювати бібліотеку	Так	Але зміни самої LGPL-бібліотеки мають залишатися під LGPL.
Поширювати бібліотеку	Так	За умовами LGPL.
Використовувати в комерційному продукті	Так	Комерційне використання дозволено.
Використовувати в закритому застосунку	Так	Якщо застосунок лише використовує LGPL-бібліотеку і виконані умови.
Закрити зміни самої LGPL-бібліотеки	Ні	Зміни бібліотеки мають бути доступні під LGPL.
Заборонити reverse engineering для debugging змін бібліотеки	Ні	LGPL не дозволяє блокувати користувача в цьому контексті.

14. Основні обов'язки при використанні LGPL

Якщо ви поширюєте програму з LGPL-бібліотекою, зазвичай потрібно:

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

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

Якщо ви просто використовуєте LGPL-бібліотеку без змін, ваш застосунок може мати іншу ліцензію.

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

LGPL library
   |
   +--> your modifications

то ці зміни зазвичай мають бути доступні під LGPL.

Це серце weak copyleft:

Застосунок може бути закритим.
Бібліотека і її зміни мають залишатися вільними.

16. LGPL і proprietary software

LGPL дозволяє використовувати LGPL-бібліотеки в proprietary software.

Приклад:

Closed-source application
   |
   +--> dynamically links LGPL library

Це дозволено, якщо виконуються умови LGPL.

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

• захистити свободу бібліотеки;
• дозволити комерційне використання;
• не відлякати proprietary ecosystem;
• залишити бібліотеку корисною для всіх.

17. LGPL і SaaS

LGPL, як і GPL, зазвичай активується при distribution/conveying software.

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

Це відрізняє LGPL/GPL від AGPL, яка спеціально має network copyleft-логіку.

18. LGPL і GPL

LGPL сумісна з GPL у важливому сенсі: LGPL-код можна використовувати в GPL-проєктах.

LGPL 2.1 має механізм, який дозволяє переоформити LGPL-код під GPL для використання в GPL-програмах; LGPL 3.0 також побудована поверх GPL 3.0 із додатковими дозволами. :contentReference[oaicite:4]{index=4}

Критерій	LGPL	GPL
Copyleft	Слабкий	Сильний
Основний сценарій	Бібліотеки	Програми й бібліотеки, де потрібен strong copyleft
Proprietary application linking	Можливий	Зазвичай проблемний або неможливий при distribution derivative work
Зміни самого licensed-коду	Мають лишатися під LGPL	Мають лишатися під GPL
Мета	Зберегти свободу бібліотеки	Зберегти свободу всієї похідної програми

19. LGPL 2.1

LGPL 2.1 — дуже поширена версія LGPL.

Вона часто зустрічається в старіших і зрілих open source-бібліотеках.

Офіційний текст LGPL 2.1 підкреслює, що вона застосовується до певних бібліотек і дозволяє linking таких бібліотек із non-free programs. :contentReference[oaicite:5]{index=5}

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

LGPL-2.1-only
LGPL-2.1-or-later

20. LGPL 3.0

LGPL 3.0 — новіша версія, пов'язана з GPL 3.0.

LGPL 3.0 включає умови GPL 3.0 і додає спеціальні permissions для бібліотек. :contentReference[oaicite:6]{index=6}

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

LGPL-3.0-only
LGPL-3.0-or-later

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

21. “Only” і “or later”

У GNU-ліцензіях дуже важлива різниця між:

LGPL-2.1-only

і:

LGPL-2.1-or-later

Варіант	Значення
LGPL-2.1-only	Можна використовувати тільки LGPL 2.1.
LGPL-2.1-or-later	Можна використовувати LGPL 2.1 або будь-яку пізнішу версію LGPL.
LGPL-3.0-only	Можна використовувати тільки LGPL 3.0.
LGPL-3.0-or-later	Можна використовувати LGPL 3.0 або пізнішу версію.

Це важливо для сумісності ліцензій і майбутніх оновлень.

22. Цікавий факт: одна фраза “or later” може сильно змінити сумісність

Фраза:

or any later version

може дати проєкту більшу гнучкість.

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

А якщо написано `LGPL-2.1-only`, такої гнучкості немає.

Тому SPDX-ідентифікатор — це не формальність, а важлива юридична деталь.

23. LGPL і Apache License 2.0

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

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

Комбінація	Сумісність	Пояснення
LGPL 3.0 + Apache 2.0	Зазвичай так	Через GPLv3-сумісність Apache 2.0 і структуру LGPLv3.
LGPL 2.1-only + Apache 2.0	Проблемно	LGPL 2.1-only не має прямої сумісності з Apache 2.0.
LGPL 2.1-or-later + Apache 2.0	Можливо через LGPL 3.0	Якщо можна обрати пізнішу версію, можна перейти на LGPLv3-сценарій.

Apache Software Foundation зазначає, що Apache License 2.0 сумісна з GPLv3, але не з GPLv2-only; це важливо для розуміння сумісності з LGPLv3 та старішими GNU-ліцензіями. :contentReference[oaicite:7]{index=7}

24. LGPL і MIT License

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

25. LGPL і BSD License

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

26. LGPL і Apache License 2.0

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

27. LGPL і MPL

Mozilla Public License або MPL теж є weak copyleft-ліцензією, але працює інакше.

Критерій	LGPL	MPL
Weak copyleft boundary	Зазвичай бібліотека / linked component	File-level copyleft
Основний сценарій	Бібліотеки	Файли й компоненти
Proprietary integration	Можлива	Можлива
Compliance-модель	Сильно залежить від linking	Сильно залежить від modified files

28. Коли варто обрати LGPL

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

• ви пишете бібліотеку;
• хочете, щоб сама бібліотека залишалась free software;
• хочете дозволити використання в proprietary software;
• не хочете strong copyleft для всього застосунку;
• хочете, щоб зміни бібліотеки поверталися спільноті;
• ваша бібліотека має бути широко використовуваною;
• MIT/BSD здаються занадто permissive;
• GPL здається занадто суворою для бібліотеки.

29. Коли LGPL може бути не найкращим вибором

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

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

30. Переваги LGPL

Перевага	Опис
Добра для бібліотек	Саме для цього LGPL найчастіше й використовують.
Weak copyleft	Захищає бібліотеку, але не змушує весь застосунок бути open source.
Proprietary-friendly	Дозволяє використання в закритих програмах.
Захищає зміни бібліотеки	Модифікації самої LGPL-бібліотеки мають залишатися відкритими.
GPL-compatible	LGPL-код можна використовувати в GPL-проєктах.
Баланс	Компроміс між MIT/BSD і GPL.

31. Недоліки LGPL

Недолік	Опис
Складніша за MIT/BSD	Linking, relinking і compliance можуть бути непростими.
Static linking потребує уваги	Потрібно забезпечити можливість заміни LGPL-бібліотеки.
Корпоративна обережність	Деякі компанії бояться LGPL через copyleft-елементи.
Не strong copyleft	Proprietary software може використовувати бібліотеку без відкриття власного коду.
Версії мають значення	LGPL-2.1-only, LGPL-2.1-or-later, LGPL-3.0-only — це різні сценарії.
Не завжди проста сумісність	Особливо зі старими ліцензіями або Apache 2.0 у випадку LGPL 2.1-only.

32. Типові помилки новачків

Помилка	Чому виникає	Як правильно думати
“LGPL = GPL”	Обидві GNU copyleft-ліцензії.	LGPL слабша й дозволяє linking із proprietary programs.
“LGPL = MIT”	Обидві дозволяють комерційне використання.	LGPL має copyleft для самої бібліотеки.
“Можна змінити LGPL-бібліотеку й закрити зміни”	Неправильне розуміння weak copyleft.	Зміни бібліотеки мають лишатися під LGPL.
“Static linking завжди заборонений”	Це популярне спрощення.	Він можливий, але з додатковими вимогами.
“Dynamic linking завжди звільняє від усіх обов'язків”	Ні.	Ліцензію, notices і доступ до LGPL-коду все одно треба забезпечити.
“LGPL безпечна без перевірки”	Compliance все одно потрібен.	Перевіряти версію, linking і спосіб distribution.

33. Приклад використання LGPL-бібліотеки

Уявімо:

libimage.so — LGPL-бібліотека
photo_editor — proprietary application

Можливий сценарій:

photo_editor dynamically links libimage.so
користувач отримує інформацію про LGPL
текст LGPL додається до legal notices
source code libimage.so доступний
користувач може замінити libimage.so на сумісну змінену версію

У такому випадку proprietary application не обов'язково стає LGPL.

34. Приклад зміни LGPL-бібліотеки

Інший сценарій:

Компанія бере libimage під LGPL.
Змінює код самої libimage.
Поширює продукт із цією зміненою libimage.

Тоді:

Зміни libimage мають бути доступні під LGPL.

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

35. LGPL у package metadata

Приклади SPDX:

license = "LGPL-2.1-or-later"

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

У source-файлах:

SPDX-License-Identifier: LGPL-2.1-or-later

або:

SPDX-License-Identifier: LGPL-3.0-only

36. Compliance checklist

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

1. Яка саме версія LGPL?
2. only чи or-later?
3. Чи змінювалася сама бібліотека?
4. Dynamic чи static linking?
5. Чи поширюється binary?
6. Чи додано текст ліцензії?
7. Чи збережено copyright notices?
8. Чи доступний source code LGPL-бібліотеки?
9. Чи доступні зміни LGPL-бібліотеки?
10. Чи може користувач замінити або relink бібліотеку?
11. Чи немає EULA, яка забороняє reverse engineering для debugging змін?
12. Чи перевірена сумісність з іншими ліцензіями?

37. Цікавий факт: LGPL часто невидима для користувача

Багато користувачів щодня запускають програми, які використовують LGPL-бібліотеки.

Але вони цього не помічають.

LGPL працює тихо:

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

Це одна з причин, чому LGPL така важлива: вона дозволяє free software-бібліотекам бути частиною дуже широкого software-світу.

38. LGPL і reverse engineering

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

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

Якщо користувач має право змінити LGPL-бібліотеку,
то license/EULA не повинна забороняти йому розібратися,
як змінена бібліотека взаємодіє з програмою.

Це не означає “можна reverse engineer усе що завгодно без обмежень”.

Це конкретно про права, потрібні для використання свободи модифікації LGPL-компонента.

39. LGPL і mobile apps

У mobile apps LGPL може бути складнішою, ніж здається.

Причини:

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

Тому для mobile apps LGPL compliance треба продумувати уважно.

40. LGPL і embedded devices

В embedded-системах LGPL теж може бути складною.

Питання:

• чи може користувач замінити бібліотеку?
• чи доступний source code бібліотеки?
• чи доступні object files для relinking?
• чи не заважає secure boot?
• чи не блокує vendor модифіковану LGPL-бібліотеку?
• чи не суперечить EULA правам LGPL?

LGPL в embedded-світі часто потребує окремого compliance-процесу.

41. Юридичне застереження

Ця стаття пояснює LGPL простими словами, але не є юридичною консультацією.

Для важливих комерційних, distribution, static linking, embedded, mobile або compliance-рішень краще звернутися до юриста або фахівця з open source compliance.

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

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

Вона не каже:

“Якщо ти використав мою бібліотеку,
відкрий увесь свій продукт”.

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

“Бери бібліотеку, закривай її зміни,
і ніхто більше нічого не побачить”.

LGPL каже:

“Твій застосунок може бути твоїм.
Але бібліотека має залишатися вільною
для всіх користувачів”.

Саме цей баланс і робить LGPL важливою.

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

Факт	Пояснення
LGPL спочатку означала Library GPL	Пізніше назву змінили на Lesser GPL.
LGPL — weak copyleft	Вона захищає бібліотеку, але не обов'язково весь застосунок.
LGPL дозволяє proprietary linking	Саме тому її часто використовують для бібліотек.
Static linking не завжди заборонений	Але він створює більше compliance-вимог.
Dynamic linking зазвичай простіший	Бо користувач може замінити shared library.
LGPL 3.0 побудована поверх GPL 3.0	Вона додає додаткові permissions до GPLv3.
“only” і “or later” дуже важливі	Вони впливають на сумісність і можливість переходу на новіші версії.
LGPL часто використовується непомітно	Багато програм використовують LGPL-бібліотеки, але користувачі цього не бачать.

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

Ліцензія не гарантує якість або безпеку коду.

LGPL-бібліотека може бути:

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

Перед використанням важливо:

• перевірити версію бібліотеки;
• читати security advisories;
• оновлювати залежності;
• перевіряти license compliance;
• не змішувати несумісні ліцензії;
• тестувати linking model;
• документувати open source components.

45. Висновок

LGPL — це важлива weak copyleft-ліцензія, створена переважно для бібліотек.

Її головні переваги:

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

Головні обмеження:

• складніша за permissive-ліцензії;
• static linking потребує уваги;
• треба надавати доступ до LGPL-коду й змін;
• потрібно дозволяти заміну або модифікацію бібліотеки;
• версія ліцензії має велике значення;
• compliance у mobile/embedded може бути непростим.

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

46. Джерела

• 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

47. Див. також

GNU Lesser General Public License LGPL GPL GPLv3 AGPL MIT License BSD License Apache License 2.0 Mozilla Public License Free Software Foundation Open source Free software Copyleft Weak copyleft Software license SPDX Dynamic linking Static linking Open source compliance