Slashdot Mirror
Mandrake Blocked By XFree86 4.4 License
Linzer writes "A mailing-list message posted by Mandrake Linux's main developer on the Cooker mailing-list states that the development version of the distro is about to revert from XFree86 4.4 to the 4.3 version because of XFree86's recent license change. Mandrake contributors have started asking for justifications from MdkSoft. Many point out features of XF86 4.4 [an 'an open source X11-based desktop infrastructure'] they can't live without, including support for some not so uncommon hardware.
A later Cooker mailing-list post extends a bit on the reasons."
Yes, I know, XFree was, and still is, THE X11 free implementation for a Linux graphical subsystem. YES, it is by far one of the most advanced overall. But NO, there is NOT only this one.
This implementation is the one we've been using for Linux Ages. But since recently, they have failed to deliver a greater-than-the-previous product: no extraordinary boosts, no rewrite of the starting system, etc... It's beginning to grow too old - we can see that by the starting greed of the project over its programmers.
What we need is a new subsystem, like Xouvert or freedesktop.org's X Server implementation.
This is my opinion. Everyone has a right to my opinion.
Laymans terms, probably misunderstood:
They have an incredible mishmash of licenses between each source file, as each file can contain a message stating what license it is released under.
Theyve just created another which encompasses the binary distribution.
The whole binary distribution.
Except the portions which had seperate licenses as specified by the source code.
But to check which those bits are, you would have to check each source file, and know what it does.
So I guess Mandrake have decided, probably in these exact words "F*CK THAT!"
I am a viral sig. Please copy me and help me spread. Thank you.
You can read his analysis on a thread on debian-legal.
There's also been extensive discussion of the new license on debian-legal. The discussion carries over from Jan into February too.
Didn't you follow the link? For those who didn't: (1) Including the new text in every place it "should" go is a lot of work, for so late in the release cycle; (2) the new XFree86 licence is likely not GPL-compatible, which causes huge problems for all distributors, not just Mandrake.
Read the license again! There is a no advertising without written permission clause. This is incompatible with the GPL *and* the amount of work it would take to get written consent from *every* developer to put "has XFree86 4.4" on a box or on a webpage is so much a pain in the ass it's quite insane that they even added that clause.
75% of all statistics are made up!
Okay... this, is an 'OLD' BSD style licence clause. It conflicts with the GPL and thus, people wanting to put GPL software in XFree86 wont be able to.
Thats the big deal.
I, for one, dont give a fuck.
NO SIG
The short version: the GPL is "incompatible" with licenses that require you to include extra text and restrict all other advertising. Thus, you cannot legally include both GPL'ed code and New XFree86 licensed code in the same program.
Which also means: you can't use KDE or GPL'd Qt on XFree86 4.4. This is a fairly big deal for Mandrake.
Finding God in a Dog
(IANAL or a licencing expert, so please correct me if I'm wrong.) I believe the problem is that this is a restriction being placed on the code, and the GPL doesn't allow any additional restrictions (however harmless they may seem) to be added. Hence, an incompatibility between that licence and the GPL.
http://alternatives.rzero.com/
It's *written* consent from all authors. It's just like the old BSD license when it had the advertising license where you had to list all contributors of a project if you advertised the software. Meaning if you had 1000 developers for a project that would easily fill an entire page in a magazine. Making the 20k dollars you just spent on a magazine ad a big list of names no one cares about. XFree86 has done this now too and made it a little bit worse too.
75% of all statistics are made up!
I find this paragraph specially interesting:
If you notice the defensive post by Alan Cox that he's asking them not to
change the license on his contributions, there's something wrong with it in
the sense that it doesn't appear as "free" software anymore (free as in
libre). (Not that they could, since Alan owns what he wrote of course)
This kind of action only adds to the licensing mess xfree86 currently is. Working with the xfree86 devlopment team is becoming harder and harder.
I can see why some mandrake users are pissed about this, but in the end it'll be better for everyone.
X is *just* the network drawing stuff. There has been no need to change that...
X *does* have the ability to support multiple servers, and each server can support multiple screens. Pretty much has *always* had this ability.
The ability to "snapshot" has very little to do with X. The server could certainly snapshot and forward. In fact, it is remarkably EASY to do with X. Except -- (and there seems to always be an "EXCEPT") when your alternate server is running a different pixel depth... Like, you launch your application on a true-colour display, and then bring it back on a monochrome (1-bit) display.
Even that has a solution. Anyway -- the other "common" display systems (MAC and Windows) don't have a solution (unless going through something like VNC).
Development hasn't stopped -- but the "main-line" of the X server *is* frozen. Development occurs on the fringes (new extensions), and with new drivers.
Ratboy
Just another "Cubible(sic) Joe" 2 17 3061
What's wrong with that? You are still allowed to modify and redistribute the code to your heart's content, as long as you acknowledge the original authors. Wouldn't you want your work acknowledged?
The problem is not that those terms are onerous in and of themselves. The problem is that those terms are seemingly incompatible with the GPL, in particular the GPL's requirements that a redistributor of GPL'ed material is not allowed to place additional restrictions on redistribution.
Given that there is a vast amount of GPL'ed software that is linked against X libraries, this would, on the face of it, make it impossible to distribute that GPL'ed software in compliance with both the new XFree86 and GPL licenses. At least, if the GPL'ed software was considered in some way derivative of the XFree86 licensed software.
I'm sure all of this will get sorted out, but people are right to be raising the question right now.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Okay... this, is an 'OLD' BSD style licence clause.
Not quite, but it has similar problems.
It conflicts with the GPL and thus, people wanting to put GPL software in XFree86 wont be able to.
Or, more to the point, people wanting to use XFree86 libraries in GPL software. That is a problem.
Human/Ranger/Zangband
Can someone give me a rational explanation as to why the GPL is so problematic in this area?
Sure. Because by requiring your program to list contributors, you're limiting the ability to use or modify the program as you see fit.
Imagine I had an OS program that required you to list 1,000 contributors each time it was run, divided by group, sorted alphabetically, blah blah blah. Now you're required to fill a user's screen with 1,000 names they'll never read, and you are unable to get around this requirement, short of writing your own program from scratch. What a waste of previously good OS code.
It wont be for long. I assume from the discussions on debian-legal and the fact that debian is still chewing on xfree86 4.3, xfree86 4.4 wont ever be packaged for debian.
In my opinion this is a bigger problem for xfree86 than it is for debian. The reason being quite simple. By the time debian is ready for a new version of X11 the fdo xserver will be ready.
Where xfree86 is losing big is that debian is the one that does all the porting to non-i386 and to a degree non-ppc archs. Xfree86 is losing this service because debian will most likely not be packaging version 4.4 and that will result in xfree86 going down hill because debian along with many other developers that are outside xfree86 proper do a lot for xfree86.
Basically what Im saying is that the fdo xserver just got a huge boost in that there will be a lot of former xfree86 developers looking for a new project and as someone who activly uses the fdo xserver, it seems to be the best.
"We Don't Need No Truthless Heros!" - Project 86
Save them from your current installation and transfer them to a Mdk10 installation? They're just fonts, after all - no reason I can think of why you couldn't just plug them into a later version of the distro.
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
Your core confusion comes from confusing what X Windows is, possibly as a result of using Microsoft Windows. Windows does a great deal to blur the lines between the graphics display layer and the widgets on top.
X Windows is (to simplify a bit) just a way to display bits on screen. Exactly what you display is left as a problem for the next layer up. This might seem odd, but it has great benefits. This means that the user interface layer (often Gnome or KDE these days) can engage in rapid change and development while the base layer (X) can sit nice and stable. Conversely, because particular widget sets and other user interface details aren't embedded into the graphics system I can pick from competing offerings.
XFree86 is mostly stable because it works fine. There have been some important developments recently (XRender, XRandR, XVideo), but on the whole we've got what we need. The user visible improvements should take place on a higher level (Gnome, KDE, etc). Those higher levels can take advantage of the stable base X provides. All that's needed are regular driver updates for new hardware as it comes out (and bug fixes as bugs become known). The X Windows standard itself is gloriously stable. It works fine, additional functionality can be (and is) provided through extensions. That stability is key to allowing higher levels in the system to experiment.
The features you want sound like great ideas (although I notice that Microsoft Windows and MacOS doesn't support the snapshot and migration functionality you want either). But they're ideas for different layers. Complaining that X should provide them is like complaining that your dashboard should provide better traction.
Search 2010 Gen Con events
From: Theo de Raadt
Like other projects, we will not be incorporating new code from David
Dawes into the XFree86 codebase used in OpenBSD. All such changes
have to be skipped, rewritten, or you can contact the XFree86 group
and place your own efforts to repair this damage.
the message continues.. but I think you get the point. Check the mailing list archives for the entire message
Please. X is one of the most painful packages to download and compile oneself. It's big. It needs lots of space to compile. It needs lots of time to compile. It's not just ./configure && make && make install, since it's got a moderately Byzantine build system based on Imakefiles, which nearly nobody else uses anymore, so if you have to change build parameters, you have a bit more work/learning to do.
In short, after having kept an XF86 build tree around to stay on the bleeding edge, it's enough of a pain even after you get it going that I don't want to do it again unless I really have to.
They lived without them before 4.4. What's so special about these features?
The biggest lost would be support for new video cards, such as some 3rd-party Radeon 9200, and various Radeon 9600 cards. There are some big fixes in the i8xx driver, and the SiS drivers.
Does anyone really think that if Redhat and Mandrake didn't put the notice in their documentation, that anyone would think that they had written the code.
Actually XFree86 is increasely being used in embedded systems, where it may not be obvious that it is running XFree86 on an ARM processor or whatever.
OpenBSD has always been very picky when it comes to respecting licenses (unlike most other OS, they read the Postfix license before putting it on CD's).
:
Here's a recent post from Theo de Raadt on the OpenBSD misc@ mailing list
Like other projects, we will not be incorporating new code from David
Dawes into the XFree86 codebase used in OpenBSD. All such changes
have to be skipped, rewritten, or you can contact the XFree86 group
and place your own efforts to repair this damage.
I've tried to negotiate with David Dawes, and show him that his new
license is not acceptable, and he has been hostile and it has gone
nowhere. He keeps insisting that his license is a standard BSD
licenses, yet, he won't use the same words that Berkeley used; if his
words were intended to be compatible to the Berkeley spirit then he
would be happy to use the same words; but he is not, and insists on
different words which a lot of the community has trouble with.
It seems like every 8 years or so we have to go through some period
where someone tries to take free software and makes it less free
because they don't feel they are getting enough credit.
This is final; if that license stands, there will be forking.
And if you don't like that, don't bother telling me. Tell them.
{{.sig}}
Even the GPL does not claim that linking to GPL'ed libraries makes your program GPL
Oh yes it does, read this. If you link to a GPL library, your program must be GPL.
The situation in this case is the opposite - using a non-GPL-compatible library in a GPL program. Doing that requires a special exception, which means that all the existing GPL programs can't link to non-GPL-compatible XFree86 libraries. Even if you put an exception in your license, you can't also link to a GPL library unless that library also has the exception.
so I don't think linking to Xfree86-licensed libraries makes your program XFree86-licensed.
This is not the problem. The problem is that the libraries are XFree86-licensed, and the GPL won't allow you to use them in a GPL program if they contain the documentation clause. The XFree86 license doesn't care about linking, but the GPL does.
Human/Ranger/Zangband
Gentoo aren't including any new xfree releases (>4.3.99.902) until the licence is sorted out.
freedesktop.org's code will be placed under free licenses that encourage wide use; most commonly, the LGPL for libraries, or an X-style license when appropriate.
link
there's no problem linking GPL code to non-free X11 implementations, such as OpenWindows, so why would there be a problem linking it with a Free X11 implementation like XFree86-4.4?
This isn't an ideological issue on the part of Linux distros. The only Linux distros that will be able to live with XFree's new license are source based distros like Gentoo. Linking GPLed source with the new XFree86 is no problem provided you do it yourself. Distributing the binaries is. For all that the likes of SCO say that IP isn't respected, it is. The new XFree86 will make it potentially illegal to distribute vast tracts of software as binaries. This is not a practical situation for the Linux distros.
There will eventually be a fork of XFree86 that the distros will use. It will this fork that gets the drivers and eventually most other development as well. What we really should be worried about is Debian having one codebase, RedHat another, and Suse still another. The sooner there is a legally kosher common codebase the better.
Dave Dawes message went to the contributors asking them if they wanted their contribution as is or changed to his new license. I wanted my contributions usable by all the X projects, including whoever finally gets annoyed enough to fork XFree.
BTW for Mandrake people (and mandrake themselves) there is a driver for the VIA chipset including DRI on ftp://people.redhat.com/alan. There is also a patch from Bero on the the dri Wiki which you may need depending which Mesa you use. I (and Im sure VIA who wrote most of the driver!) would love to see the via driver in Mandrake's XFree 4.3 packages if they go that way.
I also hope to have an accelerated Voodoo2 driver with DGA and maybe render acceleration available in the next couple of weeks - and that doesn't need Glide.
Windows has drawing issues too. Classic MacOS had the same issue. Mac OS X is the only OS I know of that doesn't have the drawing issue. The RAM and Processor requirements for keeping the screen buffer are rather large, which is why the other, older systems don't have it. Even on a Mac, there are still problems. Moving a window might be smooth but resizing it isn't. I have a Dual 1.2Ghz G4 with a Radeon 8500 at home. There's no reason such a system should have drawing issues yet it does. My PC at work running Linux handles window resizing better than my Mac.
Windows will get a screen buffer in Longhorn.
X will get one when someone writes it. I'm pretty sure there is work going on to put something like this in X already.
Link
OpenBSD has imported the XFree4.4 Release Candidate immediately before this stupid licensing change and will be basing further work off that.
I don't think that it will be long before these efforts link up and produce a viable fork.
I specifically asked Dave about this when the change first came up and he wasn't interested in keeping the library bits clean. Had he done that the only problem would have been Alan Hourihane's GPL'd X drivers for VNC.
Its also a stupid way to get credit. Repeat after me "Nobody reads the documentation anyway". Right ? They've have done far better with the old license and something like a cute XFree86 logo spinning across the display when the server started - aka the 3dfx glide library startup.
As for the server side - Freedesktop needs to work on the server side for all the cool new technologies like on the fly rotation that XFree86 convservatism won't experiment with (rightfully or wrongfully). Keith's server is neat but its definitely 'technology preview' grade at the moment. I'm running it on one box and the semi transparent menus and drop shadows are nice.
Okay some tests:
Fluxbox, Konqueror opened to Google News: Streaking.
Fluxbox, Konqueror opened to kdelook: Streaking.
Metacity, Konqueror opened to Google News: No steaking.
Metacity, Konqueror opened to kdelook: Streaking.
Kwin, Konqueror opened to Google News: No streaking.
Kwin, Konqueror opened to kdelook: No streaking.
In particular, kdelook is the only site complex enough to notice streaking with kwin.
Configuration:
2.0 GHz Pentium 4 on an Inspiron 8200
GeForce 4 Go 440 w/ 64MB of RAM
NVIDIA binary drivers, 5336 (RenderAccel on)
1600x1200 15" LCD
640MB RAM
XFree86 4.3.0
Debian sid
KDE CVS
Note: I've got kwin patches that are not in KDE 3.2. If you want to replicate the test, either compile the latest CVS, or use KDE 3.1.x. KDE 3.2's kwin is a new one, and was not highly optimized relative to previous kwin's.
A deep unwavering belief is a sure sign you're missing something...
The X Consortium has made this software non-free.
The X Consortium had nothing to do with it - it hasn't existed since 1994. This license change was done by the XFree86 Project, Inc.
The current successor of the X Consortium is the X.org Foundation, which has not adopted this new license, and in fact, has stopped importing code from XFree86 into the X.org CVS tree because of it.
Actually, Quartz does not draw line by line. Quartz preserves a bitmap of each window, and when something damages the contents of the window, restores the image from that bitmap. This takes up tons of memory (need window buffers even if window is hidden) but eliminates any streaking.
And resizes on OS X are really slow, though that doesn't have a lot to do with the double-buffered approach. Quartz is just really slow overall.
Anyway, I use OS X 10.2.8 on an 800MHz G4 17" iMac, and it definitely suffers from choppy resize operation.
A deep unwavering belief is a sure sign you're missing something...
Thx that was my plan to use your driver in my next build.
Fred - May the source be with you
The problem isn't the X server. It's badly written software or toolkits. Properly written X appications won't smear like that. Xterm doesn't do it. I write X applications and they don't have the problem.
The most likely cause of the problem is that the program has a very slow redraw function, probably due to object-oriented code, and calls that function in full on every Expose event. The way I avoid the problem is to check for events within the redraw loop using XPending(3X11). I check once every N drawing elements, and if I never get events, I increase N within that one redraw, increasing efficiency. If I do get an event, I terminate the redraw and return control to the main event switch statement.
Mozilla Firebird has the problem to a much smaller extent than plain Mozilla, for some reason.
I anticipate your saying, "You had to apply a crude hack." Well, that's not it. It takes time and effort to master X programming; that's a consequence of X's power and flexibility. There's nothing wrong with XFree86's implementation of X that I've run into. X takes the blame for a lot of mistakes by application and toolkit programmers.
Since the last story on Slashdot about this, I've been wondering why no one seems to bring up that GPL programs are allowed to link to non-GPL (even closed/proprietary) libraries. Not in general, of course, but the GPL does actually allow this in the case of OS libraries. I don't think anyone realistically could contest that XFree86 is a system library in pretty much any distribution (MacOS X and cygwin come to mind as the likely exceptions).
The point here is that XFree86 could go closed source and it would still have no effect on GPL programs in the common cases. So, the GPL angle is basically a red herring.
(That said, I do think the license change qualifies as a pretty seriously dumb idea.)
The method I described isn't to stop smearing - rather it's to stop the app from spazzing out and using 100% CPU during dragging/resizing. That would be the natural consequence of an app redrawing a complex window for each Expose event.
It looks like Mozilla took the easier approach, to postpone the redraw completely until the Expose events stop coming. That works fine with profile (non opaque) window dragging, but in combination with opaque dragging it causes smearing. On each Expose event, the app should at least fill the window with its background color, which is almost instantaneous. That will override the smearing.
Using the method described in my previoius comment will draw as much of the display list as the app has time for, improving the realism of the drag metaphor at some expense in CPU utilization.
The "advertisement clause" that everyone keeps referring to states that ADVERTISMENTS for the software must include a statement giving credit to the original developers of the software. This new license states that you must include such a statement in the DOCUMENTATION for the derived software. This argument is completely ridiculous. It is just as silly as some of the arguments of the past. Who is going to take us seriously if we keep arguing about two or three lines of text placed in the documentation for an application?
Don't worry, we already had integrate part of your work on VIA driver in Mdk 9.2 and we will finish integration for 10.0