[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

XFree86 license difficulties



Since this issue has made it to slashdot [1], it may be the appropriate
time for some discussion here. I haven't seen any here yet, but I may
not have looked hard enough, so apologies in advance if this is old
news.

To summarize, an announcement [2] by David Dawes from last night indicates
that the XFree86 Project, Inc. intends to release version 4.4.0 with a
different license than the one it had before.

The project has made available a diff [3] (subject to change, one would
assume) of the changes to be applied to the source to get the new
license in the applicable files.

The actual changes to the license are detailed at
http://www.xfree86.org/legal/licenses.html.

The new license has a reworded disclaimer, and a numbered list of terms
instead of the terms simply being stated. It goes farther than the old
one in specifying that the conditions apply to binary distributions as
well as source.

The change that causes problems is the addition of the third condition:

]  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.

Several posters on slashdot and elsewhere have mentioned the similarity
between this and the old, obnoxious BSD "advertising clause":

]  3. All advertising materials mentioning features or use of this
]     software must display the following acknowledgement:
]        This product includes software developed by the University of
]        California, Berkeley and its contributors.

The FSF is quite clear [4],[5] in that they do not consider licenses with
the advertising clause to be compatible with the GPL. In addition, the
same reasons they give appear to apply also to the clause added by the
XFree86 folks. That is, one cannot distribute something under the GPL
with added restrictions like the one above quoted.

Since it appears that the new XFree86 license will be GPL-incompatible
(although still DFSG-free(?)), what issues does this raise for Debian?
Is there any chance, at this point, of convincing the XFree86 Project,
Inc. not to make those changes in the license?

As we all know, the FSF [6] considers the mere act of linking to create a
derived work for the purposes of the GPL, and claims anything linked to
a GPL'd work must also be distributable under the terms of the GPL.

If the XFree86 Project takes a similar stance (which, indeed, does not
seem to be the case right now) then anything linked to an XFree86
library must be distributable under the terms of the XFree86 license.
That case would add somewhat deeper problems than simple license
incompatibility; it would mean no program could link against both Xlib
and a GPL'd library. This would seem to make it impossible to distribute
Qt, for example.

If XFree86 does not consider linking to create a derived work which must
carry the same restrictions as those in the library, then it does not
seem there is a problem; an application linking against Qt and Xlib
could be solely under the GPL. Or am I off my rocker here?

Is it likely that the XFree86 Project will take that stance on linking?

paul

[1] http://slashdot.org/article.pl?sid=04/01/30/140205
[2] http://www.xfree86.org/pipermail/forum/2004-January/001892.html
[3] http://www.xfree86.org/license-200401.diff.gz
[4] http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLicenses
[5] http://www.gnu.org/licenses/gpl-faq.html#OrigBSD
[6] http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL

-- 
paul cannon
pik@debian.org



Reply to: