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

[David Dawes]

On Mon, Feb 02, 2004 at 01:28:05PM +0100, Sven Luther wrote:
>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) ?

That doesn't match what I wrote exactly.

>> >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

I would like to understand what the GPL folks reasons are for being
incompatible with a licence that quite reasonably requires credit be
given to the authors.

I would also like to understand why this is suddenly a problem now
when it wasn't before.  XFree86 has always considered the original
BSD style licence acceptable, and you have all been silent about
that until now.  The FSF was obviously aware of that fact because
its links to examples of both the original and modified BSD license
are to the online copy of the XFree86 3.3.6 documentation!

>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 ? 

There are already several forks of XFree86, so it's not like there
is no choice available.  I don't buy into the whole idea that the
Open Source definition should devolve into GPL compatibility.

>> >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.

Because from the GPL point of view that is irrelevant.  The XFree86
license cannot modify the behaviour of the GPL licence, and it is
the conditions of the GPL licence (or a particular interpretation
of them) that lead to this problem.  The XFree86 license is not
infective.  It applies specifically to the licensed code, and does
not crossover into other code.

To summarise, stating that the APIs are clearly demarked does not
change the problems for those who claim that the GPL crosses dynamic
linking boundaries, because the very fact that of the claim that
the GPL crosses these boundaries make the boundaries irrelevant to
those people.

>> > <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. 

They won't be happy, because XFree86 cannot speak for the copyright holders
of GPL'd code that claim otherwise.

>> >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.

I believe that there is no problem at all.  The author of the code
gets to choose his/her licence, and I am not interested in forcing
those authors one way or the other.  There is a reason why there
was no great push from XFree86 to change the licensing of the Linux
fbdev drivers: we respect their licensing choice.  All we ask is
that others similarly respect our right to make our own licensing
choices.

>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.

If I am best placed to see the real problems, then I can state
clearly here that I don't see any real problems with the modified
licence.  I believe this to be the case in part because the modified
license is of a class that has always been acceptable for code
included in XFree86.  The modified licence does not represent a
change in XFree86 licensing policy.

David
-- 
David Dawes
developer/release engineer                      The XFree86 Project
www.XFree86.org/~dawes