GPL

GPL або GNU General Public License — це серія ліцензій для вільного програмного забезпечення, створена Free Software Foundation. GPL відома насамперед як copyleft-ліцензія: вона дозволяє використовувати, вивчати, змінювати й поширювати програму, але вимагає, щоб похідні версії при поширенні також залишалися під GPL-сумісними умовами.

На відміну від permissive-ліцензій на кшталт MIT License або BSD License, GPL не просто дозволяє користуватися кодом. Вона намагається зберегти свободу коду для наступних користувачів.

Основна ідея: GPL каже: “Можеш користуватися, змінювати й поширювати код, але якщо поширюєш похідну версію — збережи ті самі свободи для інших”.

Цікавий факт

GPL стала однією з найвпливовіших ліцензій в історії програмного забезпечення. Вона допомогла сформувати світ free software, Linux-екосистему, GNU-проєкт і багато open source-проєктів, де важливо не лише “відкрити код зараз”, а й не дозволити закрити його в майбутніх похідних версіях.

Цікаво, що слово free у GPL означає не “безкоштовний”, а “вільний”. Тобто GPL не забороняє продавати програмне забезпечення. Вона вимагає зберігати свободи користувача: доступ до source code, право змінювати й право поширювати далі.

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

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

GNU GPL використовується для програм, бібліотек, інструментів, серверного ПЗ, desktop-застосунків, системних компонентів і багатьох open source-проєктів.

GPL дозволяє:

запускати програму;
вивчати її роботу;
отримувати source code;
змінювати програму;
поширювати оригінальні копії;
поширювати модифіковані версії;
продавати копії;
використовувати код у free software-проєктах;
створювати похідні роботи за умов GPL.

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

Перевага: GPL допомагає не лише відкрити код, а й захистити його відкритість у майбутніх похідних версіях.

Free software і open source

GPL тісно пов’язана з рухом free software. Free Software Foundation підкреслює, що GPL гарантує свободу поширювати й змінювати всі версії програми. :contentReference[oaicite:1]{index=1}

У практиці GPL також вважається open source-ліцензією. OSI публікує сторінки GNU General Public License і вказує GPLv3 як ліцензію зі SPDX short identifier `GPL-3.0`. :contentReference[oaicite:2]{index=2}

Важливо: free software і open source часто перетинаються технічно, але мають різні акценти: free software більше говорить про свободу користувача, open source — про відкритість і модель розробки.

Copyleft

Copyleft — це принцип, за яким похідні версії програми мають зберігати ті самі або сумісні свободи.

У GPL copyleft означає:

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

Проста аналогія: permissive-ліцензія каже “бери й роби майже що хочеш”, а GPL каже “бери, змінюй, поширюй, але не забирай ці права в наступних користувачів”.

GPLv2

GPLv2 — друга версія GNU General Public License. Вона дуже впливова й досі використовується в багатьох важливих проєктах.

GPLv2 важлива для:

Linux kernel;
старих GNU-проєктів;
великої кількості open source-коду;
класичного copyleft-підходу;
software freedom;
source distribution;
license compatibility discussions.

OSI публікує сторінку GNU General Public License version 2 і пояснює, що GPL створена для свободи поширювати копії, отримувати source code, змінювати ПЗ і використовувати його частини в нових free programs. :contentReference[oaicite:3]{index=3}

Важливо: GPLv2 і GPLv3 — не одна й та сама ліцензія. Сумісність залежить від конкретного формулювання: “only” або “or later”.

GPLv3

GPLv3 — третя версія GNU General Public License, опублікована Free Software Foundation 29 червня 2007 року. GNU описує GPLv3 як free, copyleft license for software and other kinds of works. :contentReference[oaicite:4]{index=4}

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

software patents;
license compatibility;
anti-tivoization;
source code requirements;
additional permissions;
internationalization;
termination і reinstatement;
захист користувацьких свобод у сучаснішому software-середовищі.

Практична роль: GPLv3 створена для новішого світу програмного забезпечення, де важливими стали патенти, пристрої з обмеженим запуском модифікованого ПЗ і складніші моделі поширення.

SPDX identifiers

Для GPL важливо правильно вказувати точний SPDX identifier.

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

`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`.

SPDX License List містить окремі записи для GPLv2 і GPLv3, включно з `only` та `or-later` варіантами. :contentReference[oaicite:5]{index=5}

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

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

Або:

# SPDX-License-Identifier: GPL-2.0-only

Важливо: `GPL-3.0-only` і `GPL-3.0-or-later` — різні ліцензійні умови. Слово `or-later` дозволяє використовувати майбутню версію GPL, а `only` — ні.

Only і or later

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

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

Різниця дуже важлива.

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

Критично: сумісність GPL-коду часто ламається саме через неуважність до “only” і “or later”.

Source code

GPL вимагає доступ до відповідного source code при поширенні програми.

Source code у GPL-контексті — це не просто “архів із чимось”. Це форма, зручна для внесення змін.

До source code можуть належати:

вихідні файли;
build scripts;
makefiles;
interface definitions;
configuration files;
scripts for compilation;
installation scripts у відповідних випадках;
patches;
інструкції для збірки.

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

Distribution

Багато обов’язків GPL активуються саме під час distribution або передачі копій іншим користувачам.

Приклади distribution:

викласти binary на сайт;
продати пристрій із GPL-програмою;
передати клієнту застосунок;
поширити модифіковану версію;
включити GPL-код у продукт;
роздати копії на носії;
опублікувати Docker image з GPL-компонентами в певних сценаріях.

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

Derivative works

Derivative work або похідна робота — одна з найважливіших і найскладніших тем GPL.

Похідною роботою може бути:

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

Але межа між “mere aggregation” і derivative/combined work може бути складною.

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

Mere aggregation

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

Наприклад:

ISO-образ із багатьма незалежними програмами;
Linux-дистрибутив із пакетами під різними ліцензіями;
збірка інструментів, які не зв’язані в одну програму;
репозиторій із незалежними компонентами.

У таких випадках GPL одного компонента не обов’язково “поширюється” на всі інші незалежні програми.

Проста аналогія: якщо книги стоять на одній полиці, це не означає, що всі вони стали однією книгою.

Linking

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

Може йтися про:

static linking;
dynamic linking;
plugins;
libraries;
IPC;
shared libraries;
kernel modules;
language-specific imports;
combined programs.

Загальна обережна логіка така: якщо програма тісно поєднується з GPL-бібліотекою в одну роботу, це може створювати GPL-обов’язки для всього combined work.

Критично: не можна автоматично вважати, що dynamic linking завжди безпечний, а static linking завжди заборонений. Деталі залежать від ліцензії, архітектури й юрисдикції.

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

GPL для бібліотеки означає сильніші copyleft-наслідки для програм, які її використовують.

Якщо автор хоче дозволити proprietary-програмам використовувати бібліотеку, частіше обирають:

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

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

Практична порада: для бібліотек GPL — сильний і свідомий вибір. Якщо мета — максимальна adoption у різних продуктах, MIT або Apache 2.0 можуть бути простішими.

LGPL

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

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

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

Висновок: LGPL часто обирають для бібліотек, коли хочуть зберегти відкритість самої бібліотеки, але не блокувати її використання в закритих програмах.

AGPL

AGPL або GNU Affero General Public License — ліцензія, схожа на GPLv3, але з додатковою умовою для network use.

AGPL важлива для:

web services;
SaaS;
server-side software;
network applications;
cloud services;
проєктів, які хочуть уникнути “SaaS loophole”;
ситуацій, де користувач взаємодіє з програмою через мережу.

Проста різниця: GPL зазвичай сильніше активується при поширенні копій, а AGPL додає вимогу для користувачів, які взаємодіють із програмою через мережу.

GPL і MIT License

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

Висновок: MIT License дає більше свободи компаніям закривати похідні роботи, а GPL краще зберігає відкритість похідного коду.

GPL і Apache License 2.0

Apache License 2.0 — permissive-ліцензія з явнішою патентною частиною. GPLv3 має кращу сумісність із Apache License 2.0, ніж GPLv2-only.

Критерій	GPL	Apache License 2.0
Тип	Copyleft	Permissive
Patent grant	Є в GPLv3-контексті	Явний patent grant
Похідні роботи	Copyleft-вимоги	Можуть бути proprietary
Сумісність	Залежить від версії GPL	Часто сумісна з GPLv3, але не з GPLv2-only

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

GPL і BSD License

BSD-ліцензії permissive, а GPL copyleft.

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

Висновок: BSD-ліцензія дає більше свободи downstream-користувачам, а GPL сильніше захищає відкритість майбутніх версій.

GPL і proprietary software

GPL не забороняє комерційне використання, але сильно впливає на proprietary software.

GPL-код можна:

використовувати приватно;
вивчати;
змінювати;
запускати;
продавати як GPL-програму;
поширювати з source code.

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

Критично: GPL-код не можна просто скопіювати в закритий продукт і поширювати як proprietary software без виконання GPL-умов.

GPL і SaaS

Класична GPL зазвичай прив’язана до поширення копій програми, а не просто до використання програми на сервері.

У SaaS-сценарії:

якщо GPL-програма лише працює на сервері й копії не передаються користувачам, GPL-обов’язки щодо distribution можуть не активуватися так само;
якщо поширюється modified binary або container image клієнтам, обов’язки можуть виникнути;
якщо автор хоче copyleft-умови саме для network use, часто обирають AGPL.

Важливо: для server-side проєктів, де важливо відкривати зміни при мережевому використанні, варто розглянути AGPL, а не звичайну GPL.

GPL і Docker images

Docker image може містити GPL-компоненти. Це створює питання compliance.

Потрібно враховувати:

які GPL-пакети всередині image;
чи поширюється image іншим;
чи є modified GPL components;
чи доступний corresponding source;
чи збережені notices;
чи є SBOM;
чи є license files;
чи зрозуміло, які компоненти під якими ліцензіями.

Практична порада: для container images корисно мати SBOM і окремий список third-party licenses.

GPL і Linux kernel

Linux kernel ліцензований під GPLv2. Це один із найвідоміших GPL-проєктів у світі.

Важливо:

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

Цікавий факт: через GPLv2 Linux kernel користувачі й розробники отримують право бачити й змінювати ядро, навіть якщо воно стоїть усередині роутера, телевізора або іншого пристрою.

GPL і embedded devices

GPL часто важлива в embedded-пристроях, бо вони використовують Linux, BusyBox, U-Boot та інші open source-компоненти.

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

source code offer;
build scripts;
kernel patches;
bootloader changes;
license notices;
GPL-компоненти в firmware;
SBOM;
device update mechanism;
supplier compliance;
availability of corresponding source.

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

Tivoization

Tivoization — термін, пов’язаний із ситуацією, коли пристрій містить GPL-програму, але технічно блокує запуск користувацьких модифікованих версій.

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

Ідея:

користувач має отримати не лише source code;
у певних сценаріях він має мати реальну можливість запускати змінені версії;
апаратні обмеження не повинні повністю знецінювати свободу модифікації.

Практична роль: GPLv3 намагається захистити свободу не лише “прочитати код”, а й реально змінити програму на пристрої в підтримуваних умовах.

Патенти

GPLv3 містить сучасніші положення щодо software patents, ніж GPLv2.

Патентні питання важливі для:

великих компаній;
стандартів;
multimedia codecs;
hardware/software products;
enterprise software;
open source compliance;
patent retaliation;
license compatibility.

Важливо: якщо проєкт має патентні ризики, вибір між GPLv2, GPLv3, Apache License 2.0 або іншою ліцензією потрібно робити дуже уважно.

Warranty disclaimer

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

Це означає:

автор не гарантує роботу без помилок;
автор не гарантує придатність для конкретної задачі;
користувач сам відповідає за тестування;
production-використання потребує перевірки;
ліцензія дає права, але не гарантує якість.

Критично: GPL-код може бути вільним, але це не означає, що він автоматично безпечний, підтримуваний або production-ready.

License compatibility

GPL compatibility — важлива тема, бо не кожен open source-код можна поєднувати з GPL-кодом.

Потрібно перевіряти:

версію GPL;
`only` або `or-later`;
сумісність іншої ліцензії;
linking model;
combined work;
exceptions;
additional permissions;
dependencies;
build artifacts;
distribution model.

Практична порада: перед змішуванням GPL-коду з кодом під іншими ліцензіями варто перевірити сумісність, а не покладатися на інтуїцію.

Exceptions

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

Приклади:

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

Exceptions можуть дозволяти те, що звичайна GPL обмежувала б сильніше.

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

Як додати GPL до проєкту

Типова структура:

project/
  COPYING
  README.md
  src/

У `COPYING` або `LICENSE` додають повний текст GPL.

У `README.md` можна написати:

## License

This project is licensed under the GNU General Public License v3.0 or later.
See the COPYING file for details.

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

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

Практична роль: точний файл ліцензії, SPDX-рядки й README зменшують плутанину для користувачів, contributor-ів і compliance-інструментів.

Copyright notices

GPL-проєкти мають зберігати copyright notices.

Це може виглядати так:

Copyright (C) 2026 Example Author

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License...

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

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

Важливо: не видаляйте чужі copyright notices, навіть якщо код відкритий.

Переваги GPL

Основні переваги GPL:

сильний copyleft;
захист свободи користувачів;
вимога доступу до source code;
запобігання закриттю похідних версій;
велика історична роль;
популярність у free software;
OSI-recognized open source license;
стандартні SPDX identifiers;
хороша для програм, де важлива взаємність;
допомагає будувати commons;
змушує downstream-користувачів повертати свободи іншим.

Головна перевага: GPL не просто відкриває код, а захищає його від перетворення на закритий продукт при поширенні похідних версій.

Обмеження GPL

GPL має обмеження.

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

складніша для комерційного використання;
може бути несумісною з деякими ліцензіями;
не підходить для всіх бібліотек;
може зменшити adoption у proprietary-екосистемах;
потребує open source compliance;
складні питання linking;
складні питання derivative works;
різниця GPLv2/GPLv3 може створювати проблеми;
не завжди покриває SaaS-сценарії — для цього є AGPL;
потребує уважного поширення source code.

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

Коли варто використовувати GPL

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

захистити відкритість похідного коду;
зробити software freedom головною умовою;
створити free software application;
не дозволити закрити модифіковані версії;
вимагати source code при поширенні;
будувати community commons;
поширювати інструмент, який має залишатися відкритим;
підтримувати ідеологію free software;
уникати proprietary forks при distribution.

Практична порада: GPL добре підходить для застосунків і інструментів, де автор хоче, щоб покращення, які поширюються іншим, також залишалися відкритими.

Коли GPL може бути невдалим вибором

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

потрібна максимальна adoption у proprietary products;
це маленька бібліотека для широкого вбудовування;
потрібна permissive-ліцензія;
потрібне просте використання в enterprise без copyleft-аналізу;
проєкт має бути сумісним із GPL-incompatible dependencies;
важлива патентна простота Apache-style;
головна мета — дозволити будь-яке повторне використання без взаємності;
це sample code, snippets або навчальні приклади без copyleft-цілі.

Важливо: GPL — сильна ліцензія. Її потрібно обирати свідомо, а не просто тому, що вона відома.

Хороші практики GPL

Рекомендовано:

точно вказувати версію 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, якщо це мета;
консультуватися з юристом у комерційних продуктах.

Головне правило: GPL compliance — це не лише файл LICENSE. Це ще source code, notices, build scripts, dependencies, distribution і зрозумілий процес.

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

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

плутати 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.

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

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

GPL — одна з найвідоміших copyleft-ліцензій у світі.
GPLv3 була опублікована Free Software Foundation 29 червня 2007 року. :contentReference[oaicite:6]{index=6}
GPL дозволяє продавати software; “free” означає свободу, а не обов’язково нульову ціну.
Linux kernel використовує GPLv2, а не GPLv3.
SPDX має окремі ідентифікатори для GPL `only` і `or-later` варіантів. :contentReference[oaicite:7]{index=7}
GPL сильніше захищає відкритість похідного коду, ніж MIT або BSD.
AGPL з’явилася для сильнішого copyleft у network/SaaS-сценаріях.
GPL важлива не лише для desktop/server software, а й для embedded-пристроїв, роутерів і firmware.
GPL — це ліцензія, яка часто змушує компанії будувати серйозний open source compliance process.

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

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

Open source desktop application

Розробник створює desktop-застосунок і хоче, щоб усі поширені модифіковані версії також залишалися open source. GPL добре підходить.

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

Команда публікує command-line tool під GPL, щоб користувачі могли змінювати його й поширювати покращення з source code.

Embedded device з Linux

Виробник продає пристрій із Linux kernel і BusyBox. Йому потрібно дотримуватися GPL-умов: notices, source code, build information у відповідних межах.

Комерційна компанія використовує GPL-програму внутрішньо

Компанія запускає GPL-програму лише всередині себе. Це може не створювати тих самих обов’язків, що поширення копій клієнтам, але потрібно перевірити конкретний сценарій.

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

Якщо автор хоче, щоб зміни відкривалися навіть при мережевому використанні, варто розглянути AGPL замість звичайної GPL.

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

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

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

Або для GPLv2-only:

/*
 * SPDX-License-Identifier: GPL-2.0-only
 */

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

Джерела

GNU General Public License v3.0.
GNU General Public License v2.0.
Free Software Foundation materials about GNU licenses.
Open Source Initiative: GNU General Public License.
SPDX License List: GPL identifiers.
Документація щодо GPL compatibility.
Документація щодо LGPL і AGPL.
Матеріали щодо copyleft, free software, open source compliance, SBOM, source code distribution, Docker images і embedded Linux compliance.

Висновок

GPL — це одна з найважливіших copyleft-ліцензій у світі програмного забезпечення. Вона дозволяє використовувати, вивчати, змінювати й поширювати код, але вимагає, щоб при поширенні похідних версій користувачі також отримували відповідні свободи й source code.

GPL відрізняється від permissive-ліцензій тим, що не дозволяє легко перетворювати похідні роботи на закритий proprietary-продукт. Саме тому її обирають проєкти, для яких важливо зберегти software freedom у downstream-версіях. Водночас GPL потребує уважного compliance: версія ліцензії, source code, notices, dependencies, linking, Docker images, embedded devices і `only/or-later` формулювання мають значення.

Головна думка: GPL — це ліцензія взаємності. Вона дає свободу користуватися кодом, але просить не закривати цю свободу для наступних користувачів.