How much cost Qt for Indie developers ?



  • So how much is it? At least some approximate price?


  • administrators

    @iter I'm under the impression that the price would be about one magnitude lower than the current pro licenses, but I really am not involved in those talks. Anyway something that is much more in line with small companies / indie developers expectations.



  • @janfaroe said:
    "As long as you don't modify Qt and don't statically compile, you're good to go."

    @sierdzio said:
    "With LGPL: ... You have to ..."

    IANAL, but I do not believe that this information is complete and totally correct.
    Part of the Qt LGPL states (from http://www.qt.io/FAQ/):

    "The user of your application has to be able to re-link your application ..."
    "... the user needs to be able to run the re-linked binary ..."

    You cannot run your linker to link an updated or modified application with just the copy of your "commercial" exe file and any Qt dll lib files, so you must distribute complete obj files of your application source code. It does not say "re-compile the Qt dll", it says "re-link your application". There is no other way to interpret this license statement.

    It goes on to state:
    "It is your obligation to provide the user with all necessary tools to enable this process."
    "... this includes making the full toolchain used to compile the library available to users."

    So you cannot just give the end user your commercial application exe file, the Qt dll(s), and the Qt source code.
    You must include obj file(s) of your application source, all Qt source, plus all of the tools to re-compile and re-link a new modified exe and dll(s).

    It also states that you must include all of this content in your software package or on your own hosting site address, you cannot simply provide the end-user with an Internet link to www.qt.io to the source code and tools.
    "... a link to the source code provided by the Qt Project or Qt Company is not sufficient."

    If this is not true, then all of the wording of the LGPL license is incorrect.
    Bottom line, it isn't as easy and straight-forward as you may think...


  • Moderators

    Hi, and welcome to the Qt Dev Net!

    @DRGreen said:

    You cannot run your linker to link an updated or modified application with just the copy of your "commercial" exe file and any Qt dll lib files, so you must distribute complete obj files of your application source code. It does not say "re-compile the Qt dll", it says "re-link your application". There is no other way to interpret this license statement.

    IANAL too, but I don't think the linker is required if you use dynamically linked libraries. With the latter, linking occurs when you launch the application, just before it starts running.

    For example, let's say I downloaded a program that was built against Qt 5.5.0. I want to re-link it against Qt 5.6.0 for some performance improvements. All I need to do is replace the Qt 5.5.0 DLLs with Qt 5.6.0 DLLs. Then, the next time I launch the application, it will automatically link against the new DLLs. I do not need to modify the original .exe.



  • @JKSH - Hi and thanks.

    I do agree with your statement:
    "the next time I launch the application, it will automatically link against the new DLLs."
    But this is not what the license states.

    Sorry, I don't mean to split hairs, but in my 35+ years of software development I have never heard of dropping in new DDLs referred to as "re-linking your application", which is how it is stated in the license.
    The license specifically says, the end user must be able to re-link your application.
    It does not say, your application must be able to link against updated or modified DLLs.

    If the DLLs are replaced with another compatible DLL build version, upon execution the application "links the new DLLs" (loads and maps them into its address space), the updated DLLs do not "re-link the application".
    The only way to "re-link the application" is to use the linker on the application obj files.

    I can give you Internet links to millions of websites regarding using DLLs and all of the terminology agrees with what I wrote. So this is what I understand the Qt license to mean, and why I never use open source DLLs with a commercial executable.

    "One advantage of DLLs is that you can change and enhance them without forcing all the applications that depend on them to be relinked or recompiled."
    The use of "relinked" in this example phrase means "re-linking the application obj files", and Qt's license specifically says exactly that, "re-link the application".

    If Qt actually means something different in the license, it would be nice if they clarified it.
    Thanks.



  • If Qt clarified their license, and if in fact it was possible to use the open source version of Qt in a commercial application, so long as:

    1. The developer linked the Qt DLLs dynamically (vs static linking).
    2. Made the Qt source code available for download on their own website.
    3. Included a Qt copyright in their application About dialog.

    Then there would be virtually no reason for Qt to have to come up with a less expensive small developer subscription, as the only main difference between the free open source license and expensive commercial license would be dynamic versus static linking.

    However, the "re-link the application" statement in the license is too obscure to make me ever consider using the open source version in a commercial application. And to me, this statement does not mean what some others here believe it means.

    edit
    Or change Qt from LGPL to the MIT license.



  • Has there been any more news about the startup licensing?

    I would love have the option to use Qt on my projects, but $420/month is just not a justifiable outlay for a one-man-band - we're talking about software that has yet to make me any money at all. That's a big gamble, especially since you can't start development under LGPL and go commercial later.

    It's obvious a lot of people would rather pay for Qt than deal with the hassle of the LGPL. I'm willing to pay for tools - but at $5k/year, Qt commercial is currently not an option.



  • So, does this mean that if I provide object files, allowing the end user to recompile and relink, I can use a static Qt build and just forget about the deplymend/dependency hell that Qt is with dynamic linking?

    It is sad to see that the management takes Qt in a direction that makes its free use less and less convenient. While surely - corporate greed ain't nothing new, this will eventually be Qt's undoing. Right now they are enjoying having an easy time milking Qt, only because there is no direct competitor, but this won't last forever, and when a competitor pops up, users will remember this lowly behavior even if then management is forced to improve Qt for free use.


  • Moderators

    @DRGreen said:

    Sorry, I don't mean to split hairs, but...

    No worries; this is sometimes necessary, after all :)

    The only way to "re-link the application" is to use the linker on the application obj files.
    I can give you Internet links to millions of websites regarding using DLLs and all of the terminology agrees with what I wrote.
    ...
    to me, this statement does not mean what some others here believe it means.

    I see your point, and after a bit of Googling I agree that your definition of "re-link the application" is currently the common one.

    However, reading the license again, it seems to me that allowing users to re-link is simply one of the ways to achieve LGPL compliance. See the full license text: http://doc.qt.io/qt-5/lgpl.html

    What you've described sounds like section 4.d.0 of LGPL v3. The license says you must do 4.d.0 OR 4.d.1. (The equivalent sections in LGPL v2.1 are sections 6.a and 6.b). The full text of 4.d.1 is

    "Use a suitable shared library mechanism for linking with the Library. 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."

    So, in other words, if you use shared libraries (dynamic linking), then you are not obliged to allow users to re-link the application. Would you agree?

    the "re-link the application" statement in the license is too obscure to make me ever consider using the open source version in a commercial application.

    Above, we've seen that you are required to allow re-linking OR use shared libraries, but not both simultaneously. Does this change anything for you?

    the only main difference between the free open source license and expensive commercial license would be dynamic versus static linking.

    That's definitely not the only difference. The commercial licenses also offers:

    • Access to official, timely support
    • Prioritized bug fixes
    • Access to extra modules*
    • Access to extra tools*
    • Access to extra software stacks
      • For reduced time-to-market
    • Access to Qt on extra platforms
    • Permission to statically link against Qt in proprietary applications
      • There was a time when this was needed because Apple disallowed dynamic linking, meaning that developers couldn't use LGPL Qt in a proprietary iOS app.
    • Permission to modify Qt without releasing the modifications
    • No requirement to provide Qt source code and the tools/instructions to build it
    • No requirement to even mention that Qt was used at all
    • Peace of mind^

    ^ Large corporations are funny beasts. Some need to buy a license, even if the library is in the Public Domain (meaning that the library authors already gave everybody full freedom to do whatever they want with the library, with no restrictions whatsoever).

    * Things will change slightly in Qt 5.7. Modules that used to be only available to commercial customers will be open-sourced too, but only under the GPL which is unambiguously disallowed in proprietary applications.


  • Moderators

    @edmundmk said:

    Has there been any more news about the startup licensing?

    Not that I've seen, I'm afraid.

    @edmundmk said:

    That's a big gamble, especially since you can't start development under LGPL and go commercial later.

    You can't? Why not?

    @iter said:

    So, does this mean that if I provide object files, allowing the end user to recompile and relink, I can use a static Qt build and just forget about the deplymend/dependency hell that Qt is with dynamic linking?

    I'm not sure, but I think if you use static linking you must provide the source code for your whole application too. Have you tried reading the license?

    @iter said:

    It is sad to see that the management takes Qt in a direction that makes its free use less and less convenient.

    What do you mean? There have been no major changes to licensing requirements since 2009... May I ask how has it become less convenient for you recently?


  • administrators

    @edmundmk said:

    Has there been any more news about the startup licensing?

    Just a bit more patience please. We are in the final stretch for Qt 5.6, and that is taking up everyone's time.

    I would love have the option to use Qt on my projects, but $420/month is just not a justifiable outlay for a one-man-band - we're talking about software that has yet to make me any money at all. That's a big gamble, especially since you can't start development under LGPL and go commercial later.

    Well, if you start development now before we have the small business/indie license out, and then ask The Qt Company sales really nicely, they probably will be open for discussion. It is a special situation as the small business/indie license will be a new product.


  • administrators

    @iter said:

    So, does this mean that if I provide object files, allowing the end user to recompile and relink, I can use a static Qt build and just forget about the deplymend/dependency hell that Qt is with dynamic linking?

    With a commercial license, yes. When on an open source license, static linking means you would be using GPL and thus would have to provide your source for anyone who asks.

    It is sad to see that the management takes Qt in a direction that makes its free use less and less convenient. While surely - corporate greed ain't nothing new, this will eventually be Qt's undoing. Right now they are enjoying having an easy time milking Qt, only because there is no direct competitor, but this won't last forever, and when a competitor pops up, users will remember this lowly behavior even if then management is forced to improve Qt for free use.

    Let's get back to basics. Qt from it's start has been dual licensed.

    If you do not want to contribute to the community, you have the option of getting a commercial license and doing whatever you want with no need to think about providing object or source files, static or dynamic linking.

    If you don't want to pay for a commercial license, then you can contribute to the community in the normal open source way.

    The convenience of free use has not gotten any harder since Qt became available under the LGPL and GPL licenses, and that is ages ago. Those licenses change as times change, Qt now followed the times with adopting version 3 of those licenses. The changes are not fundamental, except for people making embedded devices, then you need to read the GPL and LGPL license carefully with a lawyer.



  • Thanks for the swift replies, I am really looking forward to having the option of Qt!

    Not sure I'll actually take the plunge as usually my brain forces me to write things from the ground up no matter what, but as far as cross-platform widget libraries go I really don't think there is a better one out there.

    Qt was really invaluable when I was using it a couple of years ago on an internal tool - achieving what I did without it would probably have taken five times as long.


  • Moderators

    @edmundmk said:

    Has there been any more news about the startup licensing?

    Not long now! http://blog.qt.io/blog/2016/03/08/qt-start-ups-awesome/ Introductory price of $49 per month.



  • @JKSH said:

    @edmundmk said:

    Has there been any more news about the startup licensing?

    Not long now! http://blog.qt.io/blog/2016/03/08/qt-start-ups-awesome/ Introductory price of $49 per month.

    Once again, sugarcoating - that price is a limited time offering and will not be applicable long term. The actual cost is like a 1000$ a year, while a significant improvement over the full commercial license, it is still discriminatory - it is too much for the standards of Eastern Europe and Asia - demographics, in which a significant fraction of the Qt developers is focused.

    There is the same amount of overprice as in the commercial license. For example, VS Enterprise costs 250$ monthly, whereas Qt is almost double that. Comparing the feature set of the two products, I'd say a sane, adequate price for the full Qt commercial license outta be no more than 200$ monthly. And no more than 35$ for the indie license - I think that's acceptable compared to something like xamarin indie.

    The 100000$ limit annually is a rather generous one. If you make somewhere near the end of that limit, you are by no means a small time developer who is too poor to buy Qt even at 400$ a month. And from the indie developers I know, there is no one who is making anywhere near that on Qt applications - it is usually custom stuff requested by a specific customer you don't sell en masse. I personally make 2-3k a year using Qt on the side from my main occupation, meaning if I opt for an indie license, it would eat a third to half of my income from it. 2-3k annually might not sound as a lot to someone, lucky enough to have been born on a greener pasture, but for many people it is a nice and very welcome addition.

    The management is not thinking rationally - 2/3 of the Qt developers live in places with fairly low standard of living. They will not benefit from the indie license as it is priced today - only small startups from richer demographics will. IMO digia will make less money on a 79$ indie license than on a 35$ one, the number of people willing to buy it at 35% is probably about 5 times higher, meaning despite the lower price, revenues from indie licenses will be more than double. Quite often, less is more where it really counts, and I'd say adoption rate and revenues outta be what counts the most to digia.

    @JKSH said:

    What do you mean? There have been no major changes to licensing requirements since 2009... May I ask how has it become less convenient for you recently?

    There might not have been major license change, but there has been quite a lot of changes in Qt, here are a few reasons why the open source is not convenient:

    • deployment - dependencies for Qt have been growing and growing, currently it is like 70-80MB of DLLs you have to ship with an average Qt application, and the deployment tool in my experience is entirely broken, pulls in unnecessary DLLs, omits the required ones, and does even worse bringing in QML modules. Static linking would solve that, at least when QML + static build is finally fixed.

    • security - aside from Qt not providing any, LGPL makes it next to impossible to implement some yourself. After all, you have to be "plug and play" with the libraries, so that substituting them with other versions must be possible. This makes exploits very easy - you can inject whatever code you need in by simply compiling it in a DLL and changing the original with it. It is even worse for stock QML modules - as they are essentially plain text with no checks for integrity whatsoever, you can open stock module QML file deployed with the project and type your code. Due to the dynamism and structure of QML, the entire GUI part becomes an open book. Not having to support plug and play library/module substitution can address those issues.

    • license ambiguity - there have been a lot of "it's OK" from digia employees, however, it is not what unaffiliated people say, what they say is "there is only one way to be sure, and that's paying for a lawyer" - and their advises sure don't come cheap, you might as well be paying for the commercial Qt license you can't afford. There is simply no ease of mind when using LGPL in commercial applications. There are lot of people who don't really care about support and all that stuff, and just want an affordable solutions for their legal woes.

    A final question - seeing the possibility for a "more flexible option" - to buy Qt indie monthly for 99$, is a Qt license necessary only for developing an applications, or is it necessary while you are selling the application, even if you are not working on it?



  • I've been monitoring this thread for a while and have just read about the new $948/year start-up licence. I'm very disappointed by the price as it's roughly double what I was expecting.

    I was considering using Qt on a commercial project that probably won't make any money. For $400-500 per year I would have given Qt a go, but $948 is way too high. It's certainly not competitive against Visual Studio Community Edition, which allows individuals and companies with up to 250 employees can develop commercial MFC applications for free.

    I prefer MFC to Qt so the only reason to use Qt is because it allows you to support Linux. There's no money to be made selling software for Linux, so the only reason you'd support Linux is to try and encourage Linux adoption. I'd pay $400-500 per year to support Linux, but I definately wouldn't pay $948.

    It looks like MFC is the only way to go for small commercial projects. On the up side at least I won't have to use Qt's container classes. Just why did you waste all that time writing something that's vastly inferior to the STL?


  • administrators

    Hi @MJ9797
    I understand that you are disappointed with the pricing. However when looking at the competition in the commercial space, that level is approximately what is normal.

    Have you considered going with the LGPL version of Qt?

    If you only plan on working on Windows, then native tools make sense. Qt is cross platform, and if you plan on working on any other platform is makes a lot more sense.

    Comparing STL and Qt is a strange thing to do, they really aren't in the same category at all.



  • Nothing wrong, much less "vastly inferior" with Qt containers - their performance is on par with std containers, and Qt containers use is actually less verbose and much easier to use. std containers are overly verbose, pretty much all operations require iterators.

    He is right about the pricing though. It needs to be cut at least in half to become reasonable.



  • This post is deleted!


  • This post is deleted!

Log in to reply
 

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