Lizenzfragen
Lizenzfragen
Hallo,
ich habe eine Frage zur Lizenz von Qt. Leider ist das mit den ganzen Lizenzen, was man darf - was man nicht darf, ein bisschen verwirrend.
Ich habe jetzt gelesen, dass Qt unter der GPL und der LGPL angeboten wird. Das heißt, ich darf Qt kostenlos nutzen (nicht kommerziell)?
Angenommen, ich biete ein Programm an, OpenSource oder kostenlos, muss ich Qt dann im Programm nennen? Oder die Lizenz nur beilegen?
Schonmal vielen Dank,
Amgon
ich habe eine Frage zur Lizenz von Qt. Leider ist das mit den ganzen Lizenzen, was man darf - was man nicht darf, ein bisschen verwirrend.
Ich habe jetzt gelesen, dass Qt unter der GPL und der LGPL angeboten wird. Das heißt, ich darf Qt kostenlos nutzen (nicht kommerziell)?
Angenommen, ich biete ein Programm an, OpenSource oder kostenlos, muss ich Qt dann im Programm nennen? Oder die Lizenz nur beilegen?
Schonmal vielen Dank,
Amgon
Lizenzfragen
Das Thema wurde wohl schon oft diskutiert. Nur leider ohne das Ergebnis, das ein Fragesteller sich erhofft hat. Und natürlich bewegen sich hier Entwickler, und i.d.R. keine Juristen.
Ich habe in diesem Forum etliche Threads zu diesem Thema durchgeschaut, und habe (vor meiner Anmeldung im Forum) "ausgibigst gegoogelt" (ohne wirklich etwas Verständliches und "Abgesichertes" zu finden). (Also bitte keine Antwort wie "Google doch mal ..." )
Daher ist die Frage von Amgon nach wie vor relevant. Was darf ich, was nicht, mit GPL oder LGPL, ...
Ich habe die GPL so verstanden, dass ich Programme, die ich mit Komponenten entwickle, die unter der GPL stehen, im Quellcode offen legen muss.
Die LGPL verstehe ich so, dass ich ein Programm, das ich mit den Qt entwickle, als solches nicht im Quellcode offenlegen muss, sofern ich mit den Qt dynamisch linke, die also als DLL (ich bin halt mal z.Zt. nur unter Windows unterwegs) verwende.
Soweit stimmt auch ein alter Kollege von mir mit überein, allerdings ist der in der Linux-Welt unterwegs.
Nun, die LGPL sagt meinem Verständnis nach aus, dass ich durchaus in meinem Closed-Source Programm (also ohne Offenlegung des Quellcodes) eine Bibliothek, die unter der LGPL steht, verwenden darf. Sofern der Endanwender die verwendete Bibliothek (eben die Qt) durch eine andere Qt-Bibliothek ersetzen kann.
Nun frage ich mich aber, wie ist das mit den verwendeten Compilern/Linkern?
In der Open-Source Welt ist das sicherlich mingw unter Windows. Aber was, wenn nun meine Applikation (sprich "Exe"cutable) mit einem Micrisoft Compiler/Linker erstellt wurde? Dann würde ja der Austausch einer unter LGPL compillierten DLL (die ja in der Windows Welt auf mingw aufsetzt) die Voraussetzungen der LGPL nicht mehr erfüllen.
Auch ich wäre dankbar für produktiven Feedback, auch wenn das Thema schon in vielen Varianten im Forum angesprochen wurde.
Ich habe in diesem Forum etliche Threads zu diesem Thema durchgeschaut, und habe (vor meiner Anmeldung im Forum) "ausgibigst gegoogelt" (ohne wirklich etwas Verständliches und "Abgesichertes" zu finden). (Also bitte keine Antwort wie "Google doch mal ..." )
Daher ist die Frage von Amgon nach wie vor relevant. Was darf ich, was nicht, mit GPL oder LGPL, ...
Ich habe die GPL so verstanden, dass ich Programme, die ich mit Komponenten entwickle, die unter der GPL stehen, im Quellcode offen legen muss.
Die LGPL verstehe ich so, dass ich ein Programm, das ich mit den Qt entwickle, als solches nicht im Quellcode offenlegen muss, sofern ich mit den Qt dynamisch linke, die also als DLL (ich bin halt mal z.Zt. nur unter Windows unterwegs) verwende.
Soweit stimmt auch ein alter Kollege von mir mit überein, allerdings ist der in der Linux-Welt unterwegs.
Nun, die LGPL sagt meinem Verständnis nach aus, dass ich durchaus in meinem Closed-Source Programm (also ohne Offenlegung des Quellcodes) eine Bibliothek, die unter der LGPL steht, verwenden darf. Sofern der Endanwender die verwendete Bibliothek (eben die Qt) durch eine andere Qt-Bibliothek ersetzen kann.
Nun frage ich mich aber, wie ist das mit den verwendeten Compilern/Linkern?
In der Open-Source Welt ist das sicherlich mingw unter Windows. Aber was, wenn nun meine Applikation (sprich "Exe"cutable) mit einem Micrisoft Compiler/Linker erstellt wurde? Dann würde ja der Austausch einer unter LGPL compillierten DLL (die ja in der Windows Welt auf mingw aufsetzt) die Voraussetzungen der LGPL nicht mehr erfüllen.
Auch ich wäre dankbar für produktiven Feedback, auch wenn das Thema schon in vielen Varianten im Forum angesprochen wurde.
@Urmeli
Ich seh einiges anders, hab aber eben die selben "Beschraenkungen" wie Du. Ich bin kein Jurist, und das was ich im Inet lese kann man xfach auslegen, was richtig greifbares find ich auch ned
Verwendet jemand die GPL, müssen theorethisch alle die das oder Teile davon verwenden, ebenfalls unter die GPL.
Kannst du aus einer qt Application die QT ersetzen, ohne neuzukompilieren ? Nein ! IMHO wirst du die LGPL-QT nie direkt an ein Programm binden koennen (egal ob dynamisch oder statisch) was selber nicht unter der GPL / LGPL steht.
IMHO ist die LGPL dafuer gemacht, das du zum besipiel ein "plugin" schreibst .... dieses plugin kann die QT verwenden, das heisst dein plugin kann unter der LGPL stehen.
Dies kann nun ein Programm verwenden, was nicht unter der GPL/LGPL steht, unter der bedingung, das Du keine Klasse von der unter der LGPL stehenden verwendeten bibliothek verwendest (also QString als parameter in der schnittstelle verletzt IMHO den Pasus "dynamisches Binden") und du deine Schnittstelle ausreichend dokumentierst und publizierst, so das man ohne Probleme dein plugin mit einem anderen modul ersetzten koennte, ohne neues kompilieren.
Am Ende sollen mit der LGPL nicht die kommerziellen versionen überfluessig gemacht werden, sondern das entwickeln und verwenden dynamischer erweiterungen für programme, die keine GPL/LGPL kompatible lizenz haben, vereinfacht werden.
Beispielsweisse Musik / video dekoder, wenn die die QT nutzen wuerden und die nur unter der GPL staende, duerften keinerlei komerzielle programme oder richtige freewaere programme die nutzen. ...
Wie gesagt ist nur meine Sicht, Juristen koennten das wiederum anders interpretieren
Ciao ...
Ich seh einiges anders, hab aber eben die selben "Beschraenkungen" wie Du. Ich bin kein Jurist, und das was ich im Inet lese kann man xfach auslegen, was richtig greifbares find ich auch ned
Ich versteh die LGPL wie die GPL, nur das eben die strenge vererbung der lizens aufgebrochen wird.Die LGPL verstehe ich so, dass ich ein Programm, das ich mit den Qt entwickle, als solches nicht im Quellcode offenlegen muss, sofern ich mit den Qt dynamisch linke, die also als DLL (ich bin halt mal z.Zt. nur unter Windows unterwegs) verwende.
Verwendet jemand die GPL, müssen theorethisch alle die das oder Teile davon verwenden, ebenfalls unter die GPL.
Das seh ich auch so, nur das ich die konsequenzen daraus bissi "Haerter" interpretier.Nun, die LGPL sagt meinem Verständnis nach aus, dass ich durchaus in meinem Closed-Source Programm (also ohne Offenlegung des Quellcodes) eine Bibliothek, die unter der LGPL steht, verwenden darf. Sofern der Endanwender die verwendete Bibliothek (eben die Qt) durch eine andere Qt-Bibliothek ersetzen kann.
Kannst du aus einer qt Application die QT ersetzen, ohne neuzukompilieren ? Nein ! IMHO wirst du die LGPL-QT nie direkt an ein Programm binden koennen (egal ob dynamisch oder statisch) was selber nicht unter der GPL / LGPL steht.
IMHO ist die LGPL dafuer gemacht, das du zum besipiel ein "plugin" schreibst .... dieses plugin kann die QT verwenden, das heisst dein plugin kann unter der LGPL stehen.
Dies kann nun ein Programm verwenden, was nicht unter der GPL/LGPL steht, unter der bedingung, das Du keine Klasse von der unter der LGPL stehenden verwendeten bibliothek verwendest (also QString als parameter in der schnittstelle verletzt IMHO den Pasus "dynamisches Binden") und du deine Schnittstelle ausreichend dokumentierst und publizierst, so das man ohne Probleme dein plugin mit einem anderen modul ersetzten koennte, ohne neues kompilieren.
Am Ende sollen mit der LGPL nicht die kommerziellen versionen überfluessig gemacht werden, sondern das entwickeln und verwenden dynamischer erweiterungen für programme, die keine GPL/LGPL kompatible lizenz haben, vereinfacht werden.
Beispielsweisse Musik / video dekoder, wenn die die QT nutzen wuerden und die nur unter der GPL staende, duerften keinerlei komerzielle programme oder richtige freewaere programme die nutzen. ...
Wie gesagt ist nur meine Sicht, Juristen koennten das wiederum anders interpretieren
Ciao ...
Doch kannst Du schon, wenn Du dynamisch linkst und die Qt Bibliothek gegen eine austauscht die binärkompatibel ist.RHBaum hat geschrieben:@Urmeli
Kannst du aus einer qt Application die QT ersetzen, ohne neuzukompilieren ? Nein !
Bitte seid so nett und ändert den Titel von Beiträgen die gelöst wurden, auf [gelöst] Beitragstitel
Naja, die ganzen objecte die ueber die Schnittstelle geschickt werden, binaerkompatibel nachzubauen halt ich fuer ... sehr aufwendig. Ausserdem wird sich von version zu version wieder zeugs aendern. praktikabel halt ich das soweiso ned, aber dafuer iss die qt auch ned gedacht ....Doch kannst Du schon, wenn Du dynamisch linkst und die Qt Bibliothek gegen eine austauscht die binärkompatibel ist.
Ciao ...
Natürlich kann man das (das ist der Sinn der LGPL). Die Bedingungen dafür sind doch in der LGPL deutlich genannt:RHBaum hat geschrieben: IMHO wirst du die LGPL-QT nie direkt an ein Programm binden koennen (egal ob dynamisch oder statisch) was selber nicht unter der GPL / LGPL steht.
Diese Bedingungen sind beim dynamischen Linken gegen QT erfüllt, denn innerhalb derselben Hauptversion (QT3, QT4) sind die Versionen binärkompatibel (selbst wenn sie das nicht wären, würde kein Verstoß gegen die LPGL vorliegen, denn diese verlangt ja nicht, dass ein Austausch gegen eine x-beliebige Version, sondern gegen eine schnittstellen-kompatible Version möglich sein muss).A suitable mechanism is one that
(a) uses at run time a copy of the Library already present on the user's computer system, and
(b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
Du kannst auch selbst ein Programm schreiben, dass gegen QT gelinkt ist und nicht unter GPL/LGPL steht. Siehe oben.RHBaum hat geschrieben:IMHO ist die LGPL dafuer gemacht, das du zum besipiel ein "plugin" schreibst .... dieses plugin kann die QT verwenden, das heisst dein plugin kann unter der LGPL stehen.
Dies kann nun ein Programm verwenden, was nicht unter der GPL/LGPL steht [...]
Natürlich darfst Du die Klassen der LGPL Bibliothek verwenden:unter der bedingung, das Du keine Klasse von der unter der LGPL stehenden verwendeten bibliothek verwendest (also QString als parameter in der schnittstelle verletzt IMHO den Pasus "dynamisches Binden")
Das Ableiten eigener Klassen ist somit dem Verwenden einer durch die Bibliothek bereitgestellten Schnittstelle gleichgestellt. Alles andere wäre auch blödsinnig.Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.
Danke erst mal für das Feedback.
Es ist immer wieder der Begriff "binärkomatibel" genannt worden. Damit bin ich wieder bei einer Frage, die ich ganz zu Anfang hatte.
Wenn ich eben ein "Werk" (wie das so schön heisst), erstelle, das dynamisch gegen die Qt linkt, dann muss der Endbenutzer in der Lage sein, die Qt Bibliotheken durch andere, die natürlich mindestens der Version entspricht, die ich verwendet, und mitgeliefert habe, ersetzbar sein. Also muss er (der Endbenutzer) z.B. die Qt 4.5.0 DLL, die ich mitgeliefert habe, durch eine 4.6.1 ersetzen können, wobei meine Applikation quasi ohne zu zucken "damit können" muss.
Nun erzeuge ich meine Applikation mit einem kostenpflichtigen MS Compiler/Linker. Kann ich dann auf den Endnutzer abwälzen, dass er gefälligst diesen zu nutzen hat, wenn er eine andere Version der Qt mit meiner Applikation verwenden will?
Und, was sicherlich auch von Interesse ist, was ist mit inline Funktionen, die ja über die Header in meiner Applikation reincompilliert ist, wenn sich in irgend einer Klassendefinition der Qt etwas ändert?
Es ist immer wieder der Begriff "binärkomatibel" genannt worden. Damit bin ich wieder bei einer Frage, die ich ganz zu Anfang hatte.
Wenn ich eben ein "Werk" (wie das so schön heisst), erstelle, das dynamisch gegen die Qt linkt, dann muss der Endbenutzer in der Lage sein, die Qt Bibliotheken durch andere, die natürlich mindestens der Version entspricht, die ich verwendet, und mitgeliefert habe, ersetzbar sein. Also muss er (der Endbenutzer) z.B. die Qt 4.5.0 DLL, die ich mitgeliefert habe, durch eine 4.6.1 ersetzen können, wobei meine Applikation quasi ohne zu zucken "damit können" muss.
Nun erzeuge ich meine Applikation mit einem kostenpflichtigen MS Compiler/Linker. Kann ich dann auf den Endnutzer abwälzen, dass er gefälligst diesen zu nutzen hat, wenn er eine andere Version der Qt mit meiner Applikation verwenden will?
Und, was sicherlich auch von Interesse ist, was ist mit inline Funktionen, die ja über die Header in meiner Applikation reincompilliert ist, wenn sich in irgend einer Klassendefinition der Qt etwas ändert?
Ja.. fast... die Sache mit Binärkompatibilität innerhalb einer Major-Version ist nur eine Sache der Trolls, nicht der LGPL. Im Sinne der LGPL wäre also, die genau gleiche Qt-Version (in deinem Beispiel 4.5.0) zu nehmen, diese zu verändern (z.B. Bugs entfernen oder sonst den Code zu verbessern), diese mit dem gleichen Compiler zu übersetzen und die bestehenden dynamischen Libraries zu ersetzen.Urmeli hat geschrieben: [...]
Wenn ich eben ein "Werk" (wie das so schön heisst), erstelle, das dynamisch gegen die Qt linkt, dann muss der Endbenutzer in der Lage sein, die Qt Bibliotheken durch andere, die natürlich mindestens der Version entspricht, die ich verwendet, und mitgeliefert habe, ersetzbar sein.
Selbstverständlich... das ist IMHO nicht das Problem des (closed-source) Entwicklers..Urmeli hat geschrieben: Nun erzeuge ich meine Applikation mit einem kostenpflichtigen MS Compiler/Linker. Kann ich dann auf den Endnutzer abwälzen, dass er gefälligst diesen zu nutzen hat, wenn er eine andere Version der Qt mit meiner Applikation verwenden will?
Hier kann -glaube ich- niemand so genau Auskunft geben. Spannender als "inline" wären für mich ausserdem die Templates (z.B. QVector...).Urmeli hat geschrieben: Und, was sicherlich auch von Interesse ist, was ist mit inline Funktionen, die ja über die Header in meiner Applikation reincompilliert ist, wenn sich in irgend einer Klassendefinition der Qt etwas ändert?
Folgendes scheinen die Fakten zu sein:
- die verwendete LGPL v2.1 regelt diesen Fall nicht.
- technisch gesehen verletzt die Verwendung von Templates die LGPL-Regeln (Code ist nicht austauschbar), weswegen daher nur die GPL eingesetzt werden könnte.
- alle anderen grösseren LGPL-Projekte nennen extra dazu "Ausnahmeregelungen" (welche die Verwendung trotz inline/template zulassen)
- der Nachfolger LGPL v3 behebt diesen Umstand (erlaubt trotz Templates Closed-Source-Applikationen)
siehe dazu auch http://lab.obsethryl.eu/content/lgpl-21 ... -templates
Soweit so gut.. was bedeutet das nun für Qt? Das weiss niemand so genau, aber weil die Trolls ja die kommerzielle Nutzung extra hervorheben (LGPL 2.1: This version is available for development of proprietary and commercial applications) würde ich an deiner Stelle wie folgt vorgehen:
- bei kleineren Projektchen das Template-Inline-LGPL2.1-Problem ignorieren
- hoffen, dass die Trolls bald auf LGPLv3 wechseln
- bei grösseren Projekten (das nächste super-duper-1000-Euro-Video-Schnitt-Programm) Qt kaufen oder mit Nokia einen extra Vertrag machen, welcher die LGPL-Unzulänglichkeiten regelt...
hth..
@MichaelS
Trolltech verkauft nicht nur eine kommerzielle version, sondern auch extra support.
Nur damit ich statisch linken kann ??? Ok, in windows komm ich ums statische linken eh ned drumherum ...
Unsere Rechtsabteilung war zumindest anderer Auffassung ... und eine expliziete Nachfrage bei Trolltech ergab ebenfalls, das wir auf die kommerzielle version angewiesen sind. Ich muesst mal in erfahrung bringen, was als begruendung genannt wird, wir verkaufen unsere Software ja nichtmal ^^
Ciao ...
Welchen Sinn hat dann bitte noch die kommerzielle version ?Natürlich kann man das (das ist der Sinn der LGPL).
Trolltech verkauft nicht nur eine kommerzielle version, sondern auch extra support.
Nur damit ich statisch linken kann ??? Ok, in windows komm ich ums statische linken eh ned drumherum ...
Unsere Rechtsabteilung war zumindest anderer Auffassung ... und eine expliziete Nachfrage bei Trolltech ergab ebenfalls, das wir auf die kommerzielle version angewiesen sind. Ich muesst mal in erfahrung bringen, was als begruendung genannt wird, wir verkaufen unsere Software ja nichtmal ^^
Ciao ...
Die Frage beantworten die "Trolltechs" in ihren Lizenz-FAQs:RHBaum hat geschrieben: Welchen Sinn hat dann bitte noch die kommerzielle version ?
Why would I want to buy a commercial license? What is the difference?
The commercial Qt license includes email support, access to upgrades and allows you to develop fully closed source software. The LGPL carries some restrictions regarding the ability for users to relink libraries and other restrictions that may impose architectural requirements that some organizations might not be comfortable with.
Und wie begründet die Rechtsabteilung diese Einschätzung?RHBaum hat geschrieben:Unsere Rechtsabteilung war zumindest anderer Auffassung ... und eine expliziete Nachfrage bei Trolltech ergab ebenfalls, das wir auf die kommerzielle version angewiesen sind. Ich muesst mal in erfahrung bringen, was als begruendung genannt wird, wir verkaufen unsere Software ja nichtmal ^^
Eventuell könnte das noch helfen?
http://www.gnu.org/licenses/gpl-faq.html
@Urmeli: Ich hab auch eine Suchmaschine benutzt
http://www.gnu.org/licenses/gpl-faq.html
@Urmeli: Ich hab auch eine Suchmaschine benutzt