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

------- Forwarded message -------
From: Sven Luther <[email protected]>
To: [email protected]
Subject: Re: [forum] [XFree86] Announcement: Modification to the base 
XFree86(TM) license.
Date: 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
> _______________________________________________
> XFree86 mailing list
> [email protected]
> http://XFree86.Org/mailman/listinfo/xfree86


i'm sending this to forum so google can index it.

peace and brotherhood man,

mark.