The real problem with the XFree86 license and a possible solution

Greetings.

We realize that this has become a tiresome topic for David Dawes and
the other XFree86 developers but we sincerely hope you will take the
time to consider our comments.  This is our first posting on the
matter.  We spent hours researching the issue and reading previous
postings in an attempt to not just rehash what has already been said.

After reading many arguments on both sides we still did not see any
clear explanations about the perceived specific problem other than
general references about how the new license is GPL incompatible.

I believe we may have a solution to the license issues that are
causing so much controversy and concern.

We are working on a project that will involve the re-distribution of
binary copies of X-windows along with other free software.  When we
first read the announcement about the license change and read the new
license, we could not understand why there was such a strong reaction
from major Linux vendors.  On the surface it did not seem to change
anything since we expect to always give credit where it is due anyway.
However, with the split into XFree86 and X.org it prompted us to
research it further and after reading the new license several more
times and re-thinking it through, a potentially serious problem stood
out.

The problem
===========

In an earlier posting, John Bradford summarized three big debates on
the issue:

> On Tue, Mar 09, 2004 at 09:52:32AM +0000, John Bradford wrote:
> ...there are three big debates happening:
>  1) What this means for GPL-licensed software who reuses X code or links
>     dynamically or statically to X libraries
>  2) Whether the credits clause is a good idea for the long-term viability
>     of the Project or not
>  3) The problems that both the GPL issue and the credits clause raise for
>      distributors who wish to package XFree86 for their distribution


We feel that the key issue is number 3 since the only change is the
credits clause and this is where our concern lies.  First, let me say
that we have no problem with your apparent motive of just wanting the
XFree86 projects work credited even in binary only releases, but there
is a serious problem with your approach.

<license clauses>
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the
   distribution, and in the same place and form as other copyright,
   license and disclaimer information.

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.
</license clauses>

We believe the entire problem lies in the two statements,

"in the same place and form as other copyright, license and disclaimer
information"

and

"in the same form and location as other such third-party
acknowledgments"

At first glance this sounds like a reasonable request.  However, as a
software distributer, it is likely to be impossible to guarantee
compliance.  With the thousands of X applications out there, a free
software distributer cannot guarantee that every application adhears
to this requirement.

For example:
    If we attempt to include all documentation and licenses in a
    common place such as /usr/share/doc/appname, and an application
    puts it's third party acknowledgments in a pop up window that does
    not include XFree86, then even if we add an XFree86 acknowledgment
    in a file in the doc directory, by the wording in the XFree86
    license, it appears we would be in violation because that is not
    the same location or in the same form as other third party
    acknowledgments for that application.

With somewhere between 8,000 and 10,000 (to the best of our knowledge)
free applications to choose from to include in a software
distribution, the probability is very high of having many such
situations.

Your FAQ about the license states:

"To avoid issues with application programs such as KDE and GNOME and
other X-based applications, that are licensed under the GPL, the 1.1
license is not being applied to client side libraries."

This is essentially saying that all distributions including software
under the GPL or similar license that is linked to XFree86 libraries
and includes XFree86 headers will be in violation of the copyright,
that you realize this, and that you are choosing at your own
discretion when and where to enforce it.

I think it is obvious that this is a risk that many or most
distributers are not willing to take regardless of your current good
intentions.  A distributer must depend on what the license actually
says or all their work can turn into a boondoggle down the road.

The solution
============

We feel that the best solution is to just word it like the simple
FreeBSD or Apache license and remove the requirement of where the
credits must reside as long as they are included.  

If on the other hand you were to instead try to add exclusions in the
license for GPL and similar licensed software, you would also have to
consider that most applications linked with X libraries also include
related headers.  So there will nearly always be code from the XFree86
project included in the binary even when it is only dynamically linked
with the libraries.  This would also have to be addressed in the
license as well, making it even more complex to deal with.

The FreeBSD license requires attribution even with binary distribution
and the project has been very successful over many years without the
controversy, resistance, and risk of infringement for distributers.
If your motivation is only author attribution as you say, is there any
reason that would not be sufficient?

=============

Ramifications of the XFree86/X.org split
========================================

If you stick with your current new license and cause the X.org branch
to become the mainstream X branch, we are highly concerned about the
direction of free software as a whole.  A split like this has the
potential of becoming incompatible at the API level and that can
affect the desktop and server market of all free and commercial Unix
branches world wide.

XFree86 has maintained very good stability and robustness until now
but, considering some of the big names involved in the X.org branch,
we are concerned that that may not continue to be the case.

  We have read articles, for example of how RedHat butchered some of
  their distributions of KDE and the KDE developers jumped in and
  fixed a bunch of bugs in it to protect their own reputation because
  of Redhats dominance in the market.

  HP came into open source software kicking and screaming, resisting
  it as long as they could.  It was only a few years ago that they
  completely refused to provide any information for writing open
  source drivers for our printer, which turned out to use a
  proprietary protocol, after lying to us and saying it was open and
  they would send us the PCL information on the phone before we bought
  it, and tried to force us to pay Microsoft their cut to use it.

  Sun has made some contributions to open source in recent years, like
  by buying StarOffice and later releasing it as OpenOffice, but we
  have not been impressed at all with the quality, robustness, and
  license restrictions of their own code when it comes to Java for
  example.

If the X.org project goes off in their own direction and becomes
unstable and/or API incompatible, and XFree86 has license issues that
block it from being distributed in the main stream where only those
advanced enough to download and install it on their own (which is a
tiny percent of the user base) use it, the whole computer user
community is going to suffer greatly.