MIT против BSD против двойной лицензии


87

Мое понимание таково:

  • MIT- лицензированные проекты можно использовать / распространять в BSD- лицензированных проектах.
  • Проекты, лицензированные BSD, могут использоваться / распространяться в проектах, лицензированных MIT.
  • Лицензии MIT и BSD с 2 пунктами по существу идентичны .
  • BSD 3-клоз = BSD 2-клоз + предложение «без одобрения»
  • Выдача двойной лицензии позволяет пользователям выбирать из этих лицензий, а не быть привязанными к обеим.

Если все вышеперечисленное верно, то какой смысл использовать двойную лицензию MIT / BSD? Даже если BSD ссылается на версию с 3 пунктами, то не может ли пользователь по закону выбрать только соблюдение лицензии MIT?

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

Аналогично, поскольку лицензии MIT и BSD являются « совместимыми с GPL » и могут быть перераспределены в проектах с лицензией GPL , двойное лицензирование MIT / GPL также представляется излишним.


1
Можете ли вы привести пример лицензий MIT + BSD? Обычно это дублирует двойную лицензию по двум аналогичным разрешающим лицензиям, но я видел злоупотребление двойной лицензией как способ явно заявить, что код может распространяться по каждой из лицензий.
Яннис

@Yannis Да, мне было интересно, если люди лицензировали их, чтобы быть более понятными для людей, которые не знают. Но я думаю, что это только делает их более запутанными для них.
ryanve



1
По моему опыту люди в основном используют двойное лицензирование для несовместимых лицензий. например, MPL + (L) GPL или платная лицензия без авторского лева вместе с (A) GPL.
CodesInChaos

Ответы:


60

Мое понимание таково:

  1. MIT-лицензированные проекты могут использоваться / распространяться в BSD-лицензированных проектах.
    ИСТИНА (но если нет изменений, пользователи также могут получить его из первоисточников.

  2. Проекты, лицензированные BSD, могут использоваться / распространяться в проектах, лицензированных MIT. Лицензия
    FALSE MIT позволяет распространять без вклада кредитов; BSD нет.

  3. Лицензии MIT и BSD с 2 пунктами по существу идентичны.
    ЛОЖЬ Смотри выше.

  4. BSD 3-кл = BSD 2-кл + предложение "без одобрения"
    ИСТИНА

  5. Выдача двойной лицензии позволяет пользователям выбирать из этих лицензий, а не быть привязанными к обеим.
    ИСТИНА (я так думаю!)

Аналогичным образом, поскольку лицензии MIT и BSD являются «совместимыми с GPL» и могут быть перераспределены в проектах с лицензией GPL, двойное лицензирование MIT / GPL также представляется излишним.

NO . Здесь главное отличие. Лицензия MIT и лицензия Apache требуют только, чтобы вы указали правообладатели оригинальных прав. Если вы выберете, вы можете распространять источник; но если вы выберете, вы можете сохранить новый продукт без открытия кода. Следовательно, можно использовать код, разработанный под MIT и Apache - по коммерческой лицензии.

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

Например, можно взять лицензионный код MIT, Apache или BSD, модифицированный и распространяемый по лицензии GPL. Как только база кода распространяется как GPL, ее дальнейшие производные версии не могут распространяться под лицензией MIT, Apache или BSD, но должны быть только GPL.

Изменить:
Пример случая двойной лицензии: Предположим, что Nice Office выпущен под двойной лицензией - MIT и GPL. У него есть две возможности. Некоторые люди могут создать NicePro Office, который может быть коммерческим и продавать. В то время как какое-то другое сообщество с открытым исходным кодом создает форк NiceOpen Office. В этом случае он может применяться при распространении GPL (исходной версии Nice Office, а также версии NiceOpen Office), поэтому, если вы начинаете с NiceOpen Office, вы должны соблюдать только лицензию GPL, а не лицензию MIT.

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

РЕДАКТИРОВАТЬ 2 Добавление интересного чтения - GPL и MPL Licenses имеют серьезные конфликты. Прочитай это. http://www.tomhull.com/ocston/docs/mozgpl.html


4
@Dipan Если проект имеет двойную лицензию по MIT / GPL, то он может быть использован в проприетарном проекте , поскольку пользователь может следовать только MIT. Если у проекта есть только лицензия MIT, его можно распространять по другим лицензиям, включая GPL. Вот что я имел ввиду под избыточностью.
ryanve

11
@DipanMehta Что вы подразумеваете под "кредитами за вклад" в # 2? Похоже, вы имеете в виду лицензию BSD с 4 пунктами, которая не проверена FSF, как 3-пункт и 2-пункт. Я говорю о 3 и 2 предложениях, и в этом случае я почти уверен, что все пять утверждений верны .
ryanve

4
Вы можете использовать BSD-лицензированный код в сочетании с MIT-лицензированным кодом; Вы просто должны упомянуть в материалах проекта, что «BazApp использует libfoobar, который распространяется под лицензией BSD» или что-то в этом роде. Лицензии BSD и MIT применяются на уровне отдельных файлов, а не проектов.
Мипади

10
@Dipan_Mehta Как уже сказал вам ryanve, вы говорите об исходной лицензии BSD с 4 пунктами, а OP говорит о пересмотренных лицензиях BSD с 3 и 2 пунктами. Лицензия BSD с 2 пунктами фактически эквивалентна лицензии MIT. Так утверждает даже страница OSI.

17
Пункт № 2 (код BSD не может быть включен в код MIT) противоречит каждой части информации, которую я когда-либо читал о BSD с 3 и 2 пунктами. Пункт № 2 был бы правдивым в отношении (теперь уже устаревшего и забытого) BSD с 4 пунктами, но OP ясно дал понять, что этот вопрос не касается BSD с 4 пунктами. Кажется весьма вредным иметь такой вводящий в заблуждение фрагмент информации в другом очень хорошем и заслуживающем доверия ответе.
Апсиллеры

4

Ваши пять баллов все верно .

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

Если вы интерпретируете «лицензии BSD» как относящиеся к более часто используемым вариантам лицензии BSD с 3 или 2 предложениями, все пять утверждений в вопросе верны.

Если все вышеперечисленное верно, то какой смысл использовать двойную лицензию MIT / BSD?

Технически в этом не должно быть необходимости. Любой из них может быть использован в одинаковых ситуациях.

Даже если BSD ссылается на версию с 3 пунктами, то не может ли пользователь по закону выбрать только соблюдение лицензии MIT?

Это звучит правильно.

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

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

Аналогичным образом, поскольку лицензии MIT и BSD являются «совместимыми с GPL» и могут быть перераспределены в проектах с лицензией GPL, двойное лицензирование MIT / GPL также представляется излишним.

Да.

Хотя иногда программный продукт будет претендовать на двойную лицензию как MIT и GPL (или некоторую разрешительную лицензию и GPL), но в действительности они ссылаются на две разные версии программного обеспечения.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.