Do Not Sign the Qt License Agreement Unchanged | Hacker News Reader

Do Not Sign the Qt License Agreement Unchanged

burkhardstubert.substack.com

174 pointsLorenDB78 comments

>Clause 11.3.2. The developers must also delete all installed copies of commercial Qt tools and Qt libraries. Qt customer can keep some developer licenses to continue the support of their End Customers. Bug fixing is OK. Adding new features is not OK.

Jeez I'd hate to be the engineer who has to explain in court that my change was a bug fix and not a feature improvement.

Why do people even buy QT Commercial? LGPL is a very easy license to comply with. Are there better tools for commercial users or something?

> Are there better tools for commercial users or something?

Some software components are only available via the commercial license (QtQuick3D is a big one, Qt3D is very barebones and you basically have to do everything via shaders). Also you get "support" which can be nice for new developers but doesn't get you very in-depth technical answers, at least from my experience. Booking support time/workshops directly via KDAB or Qt to adress specific issues is a better investment than paying the commercial license just for that.

QtQuick3D isn't only available via the commercial license. It's available under the GPLv3 too. And https://kde.org/community/whatiskde/kdefreeqtfoundation/ means that they can never make any add-ons that are only available via the commercial license (on penalty of triggering the failsafe that would destroy the entirety of their existing sources of revenue).

>Why do people even buy QT Commercial? LGPL is a very easy license to comply with.

Qt is used a lot on embedded devices (i.e. car infotainment systems, smart TVs, smart appliances, etc). Complying with LGPLv3 means that the user must be allowed to reverse engineer the product and upload a modified version of the software to the product. This blocks practices such as firmware signing, so a lot of companies would rather pay for Qt than comply with LGPLv3.

GPL 2 with the Classpath/Linking Exception? Still, not many do this.

Why would you need to allow modifications the binary und er LGPL? You will need to ship the source of qt and all mods you made to it, but that is it. Or am I missing sth?

You also have to allow the end user to make changes to the LGPL software running on the device.

Yes, you're missing the ability for the user to install and use the modified code, which is one of the main things that LGPLv3 introduced over LGPLv2.1.

Unless the software is written to ROM or otherwise made not modifiable by anyone, the creators of the GPL intend that the end user gains the right to modify this software. If using a version before GPL/LGPL/AGPLv3, it is ok if the proprietary parts of the system stop running if the software is not an official build. With the v3 versions, even this is not ok.

Now, I believe Linus Torvalds for example interprets the license differently, and doesn't believe that a company using Linux on an embedded system is obligated to allow their customers to apply a patch to this Linux system (and he certainly doesn't want the manufacturer to be forced to make their proprietary software run on top of the modified Linux, which is why he never wanted the Linux sources to be updated to GPLv3, even if it were feasible to do so).

OK, understood. One remaining question: is it enough to allow the re-linking to run in developer or emulated hw? Does LGPL e.g. forbid code signing of firmware?

No, according to the FSF and SFC at least. The goal is to allow end users to patch the GPL parts of their physical device. Whether the device has to keep functioning as before is more debatable, but being able to run the code in a separate, emulated, device is not good enough.

With the GPLv3/AGPLv3 versions, it is still OK to break the proprietary parts. For the LGPL in general, you have to be able to re-link, so that isn't OK I think.

https://events19.linuxfoundation.org/wp-content/uploads/2017...

This is still a matter of interpretation. Here is an exchange that this same author has had with Stallman about Stallman's opinion on the GPLv3 (and his intention) [0]:

> Specifically, I asked him on 2012-05-05:

> > [so], these words in GPLv3: “The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.” mean that the proprietary software that is not a combined work with the GPLv3'd work must also function?

> Stallman replied on 2012-05-06 with:

> > Absolutely. And I wrote it specifically to do that!

I don't think this has ever been litigated, so we don't know what a judge and jury would find, but I suspect that if they found Bradley Kuhn is right, there may be a GPLv4 that is more explicit about requiring the device to keep functioning as it was, not just as a dev board as he calls it in these slides. And that GPLv4 would apply automatically to lots of GPL software going forward (because of the "or later" clause that many projects are using).

I also think he is explicitly contradicting his earlier article to some extent. He also mentions in that that the whole original purpose of the GPL, as also told by Stallman, was to be able to fox your own printer by patching its code when you find a bug in it. It's clear that "turn the printer into a dev board by blowing a fuse" doesn't achieve this original goal at least - whether it achieves the license terms as written is more debatable.

[0] https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t...

LeanQt still has LGPL 2; never saw a need or advantage to switch to more recent versions.

That frankly makes me just wish it was legislated to be true. Sigh. Reverse engineering iot devices that are supposed to help you shouldn't be a necessary step but it looks like it increasingly is...

This is false, and one of the simultaneous boons and banes of the GPL family of licenses.

LGPL compliance is achieved purely by providing a copy of your version of the source code; if no modifications have been made to the LGPL portion, a simple link to upstream is sufficient, otherwise a “reasonable” means of getting the same code (full tarball, diff against upstream at some point in time, etc) is needed. The LGPL (and GPL overall) does not make any provision that the user MUST be able to replace the object binary, only that source is provided to enable doing so if you break whatever tamper seals are there for yourself.

Please don't make claims like "this is false" if you aren't familiar with the licenses you're commenting on.

Section 4e of the LGPLv3 says that one of the conditions for conveying a "combined work" (such as a proprietary application that links with an LGPLv3 library) is "Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version."

The relevant quote from Section 6 of the GPLv3 is:

> “Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

> If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

In summary, if you ship a device that is physically capable of running modified code, you must give users the ability to both link the LGPL'd library with your proprietary code and to write the resulting modified firmware to the device.

Bug fixes are technically improvements but I think the language is clearly referring to totally new features. Bug fixes refer specifically to unexpected errors within the existing design. Not a redesign or substantial improvement.

I have never had a Qt license but if you want to link a private application statically or get support, you have to have one.

Bug: the product is missing a feature that we want it to have

Tangential Qt rant:

After having worked with Qt (QML) on a daily basis (and quite in-depth, from using the scenegraph api to creating controls that with complex touch interfacing) I have to say I wouldn't pay a dime for the stuff you get with Qt. And even what they sell is almost never even close to worth it.

The underlying technology is pretty good, so the Qv4 engine, the OS-abstractions (sockets, networking etc) and so on. But all the library code ontop can be very hit or miss.

For example, they introduced new ways of handling touch events (DragHandler, TapHanderl, PinchHandler etc. etc.) which work GREAT! But they lack any way to stop propagation of events leading to them becoming utterly unusable if you have any custom "popup" things. There are also a lot of bugs with them which haven't gotten fixed in years even though they cannot be worked around. Paying for the product doesn't seem to even get you any further in that regard.

Using the open source Qt is the best option in my opinion, worst case you buy support sessions to adress specific problems but that's about it.

I mean every UI software, even the ones built into the different OS's has bugs like these. So what is the alternative? Throw Chromium into the code and build the UI with HTML and C++ backend? JUCE or some other UI package?

There really is not a ton of other options.

I think for most companies, paying for QT and maybe a few extra for bug fixes as needed makes sense. And lets you tone down the hardware expenses that say Chromium would require.

It obviously depends on your needs, if your software needs complex controls, responsive layouting and tries to achieve a smartphone-type UI, then yes I using chromium is the way to go with a c++ backend that does the heavy lifting.

Qt has a big advantage if your content is rather static and you can just top-down layout everything via anchors and rather fixed positions. But in those cases you also generally don't use complex controls that layer ontop of each other.

In my opinion it should be communicated quite clearly that QML is very good for "small" embedded UIs like for general home appliances, but if you are planning to create a rather complex application with demands like responsive layouting, custom data structures, interfacing with existing apis, then you far better off just using chromium with a custom backend. That has far less UI-breaking bugs.

Qt accidentally COMPLETELY broke lighting in Qt3d: https://bugreports.qt.io/browse/QTBUG-100402

That's something I find completely unacceptable and I haven't encountered something that application-breaking in chromium (yet).

Or just use Qt Widgets? Yes, the default sizes and styling might not be suitable but these are easily and fully customizable. The one disadvantage is that Widgets is not hardware accelerated.

Widgets seem far more robust and tested but from what I‘ve gathered pretty suboptimal for touch-first UIs and more modern design.

For the desktop I would 100% use Widgets over QML.

Flutter is another option for embedded.

Google continually lets the embedded community down. You can promise this time won't be the same, but I don't trust them anymore.

If youre a python dev, pygame is an often overlooked option, it’s quite nice if you're targeting a specific screen resolution. I’m using it in production….

That is why we can't have nice things, eventually developers decide there are better ways to make a living than contributing to products no one gives back, and there is a mortgage to pay.

> All these companies have in common that they didn’t read the Qt license agreement thoroughly and they didn’t evaluate alternatives to the QtDC license. They only have to blame themselves for their calamity.

Well, no. I'm allowed to think that the Qt company had something to do with it, even if you always have to be on guard when negotiating or signing legal agreements.

I'd counsel small businesses who do not have infinite time or legal resources to prefer Open Source products because evaluating the legal risk is cost-effective compared to evaluating proprietary alternatives. It's similar advice to what you get in this blog post, even though I'm not so cynical as to think "companies gonna evil" is a universal truism.

One thing both for and against GTK as an alternative to Qt is that Qt is not just a GUI framework, it's an application development framework. That means if you depend too heavily on it and later want to switch to GTK, you'll have to rip up a lot more than just your GUI code and you'll find that GTK doesn't provide alternative to those other things. IMHO GTK being limited to the GUI is a good thing and my main complaint is lack of respect for API stability as a key feature.

Big companies like Autodesk and Tesla are using the LGPL version of Qt without paying a cent to the Qt company.

It was a business mistake by the Nokia in 2009 to offer the non-commercial version of Qt as LGPL. They should just have continued using GPL.

Well, they keep making the commercial license worse, so if Qt were GPL, companies would probably just use something else.

isn't that at least partially due to the kde agreement? https://kde.org/community/whatiskde/kdefreeqtfoundation/

>> The core libraries of Qt (Essentials) and all existing LGPL-licensed Qt add-ons must continue to be available under the LGPLv3.

The original Qt-KDE agreement from 2000 was GPLv2.

might wanna add some context as to how that's relevant to the current time frame and situation

Nokia decided to use the LGPL and the KDE Free Qt agreement was then updated to specify LGPL.

I don't see how that knowledge is changing anything. We can only talk what is as of the qt company and just before

> It was a business mistake by the Nokia in 2009 to offer the non-commercial version of Qt as LGPL.

I don't think so. At the time I'm sure their goal was to have Qt as the development platform for all their phone hardware in time, while the profit would have come from phone sales. Using LGPL would have encouraged adoption by all developers.

What they didn't know in 2009 was that their hardware business will collapse. Or be collapsed.

I’m no expert, but this link says that you have to include install instructions:

https://www.tldrlegal.com/license/gnu-lesser-general-public-...

How are Tesla using it? If it’s in their cars, how do they comply with this?

I worked at a small company that used Qt using the LGPL version of Qt with paying a cent to Qt. I thought we should probably pay for it, but the terms of the commercial device license made that unbearable.

While Autodesk is a big company, I could see trying to use a commercial licence as impractical for them. If they tried, what would it mean for their no cost editions, what would it mean for their plugin developers, what would it mean for their customers who do custom development on to of it? I think the paid licenses would be a disaster in all cases.

(Shameless plug) If you're looking to go away from Qt, you can check out Slint https://slint.dev Being inspired from QML, Qt users should feel at ease. The license model is hopefully less constraining than the Qt one.

I played around with it for awhile but the generated code was awful for compile times. Have you looked into writing a proper interpreter instead of compiling to Rust, or optimizing the generated code for compile times?

Yes, we'd like to improve on that: https://github.com/slint-ui/slint/issues/4128

GPLv3 only. Qt at least has an LGPL option. So it seems more constraining.

There are 3 license: 1. GPL 2. Royalty-free (free of charge for desktop) 3. Paid license (which we hope is less constraining than the Qt commercial one)

That's a lot more than "seems" if it's GPL. That is "you need to release your source code entirely under GPL if you even link to this"

The horror!

Well not true anyway so don't wet yourself.

I think GP's point was that slint's commercial licensing is less of a minefield than Qt's, and the terms are straightforward and reasonable.

(I haven't verified this; this is just how I read the GP's comment.)

TBH for the GUI work I do, Flutter has been fantastic. Really great developer experience with hot reload and hot restart even on Linux. It’s a great technology and I think more people should give it a try

How is flutter when I already have an extensive c/c++ code base?

I can't speak to that personally but I found an article^1 that goes over using flutter with C++ and another that goes over debugging C++ with flutter^2. Flutter also has a template project that includes scaffolding for building C/C++ projects that can be asked from the commandline with

> flutter create --template=plugin_ffi demo_library --platforms android,ios,macos,windows,linux

Hope this helps!

1. https://dev.to/andycall/the-comprehensive-guide-to-using-cc-... 2. https://dev.to/andycall/setting-up-a-development-and-debuggi...

At what point do companies consider Android Open Source Project (AOSP, non Googled), primarily using Apache 2 license, over QT?

AOSP is an entire operating system with a GUI layered on top of it. Qt is a relatively straightforward tool for building embedded and desktop GUIs that happens to also have some cross-platform library support built in to ease the construction of these GUI applications.

It's like asking whether fish can breathe benzene when they are out of water.

To be fair, Qt also needs a POSIX API running underneath it just like AOSP does. So you're still on Linux for embedded devices.

I've tried building an embedded product with AOSP that isn't a phone or web browser. It was a massive pain in the ass. I hate the JNI.

I prefer to not sign this agreement at all (not even the contributor agreement) and recommend anyone asking not to do so; everything I need from Qt was there when it was made LGPL by Nokia. Today I work with LeanQt which still has the LGPL 2 licence version which is easier to handle (especially for embedded systems) than the more recent ones.

That license is, in my opinion, why wxWidgets is still around, despite wxWidgets looking like 90's desktops.

For me the main issue with wxWidgets isn't that software made in it looks dated - that's fine, at least it's not mobile first on desktop, with huge margins and whatever those new Windows 10 date pickers are - but that the development experience feels like it's straight from the 90s.

and it's definitely inferior to Qt. Sure, for 80% of things thy are mostly on par (provided you can bear the 90's look). But after that, there's a world between the two.

wxWidgets is an abstraction of different presentation layers, QT is a presentation layer. They focus on completely different layers.

I remember Slashdot arguments from all the way back in 1998 about the Qt license--over 25 years ago! Kind of astonishing to realize that controversy around licensing has been with this company for most of my adult life. To the point where when I see "Qt" the first thing that comes to my mind is "License Tomfoolery."

I don't see why people lose their minds about the "tomfoolery". It's very clear what the Qt company wants, and how that's good for everyone. If you want to use Qt, you have to support the free software movement either directly (by making your code foss) or indirectly (by paying for the non-LGPL use and supporting Qt).

> If you want to use Qt, you have to support the free software movement either directly (by making your code foss)

That's the problem. No matter how many times Digia threatens you, the LGPL does not require you to make your code open source.

You're either confusing the L and non L GPL licenses, or you remember the situation from before Nokia bought Qt. Trolltech Qt was indeed GPL (without the L) plus commercial and what you said would have applied. However, it does not apply now.

Imagine a world were GNUstep was pushed instead of GTK. Today GIMP would be rebased into Cocoa and made multiplatform with ease. It would be the GNUstep Image Manipulation Program.

Even legacy systems could be running a GNUStep desktop thanks to having multiple settings: a modern one a la OSX/Etoile; and another one with classical NeXT widgets without fancy effects.

Heh, a lot of wx/c++ software has been ported to QT for obvious reasons.

Seems reasonable to me. I think this is a lot of FUD. I've never had a Qt license, but nothing here scared me off from getting one.

"ten thousands of companies have built fantastic products with it"(LGPL Qt) -- any data to back this up? I doubt it myself.

the license mess at Qt is why I never touched it over the years.

Doubt what? QT is very popular. Just look at video game launchers, Battle.net, EA Origins, all use it. VLC, teamviewer, telegram, tesla UI, etc all use it. I can list about 100 different apps without even trying.

Google Earth (sadly propietary), and I wish KDE/QT Marble had bindings to display Street View data as 3D projections.

Also, Virtualbox...

Anecdotally I can name 2:

https://slint.dev/success/sksignet-evcharger#story

https://www.qt.io/blog/2015/12/15/ableton-push-qt-in-music-m...

Qt is amazing business. Somebody is buying. Double digit growth rate year after year.

  - €200M net sales
  - 1.5M developers, 
  - 3,500 commercial customers
  = €150 per developer/year
  = €60,000 per customer/year 
  - €2.2B market cap.

Well, it's easy when you're the only decent [1] cross platform UI library left on the face of the earth that does not instantiate a browser. Also the only option to get a lot of infrastructure pre done for embedded projects.

[1] My friends who still do Qt whine occasionally about quality going down, but it's not like they have other options.

These guys were pretty good when I used them: https://www.cranksoftware.com/storyboard.

I used to look down on Crank like it was the next coming of Flash Lite, but after finishing a project in QML and realizing most of the heavy lifting was connecting the Javascript components to business logic C++ code running underneath through their clunky interface methods... it's pretty much the same thing.

And I bet Crank will actually run on a Cortex-M3.

Crank doesn't scale. The project is a binary file. You can't have multiple people developing screens. Its fine for small projects, anything big and it falls apart.

"Get a quote." Cue Bugs Bunny: "Nooooo."

"Someone" in this case is almost the entire automotive industry, among others.

which could be overtaken by AAOS(android auto) down the road?

For infotainment certainly, maybe not for instrument clusters, especially in base model or commercial vehicles.

Reply on news.ycombinator.com