[forum] [XFree86] Announcement: Modification to the base XFree86(TM) license.

Sven Luther forum@xfree86.org
Sun, 1 Feb 2004 17:48:57 +0100


On Thu, Jan 29, 2004 at 11:58:38AM -0500, David Dawes wrote:
> Announcement: Modification to the base XFree86(TM) license.

Hello,

As discussed with David, i am taking discussion concerning the
problematics aspects of this licence change here. I think i understand
somewhat the reasons behind the licence change, but i wonder if all the
consequences of it have been thought of before doing the change.

Also, there are some confusing wording in one of the clause, which i
believe would best be clarified as to what the interpretations of them
by the XFree86 project are.

Also, first notice that my position is actually quite inconfortable,
since i am here mentioning the concerns of wider community and criticize
the new xfree86 licencing, in other forums, i usually do the opposite,
and take xfree86 side on this, so please do not react badly, and let's
have a rationale conversation about this, so that things can all be
resolved to everyone's satisfaction.

1) Possible confusion.

The following clause is the most problematic of all the licence, and as
such it would be nice to clarify it before starting a polemic about it.

 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.

Ok, what does this mean exactly ? If there is a end-user documentation,
but it contains no third-party acknowledgement part, do you still have
to put the acknowledgement or not ? Also, is the choice between putting
the acknowledgement in the end-user documentation or the software a
choice that is free to make, or is the second an alternative only if
there is no enduser documentation. And what do you mean by in the
software itself ? If this software is a linux distribution for example,
would a file on the CD which is copied to the disk be enough ?

2) GPL incompatibility.

This selfsame clause is also the one which clashes with the clasue 6) of
the GPL.

 6. Each time you redistribute the Program (or any work based on the
    Program), the recipient automatically receives a license from the
    original licensor to copy, distribute or modify the Program subject to
    these terms and conditions.  You may not impose any further 
    restrictions on the recipients' exercise of the rights granted herein.
    You are not responsible for enforcing compliance by third parties to
    this License.

And in the 'you may not impose any further restrictions' part. Since the
GPL does not force you to add acknowledgement in the end-user
distribution, then the clause 3) of the 1.1 XFree86 licence is indeed a
further restriction, which cause an incompatibility with GPLed software.
Now this is again modulated with the exact interpretation that is given
in the above point.

3) Where is the derivative work boundary ? 

The problem is further muddled by the place where the boundary for
something being considered a derivative work. The GPL, contrary to the
LGPL, considers that everything linked with a another binary is a
derivative work of it. I believe that this is mostly done so that
someone could not modify or extend a GPLed library by putting the
modified work in a wrapper or in the binary itself, which the LGPL
allows for dynamic linking, and for static linking with some additional
work. In our case, the problem is the opposite, since the XFree86
libraries may impose their further restrictions to the GPLed code, even
if it is the GPL here who cross the boundary.

4) What files are affected by the licence change, which one will be, and
is it problematic.

Well, if the licence of the XFree86 server and other programs is
changed to be incompatible with the GPL, this is not per se
problematic. The problem which can arise have upto now been mentioned in
two places : the XFree86 libraries, and the hardware driver code. Let's
speak about the libraries here, since the driver code problem is of
another nature.

As seen in the previous section, the actual problem is in the GPLed
software which link to the XFree86 libraries. First a question here, so
things are clarified. Is it the intention of the XFree86 Project that
every such program that links with those libraries does provide an
aknowledgement, as opposed to only modifications of the library ? If it is,
then well, the GPL incompatibility is there by intention, but will
probably not be accepted by the rest of the community, and a fork of at
least the libraries will happen (if it has not already), or at least
this fork will be consumed, and i believe that XFree86 will loose the
battle for the distributions and users mindshare, which is something
that i doubt is in the XFree86 Project best interest.

Now, if this is not the case, it can be solved in various ways. One way
would be to declare that the files affected by the XFree86 licence
change will not apply to those libraries, this is probably the easiest
thing to solve this problem, and people wanting to reuse code from the
rest of the XFree86 code base, well they either may reach an agreement
with the respective copyright holder, or not use it, but it will not be
as problematic as the library issue is.

Another pair of solutions, but i am no lawyer and it should be double
checked, would be to either : 

  a) change the clause 3) in such a form that it does no more conflict
  with the GPL. I belive that there are ways to give the aknowledgement
  without GPL compatibility problems, or maybe make the enduser
  aknoledgement not obligatory, but something considered polite or such.
  And i have recently been told by the debian-legal folk that "we should
  be polite to RMS" with regard some emacs file distribution issues,
  which should also play here.

or

  b) Clarify what we consider a derivative work, and make it clear that
  the further restrictions is not supposed to cross the
  library-application dynamic linking barrier. Or maybe add a phrase to
  the effect that if a GPLed application or library is linked with the
  XFree86 libraries, then the clause 3), which would conflict with the
  GPL is not needed to be enforced, but we would be really happy if it
  still does, or something such. Again with the caveat of clarification
  with the clause 3).

Notice that this is informal speak, and i would be happy to propose a
more formal wording of this in case it is needed, if we decide to pursue
this solution.

If that is done, then i believe all this mini-crising that has been
brewing since the past days, will fall to the side, and everyone will be
happy.
  
5) What about hardware drivers ?

Now let's come back quickly to the problem of the hardware drivers,
which are mostly the graphic chip drivers, but could also be concerning
motherboard chipsets (like the agpgart stuff) or input drivers. This is
a critical problem not only for XFree86, but also for all projects
which touch these areas, among them most prominently the linux fbdev
project.

Now, mostly the information that goes from the XFree86 project in these
areas to the fbdev driver is simple register level information which cannot
be copyrighted anyway, and would cause less of a problem if the hardware
companies would not retain this information, and thus actively oppose in
some way the development of free alternatives.

This is an area which is not problematic in the same area in which the
library situation is, since mostly the drivers are copyrighted by their
own authors, and the licence has not been changed. 

There has been some critics that the code can flow only in one side (X
-> linux fbdev) because of the linux GPL licence, but this is not the
case, and something where cooperation could solve all perceived
problems. Ideally, the code in question on the X side would remain on
the old X licence, and the linux fbdev code would be on a dual GPL-old X
licence. Or the fbdev folks may give changes and improvement back to
XFree86 under the old X licence, or whatever. Problematic is naturally
old code where lot of people contributed, and where some of those
contributors disappeared from the circulation.

So, this is basically no problem, if people on both side seek a
compromise, and act in good faith.

Ok, that is all i had to said, i hope i have properly analysed the
problems that result from the licence change, and showed path that could
lead to the resolution of said problems.

Friendly,

Sven Luther