Your last sentence is a bit hard to comprehend but not paying for Qt and shipping a commercial embedded product is pretty difficult due to the anti-tivoization clauses of GPL3.
I agree with parent poster that flutter is very interesting for Embedded GUI development.
It's really easy to ship commercial Qt app with LGPL3 (except few modules that are GPL3) You just provide sources or linkable object files.
Qt intentionally avoids explaining how to do this because they are selling commercial licenses. If you are in software business and can't figure this out, maybe you should consult someone.
(disclosure: I own commercial Qt license and stock in the company)
That is really easy as you say. What you seem to have overlooked are the implications of doing this. You are forced to help customers replace the Qt libraries in your product. That has quite large security/warranty implications.
So ... no thanks!
I do contract work for a company licensing Qt5. I'm hoping for Flutter or something else to kill Qt in the long run.
I think I'm allowed for the tone when you respond with the following:
>You are forced to help customers replace the Qt libraries in your product. That has quite large security/warranty implications.
The above is completely wrong.
You develop and distribute your closed source software and link it with QT libraries like you would do normally. Nothing is needed from the customers.
Your closed source software can be statically linked to LGPL binaries (to fix another common misconception).
What is needed from you is a way for the customers to get things separately. It can be written offer, link to files in the website (used to be directory in DVD). You can be almost 100% certain that your customers will never use or notice this option. It's just there to comply with the license.
You don't agree that you need to provide a way for your customers to replace the Qt libraries? (because that is a fact of LGPL3, read the anti tivoization clause).
Do you see any possible security problems with the above?
Because in reality it means that you give your customers the possibility to run their own code on your hardware. That is a problem for many companies and products.
>You are forced to help customers replace the Qt libraries in your product.
Depends on what you mean by 'help'. You are forced to give the opportunity for them to do the work if they need it. If you have statically linked files, it can't be done by accident.
> Do you see any possible security problems with the above?
No I don't. When I provide completely closed binaries for my customers, they can hack with the binaries and create security problems if they want to.
Software security is not improved by obfuscation. If you don't want your customers create security problems, you don't allow them to modify the software in your hardware.
Btw. I'm confused by your wording. I'm suspecting that you have some underlying assumptions you are not stating. Are you thinking that LGPL forces you to allow customers to modify the software in the hardware they are buying?
I think I'm clearly stating my assumptions. GPL3 and LGPL3 requires you to enable the user to replace the GPL/LGPL3 code on your device with the users own version of said code. It does not matter if you link statically.
Now, it would be possible let the user do this and not let it be a problem for your product (in terms of security, reverse engineering, ip theft, etc) but it is more and harder work.
I have used both older version of Qt (LGPL2) without licensing and newer (LGPL3) with licensing in commercial products. The former was not a problem. But using LGPL3 Qt without licensing in a commercial embedded product is a headache (if you are concerned about the problems it might bring), according to me.
> 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).
- If you ship embedded product where the code is not supposed to be easily upgraded, you don't have to provide means to do that. Anti-Tivoization applies to cases like TiVo where they added DRM to prevent users from upgrading but allowing you to upgrade.
- Also, anti-Tivziation clauses don't apply software distributed to business. Medical devices or safety critical software etc. Any devices sold to business.
> 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).
Also, anti-tivoizaton clauses does not apply to devices sold to business.
Good point, forgot about the latter part, that probably would help in some cases. Gotta ask some licensing experts about that one.
From what I see, only a tiny part of the potential market for embedded Qt and things like that can get away with "no updates possible", but still, applies for some.
JavaFX is fully open source, it doesn't need licensing. It also supports hardware acceleration, embedded usage on Linux, animation framework etc. Also, fits well with kotlin.
Flutter is very similar to Qt: signals and slots are similar to streams and sinks, and the BLoC pattern is similar to the state machine paradigm in Qt. I've been loving Flutter and Dart, developing with it seems almost too easy.
