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 XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86