[Proposal to Nokia/Qt] Create a "Qt Runtime"



  • To begin with, I am not a lawyer, and everything written below are some personal thoughts, provided "AS IS", without any warranty! :-)

    It would be very useful, in my opinion, if Nokia/Qt could (from a technical and legal point of view) provide a kind of a "Qt Runtime" for the most common desktop systems. For example, for LGPLed Qt 4.7.3, considering 32bit MS-Windows deployment, it should/could include Qt’s dll-files (QtCore4.dll, QtGui4.dll, QtSql, etc) and other needed files (mingwm10.dll, libgcc_s_dw2-1.dll) for separate download (without having to download the complete SDK), so that the distribution of an executable file created with Qt SDK (an application) could be accompanied with the links from Nokia’s servers for all the needed dll-files without the distributor would have to provide source code of the dll-files as well.



  • I voted "no" - because i'm pretty sure that it's close to impossible for Trolls to support a Qt runtime.

    Think about this: Qt can be built on different platforms and on each platform the programmer is free to use many different compilers and the binary compatibility is broken even between two versions of VC++ - given that what compiler should they use to build the runtime dlls?
    Anyway for you as the programmer is easy to create a setup file that contains the correct dlls.


  • Moderators

    I agree wit Zlatomir. It's not that hard to provide the dll's



  • In my opinion it is up to the developer to create an installer for each supported platform and to ensure that all dependencies will be present so sorry but I voted with No.



  • "No", i voted. But thank you for your proposal :-)



  • Thank you all for your votes! :-)

    Please read my initial post more carefully!

    Two important points there:

    "... for the most common desktop systems ..."

    and

    "... without the distributor would have to provide source code of the dll-files as well ..."

    So there are some technical but also some legal reasons for my proposal (considering you are developing using LGPLed Qt).

    Disclaimers from my initial post apply! ;-)



  • I voted yes although I agree with those who voted no for one single reason - autoupdate of Qt.

    If it is up to the developer to provide and install Qt, it can lead to
    (1) keeping an old version with security issues in, for example, QtWebKit
    (2) one application can, on install, overwrite newer version of Qt with an older one that is packaged with it thus breaking the previously installed apps that rely on the new version of Qt

    This is, generally, not applicable to free/libre systems since Qt updates with the distro, but for proprietary ones, it could be beneficial.



  • I voted yes, I think Qt Frameworks with the free dependencies (with MINGW compiler DLLs for Windows) and the rest systems should be available, in the style that .NET Framework is available for installation for all .NET applications in Windows.



  • [quote author="Ioannis Vranos" date="1310310863"]I voted yes, I think Qt Frameworks with the free dependencies (with MINGW compiler DLLs for Windows) and the rest systems should be available, in the style that .NET Framework is available for installation for all .NET applications in Windows.[/quote]

    I really hate that way of working. It leads to applications that require me to first hunt down some runtime package (.net version BlahBah), and only then will the application I am after install. Windows simply does not support a decent repository system like has been the standard on *nix for ages. That makes it neigh on impossible to support an infrastructure where libraries are updated centrally. So, I think the only feasable route is making the app developers responsible (as it is now) on Windows. For that, we don't need a Qt Runtime. On the other hand, on *nix, the distro's take the responsibility to provide repo's make supply updates. Also no Qt Runtime needed. On OSX, I think (but I may be off) that you're supposed to keep everything needed to run your app in a single bundle anyway: so again, no Qt Runtime needed.



  • Don't forget that binaries of Qt for Windows are already available for download from Qt's website. The only difference in the proposal is a request to have, for these binaries, the ability to download specific dlls as well!

    Also, all answers focus on technical matters, while the proposal could help with some legal issues as well, for closed sourced applications developed with LGPLed Qt.

    Disclaimers from my initial post apply! :-)



  • External dependencies are cumbersome for the user to handle with. I fully agree with André here. There's nothing to add for the Linux and Mac part. On Windows one will most probably need an installer anyways, so include the DLLs there. And if the Qt libs were auto updated from some external source it may break an existing application. So no from my side. It's a maintenance nightmare in my opinion it does more harm than help...



  • I have to say I totally agree with Andre on this one.
    [quote author="Andre" date="1310328202"]
    [quote author="Ioannis Vranos" date="1310310863"]I voted yes, I think Qt Frameworks with the free dependencies (with MINGW compiler DLLs for Windows) and the rest systems should be available, in the style that .NET Framework is available for installation for all .NET applications in Windows.[/quote]

    I really hate that way of working. It leads to applications that require me to first hunt down some runtime package (.net version BlahBah), and only then will the application I am after install. Windows simply does not support a decent repository system like has been the standard on *nix for ages. That makes it neigh on impossible to support an infrastructure where libraries are updated centrally. So, I think the only feasable route is making the app developers responsible (as it is now) on Windows. For that, we don't need a Qt Runtime. On the other hand, on *nix, the distro's take the responsibility to provide repo's make supply updates. Also no Qt Runtime needed. On OSX, I think (but I may be off) that you're supposed to keep everything needed to run your app in a single bundle anyway: so again, no Qt Runtime needed.

    [/quote]



  • [quote author="Stavros Filippidis" date="1310329495"]Don't forget that binaries of Qt for Windows are already available for download from Qt's website. The only difference in the proposal is a request to have, for these binaries, the ability to download specific dlls as well![/quote]
    What "specific dlls" are you talking about then? And who is supposed to do that downloading, in your plan? In my view:

    • The developer doesn't need them, as he has the full SDK or some custom build Qt already, and
    • The end user should not be bothered with them, as he is only interested in running the application, not in resolving any external dependencies that application may have.

    So who would benefit?

    [quote]Also, all answers focus on technical matters, while the proposal could help with some legal issues as well, for closed sourced applications developed with LGPLed Qt.[/quote]
    What legal issues, exactly? LGPL explictly allows you to distribute binary versions of the libraries in question, and as long as you did not modify the sources, you are not required to assume responsibility for their distribution in source form. If you are not specific, claiming that there are legal issues surrounding LGPL is just spreading FUD, IMHO.



  • [quote author="Andre" date="1310360211"]
    ...

    [quote]Also, all answers focus on technical matters, while the proposal could help with some legal issues as well, for closed sourced applications developed with LGPLed Qt.[/quote]
    What legal issues, exactly? LGPL explictly allows you to distribute binary versions of the libraries in question, and as long as you did not modify the sources, you are not required to assume responsibility for their distribution in source form. If you are not specific, claiming that there are legal issues surrounding LGPL is just spreading FUD, IMHO.
    [/quote]

    Do you really Andre think that "LGPL explictly allows you to distribute binary versions of the libraries in question, and as long as you did not modify the sources, you are not required to assume responsibility for their distribution in source form."?

    Well, I am not a lawyer either, but what was the point on which you think I wasn't specific? I have placed some specific questions on the issue "does someone who distributes LGPLed dlls with their application has to distribute their unchanged source as well?" at http://developer.qt.nokia.com/wiki/LicensingQuestions (it has been edited by others as well) and after many months no answer was given. I am making very responsible questions and proposals. I have not "claimed ... legal issues surrounding(sic) LGPL" as you mentioned. IMHO, things that are "spreading FUD" are the ones I read in your answer. :-)

    .

    One might also be interested in viewing http://www.gnu.org/licenses/lgpl-java.html (last accessed by me: Monday, July 11, 2011), and pay special attention at the paragraph

    "When you distribute the library with your application (or on its own), you need to include source code for the library. But if your application instead requires users to obtain the library on their own, you don't need to provide source code for the library."

    Since I am not a lawyer I do not know if this is an analogous situation with the one we are discussing, so read and decide for yourself.

    Maybe I am wrong! So yes, IMHO, my proposal will "free" developers from the obligation of the distribution of the dlls (as well as the source code of the dlls), so I think a legal issue is associated with this proposal.



  • You're obliged to provide the source on request, not with every binary you deliver. So, this should hardly be a problem. And as you use an unmodified version of Qt you can always point to the original archives of Trolltech/Nokia/...



  • [quote author="Volker" date="1310372580"]... as you use an unmodified version of Qt you can always point to the original archives of Trolltech/Nokia/...[/quote]

    I am not sure if this matter could be solved as simply as you describe. I mean, I wish it could, but ... I just don't know. That is why I believe it would be very useful to have an official answer from Nokia/Qt on http://developer.qt.nokia.com/wiki/LicensingQuestions



  • [quote author="Ioannis Vranos" date="1310310863"]I voted yes, I think Qt Frameworks with the free dependencies (with MINGW compiler DLLs for Windows) and the rest systems should be available, in the style that .NET Framework is available for installation for all .NET applications in Windows.[/quote]

    Yes, from a technical point of view, this could be another advantage of having a "Qt Runtime"!



  • Oh, and something I forgot:
    As cool as Qt is and as much as I like it for programming, I really would appreciate to have it spread much more. But to be honest: hardly any standard user will have more than one or two applications using Qt on his/her machine. Setting up a service for this rather small crowd is just too much wasted time in my opinion - let alone that not all Qt applications will use it.



  • [quote author="Volker" date="1310379665"]Oh, and something I forgot:
    As cool as Qt is and as much as I like it for programming, I really would appreciate to have it spread much more. But to be honest: hardly any standard user will have more than one or two applications using Qt on his/her machine. Setting up a service for this rather small crowd is just too much wasted time in my opinion - let alone that not all Qt applications will use it.[/quote]

    Yes Volker, I understand what you say and, partially, I agree. Having said that, I think that we want to support Qt so it could evolve even more, so having a "Qt Runtime" as other frameworks provide would be a step towards this direction.

    Also, the number of applications installed on a machine is not that important for this matter, IMHO: for example, I think that there are people who install .NET for 1 or 2 applications (using .NET) installed with the same machine, don't you think? Additionally, my proposal will give the ability (eg: through a network installer) for downloading only the needed dll files (for the windows example discussed).



  • Also, do not forget that what I propose is, from some points of view, similar to what is already implemented for mobile phones with: http://www.developer.nokia.com/Community/Wiki/Nokia_Smart_Installer_for_Symbian



  • In the mobile world you're actually bound to one or two installers. The same goes for the Linux distros.

    On windows you have a myriad of installer builders (nullsoft, innosetup, WiX, standard MSI installers, Qt installer framework, Bitrock, InstallShield, InstallerFramework - and those are the only ones that come to my mind while thinking 10 seconds about it). One would have to support all of these or force the developers to use one of them.

    Then you would have to make that bundle configurable, eg. for which Qt modules (not everyone needs QtWebKit or QtScript) and wich plugins (imageformats, sqldrivers...) to install. If you need some sql plugin apart from SQLite you would have to provide that on your own anyways, together with the db libs.

    Don't get me wrong - I see the good idea behind that, but I just don't see the benefits, as it would most probably a windows only service.



  • [quote author="Volker" date="1310383679"]In the mobile world you're actually bound to one or two installers. The same goes for the Linux distros.

    On windows you have a myriad of installer builders (nullsoft, innosetup, WiX, standard MSI installers, Qt installer framework, Bitrock, InstallShield, InstallerFramework - and those are the only ones that come to my mind while thinking 10 seconds about it). One would have to support all of these or force the developers to use one of them.

    Then you would have to make that bundle configurable, eg. for which Qt modules (not everyone needs QtWebKit or QtScript) and wich plugins (imageformats, sqldrivers...) to install. If you need some sql plugin apart from SQLite you would have to provide that on your own anyways, together with the db libs.

    Don't get me wrong - I see the good idea behind that, but I just don't see the benefits, as it would most probably a windows only service.[/quote]

    Believe me Volker, I do not take you wrong: I read and process very carefully every post you provided in this thread. :-)



  • [quote author="Stavros Filippidis" date="1310383839"]
    Believe me Volker, I do not take you wrong: I read and process very carefully every post you provided in this thread. :-)[/quote]

    Glad to hear that. I hope you don't get the impression that I'm the guy who's only picking the negative points :-)



  • [quote author="Volker" date="1310384024"]
    [quote author="Stavros Filippidis" date="1310383839"]
    Believe me Volker, I do not take you wrong: I read and process very carefully every post you provided in this thread. :-)[/quote]

    Glad to hear that. I hope you don't get the impression that I'm the guy who's only picking the negative points :-)[/quote]

    Of course not! :-)



  • I voted yes.

    It has been said in the past in http://labs.qt.nokia.com/ that qt is going to be more modular.
    This purpose makes qt more modular..

    Also i want to mention some benefits for the unix that something like this might have.
    Something like this (the proposal) can benefit distros which doesn't use binaries such as gentoo and slackware (they compile their binaries from the sources,a lot of time for Qt!)

    Also note that only KDE users and Qt programmers need the entire Qt,all the others,they just need some modules of it(Qt frameworks),why these users should install/compile the entire Qt.
    Don't take me wrong,but someone who needs just some Qt modules can blame the Qt frameworks that forces his to install in his system the entire Qt.

    Moreover,Qt is going to be more "open" (Qt 5),so proposals like these will not make Qt frameworks more windows friendly,(at least not with the bad meaning of it).Actually the otherwise will happen,more modular Qt means more Qt in windows systems,so when people will start searching for more (bigger) Qtish stuff they will come across to projects like KDE,meego which are of course unix friendly.:)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.