На цій сторінці показано неперевірені зміни
Офіційний логотип GNU Lesser General Public License версії 3 (LGPLv3) | |
| Автор | Фонд вільного програмного забезпечення |
|---|---|
| Вебсайт | gnu.org/licenses/lgpl.html(англ.) |
GNU Lesser General Public License (Менша загальна громадська ліцензіяGNU[1]) ранішеGNU Library General Public License (Бібліотечна загальна громадська ліцензія GNU[2])[3] абоLGPL, єліцензією вільного програмного забезпечення(інші мови), виданоюФондом вільного програмного забезпечення[4]. Вона проєктувалася як компроміс між сильнимикопілефт-ліцензіями (наприклад,GPL) і дозвільними ліцензіями якBSD абоMIT[5].
Ліцензія LGPL застосовується в основному до бібліотек програмного забезпечення, тобто до складових програмних проєктів[5][6].
Загальна громадська ліцензія GNU була написана в 1991 році[3] (і оновлена в 1999 і в 2007 роках[7][8])Річардом Столменом за допомогою професораЕбена Моглена(інші мови), головного юрисконсульта Фонду вільного програмного забезпечення[4].
Ліцензія LGPL містить обмеження копілефта безпосередньо напрограмний код, що розповсюджується за цією ліцензією, але не застосовує ці обмеження до програмного забезпечення, яке простокомпонується з даним програмним кодом[4].
У LGPL 2.1 програма, що не є ліцензованою за (L)GPL, може розповсюджуватися на будь-яких умовах, якщо вона не єпохідним твором. Якщо це похідний твір, то умови програми повинні дозволяти «модифікацію твору для власного використання клієнтом тазворотної розробки для налагодження таких модифікацій». Чи є твір, що використовує програму LGPL, похідним твором чи ні, є юридичним питанням. Окремий виконуваний файл, якийдинамічно посилається на бібліотеку через.so,.dll або подібний носій, загалом не вважається похідним твором, як це визначено в LGPL. Він підпадатиме під визначення «твору, який використовує Бібліотеку». Пункт 5 LGPL версії 2.1 говорить:
По суті, якщо це «твір, що використовує бібліотеку», то програмне забезпечення має бути можливим для зв’язування з новішою версією програми, що охоплюється LGPL. Найпоширенішим методом для цього є використання «відповідного механізмуспільної бібліотеки для зв’язування». Як варіант, дозволяєтьсястатично зв’язана бібліотека, якщо надається вихідний код або зв’язувані об’єктні файли[1].
На відміну відGPL, LGPL дозволяє комбінувати (або, у випадкубібліотек, «використовувати»)закритий (тобто власницький) код з кодом LGPL, але лише за умови дотримання наступної умови: користувач повинен мати можливість змінювати та доповнювати частину LGPL і не може бути обмежений у цьому; отже, користувачеві має бути надана необхідна інформація для зі збирання та встановлення та виконання модифікованої версії частини LGPL у комбінованій роботі[9]; крім того, користувачеві не може бути заборонено здійснюватизворотну розробку длядоопрацювання змін частини LGPL.
Програма, яка використовуєпрограмний код LGPL разом із власницьким кодом, незалежно від того, чи ліцензована вона за ліцензією сімейства GPL чи іншими ліцензіями[10], повинна бути побудована таким чином, щоб кожен кінцевий користувач міг (самостійно) пов'язати відкритий код LGPL (або його модифіковані версії) з кінцевою програмою[11]. Це можна зробити за допомогою динамічного зв'язування (де код LGPL використовується в динамічній бібліотеці); тоді кінцевий користувач може створити власну динамічну бібліотеку (жаргон Linux: Shared Object) частини LGPL (наприклад, з модифікованої версії коду LGPL) і використовувати її. Або це може відбуватися шляхомстатичного зв'язування — тоді кінцевий користувач зазвичай отримує об'єктні файли (або вихідний код) пропрієтарного коду та вихідні коди LGPL-коду і може зв'язати їх разом[5].
Зазвичай розробник пропрієтарного програмного забезпечення просто динамічно пов'язує свою програму з відповідною бібліотекою LGPL. Таким чином, програмне забезпечення містить чітке розділення між кодом LGPL і пропрієтарною частиною.
Прикладами бібліотек під ліцензією LGPL є стандартні бібліотеки окремих мов програмування, такі якglibc (реалізаціястандартної бібліотеки C Фонду вільного програмного забезпечення), бібліотекаGNU MP(інші мови),GTK,Mozilla,OpenOffice тощо.
Для бібліотекиC++, яка використовує багато вбудованих функцій і шаблонів класів («templates»), зазвичай вибирають ліцензію, яка є менш обмежувальною (щодо можливих сторонніх розробників), ніж LGPL, якщо передбачається використання бібліотеки разом із власницьким кодом. Адже в цьому випадку власницький код повинен вже містити вхідні функції та шаблонний код бібліотеки тощо у вихідному коді, і тому кінцевому користувачеві не можуть бути надані об'єктні файли пропрієтарного коду, оскільки будь-які модифікації вхідних функцій (бібліотеки) вже повинні бути інтегровані у вихідний код[12]. Як приклад можна навестиlibstdc++ (GNU C++ Library), яка використовує численні вбудовані функції та шаблони: тут розробники libstdc++ вирішили використовувати ліцензію GPL зі спеціальним додатком[13], яка дозволяє розробнику поєднувати libstdc++ із власницьким кодом, причому власницький код не повинен бути ліцензований за GPL або LGPL (але, звичайно, може бути). Зокрема, в цьому випадку відпадає вимога, щоб кінцевий користувач міг підключати бібліотеку libstdc++ у зміненій формі (статичній або динамічній), і тому вона є менш обмежувальною для власницьких розробників, які використовують бібліотеку, ніж LGPL.
Однак діє принцип, що будь-які зміни в самих частинах LGPL (якщо ці зміни були зроблені не виключно для власного використання, а продаються як програма або поширюються будь-яким іншим чином) завжди повинні бути доступними для кінцевих користувачів. Розкриття власного коду, який не залежить від коду LGPL, необхідне лише в тому випадку, якщо в загальному програмному забезпеченні містяться частини вихідного коду (або воно базується на таких частинах), які підпадають під ліцензію GPL і, отже, підлягають принципукопілефту.
LGPL містить опцію опублікувати змінену версію програмного забезпечення під ліцензією GPL. Це дає програмістамвільного програмного забезпечення можливість опублікувати свої розширення за бажанням під ліцензією «копілефт»[9].