XFree86 4.4: List of Rejecting Distributors Grows

Bootsy Collins writes "Yesterday, we discussed Mandrake's decision to revert their release-in-development from XFree86 version 4.4 back to version 4.3 because of issues with the new XFree86 license. To update this, the list of OS distributors opting out of XF86 Version 4.4, and future releases, based on licensing concerns continues to grow. While Fedora seems to be "preparing to support multiple X11 implementations", Red Hat has explicitly stated that they have no plans to ship XFree86 v4.4 under its current license. Also add to the growing list list Debian, Gentoo, and OpenBSD."

Comments

What is the issue?

[beforewisdom]

Why is the new liscence being rejected?

Steve

Re:What is the issue?

[Ubi_NL]

The really interesting bit is that there is a lot of GPL-ed code in XFree. Chunks have been copied from the linux kernel, and people like Alan Cox submitted patches. As this code is GPL, XFree must also be GPL in order to use it, or the Xfree teasm must rewrite these parts. I understood Alan Cox opposes his contributions to be placed under the new licensing scheme.

Re:What is the issue?

[Anonymous Coward]

Actually the OpenBSD people (who fight license battles more than just about any other OS/distro -- even Debian) don't think it is equivalent to a BSD license either (the original license was equivalent to the BSD licence in case anyone is wondering: XFree was never GPL'd). David Dawes thinks still thinks it is. If he believes that, I hope he will change the wording back so everyone else believes it too....

Re:What is the issue?

[Snags]

How is this different from the license for libjpeg? From jpeg-6b/README: "(2) If only executable code is distributed, then the accompanying documentation must state that "this software is based in part on the work of the Independent JPEG Group"."

Re:What is the issue?

[oohp]

The OpenBSD group has done great work in the past taking ipfilter out of the code base and replacing it with something better -- packet filter. I hope this great work gets integrated in every BSD out there.

Theo mentioned forking -- it has already happened. While the XFree86 codebase is huge, I guess it's better that they don't fork it themselves, but rather join one of the groups that forked XFree86 already (either Xouvert or the freedesktop.org team) and merge efforts. It's a question of objectives and the OpenBSD team is well known for doing things themselves. But then again, three X forks is too much and no vendor will support all of them -- they scarcely support Xfree86 anyway.

It's good that the distributions reject this kind of David Dawes style sabotage licensing bullshit. This kind of sabotage didn't work in the past and will never work. It just adds more nails into the Xfree86's coffin.

I can understand but..

[Ymiris]

Won't rejecting this actually hinder the linux desktop movement? Xfree is a huge factor in using linux, at least for a lot of the gamers, and we need the best support we can get.

Re:I can understand but..

[Ewan]

XFree 4.3 is not dramatically different from 4.4, and if the 4.3 fork were to gain momentum you'd find very quickly that people who had contributed code to 4.4 would simply resubmit it to the fork, on the basis that whoever wrote the original code can resubmit it to anyone they want unless they transferred the copyright to the Xfree project.

Ewan

Re:I can understand but..

[Asmodai]

Because XFree86 changed the license it cannot be shipped? Don't fool yourself.

Ever looked at the rest of the sources? Allow me to quote:

xc/src/lib/FS: ``* Copyright 1990 Network Computing Devices;
* Portions Copyright 1987 by Digital Equipment Corporation
*
* Permission to use, copy, modify, distribute, and sell this software
* and its documentation for any purpose is hereby granted without fee,
* provided that the above copyright notice appear in all copies and
* that both that copyright notice and this permission notice appear
* in supporting documentation, and that the names of Network Computing
* Devices or Digital not be used in advertising or publicity pertaining
* to distribution of the software without specific, written prior
* permission.''

``Copyright 1987, 1994, 1998 The Open Group
Permission to use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided that
the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation.''

And these are just two examples.

By the way xc/src/lib/GLw/README.html is fun to read as well to see an example of how the knife cuts on both sides.

So how is this different? It was never GPL compatible to begin with. Clearly the above conflicts to clause 6 as well.

Will we be stuck behind the times?

[Larry David]

With this shift back a version, does it mean we'll lose a bunch of features, stability, etc? It seems like this is petty squabbling for squabbling's sake. This reminds me of the PHP fiasco with MySQL. Hardcore PHPers are sticking with the sluggish MySQL 3 family because of the licensing on MySQL 4.

Reading their 'diff' of the new and old licenses is a waste of time, as it's pretty much:

- all the old license
+ all the new license

So could someone break down the basic point of the changes? As far as I make it out, it's a simple case of 'we want to have everyone who contributed be credited with every copy', or is it somewhat deeper than that?

Perhaps distros should distribute XFree86 4.4 as source only and have it compile in a 'firsttime' sort of system when you boot Linux up after installation. From what I read in the XFree86 license, this would work. Could this turn into a BSD-like 'build all' for Linux?

Every cloud has a silver lining

[kinnell]

This could be a good thing. If this continues to be a problem, it could drive a lot of people to the freedesktop.org XServer implementation. This looks like it will come to be a much better implementation anyway, and will almost certainly develop faster in the future, given the same resources as XFree86. If a considerable number of developers/distributions worked on getting the XServer up to speed, with proper driver support, it would probably be better for everyone.

Re:Forking hell?

[kevin_ka]

I'm no XFree86 expert, but surely any changes committed by developers prior to the license change will be still under the previous license and therefore a good starting block for any forking.

afaik your 100% right there. And the question isn't if someone will fork ist but when. (unless they change the license back in time)

Isn't this the end of the story, then?

[DoofusOfDeath]

So doesn't this mean that whoever comingled GPL'ed source code with non-GPL'ed source code broke someone's copyright?

Because either he/they broke the GPL terms, OR they performed in unauthorized GPL'ing of the other, non-GPL-using contributors' source code.

Re:Isn't this the end of the story, then?

[Lussarn]

Alan cox can do pretty much what he wants with his own source, it is not GPL just because it is in the kernel and Xfree (It becomes more like dual licenced).

And as the last Xfree licence was a BSD style one the Xfree team can change the licence to pretty much what they want, including an MS EULA one, the BSD licence is pretty loose.

Re:The Question

[markbthomas]

The license only requests proper attribution in software and/or documentation like other third parties are getting.

The license doesn't request attribution, it requires it. That is the problem. Can you see what would happen if every time I started my computer, it printed out the names of all the people and organisations that were involved in making it? It could take days to boot :)

It's just vanity.

Strange behaviour...

[phrasebook]

What's with the people making these announcements? I read the comments by XFree86's David Dawes a while back - he only wrote about 2 lines or so, and hardly replied when people started asking for clarification.

Then Theo of OpenBSD in this thread writes a quick response rejecting the whole thing, again with absolutely no explaintation as to why, and what the specific problems are.

Then check out the posts in that thread from Darren Reed, getting shot down as a troll straight away for inquiring what the problem with it actually is!

This kind of discussion and attitude floating around turns me off OSS a little. The last thing I want to see is multiple implementations of X servers in wide use, different ones on different distributions, some doing some things, others doing things a little differently. And of course yet more duplication of effort, re-writing code, etc. Seems a shame. Seems like we just have more fragmentation to look forward to.

Re:NVIDIA?

[bfree]

I suspect you couldn't be more wrong if you tried :-)

Firstly I think XFree86 will fall off the face of the earth. If distributions don't package it but instead go with X from freedesktop.org, XFree86 will die in weeks as developers will move over to the new, freer codebase (Keith Packard has said he wants the freedesktop.org release to be DFSG-free).

Replacing X cleanly on a package managed system has always been one of the more tricky things around, why do you think this will change? And what do you think will be the desire for people to support an organisation which the distributions have all turned their back on? I don't think the distributors only problem is distributing it themselves, I cannot see any good reason for them to help people use XFree86, it only slows development of their chosen system, and unless they release with a major showstopper (like no 3d and I don't see that happening) what will be the justification for doing the work?

This isn't just about gaming, it's about X! But to address what most people seem concerned about, binary drivers (this is why I try and pick hardware based on the Free driver support) the death of XFree86 will be a fait acompli if freedesktop.org can get the hardware manufacturers who currently supply binary drivers to announce that they will be shipping freedesktop.org drivers (and preferably not be shipping XFree86 4.4 drivers). If the hardware manufacturers won't do that then XFree86 may well become the closed binary drivers X, and freedesktop.org the Free one, in which case perhaps someone like transgaming would take on the work of providing a system for people to use XFree86. This is why it has always and will always be vital for people to work on Free drivers, even when binary drivers exist, otherwise you remain in the hands of the hardware manufacturers.

I think a bright future is ahead for X, and I just hope XFree86 don't reverse their position and possibly ruin it! The Free X development is probably about to come right out into the open, rejoice and stop worrying!

Re:Oh great, here we go...

[pavon]

IMHO, is much more verbose than what you see in the current XF86 config file.

Why is more verbose a good thing? What matters is readability, and XML is a lot less readable than the format that XFree86 uses.

In fact, the XF86 config file would probably be better suited to XML than what it currently uses: XML is for structured data - have you read an XF86Config file lately? notice the structure?

Yes and the XFree86 file format is perfectly capable of representing structured data. How is

Section "Screen"
Driver "svga"
Device "My Video Card"
Monitor "My Monitor"
Subsection "Display"
Depth 32
Modes "640x480"
EndSubsection
EndSection

less readable or less expressive than this:?

<section name="Screen">
<option name="Driver" value="svga"/>
<option name="Device" value="My Video Card"/>
<option name="Monitor" value="My Monitor"/>
<section name="Display">
<option name="Depth" value="32"/>
<option name="Modes" value="640x480"/>
</section name="Display">
</section name="Screen">

XML is not the best data representation for human edited files, and on linux there is the unwritten policy that while we try to not require the user to edit files directly, we certainly want to make it easy if they choose to do so.

Even in OS X where XML is king, there are two supported formats for plists, and it is standatd convention to use XML for files that are primarily meant to be edited by the computer, and the other c-struct (old Next-Step?) style format for files that are primarily meant to be edited by humans.