[thebruce87m]

You’re going to have to dumb that one down for me, if you care to explain.

My comment on the license was from an embedded perspective - if you do a bare metal product I believe adhering to *GPL becomes difficult since you have to proved the ability to update QT. Sure, there are ways to allow this but it’s not straight forward.

I’m not sure why I got downvoted for my previous comment - I mean, I just posted the license types.

[nine_k]

LGPL does not prevent you from using the library in a closed-source product, and recompile your software with a newer version of the library.

It only makes a difference if you alter the library. If you plan a proprietary fork, LGPL is not for you.

[akiselev]

Correct me if I'm wrong but all of that only applies to LGPL if you dynamically link the libraries and it doesn't apply to GPL proper at all.

When people say "embedded" they usually mean devices that run on low end bare metal hardware without an operating system (or even a memory controller!), which means nothing to provide dynamic linking, let alone the kind of end user control that the GPL philosophy is meany to promote. The vast majority of embedded software is statically linked by design so even the permissive parts of the LGPL don't apply.

[elcritch]

No the LGPL has a clause for dealing with static linking [1]. It's more difficult to do (as the comment above us mentions).

Using static linking requires you to provide program object files which can be relinked (and re-uploaded I'd presume). This allows the user to modify the LGPL file, and then relink the original program to the updated version.

1: https://www.gnu.org/licenses/gpl-faq.en.html