GPL, MIT чи Apache: що вимагає кожна ліцензія

GPL проти MIT проти Apache: чого вимагає кожна ліцензія

GPL, MIT і Apache 2.0 по-різному відповідають на одне запитання: що ви маєте іншим людям, коли передаєте їм програмне забезпечення? MIT вимагає лише зберігати повідомлення про авторські права. Apache 2.0 вимагає цього повідомлення, а також патентної угоди між усіма, хто працює з кодом. GPL вимагає опублікувати вихідний код створеного вами доповнення за тією самою ліцензією, яку ви отримали.

Це здається питанням для юристів, доки одного дня проєкт, яким ви керуєте, не змінює ліцензію та не розділяється на два. Після цього це вже операційне питання. Вам доводиться вибирати між двома репозиторіями пакетів, а клієнтські бібліотеки перестають взаємодіяти між собою. У цьому посібнику розглянуто ліцензії та механізми їхньої роботи, а не рух, який їх створив. Тому кожен розділ завершується практичним наслідком для вас — людини, яка має виконати оновлення.

Чому існує GPL: принтер, який ніхто не мав права ремонтувати

Приблизно у 1980 році лабораторія штучного інтелекту MIT отримала лазерний принтер Xerox 9700. Для попереднього принтера в лабораторії вже виправили програмне забезпечення, щоб воно повідомляло про застрягання завдання. Для нової моделі вихідного коду не було, а запит на його надання відхилили через угоду про нерозголошення. Richard Stallman, який на той час працював програмістом у лабораторії, сприйняв цю відмову не як разову проблему, а як загальну ситуацію, і 27 September 1983 року оголосив про створення проекту GNU.

Copyleft ґрунтується на законодавстві про авторське право, а не суперечить йому. За замовчуванням ви взагалі не маєте права копіювати чужий код. GPL надає таке право за певної умови: якщо ви передаєте програму іншій особі, ви повинні надати їй вихідний код на тих самих умовах, щоб вона могла зробити те, чого не могла зробити лабораторія. Цю умову можна забезпечити юридично, оскільки без ліцензії ви спочатку не мали дозволу.

Спочатку Stallman написав ліцензію для GNU Emacs, а потім узагальнив її до GPL version 1 25 February 1989 року. GPL version 2 з’явилася у June 1991 року, і досі використовується для більшості системного програмного забезпечення, яке ви запускаєте. Для бібліотек створили Lesser GPL, щоб copyleft-бібліотеку можна було підключати до програми з будь-якою ліцензією, не поширюючи GPL на всю цю програму.

Для self-hoster важлива одна деталь: зобов’язання виникає під час розповсюдження, а не під час використання. Ви можете змінити програму під GPL, запускати її на власному сервері та надавати через неї послуги загальнодоступним користувачам, не будучи нікому нічого винні, оскільки ви не передавали нікому копію програми. Саме через цю прогалину існує AGPL.

Ліберальна традиція: BSD, а потім MIT

Berkeley обрала інший шлях. Computer Systems Research Group випустила свою роботу над Unix за ліцензією, яка вимагала зберігати повідомлення про авторські права та відмовлялася від будь-яких гарантій. Початкова версія містила чотири положення. Четверте, рекламне положення, вимагало згадувати University у всіх рекламних матеріалах, де описувалися функції програмного забезпечення. Така вимога не масштабується. Stallman нарахував 75 окремих згадок у версії NetBSD за 1997 рік. UC Berkeley вилучила це положення 22 July 1999 року в листі William Hoskins з Office of Technology Licensing.

Залишилася 3-clause BSD licence. Вона додатково забороняє використовувати імена учасників для схвалення вашого продукту. Версія з 2 clauses не містить і цієї заборони. Текст MIT licence з’явився в MIT у 1980-х роках. Тоді він поширювався на X Window System. На практиці ця ліцензія виконує ту саму функцію, що й 2-clause BSD.

Мотиви були різними. Університет, який фінансувався за державні кошти, хотів, щоб його роботу використовували всюди, зокрема компанії. GNU project хотів створити спільне надбання, яке неможливо було б закрити. Обидві позиції є обґрунтованими, і кожна має свій недолік. Ліберальний код можна зробити приватним, не повернувши спільноті нічого. Компанії відмовляються від copyleft-коду, якщо їхні юристи не приймають цю умову.

З Berkeley пов’язаний і другий висновок. Саме до нього цей допис постійно повертається. AT&T's Unix System Laboratories подала до суду на Berkeley Software Design у 1992 році через код BSD. Справу врегулювали на початку 1994 року. Протягом двох років ніхто не міг бути впевненим, що на BSD безпечно будувати інші проєкти. Поширення BSD призупинилося, тоді як Linux розвивався. Правова невизначеність зупиняє поширення швидше, ніж відсутність певної функції.

Чому Apache 2.0 додала патентну ліцензію

Першою ліцензією Apache Group була похідна від BSD із 4 пунктами та тією самою проблемою з вимогою розміщувати рекламу. У версії 1.1, випущеній у 2000 році, цей пункт вилучили. Версія 2.0, опублікована в січні 2004 року, була переписана, а не просто виправлена.

Важливим доповненням стали патенти. Ліцензії MIT і BSD взагалі нічого про них не говорять. Контриб’ютор може надати чіткий дозвіл на використання авторських прав для свого коду й водночас володіти патентом, дія якого поширюється на функції цього коду, а потім подати до суду на людей, які його використовують. Apache 2.0 усуває цю прогалину: кожен контриб’ютор надає патентну ліцензію, що охоплює його внесок, а кожен, хто подає позов, стверджуючи, що робота порушує його патенти, втрачає власну патентну ліцензію на цю роботу. Загроза є взаємною, тому на практиці ніхто не подає таких позовів.

Решта положень 2.0 має адміністративний характер, і саме тому компанії її схвалюють. Існує визначений файл NOTICE, тому інформація про авторство зберігається в одному місці, а не розподілена по всьому дереву файлів. Ліцензію можна застосувати посиланням, а не вставляти в кожен файл із вихідним кодом. Для внесків передбачено явні умови. Товарні знаки виключено. Під час юридичної перевірки залежності під Apache 2.0 усі питання, які зазвичай виникають, уже мають відповіді в тексті ліцензії. Тому погодження стає стандартною процедурою, що значною мірою і означає статус «корпоративної ліцензії за замовчуванням».

Що змінила GPLv3 і чому Linux залишився на GPLv2

TiVo випустила відеореєстратор під керуванням Linux і опублікувала вихідний код ядра, саме як того вимагає GPLv2. Потім апаратне забезпечення перевіряло криптографічний підпис під час завантаження й відмовлялося запускати ядро, якого не розпізнавало. Ви могли прочитати вихідний код, змінити його та скомпілювати. Але запустити його на пристрої, з якого він походив, було неможливо. Формальні вимоги ліцензії виконувалися, але її мета не досягалася. За цією практикою закріпилася назва tivoisation.

GPL версії 3, опублікована 29 June 2007, безпосередньо вирішує цю проблему. Якщо ви передаєте бінарний файл у складі споживчого пристрою, ви також повинні надати «Installation Information»: ключі або інструкції, необхідні для встановлення зміненої версії та її запуску. Version 3 також додала явне патентне надання, умови, сформульовані у відповідь на патентну угоду Microsoft і Novell від November 2006, а також односторонню сумісність з Apache 2.0.

Linux не перейшов на цю версію. Ядро поширюється лише за GPL version 2 і не містить застереження «or any later version», а його COPYING файл це підтверджує. Linus Torvalds публічно виступав проти умов щодо tivoisation для обладнання з підписаним програмним забезпеченням. Практична перешкода більша за ці розбіжності: ядро має тисячі власників авторських прав, тому ніхто не зміг би зібрати дозволи, необхідні для зміни ліцензії, навіть якби всі цього хотіли. Цей факт є найнадійнішим захистом, який може мати проєкт. Про нього варто пам’ятати, коли ви розглядаєте проєкт, що належить одній компанії.

Інша ліцензія 2007 року важливіша для вас. GNU Affero GPL version 3, опублікована в November того самого року, поширює обов’язок надавати вихідний код на користувачів, які взаємодіють із програмою через мережу. Якщо ви запускаєте змінений сервіс AGPL для загального доступу, ви повинні надати цим користувачам вихідний код. Саме тому так багато self-hosted вебпрограм поширюється за AGPL. Nextcloud — один із прикладів. Якщо ви порівнюєте self-hosted альтернативи Nextcloud, рядок із ліцензією в репозиторії кожного кандидата розповість про його наступні п’ять років більше, ніж список функцій.

Які ліцензії насправді можна поєднувати?

Сумісність працює в одному напрямку: від permissive-ліцензій до copyleft-ліцензій.

• Код за ліцензіями MIT і BSD можна включати в будь-який продукт, зокрема в закритий.
• Код за Apache 2.0 можна включити в проєкт за GPLv3, і комбінована робота матиме ліцензію GPLv3.
• Код за Apache 2.0 не можна включати в проєкт, що використовує лише GPLv2. Умови Apache 2.0 щодо припинення патентних прав і відшкодування збитків є додатковими умовами, які GPLv2 не дозволяє додавати. FSF і ASF публікують саме такий висновок.
• Ви не можете самостійно перевести код за GPL на permissive-ліцензію. Це можуть зробити лише власники авторських прав, і тоді знову постає питання, хто саме ними є.

Ера зміни ліцензій: SSPL, BUSL і чим вони не є

Причина була комерційною. Компанія володіє авторськими правами на продукт, cloud provider продає його як керований сервіс у великому масштабі та майже нічого не повертає спільноті, тому компанія змінює ліцензію, щоб це припинити. Redis Labs зробила перший помітний крок у August 2018, додавши Commons Clause поверх Apache 2.0 для кількох своїх модулів. MongoDB наслідувала цей приклад 16 October 2018, перейшовши з AGPLv3 на Server Side Public License.

SSPL — це AGPL з одним переписаним розділом. Якщо ви пропонуєте програму третім сторонам як сервіс, ви повинні опублікувати вихідний код усього, що використовуєте для надання цього сервісу, зокрема програмного забезпечення для керування та оркестрації. Межі цього обов’язку нечіткі, і жоден суд їх не перевіряв. OSI ніколи не схвалювала цю ліцензію, а MongoDB відкликала свою заявку в March 2019. Ще в December 2018 Debian заявила, що програмному забезпеченню за SSPL не місце у її архіві, а Fedora в January 2019 визначила, що ця ліцензія не є вільною. Після цього Red Hat вилучила MongoDB з Fedora та Red Hat Enterprise Linux. Це прямий наслідок зміни ліцензії: дистрибутив припиняє пакувати програмне забезпечення, тому оновлення тепер надходитимуть із репозиторію постачальника за його власним графіком.

Business Source License — інший механізм. Її створили засновники MariaDB, а версія 1.1 датується 2017 роком. Це не copyleft і не open source. Вихідний код доступний публічно, а використання є безкоштовним, за винятком способу використання, який постачальник визначає окремо. Зазвичай ідеться про запуск конкуруючого hosted-сервісу. Кожен реліз автоматично переходить на справжню open source ліцензію у визначену дату, не пізніше ніж через чотири роки після цього релізу. Ліцензія, на яку відбувається перехід, повинна бути сумісною з GPLv2. 10 August 2023 HashiCorp перевела Terraform та інші свої продукти на BUSL 1.1. Outline також використовує цю ліцензію. Це важливо знати, якщо ви обираєте серед self-hosted альтернатив Notion: запуск для власної команди дозволений, а побудова на його основі сервісу — ні.

Жодна з цих ліцензій не є нечесною. Обидві прямо зазначають, що їхній вихідний код доступний. За визначенням OSI жодна з них не є open source, і наслідки цієї різниці відчуваєте ви, а не cloud provider, проти якого її спрямовували.

OpenSearch: чого реліцензування коштує оператору

14 January 2021 Elastic оголосила, що Elasticsearch і Kibana відмовляться від Apache 2.0 на користь SSPL або Elastic License, починаючи з release 7.11. Version 7.10.2 стала останньою версією за Apache 2.0. Приблизно через тиждень AWS повідомила, що створить і підтримуватиме Apache 2.0 fork обох продуктів. 12 April 2021 fork отримав назву OpenSearch, а Kibana перейменували на OpenSearch Dashboards. OpenSearch 1.0 став загальнодоступним 12 July 2021. Його створили на основі Elasticsearch 7.10.2 і Kibana 7.10.2.

Розгляньмо, чого це коштувало тим, хто обслуговував кластери. Змінилися назви пакетів і репозиторії. Кожне посилання на Kibana в runbook довелося замінити на OpenSearch Dashboards. Змінилися назви plugin. Потім розділення дійшло до коду застосунків: починаючи з version 7.13 офіційні client library Elastic перевіряють, до чого вони підключилися, і відмовляються продовжувати роботу з усім, що не є Elasticsearch. Вони повідомляють, що сервер є невідомим продуктом. Рішення щодо licence у компанії, де ви не працюєте, стало причиною помилки виклику у вашому власному застосунку.

Після цього історія змінилася ще двічі. 29 August 2024 Elastic додала AGPLv3 як третій варіант licence, тому поточний Elasticsearch знову є open source, схваленим OSI. 16 September 2024 AWS передала OpenSearch до OpenSearch Software Foundation, яку розміщує Linux Foundation. Це дало fork організаційну основу, що не належить одній компанії. Через п’ять років після розділення обидва проєкти є open source, обидва підтримуються, а станом на August 2026 OpenSearch розвивається в межах серії 3.x.

У цьому і полягає висновок. Licence повернулася, але fork залишився. Якщо в екосистемі вже існує по дві версії всього, скасування змін у документах не об’єднає їх знову.

Величину збитків від зміни licence визначає проміжок між оголошенням і появою стабільного fork, який можна фактично розгорнути.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

Кожен проміжок обчислюється від публічного оголошення vendor до першого stable release fork, використовуючи наведені нижче дати. OpenSearch 1.0 потребував 179 днів, оскільки fork потрібно було перейменувати й перебудувати, не маючи попереднього fork для копіювання. OpenTofu потребував 153 днів. Valkey потребував 27 днів, оскільки його відгалузили від Redis 7.2.4, зберігши ідентичними протокол і формат даних на диску. Важливий саме напрямок змін: тепер надійний fork з’являється за лічені тижні, а foundation і оплачувані maintainers залучені від першого дня.

Valkey і OpenTofu: той самий підхід, швидше

20 березня 2024 року Redis Ltd змінила ліцензію Redis із BSD з 3 умовами на вибір між RSALv2 і SSPLv1. Через вісім днів Linux Foundation оголосила Valkey — форк Redis 7.2.4, що залишився під BSD з 3 умовами. Valkey 7.2.5 випустили 16 квітня 2024 року з тим самим протоколом і тими самими файлами даних, тому для більшості операторів міграція звелася до зміни назви пакета. У травні 2025 року Redis додала AGPLv3 як третій варіант у Redis 8. За визначенням OSI це знову робить Redis open source, тоді як Valkey продовжує розвиватися під власним управлінням. Ситуація дуже подібна до Elasticsearch.

Terraform пройшов той самий шлях, але з додатковим етапом. OpenTofu створили на основі останнього релізу під Mozilla Public License 2.0, у вересні 2023 року він приєднався до Linux Foundation, а 10 січня 2024 року вийшов реліз 1.6.0. 3 квітня 2024 року юристи HashiCorp надіслали проєкту вимогу припинити порушення, стверджуючи, що до форка скопіювали код із релізу Terraform під ліцензією BUSL. 11 квітня 2024 року OpenTofu опублікував детальну відповідь і заперечив це твердження. Проєкт простежив походження спірного коду до історії під MPL, спільної для обох проєктів. Надалі публічних повідомлень не було. Головний ризик у цій історії варто запам’ятати: самої заяви про порушення достатньо, щоб на квартал призупинити впровадження. Такий самий ефект тридцять років тому мала судова справа Berkeley.

Не кожен форк починається з ліцензії. Forgejo відокремився від Gitea у 2022 році після того, як розробка Gitea перейшла під контроль компанії. Це була суперечка щодо управління, а не ліцензування. Forgejo залишався під MIT у всій серії версій 8, а у 2024 році, починаючи з версії 9.0, перейшов на GPLv3 або новішу версію. Це не дає повернути його напрацювання до продукту під комерційним контролем. Якщо ви оцінюєте варіанти self-hosted Git-серверів, ця пара є найнаочнішим актуальним прикладом однієї кодової бази та двох підходів.

Перевірка, яку слід виконати до вибору будь-якого проєкту

Чотири запитання, які потрібно поставити до першого встановлення, а не після нього.

1. Кому належать авторські права? Для зміни ліцензії потрібен дозвіл кожного власника авторських прав, тому проєкт із сотнями незалежних учасників без передання прав практично неможливо перевести на іншу ліцензію. Якщо всі права належать одній компанії, ліцензію можна змінити на засіданні ради директорів.
2. Чи є CLA і які права він надає? Угода з учасником про ліцензування, яка дозволяє компанії перевести ваш внесок на будь-які умови на власний розсуд, є саме тим механізмом, що лежить в основі кожної наведеної вище зміни ліцензії. DCO (developer certificate of origin), тобто рядок sign-off, який Linux kernel запровадив у 2004, не передає жодних прав. CLA, який належить foundation, безпечніший за CLA, який належить компанії, оскільки компанію можна продати.
3. Кому належить товарний знак? Elastic зберегла назву Elasticsearch, тому fork довелося перейменувати, а всі runbook, де згадувався Kibana, — переписати.
4. Скільки саме вам коштуватиме зміна ліцензії? Врахуйте формат даних, клієнтські бібліотеки, конфігурацію, яку доведеться переписати, і наявність сумісного fork.

Дві команди дадуть відповідь на частину цих запитань за кілька секунд.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

Кожен пакет Debian і Ubuntu містить файл у /usr/share/doc/<package>/copyright. У ньому записано ліцензію встановленої версії, а не ліцензію, яку проєкт використовує сьогодні. Для bash в Ubuntu 24.04 цей файл указує GNU General Public License version 3. Виконайте другу команду всередині checkout вихідного коду, щоб переглянути історію самого файлу ліцензії. Коміт за останні два роки варто прочитати до того, як ви почнете щось будувати на основі цього проєкту. Якщо команда нічого не виводить, репозиторій називає файл ліцензії інакше. Перегляньте кореневий каталог і знайдіть його.

Жодна ліцензія не захищає від усіх можливих наслідків, а вибір за ідеологічними міркуваннями часто призводить до несподіванок. Віддавайте перевагу проєктам, авторські права на які розподілені між багатьма власниками або належать foundation, і зберігайте дані у форматі, який можна експортувати. Потім з’ясуйте, на який fork ви перейдете, і запишіть його назву до того, як він знадобиться. Така перевірка кожного кандидата займає менше години. Саме вона визначає, чи буде оновленням або міграцією ваш вибір того, що розмістити на власному сервері у 2026.

FAQ

Чи є ліцензія MIT такою самою, як ліцензія BSD?

Фактично MIT відповідає ліцензії BSD із 2 пунктами: збережіть повідомлення про авторські права та відмову від гарантій, а далі використовуйте код на власний розсуд, зокрема створюйте закритий продукт. Ліцензія BSD із 3 пунктами додає одну умову: забороняє використовувати імена учасників розробки для схвалення вашого продукту без дозволу. Старіша версія з 4 пунктами також вимагала згадки в рекламних матеріалах. UC Berkeley скасувала цю умову 22 July 1999 року, тому майже жоден актуальний проєкт її більше не містить.

Чи можу я додати код Apache 2.0 до проєкту під GPLv2?

Ні. Apache 2.0 додає умови, які GPLv2 не дозволяє додавати, передусім положення про припинення патентних прав. Тому об’єднана робота не може одночасно відповідати обом ліцензіям. FSF і ASF публікують саме такий висновок. Зворотний напрямок працює: код Apache 2.0 можна включити до проєкту під GPLv3, і результат поширюватиметься за GPLv3. Саме тому код Apache 2.0 не можна об’єднати з ядром Linux, яке поширюється лише під GPL version 2.

Чи є SSPL ліцензією open source?

Ні, і це має практичні наслідки. OSI ніколи її не схвалювала, а MongoDB відкликала свою заявку в March 2019 року. У December 2018 року Debian заявив, що програмному забезпеченню під SSPL не місце в його архіві. У January 2019 року Fedora постановила, що ця ліцензія не є вільною. Після цього Red Hat вилучила MongoDB із Fedora та Red Hat Enterprise Linux. Для вас це означає, що пакет, який раніше супроводжувався вашим дистрибутивом, тепер надходить із репозиторію постачальника та оновлюється за графіком підтримки постачальника. Business Source License також надає доступ до вихідного коду, а не є ліцензією open source, хоча кожен випуск протягом чотирьох років переходить на ліцензію open source.

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

Ні. Ліцензію, надану разом із випуском, не можна відкликати для вже опублікованих копій. Саме тому можливі форки. OpenSearch створено на основі Elasticsearch 7.10.2 — останнього випуску, який Elastic опублікувала під Apache 2.0. Ви втрачаєте майбутні оновлення, оскільки наступне виправлення безпеки виходить уже на нових умовах. Фіксація останньої версії з дозвільною ліцензією може дати кілька місяців, але це не план.