Das deutsche Python-Forum

Hallo Community,

da ich die Programmierung in der Konsole und auch mit Tk bereits gut beherrsche,
wurde es zeit, mich in GUI-Toolkits einzuarbeiten. Da mich Wx und Gtk nicht
überzeugten, mich pyQt jedoch ansprach, entschied ich mich also dafür.

Nun ist pyQT GPL, also fiel mein Hauptaugenmerk auf pySide (LGPL). Das erste kleine
Programm lief, auch das kompilieren mittels py2exe verlief problemlos.Nun bin ich mir
jedoch auch hier unsicher, was die Lizenz anbelangt. So soll/muss die Möglichkeit
gegeben sein, die Bibliothek dynamisch einzubinden und austauschbar zu machen.
Quelle:
http://www.it-rechts-praxis.de/meldunge ... braries-12

Wie kann ich dies nun bewerkstelligen, also PySide dynamisch einbinden und sogar
austauschbar machen? Oder ist es bereits dynamisch eingebunden? Wie kann ich es
in diesem Falle durch ggf. neue Versionen ersetzen (Welche Dateien müssen ersetzt
werden)?

Würde mich über Ratschläge und Tutorials freuen, Gruß

der snowpanther

@snowpanther: Python-Bibliotheken werden immer dynamisch eingebunden. Statische Bindung gibt es in Python nicht.

@lunar: Die interessante Frage ist doch hier aber wie sich das verhält wenn man alles in *eine* EXE verpackt. Selbst erfahrene Programmierer werden die Bibliothek dann nicht so einfach austauschen können.

nun: zumindest das Einbinden scheint dann wohl einfacher zu sein, als ich es mir
vorstellte.

@BlackJack

aber wie sich das verhält wenn man alles in *eine* EXE verpackt.
Selbst erfahrene Programmierer werden die Bibliothek dann nicht so einfach austauschen können.

Genau das ist jetzt das Hauptproblem, denn nach LGPL soll diese Bibliothek einfach austauschbar
sein, mehr noch: Es muss eine Dokumentation beiliegen die den Austausch erklärt.




Zum Vergleich habe ich einmal eine Distribution mit und ohne pySide erstellt.
Daraus konnte ich erkennen, welche Dateien pySide in der Distribution
hinzufügt: (mit py2exe erstellt)

PySide.QtCore.pyd
PySide.QtGui.pyd
PySide.QtNetwork.pyd
pyside-python2.6.dll
QtCore4.dll
QtGui4.dll
QtNetwork4.dll
shiboken-python2.6.dll

und in der zip „library“ in einem Ordner „PySide“ die Dateien:
__init__.pyc
QtCore.pyc
QtGui.pyc
QtNetwork.pyc



Ich gehe mal davon aus, dass QtCore und QtGui von meiner Zeile im Quellcode
„from PySide import QtGui, QtCore“ herrühren. Sind die restlichen Dateien immer
dieselben wenn nichts weiter eingebunden würde?

@snowpanther: Also ganz ausführlich:

§6 der LGPL 2.1 regelt, wie ein Werk, welches eine Bibliothek nutzt, zusammen mit dieser Bibliothek verteilt werden darf. Dort sind im Wesentlichen zwei verschiedene Möglichkeiten genannt:

a) Weitergabe des Quelltexts oder des Objektcodes des Werks zusammen mit dem Quelltext der Bibliothek.
b) Benutzung dynamischen Linkens gegen systemweit installierte Bibliotheken, so dass der Benutzer die Bibliothek austauschen kann.

Bei der Verwendung von py2exe bleibt Dir nur Punkt a), da der Sinn von py2exe ja gerade darin besteht, dass Du PySide nicht systemweit installieren musst. Du musst also entweder den Quelltext Deiner Anwendung weitergeben, oder die „Rohform“, die als Eingabe für py2exe dient. Wichtig ist, dass Du dabei nicht nur PySide, sondern auch py2exe ausliefern musst, da die Lizenz verlangt, dass alle nötigen Tools ebenfalls zur Verfügung gestellt werden.

Die Lizenz verlangt allerdings nicht, dass Du diese Dinge zusammen mit Deinem Programm auslieferst. Vielmehr gestattet Dir §6d), all dies gesondert zu verteilen, unter der Vorraussetzung, dass der Zugang zu diesen Materialen an derselben Stelle möglich ist. Sprich, bietest Du Dein Programm zum Download an, musst Du diese Materialien auf derselben Seite ebenfalls zum Download anbietet.

Bezogen auf Deinen Fall bedeutet das, dass Du problemlos das py2exe-Kompilat Deiner Anwendung ohne zusätzliche Dateien weitergeben darfst, sofern Du jedem Nutzer Deines Programms Zugang entweder zum Quelltext oder zur py2exe-„Rohform“ gibst. Zudem musst Du den Benutzer mindestens noch auf PySide und py2exe verweisen. Möchtest Du ganz sicher sein, solltest Du beides im Quelltext auch auf Deiner Seite zum Download anbietet.

Wie genau diese „Rohform“ aussehen könnte, kann ich Dir mangels py2exe-Erfahrung nicht sagen. Wenn ich mich richtig erinnere, bietet py2exe neben der Erzeugung einer EXE-Datei auch die Möglichkeit, einfach alle Abhängigkeiten in ein Verzeichnis zu packen. Ein ZIP-Archiv dieses Verzeichnisses könnte dann als „Objektcode“ im Sinne der LGPL-2.1 gelten, und dementsprechend §6a) erfüllen.

Ich rate Dir allerdings dazu, einfach den Quelltext Deiner Anwendung freizugeben. Das muss nicht unter einer freien Lizenz geschehen (auch wenn das natürlich wünschenswert wäre), sofern diese Lizenz das Verändern des Werks für eigene Zwecke, den Austausch von PySide, sowie das Reverse Engineering zum Debuggen dieser Änderungen gestattet.

Wie Du darauf kommst, Du müsstest Dokumentation zum Austausch der Bibliothek beifügen, erschließt sich mir nicht. Ich kann im Text der LGPL 2.1 keine Klausel finden, die derartiges verlangt.

Wow, da hast Du dir wirklich viel Arbeit gemacht, Danke!

Nach §6.a muss der Benutzer die Bibliothek verändern und neu linken können. Der in klammern angefügte Abschnitt
an §6.a beschreibt, dass Benutzer hierzu nicht zwangsweise in der Lage sind. Von zahlreichen Juristen wird das
wohl als Aufforderung für eine Dokumentation gewertet (ich kann es auch nicht wirklich herauslesen). Jedoch konnte
ich dies öfter in Diskussionen und Artikeln rund um die LGPL lesen, wie z.B. hier:

„Es muß dokumentiert werden, wie ein Programmlauf mit einer modifizierten Version der LGPL-Library (s.o.) möglich ist.“
Quelle: TCI Rechtsanwälte (30.04.12):
http://www.it-rechts-praxis.de/meldunge ... braries-12
Eine solche Dokumentation ist auch weniger das Problem, denn wenn ich weiß (wüsste ) wie es geht, ist die
Dokumentation nur eine Formalität.

Das py2exe etc. mit ausgeliefert werden müssen, lässt sich durch §6.c umgehen. Hiernach genügt es auch ein schriftliches
Angebot zu unterbreiten, die benötigten Materialien zu Eigenkosten (CD-Rohling, Arbeitszeit, Strom, geringe Gewinnspanne
soll auch legitim sein) bereit zu stellen. Da das Programm nicht für den Massenmarkt gedacht ist und nur eine geringe Stückzahl
angedacht ist, besteht hier kein Problem.

Die Offenlegung des Quelltextes ist leider keine Option.
Bisher kenne ich es nur so, dass man mittels py2exe die Python-Dateien mit allen Bibliotheken zu einem Programmordner mit exe
erstellt. (Bin was das kompilieren angeht unerfahren, da bisher immer alles quell-offen gewesen ist). Allerdings beißt sich die Katze
da in den Schwanz, denn auch hier liegen wieder einsehbare Pythondateien zugrunde. Es müsste also einen Weg geben, erst
die Pythondateien zu kompilieren (die dann mit ausgeliefert werden können) und hinzu, ggf. später, die PySide Bib zu kompilieren.
Ich bin mir nicht sicher ob Du das mit den Abhängigkeiten im Verzeichnis meintest(? ).


Im Allg. kann man das Problem nun wie folgt beschreiben:
Wie bindet man eine LGPL-Bibliotheke in ein proprietäres Projekt ein, ohne den Quellcode öffentlich zu machen,
bzw. wie gestaltet man die LGPL-Bibliothek austauschbar?

@snowpanther: Vorweg: Ich kenne mich mit py2exe nicht aus.

Du könntest versuchen den pyside/Qt-Teil nicht mit in die EXE zu packen, sondern ausserhalb davon belassen. Zum Beispiel in einem Unterordner der auf der Ebene der EXE liegen muss. Dann wäre es für Benutzer relativ leicht das auszutauschen.

Ich denke ich habe soeben einen Weg gefunden:

Die erste Pythondatei ist nahezu leer, ruft eine Funktion in
einer anderen Datei auf. Von dort werden weitere Dateien
eingebunden etc. etc, das übliche halt.

py2exe kann auch mit pyc arbeiten, d.h.: ich mache
eine "Distribution", in der alle py-Dateien außer der Startdatei
*.pyc sind, die *.py werden entfernt.

Diese Distribution wird zusammen mit der für py2exe benötigten
Setupdatei, PySide py2exe und python ausgeliefert. Wer also die PySide
ersetzen will, muss einfach nur sein neues PySide installieren
und kann dann mittels der setup.py eine neue Version erstellen.


Mglw. ist das aber auch alles viel zu einfach gedacht (ist ja schon früh),
also werde ich Morgen nochmal darüber nachdenken, ob das wirklich
alles so clever ist

@snowpanther: Warum nimmst Du die Startdatei davon aus? CPython kann man auch *.pyc Dateien direkt zum Ausführen übergeben.

Bei mir ist py2exe nicht in der Lage gewesen eine Distribution
mit einer *.pyc als Startdatei zu erzeugen. Vlt war ich es auch
nicht Der offene Quellcode der Startdatei ist auch nicht
weiter schlimm, da dort eh nur zwei Zeilen Quellcode und ein langer
Vermerk enthalten sind.

Wichtig ist nun, ob es LGPL-konform ist, da es ja kein direkter Austausch
der Bibliothek, sondern das Erstellen einer neuen Distribution wäre.

@snowpanther: Vorweg: Deine Frage, ob Deine nun vorgestellte Lösung konform zur LGPL 2.1 ist, wird Dir hier niemand direkt und abschließend beantworten können. Niemand hier ist Jurist, mithin kann niemand hier juristisch einwandfreie Bewertungen abgeben. Möchtest Du eine echte Bewertung der rechtlichen Situation, dann frage Deinen Anwalt!

Der in Klammern angefügte Abschnitt in der LGPL 2.1 stellt meines Erachtens lediglich klar, dass es keinen Lizenzbruch darstellt, wenn das Programm nicht mit einer in inkompatibler Weise modifizierten Version der Bibliothek nicht neu kompiliert werden kann. Soll heißen, wenn der Nutzer aus PySide Klassen entfernt, die in Deinem Programm verwendet werden, kann er natürlich nicht mehr erwarten, dass Deine Anwendung trotzdem mit der veränderten Version von PySide läuft.

Eine Pflicht zur Dokumentation gibt es in der LGPL 2.1 nicht, wohl aber in der nachfolgenden Version 3 dieser Lizenz, siehe LGPL 3, §4e). Der von Dir verlinkte Artikel versäumt es leider, die Version, auf welche er sich bezieht, explizit zu benennen, meines Erachtens ein grober handwerklicher Fehler angesichts der Vielzahl von Versionen und Varianten der LGPL. Man kann dem Inhalt allerdings entnehmen, dass er sich auf Version 3 bezieht, unter anderem auch weil der eben diese Pflicht zur Dokumentation explizit erwähnt.

PySide allerdings ist explizit unter Version 2.1 der LGPL lizenziert, so dass Klauseln der LGPL 3 ohne Bedeutung sind, sofern Du bei Deiner Verwendung von PySide die LGPL 2.1 zugrunde legst. Du darfst selbstverständlich nicht aus LGPL 2.1 und LGPL 3 immer nur diejenigen Klauseln herauspicken, welche Dir gefallen

Wenn Du nach §6c ein schriftliches Angebot unterbreitest, die nötigen Materialen zu verteilen, so darfst Du vom Kunden meiner Ansicht nach nur den Ersatz für Aufwendungen zur Durchführung der Verteilung verlangen:

Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.

Eine geringe Gewinnspanne ist nach LGPL 2.1 meiner Meinung nach nicht gestattet. Und da „performing this distribution“ sehr schwammig ist, würde ich persönlich im Zweifelsfall schon davon absehen, „weiche“ Kosten, die sich nicht unmittelbar in Bezug zur Verteilung setzen lassen, wie beispielsweise Strom oder Arbeitszeit, mit einzuberechnen. Dir muss auch klar sein, dass Du Dich mit einem solchen Angebot gemäß des Lizenztexts drei Jahre lang bindest!

Wichtig ist auch, dass die Lizenz Deines Programms gestattet, das Programm mit einer veränderten Version von PySide zu binden (i.e. per py2exe zu packen) und auszuführen, und zusätzlich das Reverse Engineering zum Zwecke des Debuggens erlaubt, siehe LGPL 2.1 §6, erster Absatz. Das muss nach deutschen Recht explizit geschehen! Insbesondere darf Deine Lizenz auch nicht Debugging oder Dekompilieren explizit und allgemein ausschließen, wie das bei vielen vorgefertigten Lizenzen der Fall ist. Und natürlich bietet diese Anforderung der LGPL 2.1 Deinen Kunden ein gutes Schlupfloch, um unter dem Vorwand des Debuggens mithilfe eines Dekompilers an den Quelltext zu gelangen.

Dazu eine technische Anmerkung: Du scheinst davon auszugehen, dass das Kompilieren von Python-Dateien in Bytecode nennenswerten Schutz gegen Einblicke in den Quelltext gibt. Das ist nicht der Fall. Bytecode ist sehr abstrakt, und theoretisch sehr leicht wieder in äquivalenten Python-Quelltext umzuwandeln. Entsprechende Tools finden sich im Netz (beispielsweise uncompyle), und es gibt iirc auch mindestens einen kommerziellen Dekompiler-Service. Wenn Deine Kunden also ernsthaftes Interesse an Deinem Quelltext haben, dann kommen sie auch dran, selbst wenn Du nur PYC-Dateien auslieferst. Selbst ein py2exe-Kompilat ist verhältnismäßig einfach auseinander zu nehmen, schon weil py2exe selbst freie Software ist.

Vielen Danke, für die Informationen.
Ich denke weitere Schritte müssten wirklich mit einem fach-kompetenten Anwalt
geklärt werden. Das schriftliche Angebot ist kein Problem, auch eine Bindung über
3 Jahre stellt kein Problem dar und liefert mir im Gegenzug Informationen darüber,
wer versucht das Programm zu verändern.

Das Python-Bytecode zu anderen Programmiersprachen verhältnismäßig einfach
zu "knacken" ist, ist mir leider schon eine Weile bewusst. Hier bietet es sich an,
besonders schützenswerten Code in C/C++ unterzubringen.
(Allerdings schützt auch dies nicht hundertprozentig.)
Ich denke jedoch, dass diese Maßnahme zumindest das Kriterium erfüllt, dass dem
Kunden, der die Absicht hat die Software in einer von mir nicht akzeptierten Weise zu
verändern, der Quellcode nicht auf einem Silbertablett überreicht wird.


Abschliessend für alle, die vor dem selben Problem standen (LGPL in Python einbinden)
und es beim Lesen bis hier hin geschafft haben:
Für py2exe können die py-Dateien wie folgt in pyc (also Binärcode) übersetzt werden:

Pythondatei im selben Verzeichnis erstellen und ausführen:

@snowpanther: Nicht zum Thema; eher eine Formfrage Deiner Beiträge: Du scheinst da selbst Zeilenumbrüche innerhalb der Absätze zu machen. Damit passt sich Dein Text nicht mehr der Breite des Browserfensters an. Ist das breiter entsteht ungenutzter Leerraum, ist es schmaler dann entsteht ein unangenehm lesbares „Kammmuster”. In Zeiten von grossen und vor allem breiten Bildschirmen, und kleinen Smartphone-Bildschirmen sollte man es dem Browser beziehungsweise dessen Benutzer überlassen wie breit er seine Texte gerne haben möchte.

Und hier nochmal die ganz simple Lösung: PyQt lizensieren, Problem gelöst. Riverbank ist ja auf genau so seltsame Anwendungsfälle wie proprietäre Applikationen angewiesen. Dann muss du dir zu GPL etc. keine Gedanken machen, höchstens noch auf der Ebene von Qt selbst, aber dass kannst du ja dann mit Riverbank besprechen, die machen das ja nicht zum ersten Mal.

@Leonidas: Riverbank wird in diesem Fall auf eine Qt-Lizenz verweisen (müssen), dementsprechend wird Versuch, sich aus den Verpflichtungen der LGPL vollständig freizukaufen, verhältnismäßig teuer.

lunar hat geschrieben:@Leonidas: Riverbank wird in diesem Fall auf eine Qt-Lizenz verweisen (müssen), dementsprechend wird Versuch, sich aus den Verpflichtungen der LGPL vollständig freizukaufen, verhältnismäßig teuer.

Qt Commercial wird momentan von Digia vertrieben, es lohnt sich vielleicht da (und auch bei Riverbank, die haben da sicherlich Kontakt) anzufragen. Als Qt von Trolltech gemanaged wurde wars verhältnismäßig teuer (wobei, vermutlich immer noch günstiger als mehrere Tage Arbeitszeit und eventueller Rechtsstreit), ob sich das seit Nokia oder Digia geändert hat ist eben die Frage. Ich werf das nur mal so in den Raum, da der OP eine proprietäre Nutzung im Sinne hat und sich zumindest mal informieren kann. Weil die Möglichkeit einer proprietären Lizenz gibt es sowohl bei Qt als auch bei PyQt. Mehr verlieren als ein paar Mails kann man ja eh nicht, und ansonsten kann man die Meinung der Rechtverwalter der genutzten Werke einholen, das ist schon auch was, denke ich.

@Leonidas: Seitdem sowohl PySide als auch Qt unter dem Dach von Qt-Project sind, gibt nicht mehr den Rechtverwalter.

lunar hat geschrieben:@Leonidas: Seitdem sowohl PySide als auch Qt unter dem Dach von Qt-Project sind, gibt nicht mehr den Rechtverwalter.

Und won wem lizensiert man dann Qt Commercial? Ich dachte das wäre Digia?

@Leonidas: Schon. Ich hatte Deine Bemerkung bezüglich der Meinung der Rechteverwalter allerdings so verstanden, dass man bei PySide oder Qt selbst fragt, ob man die LGPL-Version richtig verwendet. Und bezüglich der freien Versionen gibt es keinen authoritativen Rechteverwalter mehr. Da kann jeder einzelne Entwickler Verletzungen geltend machen.