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

GPL

Матеріал з K2 ERP Wiki
Версія від 09:11, 9 травня 2026, створена R (обговорення | внесок) (Створена сторінка: {{SEO |title=GPL — GNU General Public License, copyleft-ліцензія для вільного програмного забезпечення |description=GPL — Wiki-стаття про GNU General Public License, одну з найвідоміших copyleft-ліцензій для вільного та open source програмного забезпечення. Розглянуто GPLv2, GPLv3, copyleft, source code, derivative works, distributi...)
(різн.) ← Попередня версія | Поточна версія (різн.) | Новіша версія → (різн.)

Цікаво, що слово free у GPL означає не “безкоштовний”, а “вільний”. Що означає

Приклад SPDX у файлі

Only і or later

GPL і Docker images

SEO title: GPL — GNU General Public License, copyleft-ліцензія для вільного програмного забезпечення

SEO keywords: GPL, GNU GPL, GNU General Public License, GPLv2, GPLv3, copyleft, free software, open source license, GPL-3.0-only, GPL-3.0-or-later, GPL-2.0-only, GPL-2.0-or-later, Free Software Foundation, FSF, Richard Stallman, source code, derivative work, LGPL, AGPL, MIT License, Apache License 2.0, software license 

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки.

}}


Практична роль: GPL exception — це як спеціальне додаткове правило, яке пом’якшує або уточнює ліцензію для конкретного сценарію. Рекомендовано:

  • плутати GPL і MIT License;
  • думати, що GPL забороняє продаж;
  • думати, що GPL означає “на безкоштовній основі”;
  • не вказати версію GPL;
  • забути різницю між `only` і `or-later`;
  • копіювати GPL-код у proprietary product без аналізу;
  • не надавати source code при поширенні binary;
  • видаляти copyright notices;
  • не перевіряти license compatibility;
  • вважати, що Docker image не має ліцензійних обов’язків;
  • вважати, що SaaS завжди покривається GPL так само, як distribution;
  • не додавати build scripts;
  • не вести список third-party components. GNU GPL застосовується для для програм, бібліотек, інструментів, серверного ПЗ, desktop-застосунків, системних компонентів і багатьох open source-проєктів. Помилка: обирати GPL для бібліотеки, якщо головна мета — щоб її безперешкодно використовували в будь-яких proprietary-продуктах. Apache License 2.0
  • static linking;
  • dynamic linking;
  • plugins;
  • libraries;
  • IPC;
  • shared libraries;
  • kernel modules;
  • language-specific imports;
  • combined programs. Загальна обережна логіка така: якщо програма тісно поєднується з GPL-бібліотекою в одну роботу, це здатна створювати GPL-обов’язки для всього combined work. Проста різниця: GPL зазвичай сильніше активується при поширенні копій, а AGPL додає вимогу для користувачів, які взаємодіють із програмою через мережу.== Загальний SEO-опис ==

SPDX License List містить окремі записи для GPLv2 і GPLv3. ! GPL вимагає доступ до відповідного source code при поширенні програми. GPL-умови все одно важливі. Висновок: MIT License дає більше свободи компаніям закривати похідні роботи, а GPL краще зберігає відкритість похідного коду.== GPL і SaaS ==

критично: якщо проєкт має патентні ризики, вибір між GPLv2, GPLv3, Apache License 2.0 або іншою ліцензією потрібно робити дуже уважно. Висновок: LGPL часто обирають для бібліотек, коли хочуть зберегти відкритість самої бібліотеки, але не блокувати її використання в закритих програмах. * SPDX-License-Identifier: GPL-3.0-or-later */ Критично: сумісність GPL-коду часто ламається саме через неуважність до “only” і “or later”. * ISO-образ із багатьма незалежними програмами;
  • Linux-дистрибутив із пакетами під різними ліцензіями;
  • збірка інструментів, які не зв’язані в одну програму;
  • репозиторій із незалежними компонентами. * Матеріали щодо copyleft, free software, open source compliance, SBOM, source code distribution, Docker images і embedded Linux compliance.== GPL і proprietary software ==
  • які GPL-пакети всередині image;
  • чи поширюється image іншим;
  • чи виступає як modified GPL components;
  • чи доступний corresponding source;
  • чи збережені notices;
  • чи виступає як SBOM;
  • чи виступає як license files;
  • чи зрозуміло, які компоненти під якими ліцензіями.== Хороші практики GPL ==
Критично: GPL-код здатна бути вільним, але це не означає, що він автоматизовано безпечний, підтримуваний або production-ready. Критерій GPL здатна бути не найкращим вибором, якщо:

Тематичні мітки

Тип Copyleft Permissive
Похідний код Має залишатися GPL-сумісним при поширенні здатна бути закритим
Commercial use Дозволене Дозволене
Proprietary use Обмежене copyleft-умовами при поширенні Дозволене
Головна ідея Зберегти свободу коду Максимально спростити повторне використання

критично: якщо проєкт комерційний або юридично чутливий, питання derivative work краще перевіряти з open source compliance-фахівцем або юристом.== Висновок == GPLv2 важлива для:

GPL і Linux kernel

У GPL-проєктах часто зустрічаються формулювання:

здатна йтися про:

  • модифікована реліз системи GPL-програми;
  • програма, що містить GPL-код;
  • тісно пов’язаний combined work;
  • binary, зібраний із GPL-компонентами;
  • ERP-продукт, який поширює GPL-код у складі більшої системи.== Warranty disclaimer ==

Див. так само

Небезпека: найчастіша GPL-проблема — не сама ліцензійний пакет, а те, що розробник поширює binary й забуває про source code та notices.

GPL і embedded devices

  • GPL — одна з найвідоміших copyleft-ліцензій у світі. * source code offer;
  • build scripts;
  • kernel patches;
  • bootloader changes;
  • license notices;
  • GPL-компоненти в firmware;
  • SBOM;
  • device update mechanism;
  • supplier compliance;
  • availability of corresponding source.

Приклади distribution:

Але межа між “mere aggregation” і derivative/combined work здатна бути складною.
! Це один із найвідоміших GPL-проєктів у світі. У таких випадках GPL одного компонента не обов’язково “поширюється” на всі інші незалежні програми.

SPDX-License-Identifier: GPL-3.0-or-later

GPLv3 розширює й уточнює теми, які стали важливими після GPLv2:

License compatibility

  • Linux kernel використовує GPLv2, не GPLv3;
  • kernel modules мають окремі складні питання сумісності;
  • багато embedded-пристроїв містять Linux kernel;
  • виробники пристроїв мають виконувати GPLv2-обов’язки щодо source code;
  • kernel compliance виступає як важливою частиною open source compliance.</syntaxhighlight>

GPL вимагає, щоб при поширенні GPL-програми або похідної роботи користувачі так само отримували відповідні ліцензійні права й доступ до source code. * вихідні файли;

  • build scripts;
  • makefiles;
  • interface definitions;
  • configuration files;
  • scripts for compilation;
  • installation scripts у відповідних випадках;
  • patches;
  • інструкції для збірки. Потрібно перевіряти:
GPLv3 — третя реліз системи GNU General Public License, опублікована Free Software Foundation 29 червня 2007 року. Головна перевага: GPL не без зусиль відкриває код, а захищає його від перетворення на закритий ERP-продукт при поширенні похідних версій. GPL стала однією з найвпливовіших ліцензій в історії програмного забезпечення.
  • сильний copyleft;
  • захист свободи користувачів;
  • вимога доступу до source code;
  • запобігання закриттю похідних версій;
  • велика історична роль;
  • популярність у free software;
  • OSI-recognized open source license;
  • стандартні SPDX identifiers;
  • хороша для програм, де важлива взаємність;
  • оптимізує будувати commons;
  • змушує downstream-користувачів повертати свободи іншим. Слово `or-later` дає можливість використовувати майбутню версію GPL, а `only` — ні. Основні конкурентні переваги GPL:

GPL, як і багато open source-ліцензій, містить disclaimer: програма надається без гарантій. ! src/

Open source desktop application

Практична роль: GPLv3 намагається захистити свободу не лише “прочитати код”, а й реально змінити програму на пристрої в підтримуваних умовах. Сумісність залежить від конкретного формулювання: “only” або “or later”. * linking exception;

  • classpath exception;
  • GCC Runtime Library Exception;
  • Autoconf exception;
  • project-specific exceptions. |-

| GPL-2.0-only | Код можна використовувати тільки за GPLv2 |- | GPL-2.0-or-later | Код можна використовувати за GPLv2 або будь-якою пізнішою версією GPL |- | GPL-3.0-only | Код можна використовувати тільки за GPLv3 |- | GPL-3.0-or-later | Код можна використовувати за GPLv3 або будь-якою пізнішою версією GPL |}

У сучасних проєктах часто додають коротший SPDX-рядок:

Можливі проблеми:

Linking — одна з найобговорюваніших тем GPL. як приклад: 

<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

компанія-користувач запускає GPL-програму лише всередині себе.</div>

</div>

* автор не гарантує роботу без помилок;
* автор не гарантує придатність для конкретної задачі;
* користувач системи сам відповідає за тестування;
* production-використання потребує перевірки;
* ліцензійний пакет дає права, але не гарантує якість. '''GPL''' — це одна з найважливіших copyleft-ліцензій у світі програмного забезпечення. * SPDX має окремі ідентифікатори для GPL `only` і `or-later` варіантів. GPL добре підходить.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

!</div>

конкурентні переваги GPL

SPDX identifiers

GPL має обмеження. Free Software Foundation підкреслює, що GPL гарантує свободу поширювати й змінювати всі версії програми. Типова структура:

! * GPL — це ліцензійний пакет, яка часто змушує компанії будувати серйозний open source compliance process. Derivative work або похідна робота — одна з найважливіших і найскладніших тем GPL. GPL часто важлива в embedded-пристроях, бо вони використовують Linux, BusyBox, U-Boot та інші open source-компоненти. Тобто GPL не забороняє продавати програмне забезпечення (ПЗ). Якщо автор хоче дозволити proprietary-програмам використовувати бібліотеку, частіше обирають:

GPL не забороняє комерційне використання, але сильно впливає на proprietary software. Mere aggregation — ситуація, коли різні програми без зусиль поширюються поруч, але не утворюють єдину похідну програму.

Розробник створює desktop-застосунок і хоче, щоб усі поширені модифіковані версії так само залишалися open source. Основна ідея: GPL каже: “Можеш користуватися, змінювати й поширювати код, але якщо поширюєш похідну версію — збережи ті самі свободи для інших”.
У `README.md` можна написати:
  • потрібна максимальна adoption у proprietary products;
  • це маленька бібліотека для широкого вбудовування;
  • потрібна permissive-ліцензія;
  • потрібне просте використання в enterprise без copyleft-аналізу;
  • проєкт має бути сумісним із GPL-incompatible dependencies;
  • важлива патентна простота Apache-style;
  • головна мета — дозволити будь-яке повторне використання без взаємності;
  • це sample code, snippets або навчальні приклади без copyleft-цілі. Похідною роботою здатна бути:

Ідея:

See the COPYING file for details. Вона дуже впливова й досі застосовують, коли потрібно в багатьох важливих проєктах. критично: GPLv2 і GPLv3 — не одна й та сама ліцензійний пакет.== Джерела ==

Критично: не можна автоматизовано вважати, що dynamic linking завжди безпечний, а static linking завжди заборонений.

SaaS-проєкт хоче сильний copyleft

GPL-код можна:

Деякі GPL-проєкти мають license exceptions. Критерій

критично: `GPL-3.0-only` і `GPL-3.0-or-later` — різні ліцензійні умови. This program is free software: you can redistribute it and/or modify До source code можуть належати: 

project/

У файлах коду:

* software patents;
* license compatibility;
* anti-tivoization;
* source code requirements;
* additional permissions;
* internationalization;
* termination і reinstatement;
* захист користувацьких свобод у сучаснішому software-середовищі.</div>
GPL відрізняється від permissive-ліцензій тим, що не дає можливість швидко перетворювати похідні роботи на закритий proprietary-продукт. /* SPDX-License-Identifier: GPL-3.0-or-later */
AGPL важлива для:

Це означає:

Виробник продає пристрій із Linux kernel і BusyBox. ! :contentReference [oaicite:7]{index=7}

  • GPL сильніше захищає відкритість похідного коду, ніж MIT або BSD. * GPL важлива не лише для desktop/server software, а й для embedded-пристроїв, роутерів і firmware.

Embedded device з Linux

GPL для бібліотеки доречна, якщо автор хоче, щоб програми, які тісно використовують бібліотеку, так само були free software у відповідних умовах. {| class="wikitable"

GPLv3 приділяє цій проблемі більше уваги, ніж GPLv2.

Copyleft — це принцип, за яким похідні версії програми мають зберігати ті самі або сумісні свободи. * SPDX-License-Identifier: GPL-2.0-only 

*/

OSI публікує сторінку GNU General Public License version 2 і пояснює, що GPL розроблена для свободи поширювати копії, отримувати source code, змінювати ПЗ і використовувати його частини в нових free programs. Вона дає свободу користуватися кодом, але просить не закривати цю свободу для наступних користувачів.</div>
/*
'''Tivoization''' — термін, пов’язаний із ситуацією, коли пристрій містить GPL-програму, але технічно блокує запуск користувацьких модифікованих версій. GPL дає можливість:

'''Підказка:''' GPL найкраще функціонує тоді, коли мета проєкту — не без зусиль популярність коду, а збереження свободи для всіх downstream-користувачів.</div>

'''Практична роль:''' GPLv3 розроблена для новішого світу програмного забезпечення, де важливими стали патенти, пристрої з обмеженим запуском модифікованого ПЗ і складніші моделі поширення. :contentReference [oaicite:3]{index=3}
</div>
  • GNU General Public License v3.0. * Free Software Foundation materials about GNU licenses. Критерій
README.md

Copyright (C) 2026 Example Author

Copyleft strength Сильніший Слабший
Для бібліотек здатна змушувати combined work бути GPL дає можливість ширше використання бібліотеки
Proprietary applications Часто проблемно Часто можливо за умов LGPL
Мета Сильне збереження software freedom Баланс між відкритістю бібліотеки й ширшим використанням

Поширені помилки:

GPLv3

GPL і BSD License

Для GPL критично правильно вказувати точний SPDX identifier. Практична порада: для бібліотек GPL — сильний і свідомий вибір.

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

Приклади:

BSD-ліцензії permissive, а GPL copyleft. '''Практична порада:''' для container images корисно мати SBOM і окремий список third-party licenses. Патентні питання важливі для:
<syntaxhighlight lang="c">
'''Висновок:''' BSD-ліцензія дає більше свободи downstream-користувачам, а GPL сильніше захищає відкритість майбутніх версій. Її потрібно обирати свідомо, а не без зусиль тому, що вона відома. Вона намагається зберегти свободу коду для наступних користувачів. * якщо ви поширюєте модифіковану GPL-програму, потрібно поширювати її під GPL-сумісними умовами;
* користувачі мають отримати source code або доступ до нього;
* не можна додати додаткові обмеження, які забирають GPL-права;
* похідний код не можна без зусиль закрити як proprietary software;
* свободи мають переходити далі. :contentReference [oaicite:2]{index=2}
Потрібно враховувати:
</div>
it under the terms of the GNU General Public License... Саме тому її обирають проєкти, для яких критично зберегти software freedom у downstream-версіях.

На відміну від permissive-ліцензій на кшталт MIT License або BSD License, GPL не без зусиль дає можливість користуватися кодом. OSI публікує сторінки GNU General Public License і вказує GPLv3 як ліцензію зі SPDX short identifier `GPL-3.0`. Вона вимагає зберігати свободи користувача: доступ до source code, право змінювати й право поширювати далі.

Docker image здатна містити GPL-компоненти. Вона дає можливість використовувати, вивчати, змінювати й поширювати код, але вимагає, щоб при поширенні похідних версій користувачі так само отримували відповідні свободи й source code. * SPDX License List: GPL identifiers. Якщо мета — максимальна adoption у різних продуктах, MIT або Apache 2.0 можуть бути простішими.=== Комерційна компанія-користувач використовує GPL-програму внутрішньо ===

* складніша для комерційного використання;
* здатна бути несумісною з деякими ліцензіями;
* не підходить для всіх бібліотек;
* здатна зменшити adoption у proprietary-екосистемах;
* потребує open source compliance;
* складні питання linking;
* складні питання derivative works;
* різниця GPLv2/GPLv3 здатна створювати проблеми;
* не завжди покриває SaaS-сценарії — для цього виступає як AGPL;
* потребує уважного поширення source code. Це ще source code, notices, build scripts, dependencies, distribution і зрозумілий бізнес-процес.</div>

* точно вказувати версію GPL;
* вирішити `only` чи `or-later`;
* додати файл `COPYING` або `LICENSE`;
* використовувати SPDX identifiers;
* зберігати copyright notices;
* перевіряти license compatibility dependencies;
* вести SBOM;
* мати source code offer, якщо поширюється binary;
* документувати build process;
* не змішувати GPL-код із несумісними ліцензіями;
* перевіряти container images;
* мати open source compliance process;
* для SaaS-сценаріїв розглянути AGPL, якщо це мета;
* консультуватися з юристом у комерційних продуктах.== Exceptions ==

Різниця дуже важлива.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Якщо автор хоче, щоб зміни відкривалися навіть при мережевому використанні, варто розглянути AGPL замість звичайної GPL. !<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
</div>
== Коли GPL здатна бути невдалим вибором ==

CLI-інструмент

  • `GPL-1.0-only`;
  • `GPL-1.0-or-later`;
  • `GPL-2.0-only`;
  • `GPL-2.0-or-later`;
  • `GPL-3.0-only`;
  • `GPL-3.0-or-later`. через Перевага: GPL користувачі можуть не лише відкрити код, а й захистити його відкритість у майбутніх похідних версіях. AGPL або GNU Affero General Public License — ліцензійний пакет, схожа на GPLv3, але з додатковою умовою для network use. BSD License

Виробник має враховувати:

Цікаві факти про GPL

У `COPYING` або `LICENSE` додають повний текст GPL. * Документація щодо LGPL і AGPL. GPL відома насамперед як copyleft-ліцензія: вона дає можливість використовувати, вивчати, змінювати й поширювати програму, але вимагає, щоб похідні версії при поширенні так само залишалися під GPL-сумісними умовами. :contentReference [oaicite:5]{index=5}

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

</syntaxhighlight>

GPL добре підходить, якщо потрібно:

Тип Copyleft Permissive Закриття похідного коду Зазвичай не дає можливість при поширенні дає можливість Attribution Так Так Ідея Свобода має зберігатися Максимальна гнучкість використання

GPL для бібліотеки означає сильніші copyleft-наслідки для програм, які її використовують. Головне правило: GPL compliance — це не лише файл LICENSE.== Як додати GPL до проєкту ==

Linking

Обмеження GPL

  • якщо GPL-програма лише функціонує на сервері й копії не передаються користувачам, GPL-обов’язки щодо distribution можуть не активуватися так само;
  • якщо поширюється modified binary або container image клієнтам, обов’язки можуть виникнути;
  • якщо автор хоче copyleft-умови саме для network use, часто обирають AGPL. :contentReference [oaicite:4]{index=4}
Критично: якщо пристрій поширює GPL-програмне забезпечення, виробник не здатна без зусиль сказати “це прошивка, а не софт”. Практична порада: GPL добре підходить для застосунків і інструментів, де автор хоче, щоб покращення, які поширюються іншим, так само залишалися відкритими.
    1. License

Source code

GPL і Apache License 2.0

Або для GPLv2-only:

Distribution

! Йому потрібно дотримуватися GPL-умов: notices, source code, build information у відповідних межах. * GPLv2 only;

  • GPLv2 or later;
  • GPLv3 only;
  • GPLv3 or later.

Tivoization

Поширені ідентифікатори:

  • версію GPL;
  • `only` або `or-later`;
  • сумісність іншої ліцензії;
  • linking model;
  • combined work;
  • exceptions;
  • additional permissions;
  • dependencies;
  • build artifacts;
  • distribution model. це серія ліцензій; так само реалізовано розроблена Free Software Foundation виступає ключовою рисою вільного програмного забезпечення забезпечується через GPL або GNU General Public License. Або:

/* Класична GPL зазвичай прив’язана до поширення копій програми, а не без зусиль до використання програми на сервері.== Free software і open source ==

Багато обов’язків GPL активуються саме під час distribution або передачі копій іншим користувачам. Практична роль: GPL хоче, щоб користувач системи міг не лише отримати binary, а й реально змінити програму й зібрати її. Це здатна виглядати так:

Але якщо GPL-код включено в proprietary-продукт як похідну або combined work, при поширенні можуть виникнути обов’язки відкрити source code всієї відповідної роботи під GPL-сумісними умовами. * GNU General Public License v2.0. GPL

У практиці GPL так само вважається open source-ліцензією. ! GPL

  • web services;
  • SaaS;
  • server-side software;
  • network applications;
  • cloud services;
  • проєктів, які хочуть уникнути “SaaS loophole”;
  • ситуацій, де користувач системи взаємодіє з програмою через мережу. Критерій
  • захистити відкритість похідного коду;
  • зробити software freedom головною умовою;
  • створити free software application;
  • не дозволити закрити модифіковані версії;
  • вимагати source code при поширенні;
  • будувати community commons;
  • поширювати інструмент, який має залишатися відкритим;
  • підтримувати ідеологію free software;
  • уникати proprietary forks при distribution. Проста аналогія: якщо книги стоять на одній полиці, це не означає, що всі вони стали однією книгою.

GPL compatibility — важлива тема, бо не кожен open source-код можна поєднувати з GPL-кодом. Практична роль: точний файл ліцензії, SPDX-рядки й README зменшують плутанину для користувачів, contributor-ів і compliance-інструментів. Команда публікує command-line tool під GPL, щоб користувачі могли змінювати його й поширювати покращення з source code. * великих компаній;

  • стандартів;
  • multimedia codecs;
  • hardware/software products;
  • enterprise software;
  • open source compliance;
  • patent retaliation;
  • license compatibility. !== Copyleft ==

Приклад у коді: ! LGPL

Exceptions можуть дозволяти те, що звичайна GPL обмежувала б сильніше. |- | Тип | Copyleft | Permissive |- | Patent grant | виступає як в GPLv3-контексті | Явний patent grant |- | Похідні роботи | Copyleft-вимоги | Можуть бути proprietary |- | Сумісність | Залежить від версії GPL | Часто сумісна з GPLv3, але не з GPLv2-only |}

Приклади сценаріїв використання

SPDX-License-Identifier: GPL-3.0-or-later критично: free software і open source часто перетинаються технічно, але мають різні акценти: free software більше говорить про свободу користувача, open source — про відкритість і модель розробки. {| class="wikitable" This project is licensed under the GNU General Public License v3.0 or later. Вона допомогла сформувати світ free software, Linux-екосистему, GNU-проєкт і багато open source-проєктів, де критично не лише “відкрити код зараз”, а й не дозволити закрити його в майбутніх похідних версіях. Вона не без зусиль “дає можливість”, а наполягає: якщо ти отримав свободу змінювати код, не забирай цю свободу в наступних людей. ! Головна думка: GPL — це ліцензійний пакет взаємності. Це здатна не створювати тих самих обов’язків, що поширення копій клієнтам, але потрібно перевірити конкретний сценарій. GPL

  • користувач системи має отримати не лише source code;
  • у певних сценаріях він має мати реальну можливість запускати змінені версії;
  • апаратні обмеження не повинні на 100% знецінювати свободу модифікації. GPL тісно пов’язана з рухом free software.== Цікавий факт ==

критично: приватне використання GPL-коду всередині себе зазвичай не створює тих самих обов’язків, що поширення копій іншим.== GPLv2 ==

  • запускати програму;
  • вивчати її роботу;
  • отримувати source code;
  • змінювати програму;
  • поширювати оригінальні копії;
  • поширювати модифіковані версії;
  • продавати копії;
  • використовувати код у free software-проєктах;
  • створювати похідні роботи за умов GPL.
  • Linux kernel;
  • старих GNU-проєктів;
  • великої кількості open source-коду;
  • класичного copyleft-підходу;
  • software freedom;
  • source distribution;
  • license compatibility discussions. COPYING

критично: не використовуйте без зусиль “GPL” без версії, якщо хочете уникнути плутанини. Це створює питання compliance. GPL

Патенти

  • LGPL;
  • MIT License;
  • BSD License;
  • Apache License 2.0;
  • MPL у частині сценаріїв.
    </div>

'''критично:''' для server-side проєктів, де критично відкривати зміни при мережевому використанні, варто розглянути AGPL, а не звичайну GPL.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''GPLv2''' — друга реліз системи GNU General Public License. * Документація щодо GPL compatibility. * AGPL з’явилася для сильнішого copyleft у network/SaaS-сценаріях. Формулювання

== GPL і бібліотеки ==

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
# SPDX-License-Identifier: GPL-2.0-only
</div>

'''LGPL''' або '''GNU Lesser General Public License''' — слабша copyleft-ліцензія, часто використовувана для бібліотек.== Derivative works ==

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
== Коли варто використовувати GPL ==
GPLv3 містить сучасніші положення щодо software patents, ніж GPLv2.

критично: Apache-2.0 код зазвичай не можна без зусиль включити в GPL-2.0-only проєкт без окремої сумісності або дозволу.</syntaxhighlight>

критично:

критично: не видаляйте чужі copyright notices, навіть якщо код відкритий. * Open Source Initiative: GNU General Public License.
  • використовувати приватно;
  • вивчати;
  • змінювати;
  • запускати;
  • продавати як GPL-програму;
  • поширювати з source code. Найлюдяніший факт: GPL — це ліцензійний пакет з характером. * Linux kernel використовує GPLv2, а не GPLv3. Цікавий факт: через GPLv2 Linux kernel користувачі й розробники отримують право бачити й змінювати ядро, навіть якщо воно стоїть усередині роутера, телевізора або іншого пристрою. критично: GPL — сильна ліцензійний пакет. Водночас GPL потребує уважного compliance: реліз системи ліцензії, source code, notices, dependencies, linking, Docker images, embedded devices і `only/or-later` формулювання мають значення. :contentReference [oaicite:6]{index=6}
  • GPL дає можливість продавати software; “free” означає свободу, а не обов’язково нульову ціну. GPLv3 має кращу сумісність із Apache License 2.0, ніж GPLv2-only. Це форма, зручна для внесення змін.
  • викласти binary на сайт;
  • продати пристрій із GPL-програмою;
  • передати клієнту застосунок;
  • поширити модифіковану версію;
  • включити GPL-код у ERP-продукт;
  • роздати копії на носії;
  • опублікувати Docker image з GPL-компонентами в певних сценаріях. Критично: GPL-код не можна без зусиль скопіювати в закритий ERP-продукт і поширювати як proprietary software без виконання GPL-умов.== AGPL ==

<syntaxhighlight lang="c"> Source code у GPL-контексті — це не без зусиль “архів із чимось”. GNU описує GPLv3 як free, copyleft license for software and other kinds of works. MIT License

Найлюдяніший факт: GPL — це ліцензійний пакет не без зусиль про код, а про ідею: користувач системи має мати право зрозуміти програму, змінити її й поділитися змінами.

GPL-проєкти мають зберігати copyright notices. * GPLv3 була опублікована Free Software Foundation 29 червня 2007 року. Деталі залежать від ліцензії, архітектури й юрисдикції. Окремо варто відзначити включно з `only` і `or-later` варіантами. :contentReference [oaicite:1]{index=1}

GPL і MIT License

Mere aggregation

<syntaxhighlight lang="python">

Linux kernel ліцензований під GPLv2.

Apache License 2.0 — permissive-ліцензія з явнішою патентною частиною. У SaaS-сценарії: У GPL copyleft означає: Практична порада: перед змішуванням GPL-коду з кодом під іншими ліцензіями варто перевірити сумісність, а не покладатися на інтуїцію. Проста аналогія: permissive-ліцензія каже “бери й роби майже що хочеш”, а GPL каже “бери, змінюй, поширюй, але не забирай ці права в наступних користувачів”. * Open source

Типові помилки початківців

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