[forum] [XFree86] Announcement: Modification to the base XFree86(TM) license.
Sven Luther
forum@xfree86.org
Mon, 2 Feb 2004 17:46:27 +0100
On Mon, Feb 02, 2004 at 10:10:47AM -0500, David Dawes wrote:
> 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:
> >> 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.
See, there clearly is need for clarification of what exactly is meant by
this third clause, and what the exact effects will be.
> 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.
Well, they have some explanation about this, and it has to do with
size of such acknowledgement becoming immensely huge over time. How
would you feel if every past XFree86 Contributor now decided to want to
have their full name in the acknowledgement ? How would this be
practical for a in-software about popup ? And how much pages would it
add to end-user documentation ?
Also, there is a reason for the library linking boundary crossing of the
GPL, it has to do with making sure someone doesn't workaround the GPL by
providing a proprietary wrapper around the library which contains
modifications and such. The second reason is to make sure a GPLed piece
of software is always allowed to have the same right they have to the
software then the libraries linked to it, in order to fix bugs in the
library and to maybe port it to new arches, tool chains, etc.
> 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!
My understanding of this is that this is a false statement. The XFree86
licence had not this third clause in the past, and altough it may have
been acceptable to add such code to XFree86, i belive this didn't happen
much, or at least not in place where it caused problems.
But let's come back to the real problem at hand.
Suppose i write a piece of software, let's say a graphical mail client
or something such. Is it your intentions or not that this graphical mail
client, by virtue of linking with the xlibs from the XFree86 Project,
needs to show an acknowledgement to the XFree86 Project in its about box
or end-user 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.
It is not a problem of GPL compatibility, only that many GPLed programs
which used to link with the XFree86 libraries cannot do so anymore. It
would be quite easy to ammend the 3) requirement so that this is not a
problem anymore, you only would need to say :
This requirement is only valable for modified works of code covered by
this XFree86 licence, and in particular does not apply to programs
linked with the the XFreee86 libraries.
Or some legalese definition of the kind. Or alternatively state that you
will not put the XFree86 libraries under this new licence, but keep
using the old one for the libraries.
This would still allow you to get the acknowledgement from people
shipping the server and other XFree86 programs, and you could also say
that even if the XFree86 libraries are not subject to the requirement of
putting the acknowledgement somewhere, you would like that they do. And
if what is really the aim is to get proper credit, i belive this would
serve quite well.
And if the GPL people still have a problem with that, its their problem.
Also, notice about the fork thing. Until now, all the major linux
distros still distributed the XFree86 code base, with some modifications
and such. But if this problem is not solved, i can guarantee you that
all the linux distros will stop distributing the XFree86 code base,
either fork at 4.3, at 4.4RC2 or something previous to the licence
change, or use an already established alternative.
> >> 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.
But your new aknowledgement requirement does. And if it is your opinion
that it doesn't, then say it so.
> 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.
Yep, but it shows good faith on your part, and puts the problem on the
GPLs said quite clearly.
> 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.
Then why did Andrew complain about not being able to get the matroxfb
changes back ? And what if some driver code is copyrighted by XFree86 ?
Will it then use the new licence, or not ?
> >> >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.
No, not in the policy, but it does in practice. Also, you don't clearly
respond to the interogation about the motication of this licencing
change, and altough i have no idea of what is going on, i have some
guesses i can make.
Friendly,
Sven Luther