)
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.
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.
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 !
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.
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.
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?
Welchen Sinn hat dann bitte noch die kommerzielle version ?Natürlich kann man das (das ist der Sinn der LGPL).
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 ^^
