The Y Window System Project have started while XFree86 4.3.0 now makes it in Debian Unstable.
Y Window System Project Started
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
49 Comments
2004-02-20 1:53 am
Anonymous
I will continue to use X. I dont think we will get a project up and running that could get the support X does now in regards to 3D support which will put us back instead of moving forward.
2004-02-20 1:58 am
Anonymous
Did some more research and yeah, apparently he’s hardened his position somewhat over the past couple of years (Amazing how many times this has been brought up on the kernel mailing list :>).
However he still seems to support binary modules where he feels they are appropriate (http://lwn.net/Articles/62464/). Like he says, it would be up to a court to decide whether or not a binary module is a ‘derivative’ work or covered by that get out of jail free clause in the kernel license.
2004-02-20 2:14 am
Anonymous
The font rendering seems to be quite good for a project that has started recently.
http://www.y-windows.org/images/y-screenshot.png
2004-02-20 2:55 am
2004-02-20 3:34 am
Anonymous
Except that’s not how X does it. With X, you’d say “blit this pixmap to location 0,0” or “draw lines here, here, here, and here.” Graphics are rarely sent pixel-by-pixel over the wire. As I pointed out earlier, server-side widgets solve a bottleneck that doesn’t exist. For windows that just use widgets (buttons, menus, lists, etc) toolkits like Qt are very fast already. The performance issues, when they exist, are for apps with custom widget (eg. Konqueror’s KHTML widget). Server-side toolkits do absolutey nothing to help that. On the network, it would seem like sending “draw button at 0,0” would be faster than blasting pixels (or even drawing commands) over the wire, but caching/compression technologies like NX manage to get the data-rate of the wire protocol down to a size comparable to what you’d get with a server-side toolkit.
——–
i’m sorry, you’re making excuses. there needs to be a standard toolkit. it’s just that simple. of course khtml would need to be done on the client, but that doesn’t mean the server can’t have a very consistent and fast serverside widget set. you give all these excuses about why it’s “ok” but you don’t actually say (and shouldn’t) that it’s better. because it isn’t. so you would rather use a worse desktop environment? that’s good to know. we need more masocist users like you to continually bring down the average computer user’s experience. i mean after all, who needs advancements and new ideas. it’s all good enough already!
——
The toolkit wars only exist among people who don’t use X on the desktop. For the mainstream of people who use X on the desktop, there is Qt, and GTK. Both use the same fonts, and work is being done to unify the themes. The remaining holdout is OpenOffice, and even that will be getting a native widget framework. Having two toolkits isn’t the greatest thing for usability, but it doesn’t seem to hurt the Mac (who has Carbon and Cocoa) or Windows (which has XP, .NET, and the Office toolkit). The only apps that use Motif anymore are proprietory apps that use a custom toolkit on every platform. Eg: XSI uses its own toolkit on Windows. Swing, also, is a seperate toolkit on each platform it supports. So every popular platform available today has a plethora of toolkits. What’s your point?
——-
carbon and cocoa are not two different GUIs they are two different APIs. big difference. their end look is identical. the only deviation on the mac platform is textured windows (which i hate.. and wish apple hadn’t done). windows is still better off than linux. there aren’t two competing GUI toolkits in OSX and windows, so your analogy is bad. .net, also, still uses windows widgets. swing is java’s interface, and it’s identical on every platform. the problem though is it’s not native on every platform, which it should be. you’re still making excuses for gtk/qt. i shouldn’t HAVE to wait for developers to merge themes. and no, the fonts aren’t the same. take a look at gtk using bitstream vera sans 12pt and qt using it. they don’t look the same. i do however agree about office’s bonehead move of using a new toolkit after every release, and this is microsoft being stupid. they aren’t exactly the model of good design.
——
Yeah, changing resolutions on the fly was something long overdue for X. Just like adding support for network transparency (RDP) was long overdue for Windows. Each windowing system has its strenghts and its weaknesses. The resolution weakness has been resolved in X (and I don’t know about you, but it works just fine on my machine) now, so you can stop harping about it. As for multiple monitors — X has excellent support for multi-monitor configurations via Xinerama. Do you have a specific complaint about it?
——-
my point is simply this: can you change *everything* with X without touching the config file? why do i have to touch the config file at all? why the hell can’t X just auto detect things like knoppix the first time it’s ran. knoppix does a fine job, and we should take their work and put it to good use. last time i checked i never needed to touch a text file in windows or os x to change anything desktop interface related.
2004-02-20 3:52 am
Anonymous
X has horrible multi-monitor support, IMHO. Horrible being that I’ve tried to get it to work, and it doesn’t 
Tried ‘XFree86 -configure’, hoping it would auto-configure it. No go (crashed). Tried manually tuning the config file, and it worked, but on one monitor the screen moved instead of the mouse…
In searching for help on the topic, I’ve seen multilple other users complaning about similar experiences, but not many articles offering any feasible resolutions…
2004-02-20 9:32 am
Anonymous
Last time i checked i never needed to touch a text file in windows or os x to change anything desktop interface related.
And this is the crux of the matter of one of big big annoyances with Linux on the desktop. All desktop settings should be accessible from the desktop.
Don’t get me wrong, I run Linux on both my desktop, my laptop and all my servers, and I’ll shoot to kill if anyone tries to touch my apache or exim configuration files with anything but a text editor – but for the love god, why must people insist on editing text files to change the resolution or change the font size? I know that this is much better than it used to be, and even things like fluxbox now have fluxconf – but it’s like this insistence of using screen scraping to interface with cdrecord. It’s very useful to have a CLI interface, but making everything interface with it that way is an ugly hack, and more to the point, it doesn’t work properly! This is the 21st century, lets start acting like it.
2004-02-20 10:12 am
Anonymous
there needs to be a standard toolkit.
I don’t think so. Users don’t mind about the toolkit. But they mind about a consistant look’n’feel for applications. Having this would probably speed up Linux adoption a lot.
Right now, users solve this pracmatically I believe: If there’s a GTK/GNOME based application with nearly the same functionality as a QT/KDE based app, I de-install the later. The same holds probably true for QT/KDE users and is one reason for the success of KDE-apps.org
The distributions seem to agree not to use XFree 4.4 – hopefully there are clever enought to agree upon one and only one successor otherwise the split might get stronger.
2004-02-20 10:23 am
Anonymous
I found this howto pretty straightforward:
http://www.scii.nl/ascii/projects/3hm
Haven’t used it yet, but i will soon. Perhaps it’ll ease you up?
2004-02-20 12:32 pm
Anonymous
OMG! — read COPYING!
The Y communication library and the YC++ library, being the contents of the
libY and libYc++ directories in this archive, are licensed according to the
terms of the GNU Lesser General Public License, contained in the file
COPYING.LGPL.
2004-02-20 1:13 pm
Anonymous
Maybe the main problem with X environment is that some parts of the X principles are outdated :
– Too many colour schemes and encodings : TrueColor, DirectColor, StaticColor, PseudoColor, StaticGray, …
– Unmanageable fonts ( do we really need hundreds of font files ? ). What about Unicode ?
– Lack of unique vector graphic drawing primitives ( see RENDER extension ) with correct handling of metafiles, antialiasing, … ( think of DisplayPostscript )
– Many extensions for real time video.
– Unmanageable mixing of audio and video trough the network.
– The extension principle have permitted to endlessly add features but it makes also X servers less compatible ( Ever tried to launch a QT or GTK app from an old X terminal ? )
– Maybe events processings could be optimised ( instead of sending an event with all mouse movment. )
The ideas sustending X were good and still are ( network transparency , … ) but maybe they would deserve to be re-implemented with a renovated protocol. ( with, of course, some kind of Xlib compatibility layer )
I think that server side widgets are not really important if the basic protocol is efficient.
I would rather prefer a X12 or X[bignum] version ( same principles with an incompatible protocol ) than Y ( server-side widgets )
2004-02-20 1:29 pm
Anonymous
As it goes i met mark thomas last year in the intel masters here in london. He was telling me about the project, ended up having a good little discussion about it. All i can say is good luck to it, i hope it does develop into a major player, maybe even the replacement.
You have to give him credit, he did it for his msc project, thats talent man.
Its much easier to restart from scratch than work your way into X.
All I can say is X needed to be dropped, too much baggage with it, The board that used to control it even had a windows guy on it. The guy was suggesting dropping the network transparancy. X had gotten to the stage where it either needed to be dropped / or forked.
2004-02-20 1:42 pm
Anonymous
@DrLinux: And what exactly is on page 64 that supports your point? If you are referring to the statement about RDP — that’s how VNC does it, not X.
@omnivector:
i’m sorry, you’re making excuses… why it’s “ok” but you don’t actually say (and shouldn’t) that it’s better. because it isn’t.
——–
I sure as hell am making excuses. The point is not that the current situation on X is perfect, but the current situation on X is not any worse than on any other significant platform. Ideally, there would be one perfect toolkit that everyone could use. Ideally, too, all current OSs would be based on safe languages. By making memory protection superflous, enormous gains in performance (as well as API simplicity) could be made.
Of course, that’s the ideal. There are no widely-used, practical platforms that live up to that ideal. Does that mean that from now on, whenever a review of Linux/MacOS/Windows comes up, I must mention how they fall tragically short of that ideal? That’d be silly. It is pointless to hang on hopelessly to that ideal, because the realities of the market simply have not allowed such a thing to exist. A single, perfect toolkit is a great intellectual abstraction, but I have yet to see one in the wild!
carbon and cocoa are not two different GUIs they are two different APIs. big difference. their end look is identical.
——–
Actually, the toolkits are different. They use the same underlying services (like text rendering via Quartz 2D), but are still different toolkits. This is evidenced by the fact that you cannot, for example, mix carbon widgets and cocoa widgets in the same window, though, reportedly Apple is working on doing that. I think there are also differences in how the two handle text rendering and widget layout, because a lot of people complained about early Carbon apps looking out of place compared to Cocoa apps.
there aren’t two competing GUI toolkits in OSX and windows, so your analogy is bad. .net, also, still uses windows widgets.
——–
There are more than two toolkits in Windows. And .NET does *not* use Windows widgets — it has its own toolkit. Load up XP (Luna), MS Office, and Visual Studio.NET. If they all used the same toolkit, they’d look the same. But they don’t look the same. Ergo, they use different toolkits. At least on Linux, its possible to get away with using only one toolkit. I only use a single GTK+ application once in awhile on my KDE desktop. However, the minute you start up MS Office, you’ve got to deal with two toolkits on Windows.
and no, the fonts aren’t the same. take a look at gtk using bitstream vera sans 12pt and qt using it. they don’t look the same.
———
I highly doubt that, unless you’ve made a configuration error. Both use the exact same text rendering interface! Screenshots?
my point is simply this: can you change *everything* with X without touching the config file?
———-
Can you change *everything* in Windows without touching the registry? The important things (multiple desktops, resolution) can be configured via the GUI (at least, KDE has control center modules for them).
2004-02-20 5:36 pm
Anonymous
We DO need a new GUI system. X already is hard to configure and compile and takes so much space. Plus it is from 1984. I have Y installed and it seems to be awesome. Y has all the things that makes a good GUI. Adding things to X just makes more bloat! Y is also very small in size not because it can’t do anything but because it is a fresh start. We should be rooting for Y-Windows because it is what can make linux and all other unix BETTER.
2004-02-20 7:53 pm
Anonymous
Should I assume Y is (or will be) api compatible with X?
People forget there’s nothing wrong with X programs, just X.
IMHO, we dont need a new gui environment, what we need is a proper implementation of X.
my 0.02$
Shouldn’t that be…
“grammar?”
i found a link to this site along time ago, but then it was dead nice ot see its back up and running, from the screen shot he has transparency working
but what about FD.org’s implementation ?? i know “CHOICE” but i mean unless they have Major different goals wouldnt it be better to work on fd.org ??
Snake
It is GPLd – so it has no future, comparing to XFree86.
GPL is too restrictive.
Oh, wonderful, we have already one non-starter, Xouvert. Add Y Windows to it. And one we are at it, why not another non-starter project: Z Windows. It surely will be the best X86 Windows implementation — ever. Except it won’t produce anything of importance, just like Xouvert, and — dare I guess – Y Windows?
Yes. Projects, like companies are singular entities. Yet no one does this…
Y is very different from X. There would be no point in them working on on FD.O, because the Y folks have made some fundementally different design decisions. For example, widgets on Y are server-side, widgets on X are client side.
The X people fundementally oppose the idea of server-side widgets. They have quite good reasons for thinking this way. Specifically, the widgets that are universal enough to belong server-side (text boxes, buttons, list views, etc) are simple enough that they are fast even when they are client-side. The widgets that would benefit the most from being server side (HTML renderer, word processor layout engine, etc) are so application-specific, that they just don’t belong server-side.
Depends.
British grammar rules dictate that organizations (companies, projects, groups, etc) are are singular entities. (ie the BBC have ousted top leadership after a row). American grammar rules treat organizations as a plural noun (ie the BBC has ousted…)
Fun with English
I could swear we have been over this before. In British English, projects, companies, and other collectives, are plural, not singular. So the British say: “The government have passed this law.” Thus it is perfectly legitimate (especially for Eugenia, who lived in the UK) to say “the Y Window Project have started.”
And yet another project using Arch as a versioning system!
Y, Xouvert, and wat ever else,, are trying to replace X-windows with something up to the 21 first century. X-windows only has a few features that must be continued, but the ability to drop in an upgraded video card driver is a big plus, true Alpha blending, so we can catch up to windows, and OSX. The one of the few good features of X is native Networked displays.
The GPL is only restricive if you enjoy breaking copyright laws. By using someone else’s copyrighted work you have a responsiblity to that person. The GPL just makes sure you give credit to whom credit is do, unlike the BSD’s which let people think Microsoft actually wrote Unix services for Windows by themselves.
1) You can already drop in upgraded video-card drivers. X has had a stable binary ABI since version 4.0.1. What do you think the ATI and NVIDIA drivers are?
2) X already does alpha blending through composite. If you mean window compositing, well, there is already an X implementation (fd.o) that does that too.
3) X’s network transparency is very cool, and with NX (a caching/compression proxy for X) performance is extremely good.
Good to know. I swear I never knew that the British considered such entities plural, nor have I seen such a discussion here or on Slashdot.
thnx for the reply
Snake
“The GPL is only restricive if you enjoy breaking copyright laws. By using someone else’s copyrighted work you have a responsiblity to that person. The GPL just makes sure you give credit to whom credit is do, unlike the BSD’s which let people think Microsoft actually wrote Unix services for Windows by themselves.”
Stop FUD’ing. Nobody’s breaking copyright law by using BSD-licensed code in a commercial product, because the copyright owner has already given them permission to do so by releasing it under that license. So stop claiming that it’s theft.
Also, the GPL is horribly restrictive for a project like this. Consider: the GPL requires any program that links against a GPL library to also use a GPL-compatible license. This means that you could NEVER run commercial software on thie Y Windowing System, since by definition the commercial program would need to link against the Y libraries. Wow, that’s just a great plan…
=====
Also, the GPL is horribly restrictive for a project like this. Consider: the GPL requires any program that links against a GPL library to also use a GPL-compatible license. This means that you could NEVER run commercial software on thie Y Windowing System, since by definition the commercial program would need to link against the Y libraries. Wow, that’s just a great plan…
=====
Misunderstanding or Bull…?
Oh yes you can write proprietary software for a GPLed Y Window System. You just arent allowed to link you proprietary GPL-incompatible Software against the GPLed libraries. But no one hinders you from linking against some LGPLed libraries to interact with the underlying GPLed Y Window System.
For example you could program your proprietary Version of “Owen Office XP” and link it against (the LGPLed) GNOME libraries (including Pango and GTK libraries). Or you could choose to use the KDE libraries which are LGPLed also.
What you cannot do is use the GPLed Y Window System libraries or the GPLed Qt libraries directly.
It’s one thing to agree that X11 is here now, and popular. but to defend it i think is short sighted.
serverside widgets – i’m sorry, but the simple fact is sending from the client to the server something like “make button at location 0,0” is going to be a HELL of a lot faster than drawing lines, sending graphics, and sending anti-aliased text pixel by pixel. that’s inefficient. period. not only that, but my theme on the server looks different than the client’s. this is annoying, to say the least and the fonts are different, etc, etc. not only that, but the toolkit wars are futile. one toolkit. i’m sick of gtk/qt/tk/fox/motif/swing. it’s hideous. from a usability standpoint this is a nightmare. will gtk widgets act like qt widgets? will my qt themes work in gtk? simply put, this drives the average user nuts.
resolutions/dual monitors/etc – this is such a sad state of affairs in X it bothers me. gnome and kde are just now getting the ability to change resolutions with menu options, and even then it still doesn’t work properly. this is getting tiresome, considering that in a few seconds i can dynamically use dual monitors, change my color/gamma, resolutions etc on my powerbook.
My main questions are about custom widgets. How would I build/test widgets w/o possibly crashing Y? How could I install my application with custom widgets?
Not sure if anything on Slashdot could be considered a “discussion.”
serverside widgets – i’m sorry, but the simple fact is sending from the client to the server something like “make button at location 0,0” is going to be a HELL of a lot faster than drawing lines, sending graphics, and sending anti-aliased text pixel by pixel.
———
Except that’s not how X does it. With X, you’d say “blit this pixmap to location 0,0” or “draw lines here, here, here, and here.” Graphics are rarely sent pixel-by-pixel over the wire. As I pointed out earlier, server-side widgets solve a bottleneck that doesn’t exist. For windows that just use widgets (buttons, menus, lists, etc) toolkits like Qt are very fast already. The performance issues, when they exist, are for apps with custom widget (eg. Konqueror’s KHTML widget). Server-side toolkits do absolutey nothing to help that. On the network, it would seem like sending “draw button at 0,0” would be faster than blasting pixels (or even drawing commands) over the wire, but caching/compression technologies like NX manage to get the data-rate of the wire protocol down to a size comparable to what you’d get with a server-side toolkit.
but the toolkit wars are futile. one toolkit. i’m sick of gtk/qt/tk/fox/motif/swing. it’s hideous.
—–
The toolkit wars only exist among people who don’t use X on the desktop. For the mainstream of people who use X on the desktop, there is Qt, and GTK. Both use the same fonts, and work is being done to unify the themes. The remaining holdout is OpenOffice, and even that will be getting a native widget framework. Having two toolkits isn’t the greatest thing for usability, but it doesn’t seem to hurt the Mac (who has Carbon and Cocoa) or Windows (which has XP, .NET, and the Office toolkit). The only apps that use Motif anymore are proprietory apps that use a custom toolkit on every platform. Eg: XSI uses its own toolkit on Windows. Swing, also, is a seperate toolkit on each platform it supports. So every popular platform available today has a plethora of toolkits. What’s your point?
from a usability standpoint this is a nightmare. will gtk widgets act like qt widgets? will my qt themes work in gtk? simply put, this drives the average user nuts.
——–
I highly doubt it. After all, even many Windows users hanging out on OSNews apparently haven’t noticed that the Office uses a totally different toolkit from the rest of Windows! Hint: there is a reason that Office XP looks nothing like Luna!
resolutions/dual monitors/etc – this is such a sad state of affairs in X it bothers me. gnome and kde are just now getting the ability to change resolutions with menu options,
———-
Yeah, changing resolutions on the fly was something long overdue for X. Just like adding support for network transparency (RDP) was long overdue for Windows. Each windowing system has its strenghts and its weaknesses. The resolution weakness has been resolved in X (and I don’t know about you, but it works just fine on my machine) now, so you can stop harping about it. As for multiple monitors — X has excellent support for multi-monitor configurations via Xinerama. Do you have a specific complaint about it?
“The GPL just makes sure you give credit to whom credit is do, unlike the BSD’s which let people think Microsoft actually wrote Unix services for Windows by themselves.”
Uh, the reason the people are upset with XFree86 is because of requiring that people give credit where credit is do.
Its unstable at the moment. Typing Y starts it but it <b style=”color:red”>crashes when I try to run a program on it. I will keep looking at the project though, since I hate X and I look foward to seeing this stablize.
changing resolutions and screen refresh-rates are nowhere near as easy in X as they are in MS windows.
as for multiple monitors, X might support it, but it too “often” (no, i do not have an empirical analysis) bugs out on my comp.
i doubt anyone minds having several widget toolkits, well, i would prefer having only a few, or the option to have them all look alike;) but i am pretty sure they (on X) could all use some speedups in redraws, wouldnt you agree?
btw, network transparency, from personal experience, rdp beats X in terms of usefulness many times over. first of, the redraws _feel_ faster. especially when dealing with large areas. this can most easily be experienced when browsing webpages. rdp lets me keep my desktop, which is a rather nifty feature. and rdp lets me have sound, which is also a big plus on many occasions.
Y Windows, ok fair enough
What happened to Cosmoe?
http://www.cosmoe.com/
changing resolutions and screen refresh-rates are nowhere near as easy in X as they are in MS windows.
You need an X server with support for the xrandr extension, as well as a userspace utility for talking to the xrandr extension, which have been implemented in both KDE and Gnome, afaik. You’ll need recent builds of everything as these are all quite new technologies (at least, compared to Windows which has been able to do it for almost a decade now)
The most difficult part of X is the initial configuration, which has been partially automated with XFree86 -configure, although that still fails miserably on a variety of hardware configuration. That’s not to mention issues with bundled free drivers incapible of properly controlling the video card (i.e. mga, nv)
Take a look at Lindows if you want something that can do on-the-fly resolution changes out of the box in a Windows-esque manner.
Server-side toolkits do absolutey nothing to help that. On the network, it would seem like sending “draw button at 0,0” would be faster than blasting pixels (or even drawing commands) over the wire, but caching/compression technologies like NX manage to get the data-rate of the wire protocol down to a size comparable to what you’d get with a server-side toolkit.
Read page 64
http://www.doc.ic.ac.uk/~ajf/Teaching/Projects/Distinguished03/Mark…
P.S.
I highly doubt it. After all, even many Windows users hanging out on OSNews apparently haven’t noticed that the Office uses a totally different toolkit from the rest of Windows! Hint: there is a reason that Office XP looks nothing like Luna!
The whole point of Y is to be better than X, OSX or XP. Don’t you want a better solution or do you want “as good as” solution?
quote:
“The most difficult part of X is the initial configuration, which has been partially automated with XFree86 -configure, although that still fails miserably on a variety of hardware configuration. That’s not to mention issues with bundled free drivers incapible of properly controlling the video card (i.e. mga, nv)”
With redhat/fedora it has always detected my setup correctly, do you or anyone know what they do? Is it kudzu that does this? If it is kudzu, maybe it could be ported to all linux distro’s.
======
Oh yes you can write proprietary software for a GPLed Y Window System. You just arent allowed to link you proprietary GPL-incompatible Software against the GPLed libraries. But no one hinders you from linking against some LGPLed libraries to interact with the underlying GPLed Y Window System.
For example you could program your proprietary Version of “Owen Office XP” and link it against (the LGPLed) GNOME libraries (including Pango and GTK libraries). Or you could choose to use the KDE libraries which are LGPLed also.
======
Oh yes, that’s wonderfully logical. If Y is supposed to be a successor to X rather than just another implementation, it’s going to include features that aren’t used in GTK or Qt. So if they want commercial developers to support their server, the commercial developers are going to have to be able to use the Y libraries directly, which is not possible if those libraries are GPL’d.
Now, if Y becomes a huge phenomenon and all the graphical toolkits are ported to it, this won’t be an issue any longer. But for a project trying to get adopted, it is a major issue.
“”For example you could program your proprietary Version of “Owen Office XP” and link it against (the LGPLed) GNOME libraries (including Pango and GTK libraries). Or you could choose to use the KDE libraries which are LGPLed also. “”
If the graphics server is GPLed then the GNOME/Pango/GTK etc libraries must also be GPLed since they link to the graphics server libs and cannot run independent of those libraries (On X this would be xlib), therefore they are derivative works (As far as the GPL is concerned). Same would apply to anything written using GNOME/Pango/GTK, there is a domino effect originating from the graphics server libraries thanks to GPL section 2.
This is the precise reason why the LGPL exists. Core libraries should not be vanilla GPLed under any circumstances unless the developers of the libraries DELIBERATELY want to allow only GPL software to use those libraries. If they insist on a GPL license then this thing is dead in the water.
I agree that essential libraries should be LGPL instead of GPL. Thats what for the Lesser GPL (or Library GPL) was “invented” for. Without LGPL the GPL is indeed a “viral license” ’cause you cannot link against essential libraries without being GPL yourself.
=====
since they link to the graphics server libs and cannot run independent of those libraries (On X this would be xlib), therefore they are derivative works
=====
Ok, but what with proprietary Linux kernel drivers? They binary-only proprietary kernel driver cannot run independet without the linux kernel. So by your definition, those drivers would be derivative works. And ’cause the linux kernel is GPL, those drivers would have to be GPL itself.
But in fact there are proprietary kernel drivers that aren’t GPLed but interface the kernel through a LGPLed interface/wrapper module that directly interfaces with the GPLed linux kernel. Why couldn’t this also be done for Y?
Yes, that could be done. And that’s basically what the first responder proposed that the toolkits like GTK and Qt do. The problem is that you none of the currently useful toolkits support the new features of Y, so developing for Y using them would be pointless.
“”Ok, but what with proprietary Linux kernel drivers? They binary-only proprietary kernel driver cannot run independet without the linux kernel. So by your definition, those drivers would be derivative works. And ’cause the linux kernel is GPL, those drivers would have to be GPL itself. “”
If you look at the Linux kernel license you will notice that it is NOT vanilla GPL and has additional clarification on derivative works.
“”NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls – this is merely considered normal use of the kernel, and does *not* fall under the heading of “derived work”.””
Linus has stated his position quite clearly that dynamically loaded modules are NOT covered by the license, however modules statically compiled into the kernel are. However you’ll notice that the GPL advocates amongst the kernel team have been offered some recompense in that a non-GPL module brings up a message about kernel “tainting” when loaded (This is a biased comment actually. The main reason is so they don’t get people moaning to them about errors in modules that they have no control over).
Linus has stated his position quite clearly that dynamically loaded modules are NOT covered by the license
Where in the world would you get an idea so far from the truth?
Read http://www.linuxjournal.com//article.php?sid=6152“ rel=”nofollow”>http://www.linuxjournal.com//article.php?sid=6152