But something has radically changed with the new LGPL licensing in recent versions, from what I can tell.
I recently received an RFP from a very large European vehicle manufacturer, the RFP requested that Qt 5.6 should be used and no later. (The licensing changed with 5.7, so their lawyers must have figured this out)
LGPLv3 includes the "anti-TiVoization" clauses which require that any device including the software must include an offer for not only the covered source code, but "Installation Information" allowing the end-user to replace the firmware on the device. Giving out this info is not something that a car company (or really any companies) want to provide.
It's unfortunate that a large car company doesn't want to buy a commercial license, but maybe they'll be forced into that once 5.6 becomes too old.
I thought, prior to 5.6, you could go licenseless if you provided a way for the user to replace the (dynamically linked) Qt libraries with libraries of their own.
Was it just too nebulous before, and most companies just didn't offer a way to do this or buried it in some backdoor or something?
Yeah, I agree it's a shame that a lot of companies don't want to license up, but if you've seen what they want for a per-device fee these days you'd probably understand. I did a product in 2008 and it was maybe $1/unit, now it's an order of magnitude larger.
Yes, that's generally the spirit of both the LGPLv2.1 (5.6 and before) and LGPLv3 (5.7 and up). Link dynamically to the LGPL covered libraries, provide the source, and you're good.
But there's a commonly-used loophole: the LGPLv2.1 does not state that the user needs to be able to actually replace the covered library with their own built binary. In 1991/1999 this may have been assumed (given dynamic linking and desktop OSes), but for embedded devices and newer platforms it is not a given.
Digital signature verification can be used to prevent the user from loading their own firmware (the only way of replacing the LGPL libraries). This is why the GPLv3 added the anti-TiVoization clauses, requiring that installation instructions be provided with the source code, so the user can actually install the libraries onto the device.
I'm in final test on a 4.8-based product and actually put in a backdoor to replace the libraries...just to be safe and compliant. Guess the work isn't totally wasted.
I briefly started investigating the changes for Qt 5.7 before I started having flashbacks of trying to figure out all this LGPL stuff again. Does not seem to be any less confusing...
Before, you had to maintain a Qt source repository that matched distribution. People could build and link in Qt as they pleased, either vanilla from that repo or modified as they liked.
With 5.7 and the new LGPL, it seemed that you also have to provide the entire toolchain needed to build the source and link it into the final application. Which means you also need to provide the kernel headers and etc that match up.
I could be totally wrong. But I'm guessing 5.7 required too much other stuff be made public and the customer wasn't pleased with that. Can't say I disagree.
Of course, part of the reason why The Qt Company likes LGPL3 is that other companies are going to look at the requirements to use and distribute open toolchains for their supported platforms and just buy a commercial license instead.
Qt seems to be almost caught up with getting qt5 in the meta directories and having everything in place.
The automotive industry is notorious for hating to change what already works, after all.