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

[Sven Luther]

On Mon, Feb 02, 2004 at 12:14:27PM -0500, David Dawes wrote:
> On Mon, Feb 02, 2004 at 05:46:27PM +0100, Sven Luther wrote:
> 
> >> 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 ?
> 
> I would have no problem with that.  The XFree86 release notes now
> has a credits section with the names of everyone who contributed
> to a particular release.  I would be very happy to extend that to
> all past releases.

Well, notice the difference between a release note, which is just a
file on a CD or on the disk, and hardly ever get printed, to a end-user
documentation which is in printed form, or the limited space in the
about popup window.

> >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.
> 
> The GPL cuts two ways.  It achieves such goals at the cost of
> limitations in how GPL'd code may be used.  It is unreasonable to
> expect the benefits without acknowledging and accepting the tradeoffs
> associated with that.  Why try to force others to change their
> licences just so that you can avoid those tradeoffs?

Well, i am not forcing you, i am only trying to convince you to take an
action which i believe would be in the best interest of the XFree86
project.

> >> 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.
> 
> It did and does happen.  Whether you were aware of it or not is
> another matter.  The licence has been displayed in our copyright/license
> document, which is part of the XFree86 user documentation, for some
> time.  It was not hidden, and as I said, even the FSF's licence
> web pages pointed to it.

And, where files of the libraries affected by this licence ? This is the
problem at hand here.

> So your complaint is that it is a matter of degree?  It's OK for
> this licence to apply to small amounts of code, but not large
> amounts?  The modified license only applies to a relatively small
> percentage of the whole source tree as it is.  Where do you draw
> the line?

No, but it may well happen that licence conflicts may have been hidden
or missed true error. Once such problems are found and publicly exposed,
you cannot ignore them anymore.

> >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 ? 
> 
> Not by virtue of linking with the xlibs, of course not.  If the
> xlibs were covered by the modified licence, whoever distributed
> those xlibs would need to make an appropriate acknowledgement.

Ok, so since this is clarified, please tell that in the licence
explicitly. It may not solve the GPL problem, but it may be a good think
to claim that explicitly.

Next step then. It is the claim of the GPL folk that this licence is
incompatible with the GPL, and in particular, if this licence does apply
to the X libraries (i think 15 or so files are affected, libs, include
files, and some manpages). You may disagree with that, but i think you
don't disagree that this is effectively what the GPL people claim, even
if you say it is a problem in the GPL.

Now, this does mean that, due to this licence change, an existing
application which was licenced under the GPL cannot anymore be linked
with the X library you distribute. Do you think this is a bad thing, and
would need to be solved, or do you think that it is the fault of the
GPL, and you don't really care ? 

> >> >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. 
> 
> Why is it necessary to state the obvious?

Because it may be obvious to you, but others may disagree or have
another interpretation, or maybe unsure of your interpretation and in
doubt take it to mean other things that whats is meant. 

In all matters legal, it is best to avoid any possible confusion. I
guess your legal advertizer which helped you draft this licence will
tell you the same thing.

> >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.
> 
> And your point is?



> >> >> 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.
> 
> I said so.  How many times to I have to say it?

Say it in an official way, quite next to the licence. Not on some random
mailing list.

> >> 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 ? 
> 
> Did you see this issue ever come up before now? I assume that he,
> like others, respected the licence and did not even consider raising
> it as an issue.  After all, why would someone GPL their code if
> their intention was not that their code be subject to those
> conditions? That is the assumption that I would start from.

David. Remember what you told me last year (or was it already two years
ago) that it would be good to have someone who was more involved with
the fbdev people, so if this was meant seriously, then hear me now.

It is _not_ a problem, but an oportunity, an oportunity to have the
fbdve driver writers and the XFree86 driver writers work together more
closely, and it is often the case that the same person will be working
on both code base anyway. I hear that this is already the case.

> >> >> >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.
> 
> The licensing of some files has changed.  Why is it a problem now, and
> not with files that had this style of licence before?

Again, if it was not a problem, it was by ignorance, but now that this
matter has come to light, it cannot be ignored anymore. Ask your legal
advicer about this issue if you don't believe me.

Friendly,

Sven Luther