If you want to use Qt in commercial closed source product without paying for the license, it’s easy to do when you use LGPL version.
1. Do not buy the commercial version.
2. Do not change the source code of the Qt library. Use it at it is.
3. Provide access to either statically or dynamically linked object files with instructions for linking. Static vs. dynamic linking does not matter with LGPL. LGPL requires access to source code and the ability for the user to modify open source library and link it to your closed source object file to create binary.
You compile your commercial code into commercial.o then compile LGPL code into lgpl.o and link them into a single binary.
ld -o binary lgpl.o commercial.o -lc
When you deliver the software, you send the binary, provide access to commercial.o and LGPL licensed source code with instructions for linking. User has now the ability to meddle with LGPL version of Qt, compile it into lgpl.o and link it against your commercial.o without having access to your source code.
(note: of course you can modify the Qt under LGPL when you release modifications with the LGPL. But then you have to maintain the fork on your own and you don't usually want to do that.)
The same, like all phone manufacturers who allow you to download the Linux kernel's source code, or Tesla who allows you to download the Qt source code they use: https://github.com/teslamotors/qt
My understanding is that it's not enough to provide the source code to the LGPL part. You need to provide a way that someone could use a modified version of that source with your application. (Indeed that is exactly what the top-level comment said.) That's because the point of GPL is not just to let you see code but also to hack around with it yourself.
So if your program ships with dynamically linked qt.dll or qt.so (or whatever) then it's good enough to just provide the source code because they can just build their own qt.dll or qt.so with their own code and directly use your program with it. But if your program statically links QT then you also need to provide some files (e.g. object files) for your application along with instructions on how to link those with the QT archive or your modified replacement. I remember a comment here on Hacker News about a program (a Sun one I think) that did exactly that, or least provided a URL to download the object files and build instructions.
So that means that if you provide a device containing GPL or LGPL code then you ought to provide a way to upload your own modified version onto that device. I'm not sure that's always true in practice, but that's the intention. If it's not possible, maybe the lawyers have figured out that a strict reading of the licence text doesn't actually require them to do that. Or maybe they simply don't adhere to the GPL properly but no one has dared to sue them.
that part varies between the (L)GPLv2 and (L)GPLv3. GPLv2 does not require it, GPLv3 does (so-called 'anti-tivoisation' clause: after Tivo used linux but locked the hardware so it would only run images they had signed). Current versions of Qt are LGPLv3 for most components though (and the rest are GPLv3)
Do you have information about which Qt version Tesla is using under which license? Do they allow to install and run user provided versions of Qt in their car?
You don't have to send the files. You just have to provide access to said files somehow. Put them into your web page, send link in email. Print link into manuals or sales agreement. And whenever customer calls and asks to have them just send them the files.
Not sure if it covers all the binaries you are likely to want - it includes qmake (although that's deprecated) and moc (that's probably what you really want). But it only includes enough to build programs, so not e.g. QtDesigner.
It also builds the actual libraries (obviously this command only builds the core ones, but there are other ports e.g. qt5-charts). But on Linux I think they are statically linked, which may not be what you want.
What parent is saying is that even if you have the file and can relink to the application .o, you can't submit your own version of an iOS app that's already on the App Store.
There's literally no way to use LGPL Qt on iOS. Thankfully Qt considers iOS a "mobile device" and not an "embedded device" so you can deploy a Qt app through the App Store with a single deployment license and not a per-unit royalty.
There's nothing in the BSD license that prevents you from mixing in code. LGPL doesn't care if you link it against BSD code. Just that the LGPL code must stay under LGPL.
"If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application."
You don't, you just need to provide a way to get them (you can even specify that requests must be sent by post and charge postage for the response on a CD). It's not a 'workaround', it's literally how the license is supposed to work.
Exactly. Any changes made to the Qt libraries themselves need to be shared, allowing users (and potentially The Qt Company) to benefit. It's up to you whether to share the source for any of your code which then links (statically or dynamically) with those libraries.
This is exactly what Nokia wanted when they made Qt available under the LGPL in 2009; they fully endorsed this kind of usage. All subsequent buyers and investors have been fully aware of what the LGPL means.
Just remember that some ancillary Qt software - such as Qt Virtual Keyboard - are only available under the GPLv3 and commercial licenses.
That doesn't sound right. The BSD licence is GPL-compatible, so you can release your code under the BSD licence and still use Qt.
It would mean however that if someone were to make a proprietary fork of your project, they would no longer be permitted to use the no-charge version of Qt. They would have to get a commercial licence. I don't see anything wrong with any of this though.
Edit: I wasn't clear here: Qt is also available under the LGPL, so the restrictions of the GPL aren't directly relevant.
> A license is "GPL-compatible" when code released under its terms can be used in a GPL-licensed project.
Correct.
> using any GPL-code, no matter if linked statically or dynamically, requires the author to release the combined work under GPL.
Yes, the combined work itself ends up being GPL [0]. This is similar to making a fork of some BSD-licensed code and adopting the GPL for the fork. Your code, treated independently of the combination, may still be released under a (more permissive) GPL-compatible licence (like the BSD licence) if you so choose.
Put another way then, if Qt were only made available under the GPL, it would still be fine to release your Qt-powered application code under the BSD licence, but it wouldn't be possible to make a proprietary fork of that BSD-licensed application code, as you wouldn't then be permitted to link against libraries released only under the GPL. (I'm ignoring commercial licensing of Qt, of course.)
1. Do not buy the commercial version.
2. Do not change the source code of the Qt library. Use it at it is.
3. Provide access to either statically or dynamically linked object files with instructions for linking. Static vs. dynamic linking does not matter with LGPL. LGPL requires access to source code and the ability for the user to modify open source library and link it to your closed source object file to create binary.
You compile your commercial code into commercial.o then compile LGPL code into lgpl.o and link them into a single binary.
When you deliver the software, you send the binary, provide access to commercial.o and LGPL licensed source code with instructions for linking. User has now the ability to meddle with LGPL version of Qt, compile it into lgpl.o and link it against your commercial.o without having access to your source code.(note: of course you can modify the Qt under LGPL when you release modifications with the LGPL. But then you have to maintain the fork on your own and you don't usually want to do that.)