Hi, Warning: I am NOT a lawyer That said, and to the best of my knowledge, you have to provide requesters with the object files generated at compilation time so that they can link modified versions of Qt if requested ☺️

Some time ago Qt published webinar concerning the topic, which helped me a lot. I am adding a link for future readers: https://resources.qt.io/videos/complying-with-the-requirements-of-the-gpl-lgpl-v3-license-on-demand-webinar

@Eeli-K That would mean you can't use github at all then since it isn't under your control. If github is considered "under your control" you can just fork Qt to your github account though. I mean along these lines though no web server you don't actually own is truly under your control. And even then you are at the mercy of your internet provider even if it is physically your system. My company has quite a few web servers, but since things like AWS came around I don't buy actual hardware any more. AWS is not technically under my control even though I have root access to all the systems that are "mine". You're right though. I don't think it would really be an issue, but people have sued over smaller things. The safe way is definitely throw up a copy on your own web server. Knowing it will never be downloaded by anyone just seems to make it such a waste of resources though.

@tekojo I knew something wasn't right :D

@Exotic_Devel, acredito que não seja culpa do open source, por que: Qt usa duas licenças, a Comercial e a LGPL. A licença LGPL diz que: o. Em caso de ligação dinâmica, então o teu desenvolvimento (o código que você desenvolver) é "trabalho que usa a biblioteca". Sendo assim, o código que você desenvolver apenas usa as bibliotecas Qt, então seu código pode ser proprietário. o. Em caso de vinculação estática da biblioteca, o próprio aplicativo é "trabalho que faz parte da biblioteca". Qualquer ligação estática com uma biblioteca LGPL, obriga a fornecer o código-fonte do aplicativo para o usuário sob a LGPL. Então do meu ponto de vista, se existe um culpado, é a Apple! por não permitir vinculação dinâmica! Hora, bastava permitir que resolveria a questão: Quem estivesse sobre licença comercial, faria o vinculo estático; Quem estivesse utilizando alguma biblioteca open, então faria o vinculo dinâmico. Não é novidade, isso só reafirma que a Apple não é muito edepta do opensource. :-)

@SGaist said: Where did you got these informations ? Nowhere. I just wanted to make certain that this was not true. Your extra information about the Apple Store is very useful -- thanks.

Hi @mrjj & @JulienMaille, Thanks to both of you for your comments. I was clear on publishing my changes done in Qt sources if working with LGPL license. What I misunderstood was the licensing for applications developed using Qt. I was under the impression that an application used for proprietary usage (irrespective of linkage - dynamic or static) requires purchase of license. The truth is that if an application is developed using dynamic linkage with Qt libraries, then purchasing of license is not required. Please correct me if I still got it wrong. Regards, Anant Agrawal

There's an interesting post on the Qt Blog which makes a case for how some things about licensed Qt make reverse engineering and hacking more difficult: https://blog.qt.io/blog/2015/02/17/qt-weekly-26-protecting-your-application-against-hacking/ Some of the arguments are more convincing than others. I'd be curious to know of any evidence - even anecdotal - of this stuff actually going on. Security and hacking and infosec is a serious business for sure, as is crackability of $100s-$1000s/seat licenses, but for most of us the idea that some team somewhere is waiting to pounce on my FooBar App, rip it's QML and plugins off and put out their own SuperFuBahPlus App is fairly incredible... isn't it????

@scrolling said: But, what does "dynamic linking" means? It applies only to Qt linking. This means that you can use LGPL version for closed source software only if you link dynamically QT libraries