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

[Sven Luther]

On Sun, Feb 01, 2004 at 01:03:28PM -0500, David Dawes wrote:
> On Sun, Feb 01, 2004 at 05:48:57PM +0100, Sven Luther wrote:
> >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 ?
> 
> My personal interpretation is that the "software" is the actual binaries
> containing the licensed code.  Some software includes third-party
> acknowledgments in an "about" popup.  Some in a banner message at startup,
> etc.  I think "Alternately" is self-explanatory.
> 
> Regardless of the interpretation of this condition, condition 2, to
> which I have seen no objections, requires that the full text of the
> license be reproduced in documentation and/or other materials accompanying
> the redistribution of binaries.  That has the side-effect of reproducing
> the statement in condition 3.  It seems to me that if a redistibution
> has no other third-party acknowledgements, then you're done.  If there
> are other third-party acknowledgements, then why is it a problem to also
> acknowledge XFree86 and its contributors?

So basically, you read this as : 

  1) If there are third party aknowledgements (other than of the actual
  authors of the piece of code linking with the x libraries), then the
  XFree86 Project should also be acknowledger there. This can either be
  in acknowledgement in the end-user documentation or in a
  acknowledgement place in the software itself (a about popup box, or
  something). The choice being left to the software author and/or
  distributor. Furthermore, a simple distribution of the XFree86 code in
  a CD (or other) distritbution, would fullfill this third clause by
  having the XFree86 licence document on the CD (or whatever) ?

> >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.
> 
> As I've said before, I think it is a serious flaw to the GPL that it is
> incompatible with licences that have a reasonable requirement like
> including attribution with binary distributions.  It would be a sad
> state of affairs if the "Open Source Definition" devolves into "GPL
> compability".  That pretty much makes the whole OSI irrelevant.  Maybe
> that is the point?

I don't understand you here. Sure, it is a limitation of the GPL, but
the GPL folk have their reasons for doing this, as you have of changing
the licence. The main point here is, do the XFree86 Project want to
fight it, or not. My understanding that the only result of this will be
for the GPL folk to fork the code, or use an already forked one, which
is not what the XFree86 Project intent here, or does it ? 

> >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.
> 
> That is something for those who apply the GPL to their work to decide.

Yep, and they claim that the GPL crosses dynamic linking boundaries.

> Personally, I believe it to be a non-issue based on what I've seen and
> read about the nature of APIs.  The APIs for the XFree86 client-side
> libraries are clearly demarked.

Why then, not explicitly write it down in the licence or an
interpretation document in it, and make this whole issue moot, as you
said ? Without you being formal about this, the rest of the world cannot
be sure this is your interpretation, nor that this will remain the
interpretation in the future.

> > <stuff skipped>
> 
> I am not convinced that it is a real issue, and judging from things I've
> read here and elsewhere, I am not alone in this opinion.

So, if it is not a real issue, let the XFree86 Project make a statement
about this, and clarify their position on this, and everyone will be
happy. 

> >5) What about hardware drivers ?
> >
> > <stuff skipped>
> >
> >So, this is basically no problem, if people on both side seek a
> >compromise, and act in good faith.
> 
> This is a non-issue too.  We've already had some authoritative comment
> about data and algorithms not being copyrightable.  If one person (XFree86
> developer, fbdev developer, or someone else) wants to copy portions of
> someone else's code (XFree86 developer, fbdev developer, or someone
> else), then they either need to abide by the author's licensing conditions,
> or contact the author for permission to copy portions of the code under
> different conditions.
> 
> We are only hearing that this is an issue now because it is possible
> (actually it has always been possible) that an fbdev developer may have
> to contact an XFree86 developer for permission to use his/her code
> because of licensing issues.  How can this be unreasonable when it has
> always been necessary in the reverse case, which nobody appears to have
> felt was unreasonable?

Did i not say here that this is basically no problem, and only a point
of negotiation and compromise ? I believe that this would be the perfect
timing to achieve some more formal resolution to this, and have both the
fbdev project release their stuff under a dual licencing situation, and
the XFree86 project clearly state that they will not modify the licence
of the drivers in such a way as to make it GPL incompatible.

As said, it is not a problem, but an opportunity.

> >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.
> 
> I'd like to see some stronger evidence that the supposed problems are in
> fact real problems.

Well, you are, i think, best placed to say what the real problems are,
since the rest of the world did never really get a followup of the
dispute that happened last year, nor of the fork that followed.

But still, i will see if i can contact some persons of the GPL is
incompatible camp, and have them tell me what they understand about
this. 

Friendly,

Sven Luther