MIT vs. BSD vs. Dual License


87

Я розумію, що:

  • Проекти, що мають ліцензію MIT, можна використовувати / перерозподіляти в проектах, що мають ліцензію на BSD .
  • Проекти, що мають ліцензію на BSD, можна використовувати / перерозподіляти в проектах, що мають ліцензію MIT.
  • Ліцензії MIT та BSD на 2 пункти по суті однакові .
  • 3-ти пункт BSD = 2-пункт BSD + пункт "немає схвалення"
  • Видача подвійної ліцензії дозволяє користувачам вибирати з цих ліцензій - не прив’язуватися до обох.

Якщо все вищесказане правильно, то який сенс використовувати подвійну ліцензію MIT / BSD? Навіть якщо BSD посилається на 3-версійну версію, то чи не може користувач юридично вибрати лише дотримання ліцензії MIT?

Здається, що якщо ви дійсно хочете застосувати застереження "без схвалення", то вам доведеться ліцензувати його як просто BSD (а не подвійне). Якщо ви не переймаєтесь пунктом "без схвалення", то лише MIT є достатнім, а MIT / BSD є зайвим.

Так само, оскільки ліцензії на MIT та BSD є " сумісними з GPL " і можуть перерозподілятися в проектах, які мають ліцензію на GPL , то подвійне ліцензування MIT / GPL також видається зайвим.


1
Чи можете ви навести приклад ліцензій MIT + BSD? Зазвичай це надмірна подвійна ліцензія за двома аналогічно дозвільними ліцензіями, але я бачив, що подвійне ліцензування зловживається як спосіб явно заявити, що код може бути перерозподілений під кожною з ліцензій.
янніс

@ Yannis Yea Я цікавився, чи люди подвійні ліцензії, щоб вони були більш явні для людей, які не знають. Але я думаю, що це просто робить їх більш заплутаним.
ryanve

Цікаво читати: tomhull.com/ocston/docs/mozgpl.html
Dipan Mehta


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

Відповіді:


60

Я розумію, що:

  1. Проекти, що мають ліцензію MIT, можна використовувати / перерозподіляти в проектах, що мають ліцензію на BSD.
    ІСТИНА (але якщо немає модифікацій, користувачі також можуть отримати її з оригінальних джерел.

  2. Проекти, що мають ліцензію на BSD, можна використовувати / перерозподіляти в проектах, що мають ліцензію MIT.
    FALSE MIT ліцензія дозволяє розповсюджувати без внесків; BSD не робить.

  3. Ліцензії MIT та BSD на 2 пункти по суті однакові.
    ФАЛЬСІ Див. Вище.

  4. 3-ти пункт BSD = 2-пункт BSD + пункт "без схвалення"
    ІСТИНА

  5. Видача подвійної ліцензії дозволяє користувачам вибирати з цих ліцензій - не прив’язуватися до обох.
    ІСТИНА (я так думаю!)

Так само, оскільки ліцензії на MIT та BSD є "сумісними GPL" і можуть перерозподілятися в проектах, що мають ліцензію GPL, то подвійне ліцензування MIT / GPL також видається зайвим.

НІ . Тут головна відмінність. Ліцензія 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.

Справа в тому, що у випадку подвійної ліцензії перший вибір, хто отримає ліцензію, має вибір. Він може вибрати будь-який шлях - проте друга людина повинна дотримуватися вибору, яку зробила перша людина. Він / вона не може відміняти оригінальні права будь-якого покоління і ніяк не може зменшити зобов'язання відповідної ліцензії.

EDIT 2 Додавання цікавого прочитаного - GPL та MPL Ліцензії мають серйозні конфлікти. Прочитай це. http://www.tomhull.com/ocston/docs/mozgpl.html


4
@Dipan Якщо проект має подвійну ліцензію відповідно до MIT / GPL, він може бути використаний у фірмовому проекті b / c, який користувач може вибрати наступний лише MIT. Якщо проект має лише ліцензію MIT, його можна перерозподілити за іншими ліцензіями, включаючи GPL. Ось що я мав на увазі під зайвим.
ryanve

11
@DipanMehta Що ви маєте на увазі під "внесками" у №2? Це здається, що ви посилаєтесь на ліцензію на 4 статті BSD, яка не перевірена FSF, як 3 та 2. Я говорю про 3-х та 2-й, і я майже впевнений, що всі п’ять тверджень є істинними .
ryanve

4
Ви можете використовувати BSD-ліцензійний код спільно з ліцензованим кодом MIT; ви просто повинні згадати в матеріалах проекту, що "BazApp використовує libfoobar, який поширюється за ліцензією BSD" або щось подібне. Ліцензії BSD та MIT застосовуються на рівні файлу, а не на одному проекті.
mipadi

10
@Dipan_Mehta Як уже говорив ryanve, ви говорите про оригінальну ліцензію на BSD з чотирма пунктами, в той час як ОП говорить про переглянуті ліцензії BSD на 3 та 2 пункти. Ліцензія BSD на 2 пункти фактично еквівалентна ліцензії MIT. Навіть на сторінці OSI так йдеться.

17
Точка №2 (BSD-код не може бути включений до коду MIT) суперечить кожній інформації, яку я коли-небудь читав про 3-класовий та 2-класовий BSD. Пункт №2 буде істинним щодо (тепер уже давньої та забутої) 4-ої статті BSD, але ОП дала зрозуміти, що це питання не стосується 4-класової BSD. Здається, дуже шкідливо мати таку надзвичайно оманливу інформацію в іншому випадку дуже доброї та достовірної відповіді.
апспіллери

4

Ваші п'ять балів - це правда .

Інша відповідь, здається, передбачає, що ви включаєте старіші, рідко використовувані 4-ліцензійні ліцензії BSD .

Якщо ви інтерпретуєте "BSD ліцензії" як посилання на частіше використовувані 3-або два-варіанти варіантів ліцензії BSD, усі п'ять заяв у цьому питанні є істинними.

Якщо все вищесказане правильно, то в чому сенс використання подвійної ліцензії 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.