it-swarm-eu.dev

MIT vs. BSD vs. Dual License

Mein Verständnis ist das:

  • MIT - lizenzierte Projekte können in BSD - lizenzierten Projekten verwendet/weitergegeben werden.
  • BSD-lizenzierte Projekte können in MIT-lizenzierten Projekten verwendet/weitergegeben werden.
  • Die MIT und die BSD 2-Klausel-Lizenzen sind im Wesentlichen identisch .
  • BSD 3-Klausel = BSD 2-Klausel + die "keine Bestätigung "Klausel
  • Durch die Erteilung einer Doppellizenz können Benutzer aus diesen Lizenzen auswählen - nicht an beide gebunden sein.

Wenn alle oben genannten Punkte korrekt sind, was bringt es dann, eine duale MIT/BSD-Lizenz zu verwenden? Selbst wenn sich das BSD auf die 3-Klausel-Version bezieht, kann sich ein Benutzer nicht legal dafür entscheiden, nur die MIT -Lizenz) einzuhalten?

Es scheint, dass Sie, wenn Sie wirklich möchten, dass die "No Endorsement" -Klausel angewendet wird, sie nur als BSD (nicht als Dual) lizenzieren müssen. Wenn Sie sich nicht für die Klausel "Keine Bestätigung" interessieren, reicht MIT allein aus und MIT/BSD ist redundant.

Ebenso, da die MIT und BSD-Lizenzen beide " GPL-kompatibel " sind und in [~ # ~] gpl [~ # ~ neu verteilt werden können ] - lizenzierte Projekte, dann scheint auch die doppelte Lizenzierung von MIT/GPL überflüssig.

93
ryanve

Mein Verständnis ist das:

  1. MIT-lizenzierte Projekte können in BSD-lizenzierten Projekten verwendet/weitergegeben werden.
    [~ # ~] true [~ # ~] (aber sofern keine Änderungen vorgenommen wurden, können die Benutzer diese aus den Originalquellen beziehen ebenfalls.

  2. BSD-lizenzierte Projekte können in MIT-lizenzierten Projekten verwendet/weitergegeben werden.
    [~ # ~] false [~ # ~] MIT Lizenz ermöglicht die Verteilung ohne Beitrag Credits; BSD nicht.

  3. Die Lizenzen MIT und BSD 2-Klausel) sind im Wesentlichen identisch.
    [~ # ~] false [~ # ~] Siehe oben.

  4. BSD 3-Klausel = BSD 2-Klausel + die "No Endorsement" -Klausel
    [~ # ~] true [~ # ~]

  5. Durch die Erteilung einer Doppellizenz können Benutzer aus diesen Lizenzen auswählen und sind nicht an beide gebunden.
    [~ # ~] true [~ # ~] (Ich denke schon!)

Da die Lizenzen MIT und BSD) beide "GPL-kompatibel" sind und in GPL-lizenzierten Projekten neu verteilt werden können, erscheint die doppelte Lizenzierung von MIT/GPL ebenfalls redundant.

[~ # ~] nein [~ # ~] . Hier ist ein großer Unterschied. MIT Lizenz und Apache-Lizenz erfordern nur, dass Sie den ursprünglichen Copyright-Inhabern eine Gutschrift erteilen. Wenn Sie dies wünschen, können Sie können Quelle weitergeben; Wenn Sie möchten, können Sie Ihr neues abgeleitetes Produkt behalten. ohne Eröffnungscode. Daher ist es möglich, Code zu verwenden, der unter MIT und Apache - unter kommerzieller Lizenz entwickelt wurde).

Wenn Sie jemals Code mit GPL-basierter Lizenz verwenden und ihn zufällig ändern, verteilen Sie muss Ihren geänderten Code auch unter GPL. Mit anderen Worten, sobald eine GPL-Codebasis unter einem Projekt verwendet wird und Sie diese als Produkt veröffentlichen möchten, muss sie mit dem Quellcode und unter der GPL veröffentlicht werden. Es kann niemals eine kommerzielle Lizenz oder Closed Source sein, und es kann keine andere Lizenz sein, die weniger streng ist als die GPL.

Es ist beispielsweise möglich, MIT-, Apache- oder BSD-Lizenzcode zu verwenden, der unter der GPL geändert und verteilt wurde. Sobald eine Codebasis als GPL verteilt ist, können ihre weiteren abgeleiteten Versionen nicht unter MIT-, Apache- oder BSD-Lizenz verteilt werden, sondern müssen nur GPL sein.

Bearbeiten:
Beispiel für eine Doppellizenz: Angenommen, Nice Office wird unter der Doppellizenz veröffentlicht - MIT und GPL. Es gibt zwei Möglichkeiten. Einige Benutzer können NicePro Office erstellen, das kommerziell und kommerziell sein kann Während eine andere Open-Source-Community eine Verzweigung für NiceOpen Office erstellt. In diesem Fall kann die GPL-Verteilung (der ursprünglichen Nice Office- sowie der NiceOpen Office-Version) erzwungen werden. Wenn Sie also mit NiceOpen Office beginnen, müssen Sie die GPL einhalten nur und nicht MIT Lizenz.

Der Punkt ist, dass im Fall einer Doppellizenz die erste Person, die eine Lizenz ableitet, die Wahl hat. Er kann so oder so wählen - die zweite Person muss sich jedoch an die Wahl halten, die die erste Person getroffen hat. Er/Sie kann die ursprünglichen Rechte beider Generationen nicht außer Kraft setzen und die Verpflichtung zur anwendbaren Lizenz in keiner Weise verringern.

EDIT 2 Das Hinzufügen einer interessanten Lesung - GPL- und MPL-Lizenzen haben schwerwiegende Konflikte. Lesen Sie dies. http://www.tomhull.com/ocston/docs/mozgpl.html

62
Dipan Mehta

Ihre fünf Punkte sind alle wahr.

Die andere Antwort scheint zu sein, dass Sie die ältere, selten verwendete 4-Klausel-BSD-Lizenz einschließen.

Wenn Sie "BSD-Lizenzen" so interpretieren, dass sie sich auf die am häufigsten verwendeten 3-Klausel- oder 2-Klausel-Varianten der BSD-Lizenz beziehen, sind alle fünf Ansprüche in der Frage wahr.

Wenn alle oben genannten Punkte korrekt sind, was bringt es dann, eine duale MIT/BSD-Lizenz zu verwenden?

Technisch sollte es keine Notwendigkeit dafür geben. Beides kann in den gleichen Situationen verwendet werden.

Selbst wenn sich das BSD auf die 3-Klausel-Version bezieht, kann sich ein Benutzer nicht legal dafür entscheiden, nur die MIT -Lizenz) einzuhalten?

Das klingt richtig.

Es scheint, dass Sie, wenn Sie wirklich möchten, dass die "No Endorsement" -Klausel angewendet wird, sie nur als BSD (nicht als Dual) lizenzieren müssen. Wenn Sie sich nicht für die Klausel "Keine Bestätigung" interessieren, reicht MIT allein aus und MIT/BSD ist redundant.

Das stimmt. Wenn Sie sich für diese bestimmte Klausel interessieren, wäre es nicht sinnvoll, dasselbe Werk auch unter Lizenzen ohne diese Klausel zu lizenzieren.

Da die Lizenzen MIT und BSD) beide "GPL-kompatibel" sind und in GPL-lizenzierten Projekten neu verteilt werden können, erscheint die doppelte Lizenzierung von MIT/GPL ebenfalls redundant.

Ja.

Manchmal behauptet ein Softwareprodukt, doppelt lizenziert zu sein als MIT und GPL (oder eine zulässige Lizenz und GPL), aber in Wirklichkeit beziehen sie sich auf zwei verschiedene Versionen der Software.

Beispielsweise kann einige Software mit einer zulässigen Lizenz wie BSD oder MIT kompiliert und verteilt werden. Wenn Sie jedoch einige Bibliotheken und damit einige Funktionen weglassen, kann sie als GPL verteilt werden. Bei den ausgelassenen Bibliotheken handelt es sich normalerweise um Bibliotheken von Drittanbietern, die nicht GPL-kompatibel sind, aber ansonsten trotzdem verteilt werden könnten.

5
thomasrutter