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-clause версія, з якої вилучено навіть цю заборону. Текст MIT licence з’явився в MIT у 1980-х роках. Там він поширювався на X Window System і на практиці виконує ту саму функцію, що й 2-clause BSD.

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

З Berkeley випливає ще один урок, до якого цей допис постійно повертається. AT&T's Unix System Laboratories подала позов проти Berkeley Software Design у 1992 році через BSD code, і на початку 1994 року сторони врегулювали справу. Протягом двох років ніхто не міг бути впевненим, що на 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 і чим вони не є

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

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

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

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

OpenSearch: скільки оператору коштує форк через зміну ліцензії

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

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

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

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

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

[
  {
    "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
  }
]

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

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