compatibility Re: License committee report for January 2008

Ernest Prabhakar ernest.prabhakar at
Mon Jan 28 19:17:54 UTC 2008

Hi Alexander,

Not sure what your point is.  The FSF -- like the OSI -- discourage  
incompatibility, and work hard to minimize it.  That is very different  
than mandating it.  In fact, given our anti-proliferation policy, we  
might actually take a harder line about incompatibility than they do.

Also, in the future, it would be helpful if you would provide a couple  
sentences of context about *why* you are positing or linking to  
someone else's words, to help minimize misunderstanding and  
confusion.  Heaven knows this list has enough of both already. :-)

-- Ernie P.
L-D moderator

On Jan 28, 2008, at 1:52 AM, Alexander Terekhov wrote:

> On Jan 27, 2008 11:42 PM, Rick Moen <rick at> wrote:
>> [Snip license-review from distribution, as being no longer  
>> appropriate.]
>> Quoting Philippe Verdy (verdy_p at
>>> 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 rms at
> 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
> license?
>    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.
> -----
> regards,
> alexander.
> --
> "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
> infringement."

More information about the License-discuss mailing list