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.
nobody forbid them to use it. its their choice, not XFree's.
altough they might have a point... XFree ppl are starting to push a bit to far... i agree with previous opinions: to bad there is not another alternative(one that is ready, i know about fd.o)
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/
The problem is that Mandrake would be violating the license on every program in their distribution that used the GPL or any other copyleft license that did not contain the requirement for acknowledgement.
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
There are numerous driver updates that greatly affect my laptop's abilities. I need 4.4, so if Mandrake drops it, I won't be using their distro.
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.
Mandrake may be wise to include XFree86 4.3 as a CYA, but my reading of the situation is that not even that is necessary.
You are not alone. This is not normal. None of this is normal.
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.
The new Fedora wont have the new XFree as well. They didnt even think of testing it..
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.
The real problem is the addition of the advertising clause, as found in the original (GPL-incompatible) BSD license. They've tried to "update" the advertising clause by allowing it to be satisfied by including of an acknowledgement message in the software itself, but still many people will find that annoying unclear, and unnecessarily redundant. And probably GPL incompatible.
Release Notes for XFree86 4.4.0-RC2. Maybe it's IPv6 support, maybe autedetecion of mouse port, maybe VIA driver, maybe Mesa 5.0.2. Nothing revolutionary, I think.
:wq
These fonts wouldn't happen to be ttf-kochi-gothic and ttf-kochi-mincho?
There are two versions of these fonts, one which is public-domain and the original one which contains non-free hinting information.
See also this post to the debian-devel mailinglist.
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}}
As someone else pointed out RMS essentially predicted it. But the most important point is that it is and was forkable into a seperate project (i.e. freedesktop.org) or just into a GPL compatible version, then the question is how much code gets shared and how much they diverge, and who chooses to use what for what and .... it's what Free software is about, each time someone closes off a freedom, someone will work to preserve it. People who put work in under the old licensing can continue on, they just mightn't be able to take the new stuff. Sometimes it will remain at the fringes but frequently the freer version will take most of the users and developers. I'm still happy that I saw Keith Packard saying freedesktop.orgs release will be DFSG-free, that's enough for me :-)
Never underestimate the dark side of the Source
Your understanding is incorrect: see what the FSF have to say about it.
The point is made though...
I doubt it's ever been in Debian because of Debian's policies on free software. Redhat, Slackware, etc, though are a different matter.
You are not alone. This is not normal. None of this is normal.
Linking against libraries is a derivative work. Otherwise, copyright would be trivial to defeat. Just take the code you want to use and put it in its own shared library, and voila, no copyright issues!
A deep unwavering belief is a sure sign you're missing something...
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.
The next release of Fedora Core, due in just over a month, won't have XFree 4.4 either.
Yeah, well trying to claim it has anything to do with the license changes is pure FUD. I've followed the discussions about this from Mike Harris, and (since you clearly haven't) I'll quote:
Q) What release of XFree86 will Fedora Core 2 be shipping?
A) XFree86 4.3.0 is what will ship in Fedora Core 2. It will contain a number of bug fixes, Radeon driver fixes and other improvements to further stabilize the 4.3.0 series, and give Fedora Core a relatively mature XFree86 base. I would also like to update the "via" driver to Alan Cox's new DRI enabled via driver, so that VIA EPIA users can enjoy 3D acceleration. I'm probably going to do a number of other video driver updates and scan bugzilla for the most critical issues to spend some time on. Any large-risk issues will likely not be addressed until 4.4.0 is integrated into the distro however if I believe the risk of regression to be too great to be worth taking for a given problem. I've considered a great number of technical and other issues/factors in coming to this decision.
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.
That blit to screen has to do with the bitmap dumping approach Windows uses versus the Display PDF draw line by line approach Quartz inherits from Openstep.
And as far as it not being smooth on OS X I would supply hardware specifics and OS X versioning before claiming it doesn't draw seemlessly, on the fly.
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.
As I said in the subject Darl == David Dawes. This man had done more to piss off developers then anyone except maybe Darl from our beloved SCO Group..See email below from the xfree86 mailing list:
On Sat, Jan 31, 2004 at 03:17:42PM +1100, Benjamin Herrenschmidt wrote:
>Hi David !
>
>> On looking through the fbdev drivers in the Linux kernel source, I see
>> very few cases where license notices from XFree86 driver source are
>> included. This means that either the license for these drivers has no
>> impact on the work you are talking about (making what you have written
>> above moot), or some authors of portions of the current Linux fbdev code
>> have violated the terms of the existing licenses by not including a
>> verbatim copy of the copyright, license notice, and disclaimer text in
>> relevant source code.
>>
>> I would also like to echo Egbert's comments about the one-way nature of
>> your concerns.
>
>I'm mostly concerned at this point about radeonfb and rivafb. The radeonfb
>in the current mainstream kernel was written by Ani Joshi who also wrote the
>first radeon driver in XFree. So there wasn't any liencing issue at this
>point.
>However, I rewrote the kernel driver almost completely using a lot of
>informations from the XFree one as ATI is maintaining it actively.
>
>My rewritten radeonfb driver _do_ contain a copy of the licence included
>in the XFree one along with the (c) assignement.
So there is no problem as far as radeonfb is concerned. The licence
choice for a driver always has been (and still is) the authors' choice.
The same applies for other code in XFree86. If the authors' choice is
incompatible with your preferences, then you are free to discuss that
with the authors. Licences like the modified XFree86 licence have
*always* been acceptable to XFree86, and some code in XFree86 already
carried licences like this prior to our latest modification. I haven't
seen great objections to that before. Why now?
Back to the XFree86 radeon driver, the listed copyright holders for the
bulk of that code are ATI and VA. If those copyright holders were to
change their licenses (and whether they do or not is entirely up to
them), then you would have to approach them about such changes if they
happened to be incompatible with your requirements.
>The fact that it is mostly a one way is mostly due to the fact that the
>main problem here is seeking for HW informations. Card vendors put that
>information into XFree via drivers, we rely on this for the kernel drivers.
Speaking from my own experience, a big reason why it is one way is
because many developers err on the side of caution to avoid infecting
their code with the GPL virus, and to avoid baseless accusations from
the GPL zealots that they have illegally "stolen" GPL'd code.
Perhaps a more serious part of the "one way" problem is this very
discussion. Has anyone considered modifying the GPL to be more compatible
with other Open Source licences rather than trying to force all Open
Source licences to be a subset of the GPL? To me it seems a signficant
flaw to the GPL if it is incompatible with Open Source developers' desire
to receive due credit for their work from those who redistribute it.
If GPL compatibility is such a big issue to GPL advocates, then perhaps,
for their own benefit, it needs to be more accomodating than it currently
is.
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
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.
Huh?
Where do you see that in the 4 clause license?
It only has 4 requirements.
1. All source distributions must include the license.
2. Binary distributions must include the license in the same location as other copyright licenses.
3. End user docs (if any) must include an acknowlegement of use.
4. You can not use the name The XFree86 Project, Inc in advertising without prior permission.
There is NOTHING else there. Where does "Version 1.1 of XFree86 Project License" say what you said?
BWP
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...
a google for freedesktop planet gave me the right link as the first result. http://freedesktop.org/~daniel/planetfdo/
Thx that was my plan to use your driver in my next build.
Fred - May the source be with you
What exactly has changed in the 4.4 release?
... [or] in the software itself, in the same form and location as other such third-party acknowledgments [apparently if you don't put it in the end-user documentation]."
Very little, in fact. The old license (1.0) required:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of the XFree86 Project shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the XFree86 Project.
The new license makes this a bit more specific:
1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution, and in the same place and form as other copyright, license and disclaimer information.
3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by The XFree86 Project, Inc (http://www.xfree86.org/) and its contributors", in the same place and form as other third-party acknowledgments. Alternately, this acknowledgment may appear in the software itself, in the same form and location as other such third-party acknowledgments.
4. Except as contained in this notice, the name of The XFree86 Project, Inc shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from The XFree86 Project, Inc.
You'll note that point 4 was already in the old license, and that the required notices are exactly the same. So what's different?
In reality, not much at all! The new license just makes specific that if you are distributing XFree86 in binary form, you must include the notices in "the same place and form as other copyright, license and disclaimer information" and/or in "the same place and form as other third-party acknowledgments [are in the end-user documentation, if such documentation exists]
So, in other words, they want credit for writing your X server and libraries, of you want to leverage that software. They're concerned that the old license appeared only to require that you only give credit if you distributed it in source form. Notably, nothing in this new license requires that you list the names of all the programmers, only "The XFree86 Project, Inc (http://www.xfree86.org/) and its contributors."
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?
4.4.0rc2 is 4.3.99.902, dude. So it's 4.3.x.
Jeremy
Looking for a Python IRC bot?
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
Y: A Successor to the X Window System
http://www.doc.ic.ac.uk/~mbt99/Y/