Я хотел бы выпустить библиотеку программного обеспечения, написанную на классовом объектно-ориентированном языке программирования (Java), на веб-сервисе размещения исходного кода , который позволяет объединять разветвления проекта с основным проектом (GitHub через pull). Запросы). Я исследовал в Интернете и много думал о том, как лицензировать программное обеспечение. Я прав в следующих предположениях (с точки зрения IANAL )?

• Как LGPL, так и MPL способствуют обмену модификациями лицензионного программного обеспечения LGPL / MPL, используемого в других программных проектах. Вместо того, чтобы требовать от пользователей измененной библиотеки размещения отдельного разветвления библиотеки, я могу способствовать внесению вклада в исходную библиотеку (например, посредством запросов на извлечение).

• Основное различие заключается в том, как лицензионный код MPL / LGPL должен быть связан с проектом. Файлы исходного кода MPL могут быть непосредственно скопированы в (возможно) проект закрытого программного обеспечения ( статическое связывание ), в то время как лицензионный код LGPL должен быть динамически связан (слабо связан с возможным проектом закрытого программного обеспечения, чтобы конечные пользователи могли отключить лицензионное программное обеспечение библиотека для другой версии библиотеки лицензионного программного обеспечения).

• Динамическое связывание и, следовательно, LGPL создают дополнительные препятствия для упаковки проприетарного программного продукта, не внося большего вклада в библиотеку программного обеспечения с открытым исходным кодом, чем при наличии статической связи (и, следовательно, MPL). Существует модифицированный LGPL, который позволяет статическое связывание.

• Там нет никаких других значимых различий (от IANAL точки зрения).

• В более старых версиях лицензии не удовлетворяют мои потребности так хорошо , как новейшие из них.

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

Я испытываю желание использовать модифицированный LPGL , но, с другой стороны, обескуражен непопулярностью. Исходя из вышеизложенного, я предпочитаю MPL.
Вопрос: верны ли мои утверждения выше? Какую лицензию мне выбрать, учитывая мои требования?

Решение: С помощью обсуждения в принятом ответе я предпочитаю придерживаться MPL из-за популярности , свободы ссылок и потому что это официальная, неизмененная лицензия .

Я полагаю, что вы точно указали различия между Общественной лицензией Mozilla и Стандартной общественной лицензией GNU , и любая из них может вполне соответствовать вашим потребностям, но вы пропускаете самое важное различие между двумя лицензиями:

Кто может делать новые версии?

Как MPL (раздел 10), так и LGPL (раздел 14) включают в свою лицензию право заменять текущую версию последней версией, и нет никаких реальных ограничений относительно того, что может входить в эти лицензии. Хотя маловероятно, что Mozilla Foundation или Free Software Foundation сделают что-то столь же сумасшедшее, как, скажем, установление условия, в котором говорится, что «все вклады в это программное обеспечение становятся нашей собственностью», но не исключено, что один из организации выпустят новую версию лицензии, которая вам не нравится.

Который поднимает другой пункт об использовании "Модифицированного LGPL".

Модифицированная лицензия - это не та же самая лицензия!

Хотя у вас есть довольно удивительная возможность указать свои собственные условия лицензирования и, по сути, можно сказать: «Вы можете распространять это в соответствии с GPL, но вам нужно указать свое имя в своих кредитах и ​​платить мне 1% от любого дохода, который вы получаете» , каждый раз, когда вы делаете это, вы создаете новую лицензию на основе чужой работы. Это означает, что вы НЕ используете MPL или LGPL, вы используете новую «лицензию Mucaho».

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

Конечно, оба они незначительные моменты. Даже «популярность лицензии» не имеет значения, если вы не ожидаете, что ваш код будет напрямую включен в более крупные проекты.

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

Ответ DougM и AER делает справедливое замечание. MPLv2 и LGPLv3 со статическим исключением одинаковы в отношении событий, которые могут привести к срабатыванию авторского лева. Тем не менее, я думаю, что мы упускаем еще одно очень важное различие между LGPL и MPL. Когда авторское лево срабатывает, авторское право применяется к:

• для MPL: точно такие же файлы вашей исходной библиотеки
• для LGPL: «работа, основанная на библиотеке», а не «работа, использующая библиотеку». Таким образом, LGPL потенциально может расширить свой авторский лев для новых файлов.

Крайний случай: использование MPL позволяет пользователям не делиться своими улучшениями

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

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

Например, кто-то может взять один из основных файлов вашего проекта, добавить «import my_private_new_file» и изменить, например, основной метод, добавив «my_private_new_file.newAwesomeFeature.run ()» .

И таким образом он мог добавлять новые функции в ваш проект, выпуская только измененный основной файл и сохраняя фактическую логику новой функции с закрытым исходным кодом в «my_private_new_file» .

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

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

LGPL написано, чтобы запретить такое поведение. Видеть:

• https://www.javalobby.org//java/forums/t15903.html#91819035
• Позволяет ли мне LGPL сделать это?

Я цитирую оригинальную лицензию LGPL:

Обратите особое внимание на разницу между «работой на основе библиотеки» и «работой, которая использует библиотеку». Первый содержит код, полученный из библиотеки, тогда как последний должен быть объединен с библиотекой для запуска.

Копирайт применяется только к «работе на основе библиотеки». Теперь, что такое «работа на основе библиотеки» на практике? Это оставляет пространство для интерпретации. Что не только приятно, но и означает, что соблюдение вашей лицензии становится более сложным и, следовательно, пугающим. Некоторые люди могут просто не использовать вашу библиотеку.

В этом смысле LGPL является более строгим, чем MPL, но также более защищает целостность проекта.

MPL облегчает пользователям из частного мира исправление вашей библиотеки и ее использование, при этом все еще приходится делиться исправлением

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

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

В результате, MPL делает интересным для проприетарных поставщиков использование и отправку исправлений в вашу библиотеку, чем LGPL.

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

В этом отношении LGPL усиливает такое поведение. Но действительно ли это необходимо?

Вывод

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

LGPL был создан Фондом свободного программного обеспечения, чтобы обеспечить широкое использование библиотек свободного программного обеспечения в проприетарном мире, но с учетом идеи продвижения свободного программного обеспечения и борьбы с проприетарным программным обеспечением. Это все часть стратегии по отношению к их идеологии. См .: https://www.gnu.org/licenses/why-not-lgpl.html.

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

По сути, MPLv2 рассматривается многими как разрешающая лицензия, в то время как LGPLv3, в том числе со статическим исключением, редко называют так.

РЕДАКТИРОВАТЬ

Я забыл упомянуть кое-что важное. LGPLv3 (со статическим исключением или без него) запрещает тивоизацию . Вы можете подумать, что это «деталь», но на самом деле это не так, в зависимости от вашей цели. Вы заботитесь о пользователях Freedom? Тогда это не деталь. Вас волнует, что ваша библиотека может быть использована на устройстве Apple? VLC больше заботится об использовании, поэтому они решили использовать LGPLv2, который не содержит таких ограничений. Точно так же это одна из причин, почему Linux продолжает использовать GPLv2 . MPLv2 также не имеет никаких ограничений для тивиоризации, очевидно, поскольку это лицензия, созданная с учетом более «практической» философии Open Source, а не идеологии FSF.

Могут быть и другие «мелкие» вещи, которые я пропустил.