Различия лицензий GPL, MIT и Apache 2.0

GPL, MIT и Apache: требования каждой лицензии

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

Это может показаться вопросом для юристов, пока в один день проект, который вы используете, не сменит лицензию и не разделится на две части. Тогда это становится операционной задачей. Вам приходится выбирать между двумя репозиториями пакетов, а клиентские библиотеки перестают взаимодействовать друг с другом. Это руководство посвящено лицензиям и принципам их работы, а не движению, которое их породило, поэтому каждый раздел заканчивается там, где он затрагивает вас: человека, которому предстоит выполнять обновление.

Почему существует GPL: принтер, который никому не разрешали чинить

Примерно в 1980 году лаборатория искусственного интеллекта MIT получила лазерный принтер Xerox 9700. Ранее сотрудники лаборатории модифицировали программное обеспечение для предыдущего принтера, чтобы он сообщал о замятии бумаги. Для новой модели исходный код отсутствовал, а в запросе на его предоставление было отказано из-за соглашения о неразглашении. Ричард Столлман, работавший тогда программистом в лаборатории, воспринял этот отказ не как досадную случайность, а как системную проблему и 27 сентября 1983 года объявил о начале проекта GNU.

Copyleft основан на законе об авторском праве, а не направлен против него. По умолчанию у вас вообще нет права копировать чужой код. Лицензия GPL предоставляет это право при соблюдении одного условия: если вы передаете программу кому-то другому, вы обязаны предоставить ему исходный код на тех же условиях, чтобы этот человек мог сделать то, что не удалось лаборатории. Это условие юридически значимо, так как без лицензии у вас изначально не было никаких прав на распространение.

Столлман сначала написал лицензию для GNU Emacs, а затем обобщил её до версии GPL 1, выпущенной 25 февраля 1989 года. В июне 1991 года последовала версия GPL 2, которая до сих пор является лицензией для большинства системного программного обеспечения, которое вы используете. Лицензия Lesser GPL была создана для библиотек, чтобы программу, использующую библиотеку с copyleft, можно было выпускать под любой лицензией, не переводя её целиком на условия GPL.

Одна деталь определяет, как GPL влияет на тех, кто размещает ПО на собственных серверах. Обязательства возникают при распространении, а не при использовании. Вы можете модифицировать программу под лицензией GPL, запускать её на собственном сервере, предоставлять к ней доступ публике и при этом никому ничего не быть должным, так как вы не передавали копию программы третьим лицам. Именно из-за этого пробела существует лицензия AGPL.

Пермиссивная традиция: BSD, затем MIT

В Berkeley выбрали другой путь. Группа Computer Systems Research Group выпустила свои наработки по Unix под лицензией, которая требовала сохранять уведомление об авторских правах и снимала с разработчиков любую ответственность. Изначально версия содержала четыре пункта, причем четвертый — рекламный — требовал упоминать университет во всех рекламных материалах, где описываются функции ПО. Это не масштабируется. В 1997 году Столлман насчитал 75 отдельных упоминаний в одной версии NetBSD. 22 июля 1999 года Калифорнийский университет в Berkeley отозвал этот пункт в письме Уильяма Хоскинса из офиса по лицензированию технологий.

Осталась 3-пунктная лицензия BSD, которая запрещает использовать имена участников для продвижения вашего продукта, и 2-пунктная версия, где даже этого требования нет. Текст лицензии MIT появился в MIT в 1980-х годах, где он охватывал X Window System, и на практике он выполняет ту же задачу, что и 2-пунктная BSD.

Мотивы были разными. Университет, финансируемый из государственных средств, хотел, чтобы его разработки использовались везде, в том числе компаниями. Проект GNU хотел создать общественное достояние, которое нельзя закрыть. Обе позиции честны, и у обеих есть свои недостатки. Пермиссивный код может быть присвоен частными лицами, и вы не получите ничего взамен. Код с копилефтом отвергается компаниями, чьи юристы не принимают подобные условия.

Есть и второй урок от Berkeley, к которому эта статья постоянно возвращается. В 1992 году Unix System Laboratories компании AT&T подала в суд на Berkeley Software Design из-за кода BSD, и дело было урегулировано в начале 1994 года. В течение двух лет никто не мог быть уверен, что на BSD безопасно строить продукты, и внедрение замедлилось, пока Linux набирал обороты. Юридическая неопределенность останавливает внедрение быстрее, чем отсутствие какой-либо функции.

Почему в Apache 2.0 добавили патентную лицензию

Первая лицензия The Apache Group была производной от BSD 4-clause и содержала ту же проблему с обязательным упоминанием в рекламе. Версия 1.1, выпущенная в 2000 году, удалила этот пункт. Версия 2.0, опубликованная в январе 2004 года, была не просто исправлением, а полной переработкой текста.

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

Остальные изменения в 2.0 носят административный характер, именно поэтому лицензия нравится компаниям. В ней определен файл NOTICE, поэтому информация об авторстве находится в одном месте, а не разбросана по всему дереву исходного кода. Лицензию можно применять через ссылку, а не вставлять в каждый файл с исходным кодом. Вклады регулируются четкими условиями. Товарные знаки исключены из действия лицензии. Юридическая проверка зависимости с Apache 2.0 показывает, что на все вопросы, которые могли возникнуть, уже есть ответы в тексте лицензии. Поэтому процесс одобрения становится рутинным, что и составляет основу понятия «корпоративный стандарт».

Что изменила GPLv3 и почему Linux остался на GPLv2

Компания TiVo выпустила видеорегистратор под управлением Linux и опубликовала исходный код ядра, в точном соответствии с требованиями GPLv2. Однако аппаратное обеспечение при загрузке проверяло криптографическую подпись и отказывалось запускать ядро, которое не было распознано. Вы могли прочитать исходный код, изменить его и скомпилировать. Но вы не могли запустить его на устройстве, с которого он был получен. Буква лицензии была соблюдена, но её цель оказалась не достигнута, а эта практика получила название «тивоизация» (tivoisation).

Версия 3 лицензии GPL, опубликованная 29 июня 2007 года, напрямую решает эту проблему. При передаче бинарного файла внутри потребительского устройства вы обязаны предоставить «информацию для установки» (Installation Information): ключи или инструкции, необходимые для установки модифицированной версии и обеспечения её запуска. Версия 3 также добавила явное предоставление патентных прав — условия, написанные в ответ на патентное соглашение между Microsoft и Novell от ноября 2006 года, а также одностороннюю совместимость с Apache 2.0.

Linux не последовал этому примеру. Ядро распространяется только под GPL версии 2, без оговорки «или любой более поздней версии», о чём прямо говорится в файле COPYING. Линус Торвальдс публично возражал против положений о запрете тивоизации для оборудования с проверкой подписей. Практический барьер здесь значительнее, чем просто разногласия: у ядра тысячи правообладателей, поэтому никто не смог бы собрать разрешения, необходимые для смены лицензии, даже если бы все этого хотели. Этот единственный факт является самой сильной защитой, которая может быть у проекта, и об этом стоит помнить, когда вы рассматриваете проект, принадлежащий одной компании.

Другая лицензия 2007 года важнее для вас. GNU Affero GPL версии 3, опубликованная в ноябре того же года, распространяет обязательство по раскрытию исходного кода на лиц, взаимодействующих с программой через сеть. Если вы запускаете модифицированный сервис под AGPL для публичного доступа, вы обязаны предоставить этим пользователям исходный код. Именно поэтому так много веб-программ для self-hosting распространяются под AGPL. Nextcloud — один из примеров, и если вы сравниваете альтернативы Nextcloud для self-hosting, строка с указанием лицензии в репозитории каждого кандидата расскажет вам о его следующих пяти годах больше, чем список функций.

Какие лицензии можно сочетать?

Совместимость работает в одном направлении: от разрешительных лицензий к лицензиям с копилефтом.

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

Эпоха смены лицензий: 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. Исходный код публичен, использование бесплатно, за исключением случаев, которые вендор ограничивает — обычно это запуск конкурирующего облачного сервиса. Каждый релиз автоматически переходит на настоящую лицензию open source в дату изменения, которая наступает не позднее чем через четыре года после выпуска. Лицензия, на которую происходит переход, должна быть совместима с GPLv2. HashiCorp перевела Terraform и другие свои продукты на BUSL 1.1 10 августа 2023 года. Outline также использует ее, что стоит учитывать, если вы выбираете из альтернатив Notion для self-hosted размещения: запуск для собственной команды разрешен, а создание сервиса на его основе — нет.

Ни одна из этих лицензий не является нечестной. Обе прямо заявляют, что они являются source available. Ни одна из них не является open source согласно определению OSI, и разница в итоге ложится на вас, а не на облачного провайдера, против которого они были направлены.

OpenSearch: во что оператору обходится форк из-за смены лицензии

14 января 2021 года компания Elastic объявила, что начиная с релиза 7.11 Elasticsearch и Kibana переходят с лицензии Apache 2.0 на выбор между SSPL или Elastic License. Версия 7.10.2 стала последним релизом под Apache 2.0. Примерно через неделю AWS заявила о создании и поддержке форка обоих продуктов под лицензией Apache 2.0. 12 апреля 2021 года форк получил название OpenSearch, а Kibana была переименована в OpenSearch Dashboards. 12 июля 2021 года стал общедоступен OpenSearch 1.0, собранный на базе Elasticsearch 7.10.2 и Kibana 7.10.2.

Посмотрите, во что это обошлось тем, кто эксплуатирует кластеры. Изменились имена пакетов и репозитории. Каждое упоминание Kibana в инструкциях по эксплуатации превратилось в OpenSearch Dashboards. Изменились названия плагинов. Затем разделение затронуло код приложений: начиная с версии 7.13 официальных клиентских библиотек Elastic, клиент проверяет, к чему он подключен, и отказывается работать с чем-либо, кроме Elasticsearch, сообщая, что сервер является неизвестным продуктом. Решение о лицензировании, принятое в компании, где вы не работаете, привело к сбою вызова внутри вашего собственного приложения.

Затем история сделала еще два поворота. 29 августа 2024 года Elastic добавила AGPLv3 в качестве третьего варианта лицензии, поэтому текущий Elasticsearch снова является открытым ПО, одобренным OSI. 16 сентября 2024 года AWS передала OpenSearch в OpenSearch Software Foundation под эгидой Linux Foundation, что обеспечило форку управление не одной компанией, а независимой структурой. Спустя пять лет после разделения оба проекта являются открытыми, оба поддерживаются, а OpenSearch по состоянию на август 2026 года находится в серии 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
  }
]

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

Valkey и OpenTofu: тот же сценарий, но быстрее

20 марта 2024 года компания Redis Ltd перевела Redis с лицензии BSD 3-clause на выбор между RSALv2 или SSPLv1. Восемь дней спустя Linux Foundation анонсировала Valkey — форк Redis 7.2.4, сохранивший лицензию BSD 3-clause. Версия Valkey 7.2.5 вышла 16 апреля 2024 года, сохранив тот же протокол и формат файлов данных, поэтому для большинства администраторов миграция свелась к смене имени пакета. В мае 2025 года в Redis 8 появилась третья опция — AGPLv3, что по определению OSI снова делает проект открытым, в то время как Valkey продолжает развиваться под собственным управлением. Ситуация во многом повторяет историю Elasticsearch.

Terraform прошел тот же путь с одной дополнительной главой. OpenTofu форкнул последний релиз под лицензией Mozilla Public License 2.0, присоединился к Linux Foundation в сентябре 2023 года и выпустил версию 1.6.0 10 января 2024 года. 3 апреля 2024 года юристы HashiCorp направили проекту требование о прекращении деятельности (cease and desist), утверждая, что код из релиза Terraform под лицензией BUSL был скопирован в форк. 11 апреля 2024 года OpenTofu опубликовал подробный ответ с опровержением, проследив спорный код до истории версий под лицензией MPL, общей для обоих проектов. Публичного продолжения история не получила. Реальный риск в этом эпизоде заключается в следующем: одно лишь обвинение способно заморозить внедрение продукта на квартал, что по эффекту аналогично судебному иску Berkeley тридцать лет назад.

Не каждый форк начинается с лицензии. Forgejo отделился от Gitea в 2022 году после того, как разработка Gitea перешла под контроль компании; это был спор об управлении, а не о лицензировании. Forgejo оставался под лицензией MIT вплоть до серии версий 8, а начиная с 9.0 в 2024 году перешел на GPLv3 или более позднюю версию, чтобы его наработки нельзя было включить обратно в коммерчески контролируемый продукт. Если вы оцениваете варианты self-hosted Git-серверов, эта пара является наиболее наглядным примером одной кодовой базы с двумя разными философиями.

Проверка перед внедрением любого решения

Четыре вопроса, которые стоит задать до первой установки, а не после.

1. Кто владеет авторскими правами? Для смены лицензии требуется разрешение от каждого правообладателя. Проект с сотнями независимых участников и без передачи прав невозможно перелицензировать на практике. Проект, где всё принадлежит одной компании, может быть перелицензирован по решению совета директоров.
2. Есть ли CLA и что он даёт? Соглашение о передаче прав (Contributor Licence Agreement), позволяющее компании перелицензировать ваш вклад на любых условиях — это именно тот механизм, который стоит за всеми случаями смены лицензий. DCO (Developer Certificate of Origin), механизм подтверждения авторства, принятый в ядре Linux в 2004 году, не передаёт никаких прав. CLA, принадлежащий фонду, безопаснее CLA, принадлежащего компании, так как компанию можно продать.
3. Кто владеет торговой маркой? Elastic сохранила за собой название Elasticsearch, поэтому форку пришлось сменить имя, а все руководства, упоминавшие Kibana, пришлось переписывать.
4. Во что конкретно вам обойдётся смена лицензии? Учтите формат данных, клиентские библиотеки, конфигурацию, которую придётся переписать, и наличие совместимого форка.

Две команды позволяют ответить на часть этих вопросов за секунды.

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. Выполните вторую команду внутри локальной копии исходного кода, чтобы получить историю самого файла лицензии. Коммит в этом файле за последние два года стоит изучить, прежде чем строить что-либо на базе проекта. Если команда ничего не выводит, значит, проект называет файл лицензии иначе — выведите список файлов в корневом каталоге и найдите его.

Ни одна лицензия не защищает от всех рисков, и выбор на основе идеологии — это то, что приводит к неприятным сюрпризам. Отдавайте предпочтение проектам, авторские права на которые распределены между многими участниками или принадлежат фонду, и храните данные в формате, который можно экспортировать. Затем выясните, на какой форк вы перейдёте в случае необходимости, и запишите его название, пока оно вам не понадобилось. Применение этой проверки к каждому кандидату занимает меньше часа, и именно это отличает простое обновление от вынужденной миграции, когда вы решаете, что разместить на собственном сервере в 2026 году.

FAQ

Лицензия MIT идентична лицензии BSD?

По сути, MIT соответствует 2-пунктной лицензии BSD: сохраните уведомление об авторских правах и отказ от гарантий, после чего делайте что угодно, включая создание закрытого продукта. 3-пунктная лицензия BSD добавляет одно условие: запрет на использование имен участников для продвижения вашего продукта без разрешения. Более старая 4-пунктная версия также требовала упоминания в рекламных материалах, но Калифорнийский университет в Беркли отменил этот пункт 22 июля 1999 года, поэтому почти никакие современные проекты его не содержат.

Можно ли включить код под лицензией Apache 2.0 в проект под GPLv2?

Нет. Apache 2.0 добавляет условия, которые не допускаются в GPLv2, главным образом пункт о прекращении действия патентных прав, поэтому объединенная работа не может одновременно соответствовать обеим лицензиям. FSF и ASF подтверждают этот вывод. Обратный вариант работает: код Apache 2.0 можно включить в проект под лицензией GPLv3, и итоговый результат будет распространяться под GPLv3. Именно по этой причине код Apache 2.0 нельзя объединять с ядром Linux, которое использует только версию 2 лицензии GPL.

Является ли SSPL лицензией с открытым исходным кодом?

Нет, и этот ответ имеет практические последствия. OSI никогда не одобряла её, а MongoDB отозвала свою заявку в марте 2019 года. Debian в декабре 2018 года заявила, что ПО под лицензией SSPL не должно находиться в её архивах, а Fedora в январе 2019 года постановила, что эта лицензия не является свободной, после чего Red Hat исключила MongoDB из состава Fedora и Red Hat Enterprise Linux. Для вас это означает, что пакет, который раньше поддерживал ваш дистрибутив, теперь поставляется из репозитория вендора и зависит от его графика поддержки. Лицензия Business Source License также относится к категории source available, а не open source, хотя каждый релиз переходит на лицензию с открытым исходным кодом в течение четырех лет.

Применяется ли изменение лицензии к версии, которую я уже использую?

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