16

I'm developing an application with the Qt open source edition. As I don't want to deliver the Microsoft Visual Visual C(++) redistributables, I'd like to use a static-linked version of Qt. The Qt licensing information says that I "should" develop with a commercial Qt license if I want to use static linking in my application, although when I use the configure -static command for building a static Qt library the command prompt asks me if I use the commercial or open source version of Qt.

So it is possible to build Qt with the open source version? Do I need the commercial edition to use static linking? I won't sell the application.

tshepang
  • 12,111
  • 21
  • 91
  • 136
martin
  • 1,099
  • 4
  • 15
  • 18

2 Answers2

35

EDIT April 2016

Actually, I have recently been reading in depth about LGPL, and asking some experts on the subject. Turns out that the inability to use static linking for Qt in closed source applications is more of a cultivated legend and has nothing to do with reality.

What LGPL requires is the possibility for the end user to relink the application against a different version of the library. Using dynamic linking is one way to achieve that, but you can just as easily provide your object files, this way you don't have to open your source and the LGPL requirement is still satisfied.

On the Qt website there are 2 legal FAQs and in neither of them is it directly stated that you can't do it. Just as it is not stated that you can. However, there are at least several instances of implying a vague legal threat in case that you do. I think there is a good explanation for all of those - they can't say that you can't do it without publishing a practical lie which may as well have negative legal repercussions for them, and they are willing to discourage doing that rather than encourage it, as it has the potential to force more people into purchasing a commercial license.

So in short, yes you can, and you most definitely should as lately Qt has become a living deployment hell, plus as of Qt 5.7 in a static build, QML files are tucked neatly in the executable rather than being out on the file system, for anyone to tamper with. Just make sure that:

  • your Qt build only contains modules, licensed under LGPL, and nothing GPL
  • the about section of your app mentions that it is using Qt and contains a link to where you can download the application's object files
  • include all the respective license files with your application

Lastly, your application actually has to be "relinkable", that is, it must be able to work with a compatible library version that provides the necessary functionality. Which means that if you have made modifications to Qt before building it, you must provide those in the form of source code as well, but only the modifications to Qt, not your application's source code.

Update:

Here is an excerpt directly from the GNU FAQ:

For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):

(1) If you statically link against an LGPL'd 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.

That states it pretty clear.

The old, original answer:

It is possible to build Qt statically as long as your application is open-source and you provide the source. If you want to keep your source closed, you either need an expensive commercial license, or you need to use dynamic linking.

BTW using a static build of Qt is pretty nice, for Qt5 I get about 7-8 MB executable with no external dependencies, which is much better than the 20+ MB of additional dll's you have to ship with a dynamically linked app.

For more information, you can take a look at this video: Making the correct license choice when developing with Qt

All in all, can it be done? 100% yes. Should it be done? It depends, for personal/testing/learning purposes it is 100% OK, however if you plan to distribute production grade software, be that commercially or not, open source or not, you'd better first consult with a lawyer. The whole subject is unnecessarily complicated, subject to interpretation, so that the consultation with a lawyer becomes more expensive than a pricey commercial license.

dtech
  • 47,916
  • 17
  • 112
  • 190
  • You must provide sources for any LGPL libraries you link to on request, whether you modified them or not, and any build scripts and/or configuration settings you use to build these libraries must be available as well. This is a necessary but not necessarily sufficient condition of LGPL compliance. I'd expect anyone being truly compliant to have a package that one gives to anyone who asks that will allow to rebuild Qt and relink with the `.lib` that contains closed-source code – Kuba hasn't forgotten Monica Apr 24 '17 at 19:43
  • I don't think anything 3rd party is your obligation. Nor to guarantee that a relink will work. That's not a guarantee with dynamic linking either. I'd say it is more about the principle of the thing than actually doing it, which likely noone will ever do. Considering that Qt keeps a source archive, I'd say configuration options and object files are all that is needed to produce a working build in case 3rd party factors don't break it. You are not obligated to account for cosmic rays flipping random bits under LGPL ;) – dtech Apr 24 '17 at 20:02
  • What you think then flies in the face of LGPL text. Distributors of closed-source products that use a LGPL-licensed library X must provide the exact source code of X that was used in the build. It doesn't matter **at all** to what extent one modified said library when compared to some canonical upstream version. One can, as a technical matter, provide the source as a canonical version + a patch file, but it must be simple enough for the user to obtain the actual full source from what's provided. Repeat for all LGPL X :) **LGPL compliance cannot depend on internet being available.** – Kuba hasn't forgotten Monica Apr 24 '17 at 20:08
  • A LGPL compliance packet is something you should be able to e.g. send by snail-mail, and it must be complete and self-contained. LGPL also implies certain things about the availability of a binary-compatible toolchain. It's probably a bad idea to ship LGPL-using closed-source products using a proprietary compiler one is not reasonably able to obtain and is not that's not binary-compatible with anything else. – Kuba hasn't forgotten Monica Apr 24 '17 at 20:09
  • I might send a raven. Internet availability is a technicality. What if the user's PC is broken? Are you violating LGPL? What is most important about legal issues is that they are **not** absolute, lawyers exist for the sole purpose to interpret and twist the law every which way. You can give zero phucks about compliance and be fine, you can go all out on complying and get your ass sued. As I said, it is mostly a matter of principle. Much like standards, yet in the end, it is the implementation that determines what happens. – dtech Apr 24 '17 at 20:17
  • what about open source GPL3 app on github? can I put to release section just a archive with statically linked .exe? – yalov Apr 11 '18 at 15:55
  • 1
    @yalov if your application is fully open source you can license under GPL so there is no limitation for static linking. You can still sell it too, GPL is "free" as in "free speech", not as in "free beer". – dtech Feb 17 '19 at 23:41
  • @dtech Wonderful response and corrected my 'legacy' view. Do you know of any practical examples of this? i.e. If the application Object files need to be provided do they need to be packaged with the application or can they be available on request etc? – Crog Oct 21 '20 at 11:06
  • @Crog I personally wouldn't bloat my application package with needless corner case stuff, rather put the object files and the instructions / version information / 3rd party links on github or whatever, in say... a "LGPL compliance" folder or something. And just in case some nit picking nagger goes out of his way to request a "physical copy", I will just print the binaries on paper, using the lowest printer quality available on the cheapest paper available, and send that ;) Sending it carved onto stone tablets will better illustrate the point, alas that would be too expensive. – dtech Nov 20 '20 at 07:40
-1

The answer is Yes, if you are willing to open source your application.

According to the Qt-Project's own interpretation of the licenses they use, if you dynamically link to the Qt libraries your application can be either closed source or open. If you statically link, however, your application is subject to the terms of the LGPL.

The exact language the Qt Project uses is this:

In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” - typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.

(http://qt-project.org/legal.html)

The suggestion in some of the other answers that the situation is "not at all clear" is simply untrue - The Qt Project has tried to be abundantly clear about in what circumstances usage of the LGPL license is permissible, and static linking is one of those as long as the app is also LGPL.

Since the original question specifies non-commercial (not necessarily open source), the asker will need to decide whether they can allow distribution under the LGPL (or GPL by extension, as the above page also says "LGPL can be converted to GNU General Public License").

James Mishra
  • 4,249
  • 4
  • 30
  • 35
stonecrusher
  • 1,246
  • 10
  • 12
  • This answer is incorrect. The quoted language from the Qt legal page is a misinterpretation of the rights that the LGPL guarantees end users. @dtech's updated answer provides further details. – James Mishra May 20 '21 at 16:42