MIT, GPL и Apache 2.0: как различаются лицензии на практике

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

Этот материал объясняет общую логику четырёх лицензий, а не заменяет юридическую консультацию. Для продукта с существенными рисками, внешними инвестициями, большим числом зависимостей или патентным портфелем итоговый выбор стоит проверить с профильным юристом.

GNU GPL объединила лицензии программ GNU

27 сентября 1983 года Ричард Столлман объявил проект GNU, целью которого было создание свободной Unix-совместимой системы. Разработка началась в январе 1984-го, а в октябре 1985 года появилась Free Software Foundation, первоначально помогавшая финансировать работу над GNU. В этот период отдельные программы проекта распространялись на похожих, но не полностью одинаковых условиях.

К 1989 году накопленного опыта стало достаточно, чтобы заменить эти варианты одной общей лицензией. GNU GPL version 1, выпущенная в феврале 1989 года, использовала авторское право не только для выдачи разрешений первому получателю, но и для сохранения этих разрешений дальше по цепочке. Такой принцип назвали copyleft: получатель может запускать, изучать, изменять и передавать программу, однако при передаче покрываемой изменённой работы обязан сохранить лицензию и доступ к исходному коду для следующего получателя.

Copyleft не делает код «вирусным» и не заставляет публиковать любую локальную правку. В GPLv3 обязанности возникают главным образом при convey, то есть когда копия становится доступна другому лицу. Внутреннее использование внутри одной организации само по себе не требует публичного репозитория, что отдельно разъясняет FAQ GNU GPL. Обычная GPLv3 также не требует открыть серверный код только потому, что пользователи взаимодействуют с ним по сети; для такого сценария существует AGPLv3 с отдельным сетевым условием.

Следующие версии решали новые практические проблемы. GPLv2 вышла в 1991 году, а GPLv3 была опубликована 29 июня 2007-го после публичного обсуждения. В третьей версии подробнее урегулированы патенты, совместимость с некоторыми другими лицензиями и передача Installation Information для определённых пользовательских устройств, чтобы получатель мог установить изменённую сборку. Последний механизм обычно связывают с термином tivoization, но он не означает всеобщую обязанность производителя поддерживать любую пользовательскую модификацию.

MIT продолжает короткую разрешительную традицию

Разрешительные уведомления существовали в университетском и Unix-сообществе задолго до того, как современные каталоги стандартизировали название MIT. Хорошо задокументированный пример дала система X Window, созданная в MIT в середине 1980-х. Архив X.Org сохраняет тексты X/MIT, которые разрешали использовать, изменять, распространять и продавать программы при сохранении copyright notice и permission notice; отдельный абзац текста отказывался от гарантий.

Сегодня идентификатор SPDX MIT относится к распространённому короткому тексту, опубликованному в каталоге Open Source Initiative. Он разрешает использовать, копировать, изменять, объединять, публиковать, распространять, сублицензировать и продавать копии. Условие у него короткое, но не нулевое: copyright notice и permission notice должны оставаться во всех копиях или существенных частях программы. Следующий абзац отказывается от гарантий и ограничивает ответственность в пределах применимого права.

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

Apache 2.0 решает больше задач явным текстом

Apache License 2.0 иногда называют длинной или «корпоративной» MIT, но такое сравнение скрывает её происхождение. Apache Software Foundation несколько лет перерабатывала собственную лицензию, чтобы яснее описать вклад участников, документацию, уведомления и патентные риски. Совет ASF утвердил версию 2.0 21 января 2004 года.

Полный текст Apache 2.0 отдельно выдаёт copyright license и patent license. Первая разрешает воспроизводить, изменять и распространять работу, а вторая охватывает те патентные притязания участника, которые неизбежно нарушались бы его вкладом отдельно или в сочетании с проектом, куда этот вклад был отправлен. Это не гарантия от любых патентных претензий мира и не передача всех патентов автора.

Положение о patent termination тоже действует уже, чем часто пишут в пересказах. Если получатель начинает патентный спор, утверждая, что сама работа или включённый в неё вклад нарушает патент, прекращаются выданные ему по Apache 2.0 патентные лицензии на эту работу. Текст не говорит, что любой патентный иск по любой теме автоматически уничтожает copyright license.

При распространении Apache-кода нужно передать копию лицензии, отметить изменённые файлы и сохранить относящиеся к работе copyright, patent, trademark и attribution notices. Если исходная работа содержит файл NOTICE, соответствующие уведомления из него переносятся в одну из разрешённых форм. При этом Apache 2.0 остаётся permissive-лицензией: она не требует открывать собственные изменения только из-за распространения производной работы.

У Unlicense другая правовая конструкция

Unlicense пытается не регулировать дальнейшее распространение авторским правом, а максимально отказаться от такого права и посвятить работу общественному достоянию. Её официальный текст дополняет это намерение широким разрешением на использование и стандартным отказом от гарантий. Unlicense одобрена Open Source Initiative и сейчас отмечена в её каталоге как special-purpose license.

Public domain и лицензия при этом не являются одним юридическим понятием. Возможность полностью отказаться от авторского права и последствия такого отказа различаются между юрисдикциями, поэтому текст Unlicense содержит формулировки для стран, признающих copyright. Кроме того, в нём нет такого явного патентного гранта, как в Apache 2.0. Если цель состоит в максимально предсказуемом отказе от авторских прав на международном проекте, следует сравнить Unlicense с CC0-1.0 и политикой конкретной организации, а не считать эти инструменты взаимозаменяемыми.

Сравнение условий без философских ярлыков

Таблица описывает типичный сценарий, но не определяет, считается ли конкретная архитектура одной производной или объединённой работой. Динамическая загрузка, IPC, плагины, генерация кода и распространение компонентов разными сторонами требуют анализа фактической связи между ними, а не механического правила «любая ссылка заражает проект».

Совместимость всегда имеет направление

Две лицензии совместимы, когда при объединении и передаче кода можно одновременно выполнить условия обеих. Это не означает, что один исходный файл меняет свою лицензию или что совместимость работает одинаково в обе стороны. Например, MIT-код можно включить в GPLv3-программу, сохранив MIT notice и распространяя объединённую покрываемую работу по GPLv3. Обратная операция не разрешает убрать условия GPLv3 и объявить получившийся код MIT.

Версия тоже имеет значение. Apache 2.0 совместима с GPLv3 в том смысле, что Apache-код может стать частью работы, распространяемой по GPLv3; FSF отдельно указывает, что Apache 2.0 несовместима с GPLv2-only из-за дополнительных патентных условий. Код под GPL-2.0-or-later может дать путь к GPLv3, которого нет у GPL-2.0-only. FAQ GNU также подчёркивает, что простая установка двух самостоятельных программ в одной системе не объединяет их в более крупную работу.

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

Что действительно умеет License Builder

License & Readme Builder объединяет три независимые функции. Compatibility Checker сравнивает исходную и целевую лицензию для 11 распространённых идентификаторов и возвращает Compatible, Conditional или Incompatible с коротким объяснением. Отдельный опросник сопоставляет ответы с четырьмя вариантами, для которых инструмент хранит полный текст: MIT, Apache-2.0, GPLv3 и Unlicense. После ручного выбора лицензии генератор подставляет владельца copyright и год там, где они предусмотрены шаблоном, а затем собирает README с названием, описанием, командами установки, примером использования и license badge.

Алгоритм рекомендации намеренно грубый. Запрос copyleft или сетевого раскрытия приводит к GPLv3, но интерфейс сразу предупреждает, что обычная GPLv3 не содержит условия AGPL для сетевого использования. Запрос явного patent grant предлагает Apache-2.0, в остальных случаях рекомендацией становится MIT; Unlicense можно выбрать только вручную. Все четыре варианта допускают коммерческое использование, поэтому запрет коммерции этот набор не реализует и такая лицензия в любом случае не соответствовала бы определению open source OSI. Флажки commercial use и liability protection в текущей реализации не меняют формулу рекомендации, а только описывают желаемые свойства, что служит ещё одной причиной не считать результат полноценным выбором лицензии.

Compatibility Checker тоже следует читать как справочник, а не как юридическое заключение. Метка Conditional означает, что результат зависит от версии, способа связывания или других условий, которые короткая матрица не может установить. Кроме того, объединённая подпись Unlicense / CC0-1.0 в интерфейсе является упрощением: это разные тексты с разными идентификаторами SPDX. Для реального релиза проверьте точную лицензию зависимости, её суффикс -only или -or-later, полный текст и необходимые notices.

Все данные вводятся и обрабатываются локально в браузере. Можно скопировать LICENSE и README вместе либо скачать их отдельно, однако генератор не проверяет права на вклады, зависимости проекта, CLA, товарные знаки или патентный портфель. Эти вопросы остаются частью процесса выбора лицензии за пределами инструмента.

Похожие инструменты

Конструктор лицензии и ReadmeОтветьте на несколько вопросов, чтобы подобрать open-source лицензию, затем сгенерируйте полный текст лицензии и шаблон README со значком — всё в браузере.Редактор MarkdownПишите Markdown с предпросмотром бок о бок, панелью форматирования и горячими клавишами, счётчиком слов и экспортом в .md или .html — всё в браузере.JSON ToolboxПроверяйте синтаксис, форматируйте или минифицируйте данные и просматривайте вложенные API-ответы и конфиги в виде дерева.Генератор пар ключейГенерируйте пары ключей Ed25519 или RSA (2048/4096) через Web Crypto API — публичный ключ в формате OpenSSH, приватный ключ в PEM, отпечаток SHA256 и скачивание файлов — всё локально.