Qt Online Installer 3.2.3 | Hacker News Reader

Qt Online Installer 3.2.3

qt.io

35 pointscaution34 comments

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.)

Number 3 is problematic in App Store software.

You don't have to send the files. Just provide link or some other way to access the said files.

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.

That's the equivalent of creative accounting for software developers.

Dick move.

Such behaviour just leaves the market to big corps who can afford to release such tools for free while extracting money from elsewhere.

The above technique is compliant with the license of Qt (LGPL). If Qt didn't want to allow it, they would have used a different license like the GPL.

Then you wouldn't be able to write BSD-licensed apps using Qt at all. Creative accounting is also legal per se. It doesn't make it right.

Why not?

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.

I was replying to the suggestion that Qt could be released under GPL if its authors wanted to prevent the creative accounting described by OP.

Also, LGPL is already problematic, because you cannot link statically with it.

> Also, LGPL is already problematic, because you cannot link statically with it.

Damn. I just wrote the whole top level comment to explain that you can link statically LGPL code and how to do it with details.

That's just a workaround. Now I need to add *.o files to my deb packages. Or ship source code in deb packages? What is it? Gentoo?

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.

https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

"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."

It's a bit odd to label doing the thing that differentiates the LGPL as a "dick move".

> That's the equivalent of creative accounting for software developers.

That's precisely what makes LGPL the LGPL. If it is a dick move, it is a FSF-endorsed, widely deployed, and widely used dick move.

I couldn't care less what's FSF-endorsed. They are not the company behind Qt. Perhaps ask the Qt company what they endorse?

This is what they want, since they release Qt under LGPL. If they wanted to prohibit static linking altogether, then they would use GPL exclusively.

No Qt for BSD-licensed projects then? Great.

"Creative accounting is what we want, since we didn't outlaw it."

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.

However, using any GPL-code, no matter if linked statically or dynamically, requires the author to release the combined work under GPL.

If you're talking about GPL, you are not talking about Qt.

I'm not sure where you're going with this.

> 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.)

[0] https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean

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.

But I don't sell software. I sell machines with my software already installed. I don't send any binaries. What I can do?

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.

It will soon be hard for free software to ship with non-vulnerable version of qt though https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...

Do you know of any example project that does this? Ideally something that'd just work like a docker script or bazel build that makes these binaries.

    vcpkg install qt-base

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.

I wonder whether the steps are similar to the Python library (PySide2).

Slightly off-topic but it's interesting how all of the discussion on this post (right now) is centered around the only other top-level comment rather than the article.

Reply on news.ycombinator.com