[kristoffer]

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.

[Nokinside]

>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?

[kristoffer]

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.

Hence, I wish Flutter all the best.

[Nokinside]

Notice the exception:

> 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.

[kristoffer]

I am yet to see a embedded system using Qt that is not upgradeable.

And lots of embedded systems are sold to consumers.

In what way was I "completely wrong"? It seems to me you were the one who was wrong and now are grasping at straws...

[detaro]

> If you don't want your customers create security problems, you don't allow them to modify the software in your hardware.

How do you do that, while said software depends on LGPL3 licensed Qt?

[Nokinside]

from GPL v3

> 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.

[detaro]

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.