[lsb-discuss] Re: [lsb-futures] Qt libs ... included in the kernel 2.6 ... Why still blocked?

Dr. Giovanni A. Orlando gorlando at futuretg.com
Thu Nov 6 23:35:43 PST 2003

Theodore Ts'o wrote:

>On Thu, Nov 06, 2003 at 10:34:23PM +0100, Dr. Giovanni A. Orlando wrote:
>>>It's not blocked because people don't use it, it's blocked for license 
>>I know that very well ... But the Linux Kernel are using it!!!, in
>>other words if someone that wants to compile the kernel in graphical
>>mode will compile the file:
>>that requeries the Qt library. What is the situation in this case about 
>>the licenses?

>The Qt license certainly allows an individual who chooses to use the
>Qt method of configuring the kernel to use it, yes.  
... And there are no other way to configure the kernel graphically, 

This is not optionally, but the only possible choice.

I beleive that Qt must be active, you can also choose Qt (GPL), and 
leave Qt (Commercial) for commercial
purpose, to maintain.

Tcl/Tk was and is GPL, and allow to recompile the kernel graphically. 
Now, the choice
is Qt. Well, if you don't make changes ti the LSB, people are 
configuring the kernel
... in some 'illegal' mode ... in accord with actual

... Again

I suppose that ISV may change the state from Qt - Blocked to Qt (GPL) - 

>However, in the
>case of an ISV writing a commercial application, they may not be able
>to distribute code linked with the Qt license without first paying
>royalties.  The requirement of making an ISV pay large amounts of
>royalties to potentially dozens of entities is the reason for the LSB
>licensing criteria which requires a no-cost license for use by
>commercial applications.
>Whether or not the Linux Kernel uses Qt (optionally!)

> as a
>configuration mechanism is completely irrelevant to this particular
>>... So, actually both the Linux Kernel and Qt are at the same level: GPL.
>The difference is that commercial applications don't have to link with
>the Linux Kernel, so they don't have to pay licensing fees just
>because they are running their application under the Linux Kernel.
>However, this would not be true in the case of a commercial
>application linked with Qt. 
qtconf.cc is NOT a commercial application.

Again, because actually is blocked because licenses, commercial 
licenses, but Qt is also available under GPL,
you may enable Qt ... but Qt (GPL). And this means only the Qt when the 
terms are GPL and therefore for free

This will solve the problem, I think.


> We do not want to specify the use of a
>library where linking with that library may expose the commercial ISV
>to needing to pay licensing fees.
>I also don't think it's fair to make a group volunteers spend time
>defining ABI's to a library which requires commercial licensing, when
>all that would do is line the pockets of the copyright holder (in this
>case, Trolltech).  On the other hand, if Trolltech were to join as a
>FSG member, and provided the funding to define the ABI for its
>library, *AND* there was a zero-cost functional alternative to Qt/KDE
>(i.e. Gtk/GNOME) defined at the same time for use by commercial ISV's,
>it might make sense for the LSB workgroup to make an exception to its
>criteria.  But this would have to be an explicit workgroup decision,
>based on these special circumstances.
>(n.b.  This is me speaking with my own personal opinion, not as an FSG
>board member.)
>						- Ted
>lsb-futures mailing list
>lsb-futures at freestandards.org

More information about the lsb-discuss mailing list