MIT vs. BSD vs. Podwójna licencja

Rozumiem, że:

• Projekty licencjonowane MIT mogą być wykorzystywane / rozpowszechniane w projektach licencjonowanych BSD .
• Projekty licencjonowane BSD mogą być wykorzystywane / rozpowszechniane w projektach licencjonowanych MIT.
• Licencje 2-klauzulowe MIT i BSD są zasadniczo identyczne .
• 3-klauzula BSD = 2-klauzula BSD + klauzula „brak poparcia”
• Wydanie podwójnej licencji pozwala użytkownikom wybierać spośród tych licencji - nie być związanym z obiema.

Jeśli wszystkie powyższe informacje są poprawne, jaki jest sens korzystania z podwójnej licencji MIT / BSD? Nawet jeśli BSD odnosi się do wersji z 3 klauzulami, to czy użytkownik nie może legalnie wybrać tylko licencji MIT?

Wygląda na to, że jeśli naprawdę chcesz zastosować klauzulę „brak poparcia”, musisz licencjonować ją jako BSD (nie dualną). Jeśli nie obchodzi Cię klauzula „brak poparcia”, wystarczy MIT sam, a MIT / BSD jest zbędny.

Podobnie, ponieważ zarówno licencje MIT, jak i BSD są „ kompatybilne z GPL ” i można je redystrybuować w projektach licencjonowanych na GPL , wówczas podwójne licencje MIT / GPL również wydają się zbędne.

Rozumiem, że:

1. Projekty licencjonowane MIT mogą być wykorzystywane / rozpowszechniane w projektach licencjonowanych przez BSD.
   PRAWDA (ale jeśli nie ma modyfikacji, użytkownicy mogą ją również pobrać z oryginalnych źródeł).

2. Projekty licencjonowane BSD mogą być wykorzystywane / rozpowszechniane w projektach licencjonowanych MIT. Licencja
   FALSE MIT pozwala na dystrybucję bez kredytów składkowych; BSD nie.

3. Licencje 2-klauzulowe MIT i BSD są zasadniczo identyczne.
   FAŁSZ Patrz wyżej.

4. 3-klauzula BSD = 2-klauzula BSD + klauzula „bez potwierdzenia”
   PRAWDA

5. Wydanie podwójnej licencji pozwala użytkownikom wybierać spośród tych licencji - nie być związanym z obiema.
   PRAWDA (tak mi się wydaje!)

Podobnie, ponieważ zarówno licencje MIT, jak i BSD są „kompatybilne z GPL” i można je redystrybuować w projektach licencjonowanych na GPL, wówczas podwójne licencje MIT / GPL również wydają się zbędne.

NO . Oto główna różnica. Licencja MIT i licencja Apache wymaga jedynie uznania oryginalnych posiadaczy praw autorskich. Jeśli wybierzesz, może rozprowadzać źródła; ale jeśli wybierzesz, możesz zachować nowy produkt pochodny bez otwierania kodu. W związku z tym możliwe jest użycie kodu opracowanego w ramach MIT i Apache - na licencji komercyjnej.

Jeśli kiedykolwiek użyjesz kodu z licencją opartą na GPL i zdarzy ci się go zmodyfikować, musisz rozpowszechniać zmodyfikowany kod również na licencji GPL. Innymi słowy, gdy jakakolwiek baza kodu GPL zostanie użyta w ramach projektu i jeśli chcesz opublikować ją jako produkt, musi ona zostać opublikowana wraz z kodem źródłowym i musi zostać opublikowana na licencji GPL. Nigdy nie może być licencją komercyjną ani zamkniętym źródłem i nie może być żadną inną licencją, która jest mniej rygorystyczna niż GPL.

Możliwe jest na przykład pobranie kodu licencji MIT, Apache lub BSD, zmodyfikowanego i rozpowszechnionego na licencji GPL. Gdy baza kodu jest rozpowszechniana jako GPL, jej dalsze pochodne wersje nie mogą być dystrybuowane na licencji MIT, Apache lub BSD, ale muszą być wyłącznie GPL.

Edycja:
Przykładowy przypadek podwójnej licencji: Załóżmy, że Nice Office został wydany na podstawie podwójnej licencji - MIT i GPL. Ma dwie możliwości. Niektóre osoby mogą stworzyć NicePro Office, które może być komercyjne i sprzedawać. Podczas gdy niektóre inne społeczności open source tworzą rozwidlenie NiceOpen Office. W takim przypadku może egzekwować dystrybucję GPL (oryginalnej wersji Nice Office oraz wersji NiceOpen Office), dlatego jeśli zaczynasz od NiceOpen Office, musisz przestrzegać tylko GPL, a nie licencji MIT.

Chodzi o to, że w przypadku podwójnej licencji pierwsza osoba, która uzyskuje licencję, ma wybór. Może wybrać jeden z dwóch sposobów - jednak druga osoba musi zastosować się do wyboru dokonanego przez pierwszą osobę. Nie może uchylić pierwotnych praw żadnego pokolenia i w żaden sposób nie może ograniczyć obowiązku posiadania odpowiedniej licencji.

EDYCJA 2 Dodanie ciekawej lektury - licencje GPL i MPL powodują poważne konflikty. Przeczytaj to. http://www.tomhull.com/ocston/docs/mozgpl.html

Twoje pięć punktów jest prawdą .

Inna odpowiedź wydaje się zakładać, że dołączasz starszą, rzadko używaną 4-klauzulową licencję BSD .

Jeśli interpretujesz „licencje BSD” jako odnoszące się do częściej używanych 3-klauzulowych lub 2-klauzulowych wariantów licencji BSD, wszystkie pięć twierdzeń w pytaniu jest prawdą.

Jeśli wszystkie powyższe informacje są poprawne, jaki jest sens korzystania z podwójnej licencji MIT / BSD?

Technicznie nie powinno być takiej potrzeby. Oba mogą być używane w tych samych sytuacjach.

Nawet jeśli BSD odnosi się do wersji z trzema klauzulami, to czy użytkownik nie może legalnie wybrać tylko licencji MIT?

Brzmi poprawnie.

Wygląda na to, że jeśli naprawdę chcesz zastosować klauzulę „brak poparcia”, musisz licencjonować ją jako BSD (nie dualną). Jeśli nie obchodzi Cię klauzula „brak poparcia”, wystarczy MIT sam, a MIT / BSD jest zbędny.

Zgadza się. Jeśli zależy ci na tej konkretnej klauzuli, nie ma sensu licencjonować tej samej pracy na podstawie licencji bez tej klauzuli.

Podobnie, ponieważ zarówno licencje MIT, jak i BSD są „kompatybilne z GPL” i można je redystrybuować w projektach licencjonowanych na GPL, wówczas podwójne licencje MIT / GPL również wydają się zbędne.

Tak.

Chociaż czasami oprogramowanie może twierdzić, że jest podwójnie licencjonowane jako MIT i GPL (lub jakaś licencja zezwalająca i GPL), ale w rzeczywistości odnoszą się do dwóch różnych wersji oprogramowania.

Na przykład niektóre programy mogą być kompilowane i dystrybuowane z licencją permisywną, taką jak BSD lub MIT, ale jeśli pominie się niektóre biblioteki, a zatem i niektóre funkcje, można je rozpowszechniać jako GPL. Pominięte biblioteki będą zazwyczaj bibliotekami stron trzecich, które nie są kompatybilne z GPL, ale nadal mogłyby być dystrybuowane.