Qt for commercial use

raven-worx

So I git clone the Qt repo(s) and rsync it to the device?

no, it doesnt have to be on the device. Either on a physical medium or on your self hosted repo, ...

Paying lawyer fees to investigate seemingly complicated licensing matters is not relevant/realistic at this stage.

doesnt have to be now, just when you are ready.
I just give an overview, i meant details have to be discussed with a lawyer once you are ready.

Anyway you are free to try Qt for personal use at any time and check if it fits your needs.

RobertB

Alright, thanks.

I found this on the Qt forums by one of the moderators:

With LGPL:

    you can distribute your application under any license, including commercial ones
    you don't have to provide source code of your application to your users

You have to:

    provide any large patches to Qt that you are using (for example when you have fixed something in QPoint). Small changes are exempt from this by Qt License extension to LGPL. Also, if you push changes to Qt Project, and they are integrated into Qt, you don't need to provide anything
    provide license file for Qt
    allow libraries to be swapped (no static linking)
    inform your users that Qt is being used (About box, readme, etc.)

So you can modify Qt itself, but you need to give your users the means to run your application with Qt they build on their own (if they wish to do it).

With GPL:

    all your code needs to be GPL'ed, too
    you need to provide source code to your clients upon request (you don't have to make them publicly available and you don't have to ship them by default. Any recipient can propagate those files, though)

For people googling and coming across this thread...

SimonSchroeder

@RobertB First of all, I am not a lawyer. However, it seems that the post you found is a little bit outdated. I remember that Qt for a while used a modified LGPL where it stated that small changes don't have to be shared. As I understand Qt's open source licensing right now it uses an unmodified LGPL v3 (and also the GPL). This means that you need to make all changes (even the tiniest ones) available. In any case you need to provide the source code of the particular Qt version your software uses (i.e. including all your own changes inside Qt) in some form. My current understanding of the LGPL v3 is that you can either provide the source code in the same way as you ship your software (if your software can be downloaded, provide a download option for Qt source; if you are shipping an embedded device I am not entirely sure how this applies) or you can provide a written offer valid for at least 3 months to request Qt's source code free of charge. In any case you need a copy of the Qt source code. It is not sufficient that everyone can download it from the official Qt web site.

I don't believe that you need to provide instructions how to exchange dynamically linked Qt libraries. Usually, this is well known information for the operating system in use. Contrary to what the quoted post says it is possible to use static linking. In that case you need to provide instructions and a way (object files?) to relink your software with different Qt libraries. The intention of the Free Software Foundation is that people will then also be able to change the software on the device, but I am not sure if the LGPL actually requires this. Can anybody chime in on this? (I don't see any point in people being able to relink your software without having a way to use it on the device they bought. But legal boundaries don't always make sense.)

RobertB

@SimonSchroeder Just to be clear, I would have to provide a copy of the Qt sources somewhere (so in practice this would be a Gitea/Gitlab/Github repository that clones & follows code.qt.io/qtbase.git (and friends))?

And my own source code would not have to be made public, even if it is a commercial offering.

Unless I make changes to the core of Qt. That needs to be open-sourced.

As for static binaries, I can do that, but I would still need to have a mechanism in-place that allows people to swap libraries. Would it be sufficient to provide 2 versions of my app, one dynamically linked, one statically linked? The former being available somewhere for people that are interested in swapping out libraries. The latter being a version that is actually distributed and used on my device.

sierdzio

@RobertB said in Qt for commercial use:

@SimonSchroeder Just to be clear, I would have to provide a copy of the Qt sources somewhere (so in practice this would be a Gitea/Gitlab/Github repository that clones & follows code.qt.io/qtbase.git (and friends))?

Yes. Although why people insist on this I don't know. Qt already has a public clone on GitHub, it wills stay online even if Qt Company goes bankrupt.

And my own source code would not have to be made public, even if it is a commercial offering.

Yes, correct.

Unless I make changes to the core of Qt. That needs to be open-sourced.

Yup, only changes to Qt itself. So for example if you modify source code of QString, you need to share these changes.

As for static binaries, I can do that, but I would still need to have a mechanism in-place that allows people to swap libraries. Would it be sufficient to provide 2 versions of my app, one dynamically linked, one statically linked? The former being available somewhere for people that are interested in swapping out libraries. The latter being a version that is actually distributed and used on my device.

The static path would still need to work on your device so I don't think it's worth the effort. Just use dynamic linking and you'll be fine (and your users will be happier, too).

JKSH

@sierdzio said in Qt for commercial use:

Yes. Although why people insist on this I don't know. Qt already has a public clone on GitHub, it wills stay online even if Qt Company goes bankrupt.

I'm guessing that the rules were written before public code repositories were a thing, so code would be hosted on the original author's/company's servers which have a higher chance of vanishing.

If you really don't want to, you don't strictly need to make your own copy of the library code available online at all times. You can offer to provide the code whenever your users (and their users) ask for it: http://www.gnu.org/licenses/gpl-faq.html#WhatDoesWrittenOfferValid This is more work though; forking the repo(s) into your own account on GitHub is less effort.

SimonSchroeder

@sierdzio said in Qt for commercial use:

Yes. Although why people insist on this I don't know. Qt already has a public clone on GitHub, it wills stay online even if Qt Company goes bankrupt.

But if GitHub also goes bankrupt then everything is gone. The ideas behind the rules are a little older and maybe also outdated. My understanding was always that if you ship your software on a CD/DVD you also have to provide the Qt source on a CD/DVD (same medium). A download wouldn't do. If you provide the software as a download on your website, the Qt source has to be provided by your website. I don't know if the "internet" as a medium will do (legally) instead of "your website". This means that I don't know if having a clone of the Qt source on GitHub is sufficient if you are distributing your software through anything else but GitHub. (You should note that you don't have to have a copy of the repository, but only of the single version you used.)

This reading of the LGPL is also what complicates the question how you have to provide the Qt source code with an embedded device.

@RobertB said in Qt for commercial use:

Would it be sufficient to provide 2 versions of my app, one dynamically linked, one statically linked?

My understanding is that it is not sufficient. If you distribute a statically linked app you need to provide a way to allow to statically re-link the app. Technically, the dynamically linked and the statically linked version are two different apps. It is a lot easier to comply with the LGPL by dynamically linking.

sierdzio

@SimonSchroeder said in Qt for commercial use:

@sierdzio said in Qt for commercial use:

Yes. Although why people insist on this I don't know. Qt already has a public clone on GitHub, it wills stay online even if Qt Company goes bankrupt.

But if GitHub also goes bankrupt then everything is gone.

Yes, but such reasoning is just detached from reality, in my opinion. An endless, improbable chain of "what ifs". Both QtC and GitHub won't just vanish overnight, at exactly the same time. If things will start looking bad for them, you will have plenty of time to prepare and either clone or download an archive. And even if you miss that, there will be thousands of other people who will have the sources and will happily share them.

And since the license only requires you to provide the source code on request you can even just keep a tarball on some old and dusty HDD you have and only send it to somebody when they ask you to. It does not have to be sitting on your web page the whole time.

jeremy_k

@SimonSchroeder said in Qt for commercial use:

My understanding was always that if you ship your software on a CD/DVD you also have to provide the Qt source on a CD/DVD (same medium). A download wouldn't do. If you provide the software as a download on your website, the Qt source has to be provided by your website. I don't know if the "internet" as a medium will do (legally) instead of "your website". This means that I don't know if having a clone of the Qt source on GitHub is sufficient if you are distributing your software through anything else but GitHub. (You should note that you don't have to have a copy of the repository, but only of the single version you used.)

This reading of the LGPL is also what complicates the question how you have to provide the Qt source code with an embedded device.

I've never encountered this interpretation before, and believe it to be false. A quick reading of the GPLv3 confirms:

Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years [...]
[...]
d) [...] If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) [...]

SimonSchroeder

@jeremy_k Alright! d) says that if you provide your software as a download, then the download of the source (Qt's source in this specific case) can be hosted somewhere else. Good to know!

b) is the case with the written offer. But a) is the most relevant: It says that if you ship the object code (i.e. the application) in a physical product (and I would count an embedded device to be such a product) you need to ship the source code on a physical medium as well. Thus, download only wont cut it. Where I was mistaken in the details is that the physical medium does not have to be the same. But it has to be a "durable physical medium customarily used for software interchange". So, this means the Qt source does not have to be on the embedded device itself (or rather can't be as it is not "customarily used for software interchange"). A CD or DVD would certainly work. I would hope that a USB thumb drive or an SD card would to the trick as well.