Show HN: Qt binding for Go with support for all major operating systems(therecipe.github.io) |
Show HN: Qt binding for Go with support for all major operating systems(therecipe.github.io) |
I recently stumbled over this project and have been using it quite a lot since. It works really well and coming from Qt-land it was really easy to use the provided bindings and generate the 'classes' for signals/slots. AND the docker images are great for cross compilation. They just work :). Thank you so much for working on this.
I've been planning on using an embedded webkit + html app in an upcoming desktop project. Are there any resources for how difficult it would be to learn Qt and create a reasonable portable, easily downloadable app?
Here [1] are some infos about QML development and here [2] you can try out QML in the browser.
[1] https://github.com/Esri/arcgis-appstudio-samples/wiki/Unders... [2] https://qmlweb.github.io
If you pay for a commercial license, you can link statically without restriction. The commercial version is also necessary for locked-down platforms like iOS where the dynamic linking can't be changed by the end user of the software.
IANAL, and there are a few details I glossed over, but that's the simple version.
In essence, you can use it in proprietary application as long as you don't modify the library and you provide means to switch to different version of the library.
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
Edit: er, why the downvotes for a harmless question? I was curious why a flag named fast is not the default. This question is also very much related to the project page linked.
It's a trade-off between deployment speed and quality, like compiler optimizations.
https://github.com/therecipe/qt/blob/053d54a2eb0658bae6e3259...
All of the code is cgo wrappers around messes of c/c++
E.g. your project has `type Qt interface {`, and the plugin exports a global symbol that can be asserted to that interface to use the library.
Qt used to have an XML markup language that auto generated C++ UI code.
Later, QML was introduced - which is a JavaScript based UI runtime.
There are Qt bindings for other languages, for example Python. So you could write business logic in Python and UI in QML.
FYI, the 'examples' link on that page is broken
So, I think there are absolutely no limitations to using Qt LGPL in a commercial application. All you get from the commercial license is support.
Note: I'm not a lawyer, don't hang me if you get sued or something. But I do think I'm right about this.
I thought you were required to allow linking to a newer or modified version of a LGPL library? So one limitation is you have to either dynamically link or provide a mechanism to relink.
I was trying to be conservative and paint a simplified picture of the license that you can't go wrong by following, but I definitely erred in leaving out some possibilities and presenting it as if they don't exist.
So, yes. You can use MIT.
Of course, the dynamic dependency still remains LGPL.
For example, you must deploy as a static linked Qt on the Apple App Store, but since Xcode is free and no Apple dev account is needed to install an app on your iOS device, you can provide instructions for how any user could install your binaries with any version of Qt. Unlikely any user would ever do this, but by making the process publicly known, you honor the license (and you don't need to share your own source code).
For the Mac app store, it might be different, as you need a Mac to access that anyway.
FWIW I think the issue here is that artificial limits on what code can be run on what hardware (legally) is in conflict with the (L)GPL -- and there's really nothing anyone other than Apple can do about it. Which is also why, as far as I know there's no actual legal way to distribute (L)GPL software on these locked app stores - there's no way for the distributor to actually honor the license, and so no way for them to be able to (re)use/distribute the code legally?
This linking restriction is not a part of other product-scoped copyleft licenses like the MPL and the EPL.
Google has now killed off Sparrow entirely, but they used to make it available for download so that an end-user could in principle re-link it, to comply with the LGPL.
This sentence is missing a "closed source". If you license your application under GPL, you will have none of these problems.
If you link statically, you also have to make your object code available for relinking if needed. But that generally comes down to doing something like "ar q libMyApp.a *.o" and then the user would make the app with "gcc -o MyApp libMyApp.a -lQtWhatever".
If you distribute as some package (like .apk for android), you'd have to make it possible for user to change the library. Simply allowing users to download .apk files would make it work, since they can unzip them, change the library and rezip them back.
So, I wouldn't really call those "limitations". Just pesky things you have to do if making a commercial app with lgpl lib.
Oh, and there is no requirement to link with a newer version of the library, to the best of my knowledge. That's generally impossible since newer versions might (and do) deprecate features that were available in the older versions.
It would appear that once again the FUD is unjustified, and in reality GNU/SFLC licenses well made