Лицензии слабого копилефта: могут ли они заменить пермиссивные (разрешительные) лицензии?

Среди открытых лицензий хорошо известны строгие GPL и (с другой стороны) разрешительные — MIT, Apache. Однако менее известен слабый копилефт, который находится между ними. А ведь эти лицензии имеют такие популярные приложения и библиотеки, как Mozilla Firefox, glibc, LibreOffice и другие. Подходящий ли это вариант для интеграции открытого софта с закрытым ? И стоит ли авторам ПО с открытым кодом использовать лицензии слабого копилефта вместо пермиссивных (когда GPL/AGPL не подходит) ? Первоначально я хотел сделать обзор лицензий слабого копилефта на основе интернет-источников. Однако, изучив материалы Debricked по свободным лицензиям, решил, что лучше сделать их перевод (глава 5 и большая часть главы 6), только сильно дополнив его в конце важными деталями. Также я дополнил сам перевод примерами программ под этими лицензиями (в скобках).

Debricked — это профессионалы в данной области, авторы системы, которая проверяет лицензии программ, работая как инструмент анализа состава программного обеспечения (SCA).

Лицензии OSS, часть 5: Лицензии со слабой копилефт-защитой (weak copyleft)

9 июля 2024 года

Введение

Для лицензий с сильной копилефт-защитой (strong copyleft) отличительным свойством является то, что их требования и ограничения также распространяются на произведения, которые каким-либо образом используют лицензионное программное обеспечение. Это справедливо, даже если ПО используется просто как библиотека. Если вы распространяете программное обеспечение, вся программа должна быть лицензирована с использованием сильной копилефт-лицензии. В этой части серии блогов мы рассмотрим лицензии со слабой копилефт-защитой. Они не столь ограничительны в этом смысле, но сохраняют свойство копилефта при модификации программного пакета.

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

Однако можно утверждать, что это ограничит внедрение программного обеспечения, поскольку оно не может использоваться вместе с проприетарным кодом (если распространяется). Разрешительные лицензии (permissive licenses) позволяют это без наложения требований на другой код.

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

Лицензия LGPL

(FFmpeg, Glibc, Gnome (библиотеки), GTK, Qt (для свободных проектов; некоторые модули только под коммерческой или GPL), ключевые библиотеки WebKit и др.)

Изначально LGPL расшифровывалась как Library General Public License. Это было название ее первого выпуска — LGPL 2.0, когда она была выпущена в 1991 году. Она начиналась с версии 2.0, поскольку была призвана соответствовать GPL версии 2, поэтому более ранних версий не существует. Название «Library» отражало тот факт, что она была создана для использования библиотек без превращения результата в производную работу.

В LGPL 2.1, выпущенной в 1999 году, и LGPL 3.0, выпущенной в 2007 году, LGPL вместо этого расшифровывается как Lesser General Public License. Термин «Lesser» (меньшая) был использован, чтобы пояснить, что она делает меньше для защиты свободы распространять и изменять программное обеспечение. LGPL 2.1 является обновлением LGPL 2.0, в то время как LGPL 3.0 является полной переработкой и предоставляется как дополнение к GPLv3. Таким образом, основные различия между LGPL 2.1 и LGPL 3.0 те же, что и различия между GPLv2 и GPLv3. Это включает различия, связанные с патентной реторсией (patent retaliation), тивоизацией (tivoization) и совместимостью с другими лицензиями.

Модификация кода библиотеки

Если вы вносите изменения в библиотеку, лицензированную под LGPL, и распространяете измененную библиотеку, то применяются обязательства копилефта. В случае LGPL лицензия для измененной библиотеки должна быть либо LGPL, либо GPL. Это означает, что вы также должны предоставить исходный код изменений. Если библиотека является частью комбинированной работы, где библиотека — лишь одна из частей, то требование применяется только к библиотеке, а не к остальному коду.

Динамическая и статическая компоновка (linking)

Главной отличительной особенностью LGPL по сравнению со многими другими лицензиями со слабой копилефт-защитой является то, как обязательства копилефта применяются к компоновке кода. Основная идея здесь заключается в том, что пользователям должно быть легко заменить код под лицензией LGPL на другой код.

LGPL допускает динамическую компоновку кода под лицензией LGPL с кодом под другими лицензиями. Это означает, что вы можете иметь программу с проприетарной лицензией, которая использует функциональность кода под LGPL путем динамической компоновки с этим кодом. Поскольку компоновка динамическая (разделяемая библиотека), легко заменить код под LGPL на другой или модифицированный код и по-прежнему запускать программу.

Статическая компоновка немного сложнее. Если код под LGPL скомпонован статически, это значительно усложнит замену кода под LGPL внутри этого программного обеспечения. Это не означает, что вся кодовая база должна иметь копилефт-лицензию, но требование возможности перекомпоновки кода под LGPL по-прежнему применяется. Это означает, что вы должны предоставить необходимый код и информацию об установке, которые позволят пользователям модифицировать программу и перекомпоновать ее с модифицированной библиотекой.

Mozilla Public License (MPL)

(Mozilla Firefox, Mozilla Thunderbird, LibreOffice)

Mozilla Public License — это лицензия со слабой копилефт-защитой, но она существенно отличается от LGPL в отношении требований копилефта. MPL основана на файлах (file-based), то есть если вы вносите изменения в файл, лицензированный под MPL, то эти изменения также должны распространяться под лицензией MPL. Дополнительные файлы, которые расширяют библиотеку или взаимодействуют с ней, не имеют такого обязательства. Это несколько менее ограничительно, но гораздо проще для понимания (и согласования), чем LGPL.

MPL 1.0 и MPL 1.1

Первая версия Mozilla Public License (MPL 1.0) была выпущена в 1998 году. Всего через год, на основе публичных комментариев и вклада, была выпущена обновленная версия — MPL 1.1. Основными изменениями были введение пункта о патентной реторсии, возможность использования нескольких лицензий по желанию автора, предоставление альтернатив для распространения кода и некоторые уточнения других частей.

MPL 2.0

MPL 2.0, выпущенная в 2012 году, модернизировала лицензию. Был внесен ряд изменений, но основная идея — файлового слабого копилефта — осталась неизменной. Лицензия прояснила свойство «файловости», которое в предыдущих версиях было несколько более неявным.

Для обеспечения совместимости с лицензиями GPL была добавлена вторичная лицензия (secondary license). Вторичная лицензия — это одна из лицензий GPL (включая LGPL и AGPL), и она позволяет комбинировать произведение с произведением под вторичной лицензией и распространять результат под этой лицензией. Это отличается от традиционного двойного лицензирования тем, что оригинальное произведение остается лицензированным исключительно под MPL 2.0. Вторичная лицензия применяется только тогда, когда произведение комбинируется и распространяется вместе с другим кодом, который лицензирован под вторичной лицензией. Если лицензиар хочет исключить вторичную лицензию, это должно быть явно указано в уведомлении об авторских правах.

MPL 2.0 также добавила явный пункт о предоставлении патентных прав (patent grant), чтобы прояснить, что участники предоставляют патент на любой код, добавленный участником. Это так называемое узкое предоставление (narrow grant), означающее, что оно применяется только к внесенному коду. Это, например, отличается от более широкого патентного предоставления в GPLv3.

Еще одним важным изменением стало введение льготного периода (grace period) на случай несоблюдения условий, после которого ваши права по лицензии не прекращаются окончательно. Если вы устраните нарушения в течение 30 дней, ваши права по лицензии будут восстановлены.

Последнее изменение, заслуживающее упоминания: MPL 2.0 отменила требование указывать все изменения, внесенные в исходный код.

Common Development and Distribution License (CDDL)

Лицензия CDDL основана на MPL. Она была выпущена Sun Microsystems в 2004 году (то есть после MPL 1.1, но до MPL 2.0) как более простая и понятная версия MPL 1.1.

CDDL существует в двух версиях: CDDL 1.0 и CDDL 1.1 — с очень незначительными различиями. Более того, фактические различия между CDDL 1.0/1.1 и MPL 1.1 очень невелики. Одно из заметных отличий заключается в том, что в CDDL не было требования указывать все изменения — той части, которая также была исключена в MPL 2.0.

Eclipse Public License (EPL)

(Большинство программ Eclipse Foundation: Eclipse IDE, Jakarta EE (Java EE) и другие; а также Clojure, GraphViz и т.д.)

Eclipse Public License (EPL) — еще одна лицензия со слабой копилефт-защитой. Популярна в корпоративной среде. Она является преемницей Common Public License (CPL) и очень похожа на лицензию MPL. Как EPL, так и MPL отличаются от LGPL одинаковым образом. Во-первых, EPL применяется только на уровне файлов, и, во-вторых, отсутствует требование о легкой заменяемости библиотеки. Таким образом, статическая компоновка не является проблемой для программного обеспечения под лицензией EPL.

Патентное предоставление в EPL считается узким, так как применяется только к коду, созданному участником. Это то же самое патентное покрытие, которое было добавлено в MPL 2.0.

CPL 1.0 была выпущена IBM в 2001 году. В результате сотрудничества между IBM и Eclipse Foundation в 2004 году она была заменена на EPL 1.0. Помимо передачи ответственности за лицензию от IBM к Eclipse Foundation, единственным отличием было небольшое изменение в части патентной реторсии. Подробности см. здесь (ссылка в оригинале).

EPL 2.0

EPL 2.0 была выпущена в 2017 году. Она осталась очень похожей на предыдущую версию, но включает некоторые незначительные изменения. Чтобы прояснить, что это файловая лицензия со слабым копилефтом, слово «файл» было явно использовано вместо предыдущего слова «модуль». В EPL 1.0 было явно указано, что она регулируется законами США и законами штата Нью-Йорк. EPL 2.0 менее США-центрична и удаляет этот пункт. EPL 2.0 также убрала формулировку «объектный код», чтобы сделать лицензию более подходящей для скриптовых языков, где исходный и объектный код часто совпадают.

Возможно, самым важным дополнением в EPL 2.0, аналогично MPL 2.0, стала возможность назначения вторичной лицензии. Она служит той же цели — обеспечению совместимости с лицензиями GPL, но позволяет указывать только GPLv2 и более поздние версии в качестве вторичной лицензии. В отличие от MPL 2.0, здесь уведомление об авторских правах должно явно включать, что программное обеспечение может распространяться под вторичной лицензией.

С EPL 1.0 проекты иногда имели двойное лицензирование с BSD, чтобы сделать проекты совместимыми с GPL. Но с BSD части копилефта удалялись. При использовании вторичной лицензии копилефт, наоборот, сохранялся.

Заключение

Лицензии со слабой копилефт-защитой представляют собой компромисс между копилефт- и разрешительными лицензиями. Только изменения в коде, лицензированном под слабой копилефт-лицензией, должны распространяться под той же лицензией, но допускается вызов этого кода из кода с другой, даже проприетарной, лицензией.

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

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

Лицензии OSS, часть 6: Совместимость лицензий и двойное лицензирование

…

Совместимость лицензий

Когда мы говорим о совместимости лицензий, мы говорим о возможности объединения программного обеспечения, лицензированного под двумя разными лицензиями, в более крупное произведение. Две лицензии могут иметь противоречащие друг другу требования, так что невозможно удовлетворить все требования обеих лицензий. Такие лицензии несовместимы.

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

Примером несовместимых лицензий является комбинация лицензии Apache 2.0 и GPLv2 в одном распространяемом ПО. Apache 2.0 устанавливает ограничения на патенты, которые не включены в GPLv2. В то же время GPLv2 явно заявляет, что вы не можете добавлять дополнительные ограничения в модифицированный и распространяемый код. Таким образом, вы не можете лицензировать распространяемое ПО под GPLv2, поскольку теперь оно будет включать ПО с патентными ограничениями. Также невозможно распространять его под лицензией Apache 2.0, поскольку GPLv2 является реципрокной (взаимной) и требует, чтобы комбинация была лицензирована под GPLv2. Следовательно, существуют противоречащие требования, то есть две лицензии несовместимы.

GPLv3 ввела патентные пункты, очень похожие на те, что есть в лицензии Apache 2.0. Это делает GPLv3 совместимой с Apache 2.0. Распространение ПО, состоящего из кода под GPLv3 и Apache 2.0, возможно при условии, что комбинация лицензирована под GPLv3.

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

Поскольку GPL является одновременно очень ограничительной и очень распространенной, совместимость лицензий часто обсуждается в контексте совместимости лицензий с GPL. Это обычно относится как к GPL версии 2, так и к версии 3, хотя, как мы видели выше, лицензия Apache 2.0 совместима только с одной из них. GNU поддерживает список лицензий с указанием их совместимости с GPL.

Совместимость копилефт-лицензий

Как отмечалось в части 5 этой серии блогов, MPL 2.0 и EPL 2.0 совместимы с GPL благодаря использованию вторичной лицензии. Это означает, что вклады также могут лицензироваться под GPL, что делает возможным комбинирование и распространение ПО с кодом под лицензией GPL. Опция вторичной лицензии явно указана в MPL 2.0 и EPL 2.0.

Другими распространенными копилефт-лицензиями являются лицензия AGPL, а также различные версии LGPL и GPL. GNU предоставляет матрицу, обобщающую совместимость между этими лицензиями. Короче говоря, если вы хотите объединить код под LGPL и GPL, такая комбинация совместима, но результирующая комбинированная программа должна быть лицензирована под GPL. Основная проблема несовместимости — между GPLv2 и GPLv3. Проблема аналогична проблеме при объединении кода под лицензией Apache 2.0 и GPLv2. GPLv2 явно запрещает дополнительные ограничения для распространяемой программы.

Код под LGPLv2.1 может быть перелицензирован на GPLv2 или GPLv3, что может помочь решить проблемы совместимости с этими лицензиями.

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

Двойное лицензирование

Двойное лицензирование означает распространение программного обеспечения под двумя (или иногда более) разными лицензиями. Поскольку семантически «двойное» относится к «двум», иногда используется термин «множественное лицензирование», чтобы охватить также ситуации, когда используется более двух лицензий. Тем не менее, здесь мы будем продолжать называть это двойным лицензированием.

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

Распространение ПО под разными коммерческими лицензиями очень распространено. Оно может использоваться для захвата различных сегментов рынка, удовлетворения конкретных потребностей и максимизации дохода. В моделях freemium или open core ограниченная версия ПО доступна бесплатно, но для доступа к расширенным функциям можно приобрести другую лицензию. Также могут определяться различные лицензии в зависимости от количества пользователей и показателей использования. Это особенно распространено в SaaS-предложениях.

Коммерческое лицензирование и двойное лицензирование с открытым исходным кодом

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

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

Некоторые примеры ПО с такой моделью двойного лицензирования включают MySQL с двойной лицензией GPLv2 и коммерческой лицензией, фреймворк Qt с двойной лицензией AGPL и коммерческой лицензией, а также Ghostscript с двойной лицензией LGPLv3 и коммерческой лицензией.

Двойное лицензирование с использованием только открытых лицензий

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

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

Более широкое внедрение может быть достигнуто за счет увеличения совместимости лицензий. Предложение ПО под несколькими лицензиями обеспечивает более широкую совместимость с другим ПО. В предыдущей части блога мы видели пример, когда код под EPL 1.0 иногда имел двойную лицензию с BSD, чтобы сделать его совместимым с GPL.

Другой пример — Mozilla Firefox, который ранее выпускался под тройной лицензией: MPL 1.1, GPL и LGPL. Поскольку MPL 1.1 не была совместима с GPL, лицензиаты могли выбрать условия GPL и распространять производные работы под GPL. Аналогично, некоторые лицензиаты могли захотеть использовать код в библиотеке под LGPL и распространять производную работу под LGPL. Распространение Mozilla Firefox также под LGPL делало это возможным. Текущие версии Mozilla Firefox, однако, выпускаются под MPL 2.0, которая совместима с GPL.

Применение более чем одной лицензии

Двойное лицензирование часто понимается как возможность для лицензиата выбрать одну из двух или более лицензий. Также возможно, но менее распространено, одновременное применение двух лицензий. Таким образом, лицензиат должен соблюдать обе лицензии. Наиболее известный пример — OpenSSL, который ранее имел две разные лицензии, и обе применялись одновременно. Чтобы прояснить это, лицензии разделяются «AND» (И), в то время как в более распространенном случае они разделяются «OR» (ИЛИ).

Заключение

Отслеживание совместимости лицензий становится все более важным из-за интеграции разнообразных и сложных программных компонентов в современных продуктах. Несовместимые лицензии могут привести к юридическим рискам и рискам соблюдения требований. Обнаружение несовместимости лицензий на раннем этапе также позволяет быстрее устранить проблему, поскольку переход на другие программные компоненты может быть затруднен, когда они становятся неотъемлемой частью продукта.

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

P.S. 4 дополнения к переводам

1. Близко к слабому копилефту находятся исключения GPL (Runtime / Linking Exception)

Исключения GPL — это специальные разрешения, добавляемые к стандартной лицензии GPL. Они созданы, чтобы решить главную проблему «вирусности» GPL: если ваша программа просто использует библиотеку под GPL (линкуется с ней), вы не обязаны открывать код всей программы.

GCC Runtime Library Exception: Это исключение для рантайм-библиотек компилятора GCC. Оно позволяет разработчикам компилировать свои программы (в том числе проприетарные) с помощью GCC, не опасаясь, что на них распространятся требования GPL.
GPL Linking Exception: Более общий термин для исключений, разрешающих линковку (связывание) кода под GPL с другими модулями, которые могут быть под любой лицензией. Классический пример — Classpath exception для Java-библиотек.

2. Подробнее про проблему LGPL при статической линковке и преимущество MPL (для проприетарных продуктов)

Основные требования LGPL при статической линковке:

Предоставление объектных файлов: Вы обязаны предоставить «Minimal Corresponding Source» (минимальный соответствующий исходный код). Это означает предоставление всех объектных файлов или исходного кода вашего приложения в форме, пригодной для повторной сборки (relink) с модифицированной версией библиотеки.
Инструкции по установке: это нововведение версии v3, направлено в первую очередь против тивоизации.

Как обстоит дело с предоставлением полных объектных файлов для статической линковки?

2.1 В экосистемах некоторых языков, к примеру Go и Rust это работает плохо из-за статической линковки в монолитный исполняемый файл и отсутствия стабильного ABI. Ситуация усугубляется использованием дженериков и инлайн-функций. Это делает LGPL в этих языках очень сложной проблемой.

2.2 Это проблема и для C++ с шаблонами, и для C с макросами. По этой причине стандартная библиотека C++ (libstdc++) распространяется под GPL с исключением для линковки, а не под LGPL.

2.3 Однако есть важное исключение в LGPLv3. Оно применяется к материалам, не выходящим за рамки:

числовых параметров;
макетов структур данных и методов доступа к ним (accessors);
небольших макросов, inline-функций и шаблонов (длиной не более десяти строк).

В версии LGPL 2.1 тоже, но исключение не распространялось на шаблоны явно .

Qt сделали свою версию LGPL 2.1 с исключением, где шаблоны были явно прописаны. При этом, если нет модификации, то длина макросов, инлайн-функций и шаблонов не ограничена. Однако, если вы меняете саму библиотеку, вы можете сохранить действие этого исключения только в том случае, если ваши изменения в заголовочных файлах ограничиваются: » …небольшими макросами, шаблонами и инлайн-функциями длиной не более 5 строк».

2.4 Публикация объектных файлов (.o, .obj) помогает раскрыть структуру закрытого кода. С помощью декомпиляторов восстановить логику из объектных файлов проще, чем из финального бинарника, так как в них сохранено больше метаданных и имен символов.

2.5 Намного лучше дело для статической линковки обстоит у MPL 2.0. Вы можете скомпилировать MPL-библиотеку напрямую в ваш закрытый исполняемый файл. Единственное условие — модификации исходного кода самих файлов MPL-библиотеки должны быть открытыми и доступными. В сообществе Rust часто выбирают для библиотек именно MPL 2.0.

3. Microsoft выпустила учебный модуль на темы совместимости открытого и закрытого ПО.

В нём слабый копилефт отнесён к «жёлтой зоне опасности», между красной (сильный копилефт) и зелёной (разрешительные, они же пермиссивные лицензии). Из него выходит, что «жёлтые» лицензии вполне практичный вариант для использования в проприетарном ПО.

4. Итоговая краткая таблица.

Лицензия	Тип триггера копилефта	Совместимость с GPL	Статическая линковка
LGPL	Библиотека целиком	Да (через GPL)	Сложно
MPL 2.0	Файл	Да (через GPL secondary)	Легко
EPL 2.0	Файл	Да (через GPL secondary)	Легко

Ссылки

ссылка на оригинал статьи https://habr.com/ru/articles/1024508/