Wie wird die statische oder dynamische Verknüpfungsregel der GPL auf interpretierte Sprachen angewendet?


19

Nach meinem Verständnis verbietet die GPL das statische Verknüpfen von Nicht-GPL-Code mit GPL-Code, erlaubt jedoch das dynamische Verknüpfen von Nicht-GPL-Code mit GPL-Code. Was ist es also, wenn der betreffende Code überhaupt nicht verlinkt ist, weil der Code in einer interpretierten Sprache (zB Perl) geschrieben ist?

Es scheint zu einfach zu sein, die Regel auszunutzen, wenn sie als dynamische Verknüpfung angesehen wird. Andererseits scheint es auch unmöglich zu sein, GPL-Code von Nicht-GPL-Code legal zu referenzieren, wenn sie als statisch angesehen wird! Kompilierte Sprachen unterscheiden zumindest zwischen statischen und dynamischen Verknüpfungen. Wenn jedoch bei allen "Verknüpfungen" nur Skripte ausgeführt werden, ist es unmöglich zu sagen, was beabsichtigt ist, ohne eine explizite Lizenz!

Oder ist mein Verständnis dieses Problems falsch, was die Frage zur Diskussion stellt? Ich habe auch von einer "Klassenpfad-Ausnahme" gehört, die dynamisches Verknüpfen beinhaltet. Ist das nicht Teil der GPL, sondern kann etwas hinzugefügt werden, sodass dynamisches Verknüpfen nur zulässig ist, wenn die Lizenz diese Ausnahme enthält?



2
@delnan lgpl! = gpl
Johann

Antworten:


16

In Bezug auf die spezifischen Fragen zu den interpretierten Sprachen ist die GPL-FAQ sehr klar :

Das interpretierte Programm ist für den Interpreter nur Daten; Eine freie Softwarelizenz wie die GPL, die auf dem Urheberrecht basiert, kann nicht einschränken, auf welchen Daten Sie den Dolmetscher verwenden. Sie können es auf beliebigen Daten ausführen (interpretiertes Programm), wie Sie möchten, und es gibt keine Anforderungen für die Lizenzierung dieser Daten an Dritte.

Als allgemeine Frage über dynamische vs statische Verknüpfung. Zuallererst ist die Ansicht von FSF und Stallman, dass es egal ist, ob die Verknüpfung statisch oder dynamisch ist, die GPL infiziert sie in beide Richtungen. Aus der FSF GPL FAQ:

Wenn das Programm Plug-Ins dynamisch verknüpft , Funktionsaufrufe vornimmt und Datenstrukturen gemeinsam nutzt, bilden sie unserer Ansicht nach ein einziges Programm, das als Erweiterung des Hauptprogramms und der Plug-Ins behandelt werden muss. Dies bedeutet, dass die Kombination des mit der GPL abgedeckten Plug-Ins mit dem nicht freien Hauptprogramm die GPL verletzen würde.

und

Durch statisches oder dynamisches Verknüpfen von [Name Ihres Programms] mit anderen Modulen wird eine kombinierte Arbeit basierend auf [Name Ihres Programms] erstellt. Somit decken die Bedingungen der GNU General Public License die gesamte Kombination ab

Dies ist jedoch aus rechtlicher Sicht fraglich. In dem einzigen Fall, der tatsächlich wegen dynamischer Verlinkung vor Gericht ging, entschied Galoob gegen Nintendo - Court of Appeals, dass abgeleitete Werke "einen Teil der urheberrechtlich geschützten Werke in irgendeiner Form enthalten müssen" . Was bei dynamischer Verlinkung nicht der Fall ist.

Unabhängig davon, ob dynamische Verknüpfungen tatsächlich infizieren oder nicht, gibt es eine Problemumgehung. Es wird zum Beispiel von Nvidia verwendet, um Binärtreiber für Linux bereitzustellen. Sie erstellen einen (L) GPL-Wrapper, aber als Autor dürfen Sie eine spezielle Ausnahme hinzufügen, um eine Verknüpfung mit einer bestimmten geschlossenen Quelle herzustellen. Vide FSF GPL FAQ .


Eine der Naturen eines abgeleiteten Werks ist, dass es nicht möglich ist, das Werk des ursprünglichen Urheberrechtsinhabers sauber zu trennen. Wenn Bob's Foo()statisch mit Call Joe's verbunden Bar()ist, welchem ​​Copyright-Inhaber sollte die CALLAnweisung zwischen beiden zugerechnet werden? Eine solche Interaktion würde ausreichen, um eine "abgeleitete Arbeit" zu bilden. Wenn jedoch Joes Arbeit vollständig in einer Datei und Bobs Arbeit vollständig in einer anderen Datei verbleibt, stellt das bloße Erscheinen dieser Dateien in verschiedenen Verzeichnissen auf derselben Festplatte eine Aggregation und keine Ableitung dar.
Supercat

2
@thepaul: Es gibt bereits einen rechtlichen Präzedenzfall, der besagt, dass mindestens ein Teil der urheberrechtlich geschützten Werke in einem Werk enthalten sein muss, um abgeleitete Werke zu bilden. Die Überzeugungen von Stallman haben im tatsächlichen wirklichen Recht oft nur eine sehr geringe Grundlage.
Vartec

1
@thepaul: auf der einen Seite haben Sie Rechtspraxis von 9 Milliarden Dollar Unternehmen, auf der anderen Seite Ansprüche von Kerl, der Alufolien Hut tragen mag. Sie behaupten, dass das letztere zuverlässiger ist, und Sie haben völlig das Recht, dies zu glauben.
Vartec

1
Sie zitieren den falschen Teil der GPL FAQ ist sehr klar . Der Teil, über den Sie zitieren Wenn ein Programmiersprachen-Interpreter unter der GPL veröffentlicht ist, bedeutet das, dass Programme, die von ihm interpretiert werden sollen, unter GPL-kompatiblen Lizenzen stehen müssen? ! Daher der an den [GPL-lizenzierten] Interpreter . Der relevante Teil sind die letzten beiden Absätze: [...] Ein anderer ähnlicher und sehr häufiger Fall ist, Bibliotheken den Interpreter zur Verfügung zu stellen, der selbst interpretiert wird. Perl wird zum Beispiel mit vielen Perl-Modulen [...] ausgeliefert
Chris Wesseling,

1
«Das interpretierte Programm ist für den Interpreter nur Daten; Eine freie Softwarelizenz wie die GPL, die auf dem Urheberrecht basiert, kann nicht einschränken, auf welchen Daten Sie den Dolmetscher verwenden. Sie können es auf beliebigen Daten ausführen (interpretiertes Programm), wie Sie möchten, und es gibt keine Anforderungen für die Lizenzierung dieser Daten an Dritte. Was nicht das Thema der Verwendung eines nicht-libre-Plugins in einem GPL-Programm in einer interpretierten Sprache abdeckt.
Tuxayo

4

Hinweis: Dies ist eine rechtliche Frage. Programmers.SE ist kein juristisches Forum, sondern ein Programmierforum. Während die Leute hier einiges über Programmierung wissen, wissen sie nichts über das Gesetz. Wenn Sie eine juristische Frage stellen möchten, sollten Sie dies in einem juristischen Forum tun, in dem es Leute gibt, die tatsächlich etwas über das Thema wissen.


Die GPL sagt nichts über statische oder dynamische Verknüpfungen aus. Es ist nicht einmal etwas sagen über die Verknüpfung überhaupt . Jeder Anwalt oder Richter, mit dem ich gesprochen habe, sagt, dass das Problem der statischen und dynamischen Verknüpfung völlig irrelevant ist.

Beim Urheberrecht geht es um Kreativität. Statische vs. dynamische Verknüpfung ist ein Detail der technischen Implementierung. Ob etwas statisch oder dynamisch verknüpft ist oder nicht, ist keine kreative Handlung, sondern kann möglicherweise den Copyright-Status eines Werks ändern.

In Ihrer Frage sprechen Sie von "interpretierten Sprachen". Aber dieser Begriff ergibt keinen Sinn: Es gibt keine interpretierte Sprache. Eine Sprache ist ein abstrakter Satz mathematischer Regeln und Einschränkungen. Eine Sprache wird nicht interpretiert oder kompiliert. Eine Sprache einfach ist . Der Begriff "interpretierte Sprache" ist nicht nur falsch , sondern auch unsinnig . Wenn Englisch eine getippte Sprache wäre, wäre dies ein Tippfehler.

Interpretation und Kompilierung sind Merkmale des Interpreten oder Compilers (duh!), Nicht der Sprache. Jede Sprache kann mit einem Interpreter implementiert werden, und jede Sprache kann mit einem Compiler implementiert werden. Die meisten Sprachen haben beides. Die meisten modernen Sprachimplementierungen kombinieren sogar beides in einer einzigen Ausführungsmaschine.

Die Rubinius Ruby-Implementierung enthält zum Beispiel einen statischen Voraus-Compiler, der Ruby-Code in Rubinius-Byte-Code kompiliert, einen Interpreter, der Rubinius-Byte-Code interpretiert, und einen dynamischen Just-in-Time-Compiler, der Rubinius-Byte-Code in LLVM kompiliert IR, das die LLVM-Infrastruktur wiederum zu systemeigenem Maschinencode kompiliert. Die MacRuby Ruby-Implementierung enthält überhaupt keinen Interpreter. Sie kompiliert Ruby-Code direkt in LLVM IR und anschließend in systemeigenen Computercode.

Auf der anderen Seite gibt es Interpreter für C oder C ++.

All dies sind nur technische Details. Es ist für das Urheberrecht völlig irrelevant.

Es macht einfach keinen Sinn, ob jemand das Urheberrecht eines anderen verletzt oder nicht, hängt davon ab, ob eine dritte Person das Programm mit einem Interpreter ausführt oder es zuerst kompiliert.

Die Frage ist, ob ein Werk von einem anderen Werk abgeleitet ist oder nicht. Es kann dynamisch verknüpft und dennoch abgeleitet werden, und es kann statisch verknüpft und überhaupt nicht abgeleitet werden.


Was ist mit interpretierten "Intermediate Code" -Sprachen? Einer der Grundsätze der GPL ist, dass jeder das Programm an jeden vernünftigen Computer anpassen kann, auf dem die gleichen Sprachwerkzeuge wie im Original verfügbar sind. Wenn jemand den Quellcode für einen Interpreter für Zwischencodes freigibt, zusammen mit einer Reihe von Code für Zwischenformulare, die ausgeführt werden können, welche Regeln gelten für die Freigabe von Informationen zu diesem Zwischencode-Blob? Im Gegensatz zu kompilierten ausführbaren Dateien, die maschinenspezifisch sind, wäre der Intermediate-Code-Blob vollständig portierbar.
Supercat

Es tut uns leid; Ich wollte auf stackoverflow.com fragen, und es schlug vor, dass ich stattdessen hier frage, als ich das Tag "gpl" verwendete! Ist diese Art der Diskussion auch hier verboten? exec ("killall -9 lawyer"); : D
Ekolis

Und ja, ich stimme zu, dass es keinen Sinn macht, dass ein Implementierungsdetail keinen Einfluss auf den rechtlichen Status der Wiederverwendung hat. Ich dachte nur, dass es einen solchen Unterschied gibt und bat um Klarstellung!
Ekolis

2
@ekolis: es ist nicht per se verboten. Es ist nur keine gute Idee, juristische Fragen von Leuten zu stellen, die nichts über rechtliche Fragen wissen (wie zum Beispiel Programmierer), wenn es Leute gibt, die über rechtliche Fragen Bescheid wissen (auch bekannt als Anwälte), die Sie stattdessen fragen könnten. Ich habe nichts gegen Anwälte, ganz im Gegenteil. Aber ich würde keinen um einen Algorithmusrat bitten, und ich würde auch keinen Programmierer um einen Rechtsrat bitten.
Jörg W Mittag

IANAL: Es mag ein technisches Detail sein, aber es macht immer noch einen großen Unterschied, weil es die rechtlich relevante Verteilung verändert. Mit der statischen Verknüpfung erstellen Sie ein kombiniertes Werk, das gemäß den Regeln der GPL nicht außerhalb der GPL verteilt werden kann. Bei dynamischer Verknüpfung können Sie dies auch tun, z. B. wenn Sie die Bibliotheken mit Ihrer Software in eine ZIP-Datei packen. Mit dynamischer Verknüpfung können Sie es jedoch auch ohne die Bibliotheken verteilen, und es ist zu 100% Ihre Arbeit, auch wenn es nicht von alleine funktioniert. Natürlich können Sie die Bibliotheken auch weiterhin unter der GPL anbieten.
Flarn2006

0

Keine Ahnung, wie viel Wahrheit darin steckt, und IANAL usw .; Bei meiner Interpretation ist es jedoch wichtig, ob die Bibliothek, mit der Sie verknüpfen, in irgendeiner Form in der "Binärdatei" enthalten ist (wobei "Binärdatei" im Fall dynamischer Programmiersprachen nur der verteilte Quellcode ist) was ich von der FSF-Definition von "binär" in diesem Zusammenhang halte).

Wenn Sie also Bibliotheken aus Ihrem Code referenzieren, ohne sie in Ihre Distribution aufzunehmen, würde ich dies als "dynamisches Verknüpfen" bezeichnen, wohingegen Sie, wenn Sie die Bibliotheken mit Ihrem Produkt bündeln oder Teile der Bibliothek in Ihren eigenen Code kopieren, Das Szenario "statische Verknüpfung" würde zutreffen. Dies liegt zumindest im Geiste der GPL: Sie können die GPL- Software ohne Einschränkungen frei verwenden (ausführen, überprüfen, referenzieren), aber sobald Sie sich daraus ableiten (indem Sie Teile davon verknüpfen oder in Ihre GPL kopieren) eigene vertreibbare Produkt), es geht viral, und Ihre Software muss auch GPL sein.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.