Subject: Re: License committee report for January 2008
From: "Alexander Terekhov" <>
Date: Mon, 28 Jan 2008 10:52:06 +0100

On Jan 27, 2008 11:42 PM, Rick Moen <> wrote:
> [Snip license-review from distribution, as being no longer appropriate.]
> Quoting Philippe Verdy (
> > If the clause is still creating incompatibilities with FreeBSD due to the
> > mandatory status, then the licence is still open-source (or free according
> > to FSF requirements with regard to possible GPL compatibility)....
> FSF have _never_ required that free-software licences be in any way
> compatible with GPL-licensed works.  I could point you to the FSF page

[forum] GPL-incompatible license
Richard Stallman
Sat, 07 Feb 2004 04:01:10 -0500

As the Debian developers have noticed, the new Xfree86 license is
incompatible with the GPL.  It has to do with the specific
requirements about including notices in manuals and documentation.
The incompatibility means that linking GPL-covered applications with
an Xlib that has this requirement would violate the GPL.

The general intention of this requirement does not conflict with the
GPL -- for instance, the revised BSD license says something basically
similar in a way that is compatible with the GPL.  The conflict comes
from the specific details of the requirement.  The revised BSD license
is less specific, so one that simply including the license along with
the program satisfies its notification requirement.

XFree86 project leaders, if you would prefer (all else being equal) to
make the license GPL-compatible, can we work together to investigate
whether you can do this and still achieve your other goals?

    Am I correct in my understanding that the problem here is the possibility
    that under current, and also previous, XFree86 licensing policy, X
    libraries are permitted to contain code under a GPL-incompatible licence,

I may be wrong, since I don't entirely know the XFree86 policies, but
this not how I thought it was.

I thought that the previous XFree86 licensing policy was to use a
specific license, which happens to be compatible with the GPL.  That
license did not pose a problem.  The problem comes from adoption of a
new license which, as far as I know, was not used in XFree86 before.

    and that by addressing the GPL-compatibility of the X library code we
    would also be addressing your concerns?

The GPL-compatibility of the license is the whole of my concern.  This
is clearly essential for Xlib, since the use of Xlib is to combine it
it with applications, but I don't think the significance is limited
to Xlib.


    XFree86 contains code from many sources and contributors, and under a
    range of licences with many copyright holders.  There has never been
    a single _specific_ licence covering everything.

Thank you, I stand corrected.

    The general preference has been for licences like the BSD and MIT
    licences.  By BSD, I mean the original BSD licence in common use when
    XFree86 began.

The original BSD license is incompatible with the GNU GPL.  I worked
for a couple of years to convince Berkeley to switch the BSD source
code to the revised BSD license.  I hope we can avoid bringing back
that sort of "advertising clause".  Its problems are cumulative at the
level of the whole system, and thus rather severe.  (Also, it is
incompatible with the GPL.)

Are there any files in Xlib that are covered by the original BSD

    So, I am surprised to hear that you were not aware of this, especially
    since the FSF web site's "Various Licenses and Comments about Them" page
    <> links to
    the online copy of the XFree86 3.3.6 COPYRIGHT document

Alas, I'm only human, and I can't keep up with all the work that would
be useful for me to do.  I remember noticing that link at one point,
and thinking "that's an unusual place to find the original BSD
license", but never thought of reading the page it pointed to.  Being
in a hurry, as always, I just moved on to the next task I had to do.
Of course, I forgot all about it until just now.

It looks now I had better fetch and read that page.

    I could see a potential case for arguing that our library licensing
    policy be tightened, i.e. become more restrictive in what licences it
    will accept, and reduce the licensing choices available to contributors
    to XFree86 libraries.

If that eliminates the GPL-incompatible licenses from Xlib, it would
eliminate the incompatibility with applications.  There might still
be incompatibilities with GPL-covered software that people might want
to use with the X server in various ways.  Freetype does not cause
a problem because its dual license provides GPL compatibility.  So it
becomes a significant question which other GPL-incompatible licenses
are really used, and where.

    I would also like to suggest that consideration should be given to
    allowing the notion of "attribution equivalency" to fall within the
    scope of GPL compatibility.

That requirement causes practical difficulties, because a person
making a change in a package--adding in a file that has this
requirement--may not know which other places such attributions must be
added to.  A person in learning enough about the code to make this
change would not have had to study everything in the package that
might contain statements giving credit to someone or other.
So he would not find it easy to follow this requirement.

Thus, although that license requirement qualifies as free software,
I think we should try to discourage it.

I'd rather not argue about the question of the mission of XFree86,
since I am not a participant in the effort.

I will say that I don't like the license change.  Keeping it out of
the client libraries prevents it from being a disaster, but using a
license incompatible with the GNU GPL is a step backwards.

    I say that XFree86 1.1 license is fully compatible with the GNU
    GPL. A compilation is NOT a derivative work.

You are right about the distinction.  However, the GNU GPL conditions
apply to creation of combined works, as well as to making derivatives
of the GPL-covered program.


"Because of their informal and diffuse nature, open source groups are
vulnerable to theft of their intellectual property. That theft, in the
form of copyright infringement, happened in this case, and Jacobsen
sought a preliminary injunction to enjoin Katzer and KAMIND's