Einerseits wäre es technisch nicht möglich ein SWT/QT Programm zu schreiben ohne auch gegen QT zu linken
Der Punkt ist, dass man kein SWT/Qt Programm schreibt, sondern ein Programm das SWT benutzt und SWT kann auf verschiedene Art implementiert werden. Was anderes wäre es, wenn das Programm explizit Funktionalität benutzt, die ausschließlich in SWT/Qt vorhanden ist. Allerdings glaube ich nicht, dass jemand so etwas machen würde, weil damit ja die Crossplatform Qualität von SWT verloren ginge.
Also ich baue mir z.B. meinen primitiven MyQT Wrapper (welcher alle Aufrufe einfach auf an die original QT Lib weiter gibt), stelle diesen unter die LGPL, und schon wäre es möglich QT - indirekt - mit jedem Kommerziellen Programm zu verwenden ohne einen Cent an Trolltech abgeben zu müssen.
Wenn du zusätzlich noch eine andere Implementierung deines Wrappers hast und nur dynamisch gegen die Implementierung linkst und maximal die alternative Version auslieferst, dann kann der Benutzer die Qt basierte Implementierung installieren, ohne dass es Auswirkungen auf dich hat.
Anderes Beispiel: für Java AWT gibt es bei GNU Classpath eine auf Qt4 basierte Implementierung der AWT Peers. Per Konfiguration oder Commandline Parameter kann der Benutzer, Administator oder Distributor eine bestimmte AWT Implementierung wählen. Trotzdem ist eine Applikation bzw. die Entwickler einer Applikation nur an die Lizenz der Java Classlibrary gebunden, nicht an den kleinsten gemeinsamen Nenner aller vergangenen, aktuellen und zukünftigen Implementierungen bestimmter Interfaces.
Scheint aber nicht nur von IBM zu kommen. Auch bei wxWidgets wird das gleiche Argument gebracht.
Äußerst verwunderlich, denn weder die GPL und erst recht nicht die QPL sollten Konflikte mit der von wxWidgets verwendeten Lizenz verursachen (wenn ich richtig informiert bin eine LGPL mit zusätzlichen Erweiterungen)
Die Lizenz des Toolkits, mit der eine Implementierung gemacht wird, hat natürlich Einfluss auf die Gesamtlizenz dieser Implementierung, aber wie oben schon gesagt, nicht auf die Lizenz von Programmen, die mit der allgemeinen API arbeiten und keine Annahmen über die vom Benutzer installierte konkrete Implementierung machen.
Der Punkt ist, dass man kein SWT/Qt Programm schreibt, sondern ein Programm das SWT benutzt und SWT kann auf verschiedene Art implementiert werden.
Was anderes wäre es, wenn das Programm explizit Funktionalität benutzt, die ausschließlich in SWT/Qt vorhanden ist. Allerdings glaube ich nicht, dass jemand so etwas machen würde, weil damit ja die Crossplatform Qualität von SWT verloren ginge.
Also ich baue mir z.B. meinen primitiven MyQT Wrapper (welcher alle Aufrufe einfach auf an die original QT Lib weiter gibt), stelle diesen unter die LGPL, und schon wäre es möglich QT - indirekt - mit jedem Kommerziellen Programm zu verwenden ohne einen Cent an Trolltech abgeben zu müssen.
Wenn du zusätzlich noch eine andere Implementierung deines Wrappers hast und nur dynamisch gegen die Implementierung linkst und maximal die alternative Version auslieferst, dann kann der Benutzer die Qt basierte Implementierung installieren, ohne dass es Auswirkungen auf dich hat.
Anderes Beispiel: für Java AWT gibt es bei GNU Classpath eine auf Qt4 basierte Implementierung der AWT Peers. Per Konfiguration oder Commandline Parameter kann der Benutzer, Administator oder Distributor eine bestimmte AWT Implementierung wählen.
Trotzdem ist eine Applikation bzw. die Entwickler einer Applikation nur an die Lizenz der Java Classlibrary gebunden, nicht an den kleinsten gemeinsamen Nenner aller vergangenen, aktuellen und zukünftigen Implementierungen bestimmter Interfaces.
Scheint aber nicht nur von IBM zu kommen. Auch bei wxWidgets wird das gleiche Argument gebracht.
Äußerst verwunderlich, denn weder die GPL und erst recht nicht die QPL sollten Konflikte mit der von wxWidgets verwendeten Lizenz verursachen (wenn ich richtig informiert bin eine LGPL mit zusätzlichen Erweiterungen)
Die Lizenz des Toolkits, mit der eine Implementierung gemacht wird, hat natürlich Einfluss auf die Gesamtlizenz dieser Implementierung, aber wie oben schon gesagt, nicht auf die Lizenz von Programmen, die mit der allgemeinen API arbeiten und keine Annahmen über die vom Benutzer installierte konkrete Implementierung machen.