It feels like every six months they completely revamp the licensing program, and the LGPL version always seems to suffer from a corporate sword of Damocles
What they have done in last year is to retreat to the minimum they need to do to comply. They can't stop distributing the LGPL version or alter the deal anymore.
Unlike what you hear you can make commercial closed source software and link LGPL binaries dynamically or statically, makes no difference. You just need to have to provide linkable object files to comply. Just stuff them into some /gpl_comply/ directory and be done with it.
1. When was this entered into
2. What there "good and valuable consideration" exchanged and what was it?
3. Are there any other projects in an agreement like this?
Edit: Great resource, still reading through it and the many links: https://kde.org/community/whatiskde/kdefreeqtfoundation/
It's not hard at all. You can add them to some directory with your app, or they can be behind some url, or you can mail them physically in a USB stick to anyone who requests them by mail or phone.
You just have to be able to provide them if somebody wants them. In reality nobody ever wants them. It's just some directory with gpl-stuff/ you add to your software.
How hard it is to have some binaries lying around?
You mentioned LTO. Don't the LLVM and GCC LTO implementations currently involve outputting compiler IR to object files, then running the optimization passes against the full collection of object files prior to linking? So they inherently collect all the object files together in a linkable form.
(Of course, it's probably more efficient to just dynamically link Qt and pay for a license if you want to publish for iOS.)
- For CLI apps, Rust has a better event loop, better language, more libraries, and is easier to deploy
- QWidgets seems like it's not "cool" anymore, and I don't feel like learning QML. I liked QWidgets because it was mostly the same from Qt 4.0 through Qt 5.0.
- The commercial side has no financial interest in adding cool new features to the LGPL code
- So how long will volunteers keep fixing the LGPL side, when their work is funding a business that does not help them?
- I'm waiting to see how Copperspice (A Qt fork that cuts off support for older C++ versions and uses STL and UTF-8 aggressively) turns out
About 10 years ago, Qt was my _jam_. I did everything in Qt. Games, CLI, GUI, IRC bots. I think I tried to build a Qt web server a couple times. For a kid who hated Windows and web stuff, it was my gateway to event loops and modern programming concepts. I just quit loving it. It's still in use at work, but I'm making plans to back out of it. Oh well.
Copperspice forked at the time of Qt 4.8 and has had since then a couple thousands commits from a dozen contributors - in the meantime Qt itself had literally tens of thousands of commits, bugfixes, new features, etc from hundreds of contributors
As far as I know, it's not 'indy devs' supporting the LPGL, rather the LPGL is merely a term of release of the regular, mainline branch. It's the 'same code'. Am I missing something?
It's been around for 7 years and is maintained by two people as opposed to a publicly traded corporation (Qt) with hundreds of employees. It has already turned out.
There is no alternative to Qt. It is the best in its class.
But you don't need it. You don't need Electron either. Just build a .NET application for Windows, a SwiftUI one for Mac, and a ncurses one for Linux. They can all share the same business logic code (if it has any), either via C ABI, IPC, or RPC. Your application will always be at the bleeding edge with the latest security patches and accessibility this way, as opposed to waiting for the next Qt/Electron release which is guaranteed to be later than the OS bugfix. Imagine if desktop OSes release, in addition to dark mode, a pink mode. Do you want your application to stand out as the ugly duckling?
Nurses as an alternative to a QtWidgets GUI app? I'm not sure you're serious.
I've been using linux both professionally and for personal use for over a decade and, with the exception of working over ssh, the thought of using ncurses apps over good old GUI apps is so outlandish that it doesn't even register in the realm of possibility.
Your comment sounds like a meme of how linux users are detached from the real world with regards to usability.
Pay for Qt or pay for developer time to maintain multiple versions of your UI. Your pick. Qt is probably cheaper in most cases.
My concern is that I don't trust Qt Company now to not change the rules on me later, or hike the price, etc. I would choose Qt for commercial solely because I already know it from building FLOSS apps. If I need to learn something else for FLOSS, I'm not going to stick with Qt. There's limited space in my brain for expertise and I want something that will meet all needs.
Qt is amazing and I love it, but an amazing thing I love but can't use/rely on isn't worth much.
CEF is geared toward native C++ and is probably more of a Qt alternative than Electron in that regard.
When I run command "ldd" on my Spotify GNU/Linux client binary, I see "libcef.so". And, I can see:
$ ls -l /usr/share/spotify/libcef.so
-rw-rw-r-- 1 root root 147980856 Sep 15 06:13 /usr/share/spotify/libcef.so
That's a big library!
It seems really weird to me how "but teh licenz" is brought up every time with Qt, when Qt itself is available under the same licenses as all the other toolkits like Gtk, wxWidgets etc.
This doesn't quite apply for embedded development (as LGPL's Tivoization clause might start to bite), but 1.) neither Gtk nor wxWidgets are viable in that space anyway 2.) considering that other people here found that Tesla manages to ship their car firmware with LGPL Qt - well. Can't be that hard to comply with it. Also, 3.) while we're used to free tools and libraries for desktop development, it's much more common to pay for tools in embedded development.
Why would you say GTK isn't a good option for non-Linux use? And would you say that it is a good option for Linux?
You need something like MSYS2 to even use GTK on Windows, and I've looked at what it takes to package and distribute GTK applications to Windows users without MSYS2, and it's headache inducing.
When it comes to Linux, it's pretty good. Getting its GObject Introspection dependencies compiled is another story, though. I've always had to rely on my distribution's package manager to install them.
FOX is really fast and looks OK, but I don't think it's very actively developed, and binding to C++ seems like a pain. And I'm not sure it supports CJK input methods.
I looked at EFL out of desperation, but that's pure style over substance and the complete opposite of what I'd want.
Theoretically, the LPGL should enable commercial use, right?
Are there specific barbs in the wire that Qt has placed, or is it merely a situation of lawyers afraid of grey areas?