GPL / LGPL und Static Linking [geschlossen]

Ich habe im Internet gelesen, dass folgende Kombination existiert:

Proprietärer Quellcode + GPL-Quellcode -> GPL-Quellcode (Der gesamte Code muss unter GPL freigegeben werden.)

Proprietärer Quellcode + LGPL-Quellcode -> Proprietärer Quellcode (Der gesamte Code bleibt proprietär)

Wie funktioniert nun die statische / dynamische Verknüpfung von GPL- und LGPL-Code mit der obigen Kombination?

— Raulp
quelle

Propriety-Quellcode + LGPL-Quellcode -> Propriety-Quellcode , dies ist falsch, LGPL-Quellcode bleibt LGPL.

— wimh

Ich stimme dafür, diese Frage als nicht zum Thema gehörend zu schließen, da es um Lizenzierung oder rechtliche Fragen geht, nicht um Programmierung oder Softwareentwicklung. Weitere Informationen finden Sie hier und weitere Informationen in der Hilfe .

— JasonMArcher

Die Lizenzierung ist ein entscheidender Bestandteil der Softwareentwicklung. Wenn man bedenkt, wie sich eine statische und dynamische Verknüpfung eines GPL- und eines NICHT-GPL-Teils eines Codes auf die Softwareentwicklung und damit auf die Programmierung in viel größerem Maße auswirkt, sehe ich dies nicht als aus -topic und daher würde ich darum bitten, es zu überdenken, um offen zu bleiben.

— Raulp

Ich frage mich, ob dies auf opensource.stackexchange.com migriert werden sollte . Aber es ist auch irgendwie irgendwie wichtig für Entwickler, also nicht sicher.

— Pevik

103

Wenn Sie ein kombiniertes Werk verteilen möchten, müssen Sie die folgende Lizenz verwenden.

Proprietärer Quellcode + GPL-Quellcode

Entweder statisch oder dynamisch verknüpft: Sie müssen beide Teile als GPL freigeben .

Proprietärer Quellcode + LGPL-Quellcode

statisch verknüpft:
- Entweder müssen Sie beide Teile als LGPL freigeben .
- Oder stellen Sie alles bereit, was es dem Benutzer ermöglicht, die Anwendung mit einer anderen Version des LGPL-Quellcodes zu verknüpfen . In diesem Fall sind die anderen Anforderungen dieselben, als ob sie dynamisch verknüpft wären.
dynamisch verknüpft: LGPL-Code bleibt LGPL, Sie können den proprietären Code proprietär halten .

Siehe auch Ausführen eines (L) GPL-Programms aus proprietärem Quellcode .

Update (November 2014) : Ein umfassendes Tutorial und Handbuch enthält eine klare und detaillierte Beschreibung der (L) GPL und ihrer Verwendung, einschließlich der Verteilung. Ich empfehle es für weitere Details.

— wimh
quelle

Über " Sie müssen beide Teile als LGPL freigeben " Teil: Muss nicht LGPL sein, denke ich. Der unter einer Lizenz veröffentlichte Anwendungsquellcode sollte in Ordnung sein, auch eine Lizenz, die das Ändern verbietet, solange die Neuverteilung der nicht geänderten Anwendungsquelle zusammen mit der LGPL-Bibliothek möglich ist (eine erneute Kompilierung ist daher möglich).

— Hyde

... Ich nehme jedoch an, dass der Teil " Alles bereitstellen, mit dem der Benutzer die Anwendung erneut verknüpfen kann" auch die Bereitstellung einer anderen Quelle als LGPL abdeckt, sodass sie neu kompiliert und dann erneut verknüpft werden kann.

— Hyde

Ich wollte ein Spiel versenden, das statisch mit SDL1.2 verknüpft ist. Müssen wir die Objektdateien oder was auch immer tatsächlich versenden, um eine erneute Verknüpfung zu ermöglichen, oder nur anbieten, sie auf Anfrage bereitzustellen, wie beim Copyleft-Quellcode? Könnte lieber mit dynamischer Verknüpfung gehen, wenn ich die .o-Dateien versenden müsste.

— Sam Watkins

Ich bin mir größtenteils sicher, dass dieser Kommentar absolut richtig ist. Wenn Sie eine LGPL-Bibliothek statisch verknüpfen, muss die Anwendung selbst LGPL sein. Wir haben dies in der Vergangenheit von unserem Anwalt überprüfen lassen. Die dynamische Verknüpfung mit einer LGPL-Bibliothek ist der einzige Weg, um zu vermeiden, LGPL zu werden.

— Steve Grahovac

Gibt es einen Unterschied bei der Verwendung von binären (statischen) oder gemeinsam genutzten Bibliotheken in apk (Android App)? Benutzer kann Bibliothek in apk in beiden Fällen sowieso nicht einfach ersetzen

— Benutzer25