[Qt-interest] Licensing

[Malyushytsky, Alex]

>> So why am I interested in statical linking?
>> For one, it is often the preferred method by the user - a single working executable
and not bunch of files and/or library dependencies.

Which platform you at?

AFAIK static linking is not supported on Windows at least with MSVC.
You are forced to link against dynamic CRTs.
You may try to change compiler settings, but I faced runtime problems in a few cases (repeatable) and support just stated that static CRTs are not supported.

So unless it changed recently or you want to fix Qt you can't have a single executable.

On the other hand I see a better reason why static linking is desirable
Since Qt 4.4.2 to Qt 4.6 I believe not only binary, but source code compatibility was broken at least two times.

How? I support a project which has one of the widget using native graphics, more of that it painting might be done outside of paintEvent with native API  ( code which does painting may be in a different process ) in order to provide user with dynamic evolution of the picture or with regular Qt way from pixmap when window needs an update.
To make it work paintEvent was overridden and some attributes flags were changed.
Now, with each new Qt version I had to update the code to make it work.
Fixing problem was not difficult - setting attribute instead of widget flag or override additional virtual function to stop paint engine to do double buffering which was not required in the previous version.
But simple upgrade to the new Qt version, even if user can rebuild application would not work.

As for me being able to have Qt code linked inside executable would be the main reason to do "Qt way static" linking. This can be achieved, even though it still will not be standalone executable, but you have to make sure you would not need any feature you will lose if you build Qt for static linking.

Regards,
  Alex

-----Original Message-----
From: qt-interest-bounces at trolltech.com [mailto:qt-interest-bounces at trolltech.com] On Behalf Of Kustaa Nyholm
Sent: Wednesday, June 02, 2010 11:03 AM
To: Thiago Macieira; qt-interest at trolltech.com
Subject: Re: [Qt-interest] Licensing


> I think that was not the point.

Yes and no. Than was not her point but my point was weather or not
static linking is allowed.

>The point was that anyone receiving your application can enforce the LGPL
>obligations on you.

As I wrote, I understood that.

> So Nokia's opinion is not the only one you have to worry
>about. You have to worry about the opinion of everyone you're giving the
>application to.

Correct.

>In the static linking case, I think the point is that any recipient could ask
>you for the right to relink the application against a newer version of Qt and
>you can't deny them that right.

I had no such intention (and all this is just academic discussion I'm not (yet)
in the position to link anything either way).

But my point is that I can statically link my application as long as
I do not deny the users the right to re-link it.

And I can do that with static linking if in *addition to*  the statically linked
application executable  I will distribute the unlinked object files of the
application as well.

 I was further speculating that under 6c I would not even have to
distribute those unlinked object files if I just promised in writing to deliver
them on request.

So why am I interested in statical linking?

For one, it is often the preferred method by the user - a single working executable
and not bunch of files and/or library dependencies.

Also, in an embedded environment statical linking has some appeal, at least
in particular circumstances.


> And no, relinking it for them is not an option.

Agreed.

br Kusti
_______________________________________________
Qt-interest mailing list
Qt-interest at trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-interest


---------------------------------------------------------------------------------------------------
Weidlinger Associates, Inc. made the following annotations.

“This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you.”

“Please consider our environment before printing this email.”