Qt and commercial usage

[aleksjej]

Hi,
I a little bit confused about Qt commercial use. I am going to develop an commercial app that would use Qt. I am not going to public application source code and not going to introduce any changes to Qt itself. The question is: do I and my company have to pay for using Qt? or in compliance with LGPL I can use Qt for free to develop proprietary applications? And I I have to pay how big the cost would be for developing application for mac, win and linux by 5 developers?
Thanks in advance

[wysota]

If you link dynamically, you can probably live with the LGPL version.

[mtrpoland]

I have read the LGPL 2.1 licence and I am a little puzzled.

As far as I understood, any "work based on the Library (LGPL'lled)" is being "poisoned" with LGPL.
If we treat subclassing of a 'QFrame' for instance (in order to create our GUI), as a modification, it means that we have to public our 'OurFrame' class code on LGPL conditions. It would mean all the GUI we've created, needs to be treated as a "work based on the Library" which entails being "poisoned" by LGPL.
The modules we are permitted to close on our terms are these which do "contain no derivative of any portion of the Library, but are designed to work with the Library by being compiled or linked with it, are called a >>work that uses the Library<<." (5. LGPL 2.1)

This would mean that all custom widgets we paint fall under LGPL.
We then need to treat it as a new modification to LGPL'lled Library and enable it to work without strong constraits to our proprietary code. (2. LGPL 2.1)
We can close the "buisness logic" that only communicates with GUI modules, that only uses LGPL'lled modules but is not based on them.

Finally we actually sell our proprietary module combined with our LGPL'lled GUI library which means anyone can take 'our' GUI module and use it with their "buisness logic".

This is how I understand LGPL 2.1

But I am only an unexperienced undergraduate student.

Please fix my wrong comprehension...
:-)

[wysota]

As far as I understood, any "work based on the Library (LGPL'lled)" is being "poisoned" with LGPL.
Yes, but using a library is not a "work based on". It means if you modify an LGPL component, it has to be released under LGPL as well.


If we treat subclassing of a 'QFrame' for instance (in order to create our GUI), as a modification, it means that we have to public our 'OurFrame' class code on LGPL conditions.
We don't. If you modified QFrame then you'd have to release source code of your modifications.


It would mean all the GUI we've created, needs to be treated as a "work based on the Library" which entails being "poisoned" by LGPL.
The modules we are permitted to close on our terms are these which do "contain no derivative of any portion of the Library, but are designed to work with the Library by being compiled or linked with it, are called a >>work that uses the Library<<." (5. LGPL 2.1)

This would mean that all custom widgets we paint fall under LGPL.
Derived work doesn't mean inheritance in terms of object oriented languages. It means you can't take LGPL code and put it into Windows code (like it did happen with BSD code).



The thing you mention only applies to template classes but there is a special exception for this case in Qt's licence.

[mtrpoland]

Do you have any links to well-crafted articles touching that matter?

These are the good news. :-)

By the way, what now differs commercial and LGPL licenced Qt in proprietary usage?
Not counting wider range of components of the former and support(?).

I found "work based on the Library" quite vague...

[wysota]

Start here: http://www.qtcentre.org/forum/f-qt-software-16/t-qt-45-to-be-released-under-lgpl-18024.html