Kann sich ein GPLv2-Programm auf von Apache lizenzierte Bibliotheken verlassen?

Kann ein GPL-lizenziertes Softwareprogramm (Version 2) Bibliotheken verwenden, die unter APLv2 lizenziert sind, ohne die GPL zu verletzen? Die Sprache hier suggeriert mir vielleicht nicht.

In meinem speziellen Fall schaue ich auf einen Daemon, der einige APLv2-lizenzierte externe Bibliotheken verwendet.

UPDATE (Als Antwort auf Antworten / Kommentare.)

1. Für diese Frage kann ich das Hauptprogramm (den Daemon) nicht neu lizenzieren.
2. Das Hauptprogramm wurde um Funktionen erweitert, die apr-utilmöglicherweise auch andere APLv2-Komponenten verwenden

Meine Frage ist, ob ich den erweiterten Daemon unter der GPLv2 freigeben kann oder ob ich dies für mich behalten (keine Distribution) und / oder ohne APLv2 erneut implementieren muss, wenn ich verpflichtet bin, (a) diese Erweiterung freizugeben, und (b) Beibehalten der GPL für den Daemon?

Lassen Sie uns zunächst einige Begriffe klären. Wenn die FSF sagt, dass eine Lizenz mit der GPL kompatibel ist , bedeutet dies nicht, was viele Leute darunter verstehen. Viele interpretieren "kompatibel", um zu bedeuten, dass die beiden Softwareteile glücklich in derselben Anwendung koexistieren können.

Das kommt dem, was die FSF bedeutet, sehr nahe, aber die Copyleft-Bereitstellung der GPL geht noch ein bisschen weiter.

In den GPL-FAQ wird der Schwerpunkt auf meine gelegt.

Dies bedeutet, dass die andere Lizenz und die GNU GPL kompatibel sind. Sie können Code, der unter der anderen Lizenz veröffentlicht wurde, mit Code, der unter der GNU GPL veröffentlicht wurde, in einem größeren Programm kombinieren.
Alle GNU GPL-Versionen erlauben solche Kombinationen privat; Sie erlauben auch den Vertrieb solcher Kombinationen, vorausgesetzt, die Kombination wird unter derselben GNU GPL-Version veröffentlicht .

Eine Lizenz ist also mit der GPL kompatibel, wenn ihre Bedingungen unter der GPL aufgenommen werden können.

Schauen wir uns also die APLv2 und die GPLv3 an.

• APLv2_Lib + GPLv3_Lib => Kombinierte Bibliothek als GPLv3 ist in Ordnung.
• APLv2_Lib + GPLv3_Lib => Kombinierte Bibliothek als APLv2 ist nicht in Ordnung.

Und Apache sagt so viel hier :

Wir vermeiden die GPLv3-Software, da die GPLv3-Autoren lediglich die Verknüpfung mit ihr als Grundlage für die Erstellung eines abgeleiteten Werks betrachten. Wir möchten ihre Lizenz einhalten.

Sie arbeiten jedoch mit einem Daemon, der unter der GPLv2 und nicht unter der Version 3 lizenziert wurde.

FSF ist sich ziemlich sicher , dass das, was Sie tun möchten, für eine öffentliche Verbreitung nicht akzeptabel ist.

Bitte beachten Sie, dass diese Lizenz nicht mit der GPL-Version 2 kompatibel ist, da es einige Anforderungen gibt, die nicht in dieser GPL-Version enthalten sind. Dazu gehören bestimmte Bestimmungen zur Beendigung und Freistellung von Patenten.

Um Ihre Frage zu beantworten:

Nein , Sie dürfen den kombinierten Dämon nicht unter Verwendung von GPLv2- und APLv2-lizenziertem Material verteilen .
FSF weist ausdrücklich darauf hin, dass diese Kombination für die öffentliche Verbreitung nicht zulässig ist.

Alternativen:

1. Sie sind erlaubt es privat zu nutzen.

2. Sie können auch die APLv2-Funktionalität neu schreiben und dann Ihre neue Arbeit mit der GPLv2-Arbeit kombinieren.

3. Sie könnten sehen, ob der Daemon auf GPLv3 geändert werden kann. Wenn ja, wären Sie in der Lage, die APLv2-Arbeit in den GPLv3-Daemon zu integrieren.

Meiner Meinung nach stimmt OP mit dem Text des ASF-Links von OP überein.

ASF (Apache Software Foundation) mag die Idee nicht, dass ASFv2-Code Teil eines Systems ist, das GPLv2 verwendet, basierend auf den begrenzten Informationen Ihres Falls und meinem Verständnis der verschiedenen FOSS-Lizenzen: unabhängig davon, ob das Umbrella-Projekt GPLv2 hat oder das Umbrella-Projekt ist GPLv2 und versucht, ASFv2 einzuschließen.

Ferner scheint es, dass ein ASFv2-Umbrella-Projekt mit GPLv3-Code nicht stattfinden sollte, aber ein GPLv3-Umbrella-Projekt kann ASFv2-Code haben.

Die Caveot, vielleicht (nach Gnu), ist, wie sie miteinander interagieren. Wenn eine Verknüpfung besteht und dieselben Kopien von Daten während der Ausführung freigegeben werden, befinden sich diese im selben Programm. Wenn sie jedoch als getrennte Prozesse (dh als Fork) arbeiten, die Daten zwischen verschiedenen unterschiedlichen Prozessen übertragen, ist das, was Sie tun, möglicherweise zulässig, da es sich für sie um getrennte Programme handelt. Wenn es während der Ausführung gemeinsam genutzten Datenraum verwendet und nicht mit unterschiedlichen Prozessen arbeitet, ist das, was Sie tun, möglicherweise nicht zulässig, da sie identisch oder zu eng miteinander verbunden sind, um eindeutig oder unabhängig zu sein.