[vox-tech] XFree86 4.4.0 non-GPL compatible

[Peter Jay Salzman]

On Mon 01 Mar 04, 12:19 AM, Mike Simons <msimons@moria.simons-clan.com> said:
> On Sun, Feb 29, 2004 at 07:35:23PM -0800, Ken Bloom wrote:
> > On 2004.02.29 18:32, Mike Simons wrote:
> > >On Fri, Feb 27, 2004 at 07:18:38PM -0800, Jim Lowman wrote:
> > >Xfree86 4.4.0 does have support for the Radeon 9800 video card...
> > >however it seems that XFree86 recently (Jan 29) decided to change the
> > >license on the X server to be GPL incompatible.  Depending on how
> > >the various distributions deal with with this it may take a while for
> > >that card to work in most distros.
> > >
> > >http://xfree86.org/legal/licenses.html
> > >===
> > >What about GPL-compatibility?
> > >
> > >The 1.1 license is not GPL-compatible. To avoid new issues with
> > >application programs that may be licensed under the GPL, the 1.1 licence
> > >is not being applied to client side libraries.
> > >===
> > 
> > How exactly does GPL incompatibility cause a problem for the distros?
> 
> Well the old license was GPL compatible.
> 
> If there are any parts of the distribution that the non-GPL X server portions
> run time link with GPL'd code then distributions would not be able to continue
> shipping both the new X server and that GPL'd thing.

ken,

mike was in a hurry, and that sentence didn't parse well.   :-)

the problem is when code (forget about GNOME and KDE.  we're talking
about anything that puts a window on your screen) links to xfree86
libraries shipped under the 1.1 license.

the problem is that when your GPL code statically links with something,
it produces a "derived work".   under the terms of the GPL, that
derivative work must be GPL.  however, when you statically link to the
new X libraries under the 1.1 license, there's an advertising clause
that is GPL incompatible.

therefore, when you link against X 4.4 libraries, the resulting work
MUST be GPL because of the terms of the GPL.  but it CAN'T be GPL
because of the terms of the X library.

that's the problem.

furthermore, the FSF has ruled that dynamically linking to a library
also produces a derivative work, so the problem exists whether you
statically link or dynamically link.


this is really, really bad.  a project the size and complexity of the X
server and libraries is not something you want to fork.  unless a good
chunk of the developers move to the fork, this will be crippling for
awhile.

the fact of the matter is, nobody was really happy with xfree86 before
this happened.  they were extremely slow, secretive, and seemingly
rejected patches in a passive-aggresive way (the cygwin xfree86 issue).
it's just that they haven't been viewed as "evil" up until now.  many
forks have been started, and they've all stalled.

people have started to talk about new projects like freedesktop.org.  i
believe it will be a long while until we see something useful and new
out of them.  this ain't exactly like hacking a new openGL
infrastructure for doom...


unfortunately, X 4.4 looks really good.  i've read that it autodetects
so much that in some cases, you don't even need an XF86Config file.
suh-weet!

the good news (i think) is that only the client xfree86 libraries have
the new 1.1 license change.  the server does not.  most distros have the
X libraries as a different package than the xserver.  i *believe* that
all will be good, at least in the short run, if they update the server
to 4.4, but leave the libraries at 4.3.  of course we don't want to have
different versioning on the server and libraries forever, but until the
forks get a chance to rally and start pumping out stuff we can use, it
might be a good short term fix.

unfortunately, i read that brandon robinson (sp?) refuses to put 4.4
anything into debian.  i believe the 4.4 server should be fine, but
perhaps there are issues i'm not aware of.  at least, i'm fairly sure
the server doesn't have the new license.  maybe i'm wrong...

pete





> There's also some recent evidence that GPL compatibility is important
> from one project that's tried to go from GPL-compatible to
> GPL-incompatible: XFree86. The XFree86 project has historically led
> development of a popular X server, and traditionally the vast majority
> of its code used the simple "MIT/X" open source license that is
> GPL-compatible. The XFree86 president, David Dawes, decided to change
> the XFree86 license to one that isn't GPL-compatible, primarily to give
> developers more credit. This proposed license change caused a serious
> uproar. Jim Gettys, a well-respected developer, strongly opposed this
> change to the XFree86 license, even though he's not a strong advocate of
> the GPL. Richard Stallman asked that something be worked out. An article
> at Linux Today and a discussion at Freedesktop.org show that Red Hat,
> Debian, SuSE, Gentoo, Mandrake, and OpenBSD plan to drop XFree86 if they
> switch to this new license. [...]
> At this point it's not clear what will happen, but I think it's very
> likely that the license will change (again) or the project will be forked
> (with most users switching to the fork).
> ===
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

-- 
Make everything as simple as possible, but no simpler.  -- Albert Einstein
GPG Instructions: http://www.dirac.org/linux/gpg
GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D