Announcing the Qt Automotive Suite
blog.qt.ioSo I'm remaking a product and was approaching qt about the commercial version. The rep was very insistent that I can not develop an internal prototype using the open source license and then move to the commercial license. So that makes qt pretty unattractive to me since I have to pony up cash and hope it's good.
What I would like is something like electron that can run on a frame buffer. What's the current state of the art for a html5 based embedded interface?
Why can't you ship commercial version with LGPL? It's LGPL not GPL?
I mean, if you don't need to modify the Qt-library, you don't need commercial license. You just need to provide link to the Qt-sources.
You also need to make it so the user can replace the Qt binaries with a later / modified version which may not be possible on an embedded device.
Really? Why? Is this something applicable to all commercial software using GPL/LGPL components?
Which clause of the GPL/LGPL makes you say that, or is there prior judgement that resulted in making such a demand?
This one:
d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
1) 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.
> Will operate properly with a modified version
Sounds like all you have to do is prove your build on your dev machine works with newer versions. Up to the user to update the library on the target machine!
Nope, that's explicitly the loophole that *GPLv3 family of licenses were created to fix.
> With LGPLv3 it is explicitly stated that the user also needs to be able to run the re-linked binary, and that sufficient installation information must be provided.
Thanks for digging this up for me :) . However,
0) leaves room for interpretation: when it says "to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work", should we read this as "the very same Version, modified to accommodate some needs while keeping API compatibility in mind" or a much-broader "any later Version, maybe even upstream, that may have received drastic API changes" ?
1) has boundaries: you are supposed to be able to "operate properly with a modified version of the Library __that is interface-compatible__ with the Linked Version". This notion of interface-compatibility seems here to prevent an attacker from saying to a commercial developer: "Here's Qt 42.0, now you will update your code for free for me so that it runs on it". Doesn't it?
More broadly, do you know of any lawsuit where these points were used to successfully prove non-GPL compliance and require more work from a commercial user?
EDIT I'm asking this (and my initial question) because it seems such a clause w/should have absolutely deterred commercial developers from using GPL libraries at all. Not starting a flamewar, I know MIT/BSD/Apache libs are generally more reassuring and popular in commercial software, but GPL code keeps being used by commercial software under the basic "We'll mention usage of the GPL lib in the docs, and will either leave the lib untouched or publish our modifications" promise. This condition as you interpret it seems much more chilling, I'm surprised to hear about it and would like to understand how severely it's enforced.
You absolutely can't use GPL libraries like this. If you use a GPL library you are required to release your entire application source code under a GPL compatible license.
With LGPL libraries I find a lot of developers aren't aware of the relinking requirement, but it does get enforced. That's why you won't find LGPL libraries being used in the iOS App Store and why you need to buy a commercial license for Qt for mobile.
Of course none of this applies to server apps since they aren't distributed to users. You can use all the GPL code you want.
"If you use a GPL library you are required to release your entire application source code under a GPL compatible license."
Thanks for contradicting. I almost swore nonsense, but I'm so unsure about everything when it comes to licensing that I thought I'd read about it first, and you're right. I'm flabbergasted; never understood this, and never met anyone confident enough about their understanding of GPL to contradict my (wrong) understanding.
But then, does this mean anyone can ask for the source of closed-source software that use GPL code, like the ones below? (I just dug two random examples).
- AutoDesk software. Uses GPL components at http://www.autodesk.com/company/legal-notices-trademarks/ope... -- EDIT: alright these are all _L_GPL libs, which means just distributing the (potentially modified) lib sources is okay as long as you don't link statically. Right?
- HipChat Enterprise. Server-side, but distributed, to be run by enterprises on their own servers. Uses GPL components at http://sources.hipchat.com/ -- EDIT: in this case, all the GPL components seem to be basic GNU utilities, used by calling binaries rather than being coupled to the commercial software by a linking / shared object mechanism. Right?
> But then, does this mean anyone can ask for the source of closed-source software that use GPL code, like the ones below? (I just dug two random examples).
If their software is a derivative work of someone else's code then they can't distribute their software without a license from the copyright holder of that code. In the case of the GPL, that licenses them only to distribute their code under the GPL. If they are distributing their software other than under the GPL, then that is copyright infringement (in the same way as if they had made a derived work of some non-GPL code and distributed that), they lose their license, and any holder of a copyright on the code that their software was a derivative work of could sue them for copyright infringement. (In theory they sue for damages; in practice the copyright holder of GPLed code they made a derivative of will usually settle for compliance and an agreement to have their future releases audited).
What constitutes a derivative work is a question for the courts. It's generally accepted that any program that uses a library is a derivative work of that library, and a program that invokes another program at arms length or via a standard interface is probably not a derivative work of that program. The exact boundary is unclear; there's a case to be made that a program that is tightly coupled to another program and invokes it via piped commands might still be a derivative work even though it's not shared objects.
The LGPL is an entirely different license from the GPL.
I didn't look at all the LGPL/GPL code they are using, but your understanding seems correct.
From my understanding of the licensing, that doesn't sound right. The internal product will be subject to the LGPL, but eve if that's a problem you only need to make sure you don't distribute it to anyone so that no one can ask you to oblige to the license.
No, that's always been a quirk of the Qt licensing.
If you intend to launch a closed-source* product at some future date and pay the per-unit licensing fees, the developer needs a seat license from day one.
(* closed-source or code that statically links in the Qt libraries)
That sounds like FUD* - Qt's LGPL is LGPL without modifications, so it does not have any quirk. Is it written in the commercial license that you cannot buy it if you have used the LGPL license?
* Not accusing you of course; I'm totally convinced that it can come from a misguided sales rep trying to close a deal as early as possible.
I found the applicable text: https://www.qt.io/terms-conditions/
*NOTE: If Licensee, or another third party, has, at any time, developed or distributed all (or any portions of) the Application(s) using an open source version of Qt licensed under the terms of the GNU Lesser General Public License, version 2.1 or later (“LGPL”) or the GNU General Public License version 2.0 or later (“GPL”), Licensee may contact The Qt Company via email to address sales@qt.io to ask for the necessary permission to combine such development work with the Licensed Software. The Qt Company shall evaluate Licensee´s request, and respond to the request with estimated license costs and other applicable terms and details relating to the permission for the Licensee, depending on the actual situation in question. Copies of the licenses referred to above are located at http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html, http://www.gnu.org/licenses/lgpl-3.0.html, http://www.fsf.org/licensing/licenses/info/GPLv2.html, and http://www.gnu.org/copyleft/gpl-3.0.html.
So really the questionable term isn't an additional term on the LGPL, it is on the commercial license.
That is very interesting. Note that they are not precluding you to switch, but they do reserve the right to sell or not sell to you the commercial license after you've used the LGPL. It sounds like an empty threat to me (if you talk to the sales rep and say "I have an internal prototype and I would like to buy the commercial license to finish and distribute it", will they say no?), but one should definitely consider this before choosing to try the LGPL version for early product development.
I think this is mostly meant to avoid having a team of 50 develop an internal version based on LGPL, and then a team of 1 maintain the commercial version, paying a single developer seat.
Note that you can still do a throw away prototype without problems. Some say you should in any case!
It's not an empty threat so much as it's an opportunity for them to gouge you later when your product is already highly dependent on their product.
Qt-as-the-company has always made it very clear that you can't switch your Qt LGPL/GPL project to a commercial one if you didn't start with the commercial Qt license from the beginning.
You're right, it does sound a bit nasty. No, I haven't read the license myself. It's been brought up multiple times on official Qt blog comments and mailing lists, though.
Edit: checked it now, and it's clearly written at https://www.qt.io/faq/, "Developing with a Commercial License":
> Q: If I have started development of a project using the open source version (LGPL), can I later purchase a commercial version of Qt and move my code under that license?
> A: This is not permitted without written consent from The Qt Company. If you have already started the development with an open-source version of Qt, please contact The Qt Company to resolve the issue.
It's not standard and it's not pleasant to most ears, but I think over the last 20 (!) years of development the Trolltech guys have tried to make sure they could advance Qt and make a living doing it. I respect that a lot.
OSS was a completely different animal back when this thing started. And it was forward thinking to avoid the whole problem with people demanding free support and bugfixes for open-source code.
Not saying that this is wrong, just that it's no wonder if they think this to be FUD if one isn't familiar with the rule.
As for the reasoning, a customer developing their product for years in-house and switching to commercial just before releasing would definitely place Qt financing in a shaky ground when compared to traditional commercial frameworks.
At my last company we had this situation. But they are more than happy to sort this out for free if you take a license for the next 2 years.
Good to hear!
It would be nice if they had some form of migration publicly stated. For example something like this:
If your project decides to go commercial the initial license term will include a cost of conversion based on the quantity of code already written.
It would be interesting if they expressed that rate as something like:
A gz -1 compressed tarball of the affected source code will be created, the size (in bytes) multiplied by X is the maximum fee we would charge for retroactive licensing.
I choose the wording 'maximum' there as it still allows them to offer better deals under other circumstances.
I imagine they have sales guys. If you have a meaningful amount of money to spend they will talk to you. If not, don't use their LGPL code in a proprietary product.
Qt is not an end-user, boxed product. This may shock you, but B2B software doesn't always have a public, standard price list.
Shock, no; sadden and drive me to other ventures yes.
My rule of thumb for pricing is that if someplace /makes you ask/ they aren't going to sell at a price you'd find worthwhile.
And their rule of thumb is that you aren't worth the sale. Bespoke software is not a bulk commodity. They have a free product. If you're going to be a cheapskate, use it.
The notion of charging by byte, as if software were content farming, shows that you are obviously not a professional.
The LGPL thing is not really the issue here. It's how Trolltech/Nokia/Digia/QtCo approached the payment of a commercial license.
It's always been explained to me by the sales people that "you cannot switch licensing models mid-stream". So if you're planning to go commercial, you start commercial.
It's not really about closing the deal as much as making sure the Trolltech developers were paid during the time you needed their support.
> It's not really about closing the deal as much as making sure the Trolltech developers were paid during the time you needed their support.
The OSS license doesn't grant you any support from Trolltech, does it?
Of course not. But I could totally see Trolltech getting critical bugfix requests from people "promising" to pay the commercial license once they launch.
I would totally understand the response eventually turning into "yeah, we'll fix your bug, but put your money where your mouth is", which is where they are today.
But do you even need a commercial license to sell your product commercially? It's LGPL, so surely you can just keep the Qt library LGPL. If you're not changing anything at all in Qt (and you really shouldn't be...), and you don't care about getting support (the docs are good enough for you), then why do you need a commercial license at all?
There are still some cases where you need a license, like Qt for Device Creation (https://www.qt.io/qt-for-device-creation). Or perhaps you need static linking, or want to include some Qt code in the app proper for one reason or another.
Ok, but if you stick with dynamic linking and don't insert Qt code into your app, then you don't need a commercial license, right? Why would you insert Qt code in your app anyway? That kinda defeats the point of using a library. As for static linking, why would you opt for this over dynamic linking anyway? Dynamic linking is better since other applications can share the libraries. Static linking on a PC platform is basically a hack for poor library management.
As for Qt for Device Creation, I looked through that and didn't see why you'd need a license there, unless they're selling optional components or plug-ins which are not LGPL licensed (which appears to be the case with things like "Qt Quick 2D Renderer" and "Qt Virtual Keyboard").
I even tried out the questionnaire at www.qt.io/download: if you select "Commercial deployment" for development and then say that you're doing dynamic linking, don't have any concerns about reverse-engineering, and can comply with the LGPL, it recommends you use the open-source LGPL'ed version.
Just listing some possibilities, different projects have different needs. Sure, for most of the cases the dynamically linked open source version works just fine.
Qt for Device Creation needs a license, that one is not available as LGPL. Of course you can use the open source Qt yourself for that, but then you'll be facing a lot of platform work to get Qt running on your device before even starting with the stuff that you actually want to build.
You can statically link LGPL. Your only obligation is to provide object files so that customers can relink.
Yea, that was my understanding of it also. I think they are trying to make the argument that once the your code is written under LGPL, its LGPL forever and can't have another license.
Your code is never under the LGPL though; you are free to license your code as you please. It's the binary you release that being linked to a LGPL library is subject to its conditions.
If that was true, then QT would violate this principle itself and could not sell you a commercial license.
Qt doesn't violate this principle, cause it is double licensed, Digia is just not using the LGPL version.
Electron might not be "fast" enough for many serious GUI applications? That been said, I also am struggling with finding a non-Java cross-platform GUI dev platform. The selection pool boils down to between QT and Electron indeed these days.
You are correct. The only serious frameworks nowadays are Qt or Electron if you're targeting the cross-platform desktop. There's also wxwidgets, although its python 3 bindings are still being built.
Personally, I'm keeping my eye open on libui (https://github.com/andlabs/libui/) as it is already possible to do some basic things with it. However, it is pretty much in alpha state and I'm slowly writing the Python bindings for it at https://github.com/joaoventura/pylibui/. The thing that I like in the libui is that it is a thin wrapper around platform specific frameworks. Therefore, the library is very small (some 340 KB) and it's as native as the underlying platform calls are..
Regarding Electron, I am writing an application on it, but it is too god damn heavy in terms of memory, disk space and boot time, and web front-end development is absolute chaos these days. Although I'm currently writing my app on it, it is mostly an MVP as I want to make pylibui/libui usable enough to switch to a pure desktop cross-platform library asap..
"Regarding Electron, I am writing an application on it, but it is too god damn heavy in terms of memory, disk space and boot time,"
Try Sciter HTML/CSS engine then (http://sciter.com). It is a monolitic DLL (4-8 Mb) without external dependencies. Works on Win/Lin/OSX and even on Raspberry Pi 2 - http://sciter.com/sciter-on-raspberry-pi-2/
Thanks for the suggestion, I didn't knew about this before! So I've tried it, the lib is small (~9MB on OS X), it renders pretty fast and has python bindings which is quite great.
However it lacks in some areas, such as the scrolling which is quite bad, and it does not render the SVG files that I'd need it to render (tiny SVG spec, but lots of defs and rotations). I'm still going to look better into it since I can use Cairo and CairoSVG to convert my SVGs to PNGs, but I still do not know how well it renders some css rules, fonts, etc..
There is also JUCE, but it's more focused on audio application development. https://www.juce.com/
Kivy isn't well know but I use this often : https://kivy.org/
Kivy looks neat, it seems geared towards python-games.
Electron is probably fast enough for my purposes, just I wouldn't call using for an embedded device easy. You need to have x running for it. It doesn't support chromium ozone and KMS yet. Also it has a pretty big footprint. I'm targeting the RPI compute module so I don't have a ton to work with.
I love it when commercial software developers complain about having to pay for software.
How dare Qt demand that others pay them before developing a commercial product using their code?
Or maybe I just want a prototype to prove out a concept and software stack. Rather than just blindly throwing money at a problem.
I have no problem paying Qt. I'm just unwilling to do it until I know its the direction I want to go. The current Qt licensing structure adds friction to my making that decision.
Of course it adds friction. It's supposed to add friction. They wrote the code, they're a going concern, if you're going to pay they want you to commit and pay, not "prove out the concept" for free. Qt will give you a license for prototyping, you're just not willing to pay it.
Most commercial vendors won't give you their entire product for free until your own product is half-built. Qt is different; they offer an entire free product. You want to have your cake and eat it too.
The license for prototyping seems to be the same one for release. And Qt isn't offering me a free product, their terms are pay then develop your software. At least in my context.
In any event the only issue is the weird quirk of the Qt commercial license preventing you from switching to commercial from LGPL. Which I and apparently a few other people in the thread really didn't get at first.
> The license for prototyping seems to be the same one for release. And Qt isn't offering me a free product, their terms are pay then develop your software. At least in my context.
Their standard Qt for Application Development license gives you a free 30 day evaluation period. Also, I don't think any of this encompasses simply examining the free product without use in product development, e.g., reading the APIs, documentation, and source code. That's a lot of freebies, that you don't necessarily get with other commercial products.
> In any event the only issue is the weird quirk of the Qt commercial license preventing you from switching to commercial from LGPL. Which I and apparently a few other people in the thread really didn't get at first.
There's no weird quirk. As they state, "If you have already started the development with an open-source version of Qt, please contact The Qt Company to resolve the issue." If you have money, they will take your money. But if you want to develop a commercial product and use Qt up front then you have to budget for it. If you can't afford it then use something else. No one is holding a gun to your head forcing you to develop a proprietary product with Qt.
Why do many enterprise software companies offer free (or low cost) trials then?
Does the company that you work for (or yours if you're a founder) take the same "take it or leave it" attitude towards potential customers?
> Why do many enterprise software companies offer free (or low cost) trials then?
So does Qt. So much so in fact, they even offer an entire free product; evaluate it all you want. Just don't use it to build a commercial product while paying zero dollars and then come back when it's half-built and expect to dictate pricing terms after the fact.
> Does the company that you work for (or yours if you're a founder) take the same "take it or leave it" attitude towards potential customers?
I'm not going to talk about my work here. I'm writing on my anonymous behalf only. I've worked at places that were more or less liberal with evaluations and more or less tolerant of tiny accounts. I have never worked somewhere that salespeople loved customers who wasted their time asking for freebies and handouts with illusory promises of future money that never seems to materialize.
> So does Qt.
No, they don't. Not in any meaningful sense. They're offering to let you evaluate a bed, so long as your evaluation doesn't include sleeping on it.
> expect to dictate pricing terms after the fact
Excuse me, but who here has said a single thing about the customer dictating terms? Not a single person.
> I'm not going to talk about my work here.
The question was rhetorical, thanks.
> who wasted their time asking for freebies and handouts
No one is asking for either a hand-out or freebie. Potential Customers are asking to evaluate a product before paying for licenses THAT THEY MIGHT NOT USE. That is not un-reasonable.
That would be why there's a 30 day free trial, for potential customers to evaluate with: https://www.qt.io/download/#Licence-anchor
What's his reasoning? As long as you purchase the commercial license prior to releasing why should they care?
Agreed, that policy is utterly nuts.
The incentives for me to comply with those terms are nonexistent, which is never a sign of a good contract.
As far as I know, almost all independent (meaning manufacturer proprietary, so disregarding Android Auto here) user-facing in-car systems are using either HTML5 or Qt. In that light it sounds like a smart move to make it even easier to pick their offering.
Interesting the focus on QML.
It feels like the Qt Company is pushing C++ down the stack, with QML getting the main focus as application development language.
I don't think it has to do with language but rather with interface patterns. Qt Widget was made to do native desktop apps like Word; QML was made to do touch apps like on mobile. Embedded has shifted to adopt touch screen and copy interface patterns from mobile (where touch based interface were innovated first).
You don't want a Word-like app in your car dashboard, but a iOS-like app.
Except that on iOS you can do everything in Objective-C/Swift if you feel like it.
Same applies to Android, UWP and even Tizen with their respective native languages.
So it is a conscious decision not to provide C++ APIs besides the old QtWidget and make developers use QML and its compiler instead, as far as I understand it.
It's not as clear-cut as that. This is a case for automotive, and there isn't a single native UI widget set that Qt could use/mimic. It absolutely makes sense to use QML for custom UI development, it really shines there -- using Qt widgets for custom UI on touch screens would be madness.
I've used Qt myself for desktop, mobile, and embedded development. For mobile and embedded I would not use widgets, and probably not even for desktop. I understand why the widgets still has staunch fanbase, but they do not belong everywhere.