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

Dr. Giovanni A. Orlando gorlando at futuretg.com
Fri Nov 7 09:53:49 PST 2003

Theodore Ts'o wrote:

>On Fri, Nov 07, 2003 at 11:16:41AM +0100, Dr. Giovanni A. Orlando wrote:
>>I am not agree with you. It is clear that if a company includes a
>>new Linux kernel and had included Qt ... and/or Gtk ... nothing
>>happens, and the panorama remains, untouched, like now.
>A company that ships a Linux kernel does not include anything of Qt
>and/or Gtk.  Indeed, a company doesn't need to use Qt *at* *allI* in
>order to compile a kernel.  Most of them don't actually --- since they
>use real hackers, and real hackers tend to prefer to edit the .config
>file via vi or emacs, and then run "make oldconfig".  I've never,
>never, never built any of the GUI tools for configuring the kernel,
>because it's so much faster to edit the .config file directly.
If you to maintain kernel recompilation between a group of hackers,
this is your mind, and probably what you want.

I suppose and hope that the Linux Kernel re-compilation may be available
also to childrens, yes childrens, (I 7-years children comment to me time 
... however, to everyone and to the masses.

Also civil engineers, architects, and other middle people like them that 
approach computers.

You prefer to edit .config, others have no time for this. Anyway each 
may need to be free to apply things
lilke prefer.

>That is what makes the difference between the kernel's ***optional***
>use of Qt, as a configuration tool, where the shipped kernel binary
>does not include or use Qt AT ALL, and including Qt in the LSB, which
>would implicitly cause ISV's to assume that they are free to use that
>library in commercial applications --- which in fact, they would not
>be able to do.
>>>>... And there are no other way to configure the kernel graphically, 
>>>>This is not optionally, but the only possible choice.
>>>That is wrong, and you have already been told so. There are five ways to
>>>configure the kernel: edit .config directly, make config, make
>>>menuconfig, make gconfig, make xconfig. Two of those are graphical.
>>>(Three, if you use a graphical editor for .config. Four, if you consider
>>>make menuconfig being graphical, which it is. It uses ASCII and not
>>>pixels for its graphics, but it is graphical.) Only one of those
>>>requires Qt. AFAIK there are even more graphical kernel configuration
>>>programs, which are not distributed with the kernel source code itself.
>>(See above)
>See above.  Again, you're wrong.  I suspect that over the 12 years
>that I have been building kernels, I have built several orders of
>magnitude of kernels than you have
Ted, you are moving the discussion to personal. I am sorry for you. :-*

This is not the question, if you or me, are capable to compile or need 
this or other tool. This is not the point.

The question is clear: The Linux Kernel reflect, in a wide mode the 
GNOME/KDE alternative
and you need to play attention on the ball, not on other things, that 
are not in discussion.

... And this is wrong for me.

If you read a past reply, just last one, Joerg W Mittag 
<Joerg.Mittag at GMX.Net> and also "Nils O." Selåsdal <nos at utel.no>
fix the point better than me.

Trolltech must release the Qt version, only under GPL, allowing also 
commercial development without to get money.

... But this is a Trolltech problem and a forcing behaviour to them.

LSB may re-evaluate the Qt, if they choose this way. I don't beleive 
they will do, so the panorama will remains like now.


>, and not once have I ever built it
>using the Qt code, or used a kernel that included the Qt code, and or
>even had a system that had the Qt development on the code.  Sure, the
>kernel sources may include optional, not-ever-been-used-by-me code
>that happens to makes calls into Qt (as well as GNOME, now), but
>that's completely irrelevant from a copyright standpoint.  
>>>>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
>No, the way people are configuring the kernel, it is perfectly legal
>to use GPL'ed code, whether it be Tcl/TK or Qt, because they are not
>shipping any code which links against these GPL'ed libraries.
The program "qtconf.cc" needs a library that does not belong to LSB. 
More easy for you?
What you replay?

It is clear you super expert will configure the kernel with telekinesis, 
(without to touch the keyboard, but with your mind)
but this is not the matter.
I will happy if a secretary (poor example, sorry for the secretary, they 
are fine), may recompile the kernel
in the same way they use MS Word (don't attack me for MS Word), or just 
any other software tool.

I appreciate what kernel maintainers simply it, including a more 
effective kernel re-compilation, graphically. Thanks to them.
I plan to still simplify this matter, and some people knows my idea it 
from Comdex 2000, including some reporters.

... Probably my posting will not have a future and things will remain 
like before. But my point was clear! :-)  ... very clear ;-)


>The difference is that the way commercial ISB's use LSB libraries is
>very different from a licensing requirement than from how people who
>are using kernel configuration tools use the GPL'ed code.  If you
>don't understand this, go talk to a lawyer.  I assure you that people
>who are configuring the kernel are doing so on very solid ground, and
>do not require any kind of commercial license.  However, ISV's wishing
>to ship applications that use the Qt application would require a
>commercial license.  And this is currently considered not acceptable.
>>>>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 software.
>>>>This will solve the problem, I think.
>Fundamentally, the LSB is not just for free software.  Part of the
>LSB's goal is to make it simpler for ISV's to write commercial
>software that will run on Linux.  If we don't give them an easy way to
>do this, companies like Intuit and Delorme will continue to only write
>commercial programs for Microsoft Windows.  And that would be a good
>thing to change.  And specifying the Qt works against this particular
>luadable goal.
>							- Ted
>lsb-futures mailing list
>lsb-futures at freestandards.org

More information about the lsb-discuss mailing list