I slightly lament the rise of MIT or BSD licensed middleware like this. It's undoubtedly great for the developers and organisations in question, but there's undoubtedly some societal good from having GPL or LGPL licensed products encouraging organisations to release their code under a similar license. This already exists for Go and Qt, and the competing library is "soon" to release a commercial license that would be available for those who do not wish to use the LGPL. Nevertheless, huge props to the author(s) for what undoubtedly is a vast amount of work.
There's a whole handful of permissively-licensed, feature-matched alternatives to GNU Readline that I suspect only exist due to political aversions to its license. It saddens me that these people would rather waste time treading over the same paths others have just to increase the potential for nonfree software, rather than using that time to write free and useful things.
Well yeah, that's the old "open source" vs "free software" schism: Go itself being permissively licensed, there's a lot of interest in having libraries that also come with "no strings attached".
> Yes. You must also meet your Qt license obligations: either use Qt dynamically-linked dll/so/dylib files under the LGPL, or, purchase a Qt commercial license for static linking.
There is this misconception that you can't statically link under the LGPL. From my reading (non legal advice), LGPL supports static linking - you just have to release your object files alongside the binary to allow people to link them with different versions of Qt.
I also think that is legal. But if you are required to distribute additional object files, that does somewhat reduce the benefits of static linking - you might as well use dynamic linking in that case.
It's also not completely trivial to do this with the Go linker.
Nice, thanks. All the other Qt bindings seem abandoned. https://github.com/kitech/qt.go is interesting though, it uses a huge wrapper, and then FFI calls. Now we can use libffi with purego (there is already a library) so in theory such a method can be used for CGo-free Qt bindings.
A lot of kitech's work was in making the large C ABI wrapper. There's another C ABI wrapper already in Debian (libqt5pas) that might be possible to use directly.
Hi, author here, ask me anything. (Qt 6 branch is nearly ready.)
Hey, I noticed that you reference other implementations. What's the rationale for a new implementation?
Cheers
The main rationale is definitely the license. The existing bindings for Qt Widgets (therecipe/qt and kitech/qt.go) are LGPL. That's just really difficult to use in Go where static linking is the default behaviour.
The other bindings have some strange behaviours when I checked them closely.
- therecipe/qt: The design of the "qtbox" runtime for therecipe/qt, introduced before the maintainer went MIA. Now that we know the Jia Tan xz story, it's my hope that MIQT can be a "nothing up my sleeve" binding with a clear source code supply chain, with no prebuilt binaries.
- kitech/qt.go: The rationale for their version was to focus on compilation speed, but with GOCACHE this is no longer really a problem. It also seems to be unmaintained.
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
You can have the LGPL'ed code but the price to pay is that your users give your objects files (i.e. pre-link stuff; but not the source code) so that your users can modify the LGPL code and rebuild your project with the modifications.
Moreover: https://pkg.go.dev/cmd/link
So it seems that you can have access to the object files.
Overall, it is possible to make your bindings LGPL. I understand this is a bit trickier and not very user friendly.
Or you could dual license.
But well, it's a political choice, so I won't try to convince you :-)
Does this support Qt Quick and QML?
No(t yet), i've focused on the traditional desktop Widgets toolkit. There are other existing QML/Go bindings you might be interested in.
Qt Widgets has a lot of benefits over QML. It is native compiled code whereas QML is interpreted; the native compiler (qmlsc) is proprietary and only available for commercial licensees. If you are happy with a large runtime for an interpreted UI then I'd suggest looking at web technology (e.g. Wails) to enjoy the broader ecosystem effects.
Also, QML exposes only a fraction of the functionality of the Qt Widgets API.